[Bug]: Remote update fails on Windows hosts with "launcher speaks protocol 3" and only Linux/macOS fix steps #34435

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On a Windows host, run the server under t3.exe __service-launcher. Windows has no t3 service install, so here a Task Scheduler task starts it. The launcher comes from a runtime that predates fix(server): a remote update points the service unit at the runtime it committed #19652, for example .t3\runtime\versions\0.1.7-nightly.20261101.4048\t3.exe. The host advertises serverSelfUpdate: boot-service, and earlier remote updates from the desktop app work (0.1.9-nightly.20261110.4491 → 0.1.9-nightly.20261111.4515 committed normally).
2. From another machine's desktop app, update that host to 0.1.10-nightly.20261111.4529.

Expected behavior

Either the update applies, or the error gives steps that work on Windows. After that one fix, later protocol bumps should not strand the host again.

Actual behavior

Every attempt, Retry included, fails right away with:

Server update failed: The installed service launcher speaks protocol 3, but [email protected] requires protocol 4. On the server machine, install this exact CLI: `curl -fsSL https://t3.codes/install.sh | T3CODE_VERSION=0.1.10-nightly.20261111.4529 sh`. Check that `t3 --version` prints 0.1.10-nightly.20261111.4529 and that `which -a t3` lists no older t3 (such as an npm or nvm install) first, then run `~/.local/bin/t3 service install` (the installer's default path). ...

On a Windows host there are two problems:

1. The steps are Linux/macOS only. curl | sh, which -a and ~/.local/bin/t3 service install don't apply. t3 service install reports that only Linux with systemd and macOS with launchd are supported. The message should be platform-aware, or say plainly that Windows hosts need a manual launcher swap.
2. The Windows launcher never moves forward on its own. fix(server): a remote update points the service unit at the runtime it committed #19652 fixes this on Linux and macOS by repointing the systemd unit or launchd plist after each committed update. serviceUnitFromEnvironment only knows those two managers, so on Windows the launcher binary stays at whatever version first started it. Child servers update fine, but the next launcher protocol bump refuses every remote update until someone changes the host by hand. The desktop app shows this as a "failed" update with a Retry button that can never succeed.

Possible directions: a supported way to upgrade the launcher on Windows (for example t3 update --yes documented for Windows hosts), or a launcher that hands off to the committed runtime's own launcher at its next restart when that runtime has a newer protocol.

Impact

Major degradation or frequent failure

Version or commit

Target 0.1.10-nightly.20261111.4529 (d2c2595). Host launcher from 0.1.7-nightly.20261101.4048 and 0.1.6, serving 0.1.9-nightly.20261111.4515.

Environment

Windows 11, server-only hosts with the release win32-x64 zip; updates sent from the Linux and Windows desktop apps (nightly channel).

Workaround

On the host: stop the task and its __service-launcher / serve processes and back up userdata\statev2.sqlite*. Extract t3-<version>-win32-x64.zip into .t3\runtime\versions\<version>\ and write .install-complete. Set runtime\service-state.json to {"protocol":3,"activeVersion":"<version>"}, then start the launcher from that version's t3.exe. To keep later protocol bumps from repeating this, the task's script now reads activeVersion from service-state.json at each start and runs that runtime's launcher. That mirrors #19652's unit repoint by hand.