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.