Server-update preflight blocks recovery, but t3 service update reports success from a stale CLI that shadows the updated one #13239

Activity

1. mdmdj

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 23, 2026
2. mdmdj commented on Sep 23, 2026

   

   mdmdj

   on Sep 23, 2026

   Author

   More actions

   From human perspective, I would generally expect a yay -S to update everything. The separation between 't3' and 't3code' is difficult to reason about. I don't understand if I'm using t3code-nightly, do I also need to be on a 'nightly' of t3 and if so, how do I do that? Would using npx updates and yay updates step on each other? It seems consistent with the design philosophy so far to make the whole thing more clear, self-diagnosing and self-healing. Thank you~
3. juliusmarminge commented on Sep 23, 2026

   

   juliusmarminge

   on Sep 23, 2026

   Member

   More actions

   Triage

   Confirmed on main at f5ef0ddb9. The nightly in this report (0.0.43-nightly.20260923.2135) already contains it. Not already fixed.

   What you reported. The desktop client blocked a server update with "This release requires a newer T3 Code service launcher. Update it on the server machine." Updating the Arch desktop package and running t3 service update printed T3 Code service is already using t3@0.0.40. and the notice came back. which -a t3 showed an nvm global t3@0.0.40 ahead of any ~/.local/bin/t3. The service state stayed {"protocol": 2, "activeVersion": "0.0.40"}, with a staged 0.0.43-nightly.20260921.2044 runtime left unused. Installing a nightly CLI and running t3 service install moved the service to protocol 3 and cleared the notice.

   The block itself is the protocol gate from #11940. The bug is that the recovery path reports success without saying which t3 ran, and the only release that satisfies this client is a nightly CLI. Stable latest is still protocol 2.

   What the code does

   1. The in-app update is supposed to stop here.

   The running 0.0.40 server calls the staged binary's __service-preflight with its own launcher protocol, which is 2:

   https://github.com/pingdotgg/t3code/blob/v0.0.40/apps/server/src/cloud/selfUpdate.ts#L225-L229

   https://github.com/pingdotgg/t3code/blob/v0.0.40/apps/server/src/cloud/serviceProtocol.ts#L4

   The staged nightly requires protocol 3 and returns that exact sentence. Nothing in the sentence names a command, a protocol number, or a path:

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

   Lines 23 to 29 in f5ef0dd

   	if (input.launcherProtocol !== SERVICE_LAUNCHER_PROTOCOL) {
   	return {
   	status: "blocked",
   	version,
   	reason:
   	"This release requires a newer T3 Code service launcher. Update it on the server machine.",
   	};

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

   Lines 3 to 5 in f5ef0dd

   	// Protocol 3 requires the standalone executable layout. Bump when runtimePaths
   	// or the installed runtime tree changes incompatibly; launchers survive self-updates.
   	export const SERVICE_LAUNCHER_PROTOCOL = 3 as const;

   #11940 added this on 2026-09-15 so an old launcher would not activate a standalone runtime. It is not in stable v0.0.42 (still protocol 2). It is in nightlies from v0.0.41-nightly.20260916.1795 onward. The staged 0.0.43-nightly.20260921.2044 tree is the preflight failing before the launcher is asked to switch. That part of the report matches the code.

   2. On 0.0.40, t3 service update only repairs the CLI that ran it.

   v0.0.40 has no t3 update command and no deprecation warning. t3 service update is the real command, and its description says it uses this CLI version (npx t3@latest service update for a newer one). When the unit, sentinel, and service-state.json already match that CLI, it prints the line you saw and exits 0:

   https://github.com/pingdotgg/t3code/blob/v0.0.40/apps/server/src/cli/service.ts#L136-L146

   "Already using t3@0.0.40" was true for that process. It does not print execPath, so an nvm shim earlier on PATH is invisible. The deprecated-alias text on current main was not what ran: that copy landed in #11702 and is in v0.0.42+, not in 0.0.40.

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

   Lines 142 to 157 in f5ef0dd

   	// Kept one release for muscle memory and old docs. It did what `t3 service
   	// install` does; the way to move to a newer release is `t3 update`.
   	const serviceUpdateCommand = Command.make("update", serviceReconcileFlags).pipe(
   	Command.withDescription("Deprecated. Run `t3 update` to move to a newer release."),
   	Command.unlisted,
   	Command.withHandler((flags) =>
   	runServiceCommand(
   	flags,
   	Effect.gen(function* () {
   	yield* Console.log(
   	"`t3 service update` is deprecated: run `t3 update` to move to a newer release, or `t3 service install` to repair the service. Repairing now.",
   	);
   	const result = yield* reconcileService({ allowDowngrade: flags.allowDowngrade });
   	if (!result.changed) {
   	yield* Console.log(`T3 Code service is already using t3@${packageJson.version}.`);
   	return;

   Current main prints the deprecation, then the same version-only success line, still with no path. status.current is "this process's version already matches the unit and state," not "this machine has the release the client asked for":

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

   Lines 975 to 982 in f5ef0dd

   	current:
   	problems.length === 0 &&
   	normalizeUnit(unit) === normalizeUnit(detectedManager.render(plan)) &&
   	runtimeEntryExists &&
   	Option.isSome(runtimeSentinel) &&
   	runtimeSentinel.value.trim() === input.cliVersion &&
   	state?.activeVersion === input.cliVersion &&
   	state?.update?.status !== "pending",

   3. Following the old help text still cannot clear a nightly client.

   npx t3@latest and t3 update with no --channel both follow stable. Latest stable is v0.0.42, which is still protocol 2, so the preflight blocks again. The channel flag defaults to the channel of the CLI that ran, not the desktop app:

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

   Lines 228 to 232 in f5ef0dd

   	channel: Flag.Literals("channel", CLI_RELEASE_CHANNELS).pipe(
   	Flag.withDescription(
   	"Release channel to follow. Defaults to the channel this t3 was published on.",
   	),
   	Flag.optional,

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

   Lines 354 to 355 in f5ef0dd

   	const currentVersion = packageJson.version;
   	const channel = input.channel ?? cliReleaseChannelOf(currentVersion);

   t3code/packages/shared/src/cliRelease.ts

   Lines 89 to 92 in f5ef0dd

   	/** The release train a version was published on, derived from its prerelease tag. */
   	export function cliReleaseChannelOf(version: string): CliReleaseChannel {
   	const channel = /^[^-+]+-(nightly|preview)\.\d{8}\.\d+$/.exec(version)?.[1];
   	return channel === "nightly" || channel === "preview" ? channel : "stable";

   install.sh does the same (T3CODE_CHANNEL defaults to stable). A nightly desktop package does not change that. t3code-nightly-bin is the AppImage only; it does not install a t3 binary or touch the systemd user service:

   t3code/packaging/aur/README.md

   Lines 1 to 7 in f5ef0dd

   	# AUR packaging
   	This directory maintains the [`t3code-bin`](https://aur.archlinux.org/packages/t3code-bin) and
   	[`t3code-nightly-bin`](https://aur.archlinux.org/packages/t3code-nightly-bin) packages. Both
   	repackage the official x86_64 AppImage from GitHub Releases.
   	## Publishing

   t3code/docs/user/install.md

   Lines 59 to 66 in f5ef0dd

   	or use a package manager:
   	| Platform | Install |
   	| ------------------ | ------------------------------- |
   	| Windows | `winget install T3Tools.T3Code` |
   	| macOS | `brew install --cask t3-code` |
   	| Arch Linux | `yay -S t3code-bin` |
   	| Arch Linux nightly | `yay -S t3code-nightly-bin` |

   The host command in the user docs is t3 update <client-version>. The preflight string never says that, and v0.0.40 cannot run it:

   t3code/docs/user/updating.md

   Lines 34 to 38 in f5ef0dd

   	On the host, run:
   	```sh
   	t3 update <client-version>
   	```

   t3 update <nightly> from a protocol-2 CLI that does have the command (v0.0.42) is the crash-loop in #12627, still open. #12629 is not merged, and main has no older-state adoption. The workaround that worked here avoids that: put a protocol-3 CLI first on PATH, then t3 service install.

   Not a duplicate

   • [Bug]: background service self-update fails permanently against a pre-#11510 service-launcher.mjs #11934, closed by fix(server): block updates under legacy service launchers #11940 — the preflight did not fire, so the update failed with a misleading launcher error. Here the preflight fired, as designed.
   • Service runtime 0.0.42 cannot be started by a pre-0.0.42 service-launcher (layout changed to Node SEA; launcher not replaced) #12020, closed duplicate — a stale service-launcher.mjs crash-looped on a 0.0.42 runtime. This service stayed up on 0.0.40.
   • [Bug]: t3 update across a service-launcher protocol bump leaves the service crash-looping ("Service state is invalid or unsupported") while reporting success #12627, open, and fix(server): the service no longer crash-loops after t3 update crosses a launcher protocol #12629 — t3 update across the protocol bump writes protocol 2 next to the new version and crash-loops while reporting success. This host never left 0.0.40 and did not crash-loop.

   No open issue covers the preflight telling you only to "update on the server machine," or t3 service update reporting success from whichever t3 is first on PATH.

   Fix direction

   The string users see is produced by the staged nightly, so a change there reaches hosts still on protocol 2.

   Say which protocol was offered and which this release requires. Name the host command that actually moves the launcher: install this exact version (T3CODE_VERSION=<client-version> on https://t3.codes/install.sh, or t3 update <client-version> once that CLI is what t3 is), then t3 service install. Say that t3 service update, npx t3@latest, and t3 update with no version stay on the CLI that is first on PATH, and that a desktop or AUR upgrade does not replace it. Point at t3 --version and which -a t3 when that version is not the one in the notice.

   On current CLIs, include the executable path in the "already using" / "already installed" lines. That does not rewrite 0.0.40; the preflight string is what those hosts see.

   Leave the channel default as it is. A stable CLI updating to stable is correct. Do not treat "AUR has no t3 binary" as a defect.

   Accepting as a recovery-message bug. The protocol block stays.
4. juliusmarminge

   added

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

   acceptedfeature request acceptedfeature request accepted

   on Sep 23, 2026