In-app server update leaves the t3 CLI launcher on the old version #25724

What happened

On a Linux box running T3 Code as a systemd background service, t3 doctor failed with:

ERROR
  Unknown command "doctor". Use "t3 --help" for commands or an explicit path such as "t3 ./my-project" for a new directory.

The same command works on the user's Mac. The server on the Linux box was already on the latest nightly. The user keeps it current with the update button in the app, and never ran t3 update there.

Diagnosis

The in-app server update moves the background service to the new version but never repoints the t3 launcher on PATH. The launcher stays on the version from the last time the user ran the installer or t3 update.

• repointLauncher has a single caller, t3 update (apps/server/src/cli/update.ts:473). The self-update path in apps/server/src/cloud/selfUpdate.ts hands off to the service launcher and returns. Neither side touches ~/.local/bin/t3.
• The runtime prune keeps any version a launcher points at (pinnedRuntime.ts:561). The stale runtime is never removed, so the drift never resolves on its own.
• t3 service status detects the mismatch ("newer than this t3@... CLI", "Next: Run t3 update <version> to match it"), but users only see that if they run it.

On this machine the launcher was 13 days and two minor versions behind the service. t3 doctor shipped in between (#19436), and so did a newer triage playbook, which meant t3 triage also ran the outdated one.

The docs don't say the in-app update leaves t3 behind. docs/user/updating.md says the sidebar update button "updates every connected machine in one step", and install.md and the web UI's database storage notice both point users at t3 doctor.

If leaving the launcher alone is intentional, because a server shouldn't rewrite a symlink on the user's PATH, then the update flow should probably tell the user to run t3 update <version> afterwards.

Steps to reproduce

1. On Linux, install with the install script so ~/.local/bin/t3 links into ~/.t3/runtime/versions/<A>/t3, then run t3 service install.
2. Once a newer release <B> is out, update the server from the app (sidebar update button or Update server).
3. t3 service status reports the service on <B>, newer than the CLI.
4. readlink -f $(which t3) still points at <A>, and t3 --version prints <A>.
5. Any command added after <A>, such as t3 doctor on a build older than 0.1.1, fails with Unknown command.

Version

Service: 0.1.3-nightly.20261026.3740 (updated from the app, previously 0.1.3-nightly.20261026.3726). CLI launcher: 0.0.46-nightly.20261013.3053.

Environment

Linux x64 (kernel 7.0.0-38-generic), Node v26.8.2, systemd user service, nightly channel.

Evidence

$ readlink -f $(which t3)
~/.t3/runtime/versions/0.0.46-nightly.20261013.3053/t3

$ t3 service status
T3 Code service
  Status: installed · t3@0.1.3-nightly.20261026.3740 (newer than this t3@0.0.46-nightly.20261013.3053 CLI)
  Next: Run `t3 update 0.1.3-nightly.20261026.3740` to match it, or pass `--allow-downgrade` to `t3 service install` explicitly.

# boot-service.log
[01:45:58.535] INFO: Server update prepared; handing off to the service launcher.
  { targetVersion: '0.1.3-nightly.20261026.3740', runtimePath: '~/.t3/runtime/versions/0.1.3-nightly.20261026.3740/t3' }
[01:46:24.446] INFO: Removed unused t3 runtimes.
  { versions: [ '0.1.3-nightly.20261026.3710' ] }

# ~/.t3/runtime/versions after the update
0.0.46-nightly.20261013.3053   <- kept because the launcher points here
0.1.3-nightly.20261026.3726
0.1.3-nightly.20261026.3740

Related issues

#12020 is also about the service launcher not being replaced, but that covered the 0.0.42 runtime layout change and is closed. I found no open issue about the PATH launcher lagging the service after an in-app update.

Fix applied or workaround

Ran t3 update 0.1.3-nightly.20261026.3740. It repointed ~/.local/bin/t3 and left the service running because it was already on that version. t3 doctor works afterwards.

Filed by

Claude Code (claude-opus-5-5) via t3 triage