First launch after a desktop update can start the backend in web mode without the bootstrap secret, so the desktop's own login is rejected (invalid_credential)#17367

Thanks for the detailed traces. Triage notes from current main (393ff4c):

What the code does on a missed envelope

• The desktop starts the primary backend with --bootstrap-fd 3 (DesktopBackendConfiguration.ts#L589-L606) and hands the JSON envelope to fd 3 as a child-process input stream (DesktopBackendManager.ts#L449-L507). The envelope carries mode: "desktop", host, t3Home and desktopBootstrapSecret (#L562-L581).
• readBootstrapEnvelope waits 1000 ms by default (L86) and wraps the read in Effect.timeoutOption (L145). A timeout, an unavailable fd (L81-L82) or a stream that closes before a line (L136-L138) all resolve to Option.none() with no log or error.
• resolveServerConfig then defaults mode to "web". desktopBootstrapSecret/desktopBootstrapToken stay undefined (L361-L362), so PairingGrantStore has nothing to accept the desktop's credential with, and the auth policy becomes loopback-browser with one-time-token bootstrap only (EnvironmentAuthPolicy.ts#L23-L37). The bind host falls back to 127.0.0.1 (server.ts#L252), so the failure mode looks fail-closed rather than more exposed.
• Web-mode defaults also kick in: autoBootstrapProjectFromCwd turns on (config.ts#L368-L376) and noBrowser turns off (L352-L360). The packaged backend's cwd is the home directory (DesktopEnvironment.ts#L220), so a fallback launch may also create a project rooted at ~ and may try to open a browser (serverRuntimeStartup.ts#L531-L537, #L596-L603). The welcome.autobootstrap span in your trace fits that path. Worth checking for a stray home-directory project after a failed launch.

Why it might miss the window after an update (not verified)

• The 1 s timer only starts once readBootstrapEnvelope runs, so a slow module load before that point should not count against it on its own. Something has to stall the read after the timer is armed.
• On Windows there is no /proc or /dev/fd path (bootstrap.ts#L233-L241), so the envelope is read via fs.createReadStream on the pipe fd (L207-L214). Reads on that path go through the libuv threadpool (see the analysis in #14776 for the telemetry fd). On a cold first launch with Defender scanning freshly installed files, threadpool contention or a long synchronous stall, as you describe, could plausibly push the read past 1 s even with the envelope sitting in the pipe. Neither has been reproduced here.
• No test covers the timeout-then-web-mode fallback; bootstrap.test.ts only exercises the success, unavailable-fd and error paths.

Desktop side

• invalid_credential is final: isTransientBearerBootstrapError retries only fetch/timeout and 502-504 (from #12919), and the failure surfaces as DesktopLocalEnvironmentAuthSessionBootstrapError (L118-L124) through the bearer-token IPC (window.ts#L175-L183). Nothing on that path restarts the backend.
• Readiness only checks that /.well-known/t3/environment answers (DesktopBackendManager.ts#L378-L399, #L616-L633); the descriptor it returns does not include the server mode, so a web-mode backend looks ready. The sticky error screen is #3513.

Possible fix directions (for maintainers to choose)

1. Fail closed on the server: when --bootstrap-fd/T3CODE_BOOTSTRAP_FD is set and no envelope arrives, exit nonzero with a clear error instead of starting in web mode, so the desktop supervisor restarts it. Smallest change; it does turn a slow start into a restart loop if the stall repeats.
2. Wait longer: raise the timeout for an explicit fd (or wait until a line or EOF), possibly with a log line when the envelope is late. On Windows, reading the pipe through net.Socket instead of fs.createReadStream, as #14776 does for telemetry, may remove the threadpool dependency.
3. Detect the mismatch on the desktop: check the auth descriptor (expecting desktop-managed-local) or treat invalid_credential from the primary local backend as "respawn once" before surfacing the error.

Options 1 or 2 address the root cause; option 3 is a safety net and could pair with either.

Related

• #16826: same invalid_credential symptom, different cause (WSL service on the same port). Not a duplicate.
• #3513: sticky error UI with no recovery.
• #12918 / #12919: transient bearer bootstrap retries, which don't cover a rejected credential.
• #14776 (open): same fs.createReadStream-on-pipe pattern for the telemetry fd.
• I didn't find an open or merged PR that changes the envelope timeout or the silent web-mode fallback.

Existing fix: #17568, still open at d52b1cc7fb. No replacement PR created. Its recorded verification covers focused bootstrap/config tests and real Linux CLI launches; the original Windows post-update trigger remains unverified. This Linux triage run did not reproduce the Windows/Electron update sequence. Handing the existing PR to Julius because the fix changes bootstrap credential delivery and runtime mode selection, which this triage flow reserves for maintainer approval.

Fresh triage on main at 49e97d48f9 reproduced the missing-envelope failure mode with the real Linux CLI: empty or delayed bootstrap input allowed startup, then the desktop credential exchange returned invalid_credential. Existing #17568 at d52b1cc7fb rejects empty/invalid/malformed input before state creation and accepts valid input delivered at 12 seconds (OAuth 200); all 33 focused tests pass. Preserved the existing fix, added via-triage, and updated its proof. Native Windows/Electron post-update startup remains unverified; the Linux injection does not establish the original cold-start cause.

Another occurrence on Windows nightly (0.1.3-nightly.20261024.3604). This one was not the first launch after an update, so updates are not the only trigger. Any slow cold start seems to be enough.

Timeline (UTC)

• 10-24 03:28: nightly installed (asar mtime)
• 10-24 16:05: normal launch. Backend ready in ~6 s, desktop /oauth/token succeeded.
• 10-25 04:14: launch with the same build. Backend started in web mode without the bootstrap envelope.

Evidence from the bad launch (server.trace.ndjson / desktop.trace.ndjson)

• desktop.backendInstance.start at 04:14:24.46. /.well-known/t3/environment gave transport errors until 04:14:27.3, then 503s until it succeeded at 04:14:28.5.
• Every desktop POST /oauth/token was rejected: 35 of 35 attempts (2 at 04:14:29–30, 33 at 04:48:03–08 after "Reload app"), all EnvironmentAuthInvalidError ... (invalid_credential) in about 1–3 ms.
• Server spans present only in the bad run: EnvironmentAuth.issueStartupPairingUrl, EnvironmentAuth.issueStartupPairingCredential, server.startup.welcome.autobootstrap, environment.auth.browserSession, PairingGrantStore.consume. A browser session was then created from http://localhost:3773, so the server opened the default browser as in web mode.
• Server spans present only in the good run: resourceTelemetry.desktopTelemetryReceiver.writeAllToFileDescriptor and recordSampleHealth. The desktop telemetry fd from the envelope was never used in the bad run.
• The backend process was the child of the current desktop process, with no stale backend on :3773, so a secret mismatch from a leftover server is ruled out.

This matches the diagnosis above: readBootstrapEnvelope hits its 1000 ms timeoutOption or gets nothing, startup continues silently in web mode, and the only recovery is to fully quit and relaunch. Looking forward to #17568. Making a missing envelope fatal (or retried) in desktop mode, and logging it, would also make this much easier to spot.

Another occurrence on Windows nightly 0.1.7-nightly.20261101.4035, on the first launch right after a desktop auto-update.

Environment

• Windows 11 Pro 10.0.26200, x64
• Desktop app (Nightly channel) against its own local backend on 127.0.0.1:3773. No WSL backend and no other server on the port.
• Previous build: 0.1.6-nightly.20261030.3904. The update was installed at 17:54Z.

Timeline (UTC, 2026-11-01)

• 17:55:05: desktop starts and the backend is spawned.
• 17:55:07–17:55:15: /.well-known/t3/environment returns transport errors, then 503s until about 17:55:19.
• 17:55:20–17:56:11: readiness probes are Interrupted.
• 17:56:12: the first 200, about 67 s after spawn. Normal starts on this machine take a few seconds.
• 17:56:28: the desktop's POST /oauth/token fails with EnvironmentAuthInvalidError ... (invalid_credential). The UI shows PrimaryEnvironmentRequestError / DesktopLocalEnvironmentAuthSessionBootstrapError: Failed to create the local desktop bearer session.

Evidence that the backend fell back to web mode (server.trace.ndjson)

• server.startup has the attributes "server.mode":"web", "server.port":3773.
• Spans that only appear on the web-mode path: server.startup.welcome.autobootstrap, EnvironmentAuth.issueStartupPairingCredential, EnvironmentAuth.issueStartupPairingUrl, PairingGrantStore.issueOneTimeToken, server.startup.browser.open.
• 12 of 12 desktop exchanges failed with PairingGrantStore.consume → UnknownBootstrapCredentialError and then ServerAuthInvalidCredentialError.
• server-runtime.json records the backend as serverVersion: 0.1.7-nightly.20261101.4035, so the same build as the desktop. A stale or old-version server is ruled out.
• No readBootstrapEnvelope span appears in the trace, so the miss itself left no log line. This matches the silent Option.none() fallback described above.

This is another data point that a slow cold start after an update on Windows pushes the envelope read past the 1 s window. It also supports #17568, or at least logging and failing when --bootstrap-fd is set and no envelope arrives.

Produced by T3 Code triage with Claude Code (Claude Opus 5.5).

Another occurrence on Windows, plus a direct reproduction of the dropped envelope with the real readBootstrapEnvelope on Windows, which this thread lists as unverified.

Occurrence

• Build: v0.1.10-nightly.20261112.4580, built locally with an unrelated desktop tray patch. apps/server/src/bootstrap.ts and the backend launch path are unmodified.
• Trigger: the first launch after an unclean OS reboot (the machine bugchecked overnight). No update was involved. The same build had started normally the day before.
• Windows 11 26100 x64, local Windows backend on 127.0.0.1:3773, no WSL backend.

Timeline (UTC, 2026-11-13):

• 09:01:17 desktop.backendInstance.start. /.well-known/t3/environment gives transport errors, then 503s, and is ready at 09:01:24 (about 6.9 s).
• 09:01:22 server server.startup has "server.mode":"web", "server.host":"default". The two later launches that worked report "server.mode":"desktop", "server.host":"127.0.0.1".
• 09:01:24 to 09:01:44: all 20 desktop POST /oauth/token attempts fail with PairingGrantStore.consume → UnknownBootstrapCredentialError. No desktopBootstrapToken.isValid span appears, so the server had no secret.

Reproduction of the dropped envelope

A child process calls the real readBootstrapEnvelope(schema, 3) from apps/server/src/bootstrap.ts. The parent passes fd 3 as a pipe and writes one envelope line, as the desktop does. Windows 11, Node 26.12.1, six runs per row:

So the hypothesis in the issue holds on Windows: with the envelope already sitting in the pipe, a synchronous stall longer than the timeout makes the read resolve to Option.none(). The runs that still succeed under a stall are the ones where the pipe read completed before the stall began.

The stall is injected like this, right after the read is started:

What this does not show: that the 09:01 launch above hit this exact path. That launch left no readBootstrapEnvelope span or log line, so only the outcome (a desktop-spawned backend in web mode) is confirmed.

Produced with Claude Code (Claude Fable 5.2).