[Bug]: T3 Code is not opening #22403

Activity

1. iamrakhmatov

   added

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

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 20, 2026
2. UtkarshUsername commented on Oct 22, 2026

   

   UtkarshUsername

   on Oct 22, 2026

   Contributor

   More actions

   @iamrakhmatov Can you run npx t3 triage to diagnose the issue?
3. GeorginaAwani commented on Oct 22, 2026

   

   GeorginaAwani

   on Oct 22, 2026

   More actions

   I confirmed this on native Windows (Electron), post-update launch

   • Version the bug happened on: T3 Code (Nightly) desktop 0.1.1-nightly.20261020.3411 (commit d36b7da). The self-update to 0.1.2-nightly.20261022.3526 had downloaded, but after "restart to update" the installer did not apply it; the app relaunched on 3411.
   • OS: Windows 11 Pro 10.0.22631 x64, Windows primary backend (no WSL).
   • Surface: desktop app → its own local backend on 127.0.0.1:3773.

   On relaunch, the window showed PrimaryEnvironmentRequestError ← desktop:get-local-environment-bearer-token ← DesktopLocalEnvironmentAuthSessionBootstrapError: Failed to create the local desktop bearer session.

   I ran t3 triage to diagnose and here's what was reported as evidence:

   • desktop.trace: all 12 POST /oauth/token attempts between 15:40:49Z and 15:41Z returned 401 → EnvironmentAuthInvalidError (invalid_credential) in clientRuntime.authorization.bootstrapRemoteBearerSession.
   • server.trace: server.startup reports {"server.mode":"web","server.host":"default","server.port":3773}. No T3CODE_MODE/T3CODE_HOST env vars were set and no flag overrides these, so the --bootstrap-fd 0 envelope was not read (readBootstrapEnvelope → Option.none()).
   • The listener on 3773 was the desktop's own child backend (same parent PID as the renderer, started 15:40:38Z), not a stale or WSL process.
   • The machine was slow at that moment: the readiness probe got transport errors for ~4 s, and the server only reached server.startup ~7 s after spawn. This is consistent with the 1000 ms envelope timeout expiring under post-install load.
   • The same build exchanged the token successfully (HTTP 200) on every launch on 2026-10-20/21.

   I tried fixing it with a full quit and relaunch, but it reproduced a second time on the next update: the first launch of 0.1.2-nightly.20261022.3526 right after the installer ran again logged server.startup with server.mode: "web", server.host: "default", and /oauth/token → 401 invalid_credential. A plain quit and relaunch on 3526 then started in desktop mode and the bearer exchange succeeded. So on native Windows this reproduces on every update-triggered relaunch so far, and 3526 still has the 1000 ms fallback.

   As a workaround (NOT A FIX), I fully quit T3 Code, including its backend process (on Windows: Stop-Process -Name "T3 Code (Nightly)" -Force, then confirming nothing listens on port 3773), and relaunched normally. The relaunched backend received the bootstrap envelope (server.mode: "desktop") and /oauth/token returned 200. I didn't change anything else. The bug itself remains on the updated version and recurs on the first launch after an update.
4. juliusmarminge

   closed this as completedin #34932on Nov 12, 2026