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

Activity

1. juliusmarminge commented on Oct 1, 2026

   

   juliusmarminge

   on Oct 1, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   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:

   t3code/scripts/install.sh

   Lines 219 to 221 in 5cc99e1

   	step "Setting up the t3 command..."
   	mkdir -p "$bin_dir"
   	ln -sfn "${target_dir}/t3" "${bin_dir}/t3"

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

   t3code/apps/server/src/cli/update.ts

   Lines 539 to 544 in 5cc99e1

   	const launchedAs = (yield* HostProcessIsExecutable) ? yield* resolveLauncherPath : undefined;
   	const repointed = yield* repointLauncher({
   	launchedAs,
   	versionsDir: path.dirname(runtime.versionDir),
   	targetEntryPath: runtime.entryPath,
   	});

   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:

   t3code/apps/server/src/cloud/selfUpdate.ts

   Lines 313 to 332 in 5cc99e1

   	yield* reportProgress("installing");
   	const updateId = yield* Effect.uninterruptible(
   	launcher.requestUpdate({ targetVersion, dbPath: serverConfig.dbPath }).pipe(
   	Effect.mapError((error) =>
   	failWith(
   	error._tag === "ServiceLauncherRejectedError"
   	? error.reason
   	: "Could not ask the service launcher to activate the prepared update.",
   	error,
   	),
   	),
   	Effect.tap(() => onHandoffAccepted()),
   	),
   	);
   	yield* Effect.logInfo("Server update prepared; handing off to the service launcher.", {
   	updateId,
   	targetVersion,
   	runtimePath: paths.entryPath,
   	});

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

   t3code/apps/server/src/serviceLauncher.ts

   Lines 553 to 563 in 5cc99e1

   	const committed = terminalUpdate({ pending, status: "committed" });
   	const next: ServiceState = {
   	...this.#state,
   	activeVersion: pending.targetVersion,
   	update: committed,
   	};
   	await writeServiceState(this.#statePath, next);
   	this.#state = next;
   	child.role = "active";
   	await discardDatabaseBackup(this.#baseDir, committed.id).catch(() => undefined);
   	await sendMessage(child.process, { type: "committed", updateId: committed.id });

   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:

   t3code/apps/server/src/serverRuntimeStartup.ts

   Lines 1046 to 1048 in 5cc99e1

   	// This is the prepared boundary. Every dependency has been acquired and
   	// every runtime root has confirmed that it is parked before this request.
   	const updateOutcome = yield* launcher.prepareTrial;

   Related, but not duplicates

   • Server-update preflight blocks recovery, but t3 service update reports success from a stale CLI that shadows the updated one #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. fix(server): launcher preflight and service install explain which t3 ran #13804 (open PR) improves the recovery message for Server-update preflight blocks recovery, but t3 service update reports success from a stale CLI that shadows the updated one #13239 but doesn't move this symlink.
   • fix(install): launch t3 by absolute path #13794 (open PR) proposes replacing the installer symlink with an absolute-path wrapper. The installer still uses ln -sfn today.
   • fix(server): t3 run from a T3 terminal no longer trips on the service's launcher context #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.

   ❤️React with ❤️1Reacted by Rohit Girdhar
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 1, 2026
3. alexisbeaulieu97 commented on Oct 9, 2026

   

   alexisbeaulieu97

   on Oct 9, 2026

   Last edited by alexisbeaulieu97

   More actions

   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.