[Bug]: windows desktop t3 browser codex models cant use anymore #12778

Activity

1. TheDarkSkyXD

   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 Sep 20, 2026
2. juliusmarminge commented on Sep 20, 2026

   

   juliusmarminge

   on Sep 20, 2026

   Member

   More actions

   Triage

   This is a real desktop preview-host failure, not a Codex “picked the wrong browser” miss.

   The screenshot is GPT-6-Astra on Windows desktop 0.0.42 after “go to google.com using t3 browser.” The model reports that T3 said no preview automation host is available in this environment. That is PreviewAutomationNoAvailableHostError from PreviewAutomationBroker.invoke when that environment has no live Electron host. So preview_* ran; the broker had nobody to route to.

   The collaborative Browser tab is not the host. PreviewAutomationHosts only mounts on Electron (isElectron && previewBridge?.automation) and holds one previewAutomation.connect stream per saved environment. focusHost cannot recreate a missing stream. Opening another tab will not help once preview_status / preview_open themselves return no host.

   Why 0.0.42 is a likely hit

   #11381 shipped in 0.0.42: an unanswered broker deadline disconnects that host and shuts down its request queue. A typical desktop session has one host, so eviction leaves clients empty.

   #12535 (merged 2026-09-19; first nightly 0.0.43-nightly.20260919.1948) is the reconnect: timeout evictions complete the registration stream cleanly and the desktop re-registers with a fresh connection ID. 0.0.42 does not have that. #12146 is the same error on Windows (later also Linux/macOS) and was closed as fixed by #12535.

   This report is not a wash of #12146. That issue is closed as fixed on later builds, and this screenshot is a short first-looking turn with no traces. “Anymore” is consistent with a leftover eviction, but it can also be a host that never registered, or a Windows 0.0.42 WSL / disabled-local environment mismatch.

   Not #11579 / #12739

   #11579 is Codex choosing bundled Computer Use (cua_repl / unified-computer-use / IAB) and never calling T3 preview_*. This screenshot is the opposite: T3 preview ran and returned no-host.

   #12739 only moves the existing Codex browser guidance into application context. That can change tool selection. It cannot create a missing host.

   Also not #6355 (thread-switch CDP detach; the broker still has a host). Open #12273 / #12279 are complementary: the optional 500ms metadata status can evict the only host even after a successful action.

   Workaround

   Quit T3 Code fully and reopen, or reload the desktop renderer. A later nightly that includes #12535 (0.0.43-nightly.20260919.1948 or newer) is the build that should recover after a timeout eviction without a restart.

   If a brand-new session after that nightly still fails on the first preview_status / preview_open, comment here. That would be a remaining first-register / environment-routing bug, not the closed #12146 eviction.

   If you still have the session

   ~/.t3/userdata/logs/server.trace.ndjson (not provider events.*.log). Filter for PreviewAutomationBroker.connect, disconnect, invoke, and ws.rpc.previewAutomation.connect. Also useful: local vs WSL / disabled local environment, and whether a full restart restored the host.

   Accepting as the host-lifetime / no-host class on 0.0.42 Windows desktop. Leaving open; not a duplicate of #11579 or #12146.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

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

   on Sep 20, 2026