Remote server self-update leaves the installed t3 CLI pointing at the previous runtime#14609

Triage

Thanks for the detailed write-up, @rohitgirdhar. The before and after readlink output and the service log lines made this easy to trace. I confirmed it on main at 5cc99e1c23980d7995a13c47f969b47cb68ed1be. The release commit you cited (148e6deea046658639aae9fef5b349781cec39d1) is an ancestor of that commit, and this code path hasn't changed since, so it isn't already fixed.

What's happening

The standalone installer creates ~/.local/bin/t3 (or the same name under T3CODE_INSTALL_BIN_DIR) as a symlink into this home's runtime tree:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/scripts/install.sh#L219-L221

Only t3 update repoints that symlink, and it does so after the new runtime is installed:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/cli/update.ts#L539-L544

The desktop app's Update server action never calls that step. The running server downloads and preflights the target, then hands it to the service launcher:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/cloud/selfUpdate.ts#L313-L332

The launcher commits activeVersion in service-state.json and starts that runtime. It never touches ~/.local/bin/t3:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/serviceLauncher.ts#L553-L563

Keeping the stable launcher separate is intentional, because it lets a failed trial roll back (server-updates.md). The side effect is that after a remote update the CLI symlink stays on the old runtime while /.well-known/t3/environment reports the new server. That's the mismatch you saw.

Repointing from the handoff in selfUpdate.ts wouldn't work. That code runs in the outgoing server, which wasn't started through ~/.local/bin/t3, and it runs before the trial commits, so it could move t3 onto a version that later rolls back. The new runtime only knows the update stuck once prepareTrial returns committed:

https://github.com/pingdotgg/t3code/blob/5cc99e1c23980d7995a13c47f969b47cb68ed1be/apps/server/src/serverRuntimeStartup.ts#L1046-L1048

Related, but not duplicates

• #13239 (open issue): there, an older t3 earlier on PATH shadowed the intended install. Here the installer's own symlink is the one on PATH, and it gets left behind. #13804 (open PR) improves the recovery message for #13239 but doesn't move this symlink.
• #13794 (open PR) proposes replacing the installer symlink with an absolute-path wrapper. The installer still uses ln -sfn today.
• #14263 (open PR) is about a service environment variable leaking into terminals. It's unrelated.

Likely fix

Once the new runtime's prepareTrial returns committed, it should repoint any user launcher this home owns. That means checking ~/.local/bin (or T3CODE_INSTALL_BIN_DIR) and PATH, using the existing ownership rule: only symlinks, or a Windows t3.cmd shim, that point into this home's runtime/versions. A missing launcher is normal on desktop-managed and npx hosts, and a failed rewrite should only be logged, never roll back an update that has already committed. The systemd or launchd unit and the stable launcher can stay on the local t3 update and t3 service install path.

Until that lands, your workaround is right: point the symlink at ~/.t3/runtime/versions/<activeVersion>/t3. Running t3 update <activeVersion> on the host also works, but it rewrites the service unit and restarts the service when you confirm.

Another consequence beyond the version mismatch: pairing links created by the stale CLI are rejected. After updating from the desktop app to 0.0.46-nightly.20261009.2873, ~/.local/bin/t3 was still 0.0.44, and t3 auth pairing create from it produced links the server refused. The client only showed "The environment credential is invalid." Running ~/.t3/runtime/versions/<active>/t3 auth pairing create worked.

One more consequence now that 0.1.0 is out: the stale t3 can write to a different database than the one the server reads.

0.1.x keeps its data in userdata/statev2.sqlite, while pre-0.1.0 builds use userdata/state.sqlite, and the t3 auth … commands open the database directly. After Update server moves a background service from 0.0.x to 0.1.x, the t3 left on PATH still reads and writes the old database. From the code:

• t3 auth pairing create prints a link the server rejects. That's the same split as #15492, just reached through the stale link instead of npx.
• t3 auth session revoke reports success, but the session stays valid in statev2.sqlite.
• t3 auth session list and t3 auth pairing list show the old database.

It's still the case on main at 5b72385. cloud/selfUpdate.ts hands off to the launcher, and #handlePrepared in serviceLauncher.ts only commits activeVersion. After that, nothing after prepareTrial in serverRuntimeStartup.ts touches the link.

Until a fix lands, the workaround is to run ~/.t3/runtime/versions/<active version>/t3 …, or to repoint ~/.local/bin/t3 to it. We hit this while moving our hosted machines to 0.1.0 and patched it downstream for now.

Existing PR #14875 covers this exact report: after a fresh managed update commits, it reconciles this home’s owned CLI launcher links. Its verification includes before/after real-launcher IPC transcripts and focused regression tests; GitCafe currently reports 30 successful checks. Linked the PR here rather than opening a duplicate. The PR remains unmerged, and this issue stays open. This triage pass checked current main at 89fe509232 and the existing PR diff; it did not repeat the installed-service reproduction.

Two more cases, one of them worse than a version mismatch:

• On a Raspberry Pi 5 (Debian 13 arm64, systemd user service), t3 didn't run at all on Nov 2. Its symlink pointed into ~/.t3/runtime/versions/ at a version that had been deleted. I don't know which update path left it there. Once the old runtime is gone, the stale link breaks instead of running the old CLI.
• On a Mac (desktop app), on Oct 12, Settings → Install CLI refused with "Another t3 at ~/.local/bin/t3 runs first". That file was T3's own symlink to ~/.t3/runtime/versions/0.0.45/t3, left from an earlier install. A second stale t3 link sat in another PATH folder. Install only worked after I removed both.

For the second case, as far as I can tell from #25417's head, the desktop app still only claims a link that carries its shim marker. A link into the same home's runtime/versions still counts as "another t3", so Install would still refuse there.