Repository navigation
@Chrome: session route captured then revoked within ~374 ms by a client-new-thread browser host (Desktop 26.1002.52244) #52472
Description
Desktop 26.1002.52244 (macOS): @chrome session route is captured and then revoked within ~374 ms by a client-new-thread browser host
Environment
| Item | Value |
|---|---|
| OS | macOS 27.0.1 (Darwin 27.0.0, arm64) |
| Desktop app | ChatGPT.app / Codex Desktop 26.1002.52244 (build 13536, commit b157f434) |
| Browser | Google Chrome 155.0.8059.40 |
| Extension | hehggadaopoacecdllhhajmbjkdcmajg v1.26.901.11451 (installed and enabled) |
| CLI | codex-cli 0.162.0 |
| Native host | com.openai.codexextension — manifest validation passes |
Symptoms
When using @Chrome (tab mention) to perform browser actions in any conversation:
- The action fails immediately, or times out after 30 seconds when invoked through the
cuaAPI; - The desktop log repeatedly shows
No ChatGPT browser route is available for browser session <id>; - The native accessibility path works perfectly in the same environment (see table below).
cua API calls executed by Codex itself inside the desktop app:
| Call | Duration | Result |
|---|---|---|
cua.getState() |
30.05 s | js execution timed out; kernel reset |
cua.createBrowserTab("chrome", …) |
30.14 s | nodeRepl.fetch request failed |
cua.listTabs({ browser: "chrome" }) |
30.40 s | nodeRepl.fetch request failed |
cua.getApp("com.google.Chrome") |
0.32 s | OK (native AX path) |
Reproduction
- Open ChatGPT.app with Chrome running and the ChatGPT extension installed/enabled;
- Open any conversation (historical / new session / brand-new draft — all reproduce);
- Send a
@Chromeinstruction (e.g. "list the currently open Chrome tabs"); - The action fails immediately (or times out after 30 s via the
cuaAPI).
Decisive evidence: the 374 ms window
Desktop main-process log (local time; session IDs unchanged):
16:31:02.550 IAB_LIFECYCLE received browser sidebar owner sync ownerRoutePath=/local/01a11fbe…
16:31:02.550 IAB_LIFECYCLE rebound browser sidebar window windowId=1
16:31:02.551 IAB_LIFECYCLE captured session route conversationId=01a11fbe… OK
-- 374 ms --
16:31:02.925 IAB_LIFECYCLE created browser use host client-new-thread:347c2900… windowId=1
16:31:02.926 IAB_LIFECYCLE ended browser use session activity conversationId=01a11fbe… REVOKED
16:31:26.419 No ChatGPT browser route is available for browser session 01a11fbe… FAILED
The user session's route is captured, and 374 ms later the browser host is created for a client-new-thread (draft) session while the user session is ended in the same instant.
The same pattern reproduces independently in an earlier desktop instance (≈45 min apart, different sessions, different draft IDs):
| Desktop instance | Time | Revoked session | Draft session taking the host |
|---|---|---|---|
| pid 49443 (started 14:23) | 15:46:20 | 01a0e617… |
client-new-thread:8635c606… |
| pid 22265 (started 16:28) | 16:31:02 | 01a11fbe… |
client-new-thread:347c2900… |
Code-level localization
The error stack points into app.asar/.vite/build/main-B6ZOwXa3.js (around line 997):
// Any session without a valid route (revoked or never captured) fails here:
ensureSessionRoute(e) {
const t = this.sessionRoutes.get(e.conversationId);
if (t != null) {
if (this.delegate?.isWindowAlive(t.windowId) === true) return true;
this.disposeBrowserUseRoute(…); // "Discarded stale Browser Use session route"
}
// remaining paths return non-true
}
ensureBrowserUseSessionRoute(e) {
if (this.options.ensureSessionRoute?.(e) !== true)
throw Error(`No ChatGPT browser route is available for browser session ${e.conversationId}`);
}Diagnostics: all pass
Verified with the plugin's own scripts (check-extension-installed.js, check-native-host-manifest.js, chrome-is-running.js):
| Check | Result |
|---|---|
| Chrome running | yes |
| Extension installed & enabled (Default profile) | installed · enabled |
| Native host manifest (name / origins / path) | Correct: yes |
| Native host binary | present, Mach-O arm64 |
Extension side, manifest, and binary are all healthy — the failure is entirely inside the desktop app.
Attempted fixes that did NOT help
- Restarting ChatGPT.app (multiple times, including a clean start after permissions were granted) — the route still dies right after startup;
- Disabling/enabling and reinstalling the Chrome plugin — no change to the registration file or routing behavior;
- Granting Full Disk Access — the recurring
EPERM: …/Microsoft Edgeplugin-sync error disappeared, but the routing issue remains; - Historical sessions, new sessions, and a brand-new draft conversation — all three are revoked after capture.
Secondary observations
~/.codex/chrome-native-hosts-v2.jsonpresence is frozen at 10:04 (pid 6324, long-dead); no restart or plugin operation refreshed it;- The native host process exists, but shares no socket with the desktop app;
EPERM: operation not permitted, scandir '…/Microsoft Edge'repeatedly interrupted the plugin'schrome_extension_sync_stateread (resolved by Full Disk Access; not causally related to the routing failure).
Expected vs actual
| Expected | Actual | |
|---|---|---|
| Session route | stays valid after capture; rebuilt on session switch | revoked ~374 ms after capture by a draft-session host |
@Chrome |
claimTab / actions execute | No ChatGPT browser route is available |
cua API |
both chrome and native paths work | chrome path times out at 30 s; native path OK |
Report generated 2026-10-09. Full raw logs (desktop app log, logs_2.sqlite, rollout records) available on request.
Activity
github-actions commentedon Oct 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
NicolaChen commentedon Oct 9, 2026
Update: still reproducing on 26.1007.21159
Updated the desktop app to 26.1007.21159 and retested. The failure persists, with a slightly changed shape.
What improved:
getInforequest now completes (previously it failed withNo ChatGPT browser route is available); theNo ChatGPT browser routeerror no longer appears at all in the new version's log;reassigned browser use routeevent appears.What still fails:
cua.getState()still times out after 30 s (js execution timed out; kernel reset). The retry returns only the generic "Computer Use" help text with no browser inventory (no tabs, no Chrome state) — the extension-backed browser provider never becomes usable;browser-use native pipe rejected socket peer reason=untrusted-process-ancestrystill appears (also present in the previous version; 44 occurrences there).Environment: same machine as the initial report; extension and native host manifest checks still pass.
Reproduction steps unchanged (open any conversation, use
@Chrome; or callcua.getState()— it times out at 30 s).NicolaChen commentedon Oct 9, 2026
Keeping this open. #51442 and #51363 describe the same root cause from Windows; this report is the macOS case and currently contains the most complete mechanism analysis of the shared root cause:
captured session routefor the user's conversation →created browser use hostfor aclient-new-threaddraft session →ended browser use session activityfor the user's conversation. Reproduced across two desktop instances and three conversation types (historical / new / brand-new draft).ensureSessionRoute/ensureBrowserUseSessionRouteinapp.asar/.vite/build/main-B6ZOwXa3.js— the exact throw site ofNo ChatGPT browser route is available.No routeerror disappeared andgetInfonow completes, butcua.getState()still times out at 30 s with no browser inventory — the extension-backed browser still never becomes usable.Note that the inventory shape reported in #51363 (
{"family":"chrome","type":"extension","tabs":[]}) is isomorphic to what we observe on macOS (backend=chrome browserID=1 tabID=undefined), which supports a single root cause across platforms.If a maintainer prefers to consolidate, this issue is a good candidate to serve as the tracking issue for the mechanism; otherwise feel free to close it in favor of whichever issue you track.
SiyXo511 commentedon Oct 9, 2026
Additional observation on macOS 27.0 (arm64), desktop app 26.1007.21159, build 20052:
The built-in browser is also affected on my machine.
Unlike the earlier update in this issue, my logs still contain this error on 26.1007.21159:
No ChatGPT browser route is available for browser session <redacted>The latest observed occurrence was 2026-10-09T10:04:07Z. No page content was returned. I have not established whether this shares the same underlying cause.
Crnobog9527 commentedon Oct 9, 2026
Same issue here, still reproducing on 26.1007.21159 (macOS, Darwin 25.6.0 arm64, Chrome 154.0.8037.99, extension 1.26.901.11451, CLI 0.162.0-alpha.17.2).
Native host manifest check, extension check and chrome-is-running all pass; the native host process is spawned by Chrome and listening under
/tmp/codex-browser-use/. System proxy (Clash) excludes localhost, so it's not a proxy issue.On this build the route is captured and then reassigned to a
client-new-threaddraft ~100 ms later:After that, every browser call from that conversation logs
No ChatGPT browser route is available for browser session 01a120ad-…(79 times today on 26.1007.21159; also present on 26.930.x and 26.1002.x — 783 occurrences over Oct 5–9).At the moment of failure the client has already selected the Chrome backend (
browser-use-pip … backend=chrome browserID=1) in the same millisecond as 5× route-missing errors; the session command and tab listing then time out at 30 s.NicolaChen commentedon Oct 10, 2026
Verified local workaround: TUN mode
On this Mac, enabling TUN mode in the existing proxy client restored usable Chrome extension control.
Environment: desktop app 26.1007.21159 (build 20052), Chrome 155.0.8059.40, macOS 27.0.1. Verified on 2026-10-10.
Evidence
Before recovery, the desktop app's durable WebSocket connection to
codex-cloud-backend.chatgpt.comattempted a direct TCP connection and timed out despite system proxy settings being enabled. Logs showed WebSocket open timeouts andCodex app-server is not available.After enabling TUN, read-only checks confirmed the destination was routed through the tunnel. The durable WebSocket initialized successfully, and previously failing thread reads and resumes succeeded.
At 03:03 UTC, Chrome was also verified through the extension-backed connection, not merely browser discovery:
Steps to try in a similar environment
No configuration reset, reinstallation, credential export, or disabling TLS verification was required during this validation.
Limitations: this is a verified local workaround, not a universal root-cause fix. The app also restarted during recovery, so this was not an isolated TUN-only experiment. We did not disable TUN again for a disruptive comparison. It does not prove the cause of every Chrome extension failure or resolve all of the previously reported routing observations.
NicolaChen commentedon Oct 10, 2026
Independent log verification (same machine)
Confirming the TUN workaround from the desktop app's own logs, independent of the account above:
No ChatGPT browser routetime distribution: all 52 occurrences fall within 02:57–03:02 UTC; zero after 03:02. The boundary aligns with the TUN switchover and the successful extension-backed verification reported above.open_timeout(dozens of reconnect attempts). The post-switch instance reachedconnectedon its first attempt (02:53:35).client-new-thread:*drafts, one to a real conversation at 03:00:02, followed by normal page operations such as webview attach and dom-ready). Similar host/endedchurn also occurred while the extension path was still failing, so these events appear to be internal lifecycle activity rather than the failure mechanism itself.Net: the workaround is reproducible and its timing correlates exactly with the network-routing change. The precise causal chain (why the abnormal routing state broke the extension-backed path) is best verified from inside the product.
jamespud commentedon Oct 10, 2026
Windows 26.1007.2314.0: three reproductions, no session-end revocation, intermittent route lookup failures
Cross-reference: #46137
I reproduced the browser-control failure on Windows Codex Desktop (MSIX
26.1007.2314.0, app/CLI26.1007.21434) across three independent conversations and two Desktop processes.The results challenge the capture→revocation explanation in the original report. They also show that browser operations can succeed while their callers time out.
1. Failure occurs without a session-end event
In the fresh Desktop process, the affected conversation
01a12467-6c3e…accumulated 19 failed and 3 completedgetInfooperations, without anyended browser use session activityevent for that conversation.The only session-end event in the process belonged to the previous conversation during startup cleanup.
Therefore, the specific capture→
ended browser use session activitysequence described in this issue is not necessary to reproduce the failure on this Windows build.This does not exclude other route invalidation mechanisms.
2. Route reassignment occurs during conversation creation
All three experiments exhibited the same sequence. In the fresh process:
The reassignment occurred 126 ms after capture and before the
Conversation createdevent.Changing the
@Browsermention order did not prevent this sequence. A complete Desktop restart did not prevent it either.3. Route lookup failures are intermittent
Across the three conversations,
getInfolog outcomes were:01a12443…01a12454…01a12467…In one case, requests using the same conversation ID produced completed and failed outcomes within approximately 1–2 ms of one another.
Page/tab operations referenced a
client-new-thread:*route key, while failinggetInforequests used the persisted conversation ID.This suggests an identity-resolution or route-availability problem in the request path, but the logs do not prove which mapping operation is defective. Request-level correlation would be needed to distinguish simultaneous requests from a single request's lifecycle.
4. Browser actions complete even when tool calls fail
On the fresh thread:
cua.getState()completed in 22.7 s.createBrowserTab("iab", "https://example.com")calls each failed after approximately 32 s.getState({emit:false})completed and listed two actual tabs, both titledExample Domainathttps://example.com/.The Desktop logs independently confirmed tab creation, debugger-listener registration, and page
dom-ready.Thus, at least some navigation side effects complete despite the caller receiving a timeout. Repeated calls can create duplicate tabs.
Successful calls also exhibited an approximately 22-second duration in several measurements, suggesting an additional fixed-delay or shared-wait component worth investigating.
5. Durable WebSocket connection remains unstable
Across the available Desktop logs:
By contrast, local and remote hosts reached
connectedrepeatedly.Restarting Desktop reset the durable reconnect counter, but the connection failed again.
I also saw the newly reported TUN-mode workaround in this issue. That result makes network routing a relevant hypothesis for my environment, although I have not yet performed a TUN on/off comparison.
The relationship between durable connectivity, route reassignment, and request completion remains unresolved.
6. Installation and recovery checks
chrome/latestjunction resolves to the installed app/CLI version.%LOCALAPPDATA%.@Browserselection before the first message: failed.Investigation request
Could maintainers investigate:
ensureBrowserUseSessionRouteresolves requests against temporary and persisted conversation identities.The capture/reassignment events may be normal lifecycle activity rather than the root cause. The observable defect is unreliable route resolution and browser-operation completion.
Sanitized Desktop log excerpts and the full local reproduction timeline are available on request.
u2bo commentedon Oct 16, 2026
Additional Windows reproduction on 26.1007.71326 (build 20398)
Observed on 2026-10-16 in a new local Codex desktop chat using the built-in browser. App version
26.1007.71326, build20398, production channel; Windows x64 package version in the exception stack:26.1007.9446.0.Observed sequence:
example.com.agent.browsers.get("iab")returnsBrowser is not available: iab.agent.browsers.list()returns onlyCodex MCP Apps(type: mcpapps); noiabbackend is exposed. No website navigation was attempted by the agent because selection failed.Sanitized desktop log excerpt (UTC):
CHAT_Aconsistently denotes the persisted conversation;DRAFT_Bconsistently denotes the draft ID. Full identifiers and local user paths are omitted.This adds a newer Windows build with failure at browser discovery, and successful/failed
getInfoentries interleaved for the same conversation. The first observed failure precedes the session-end event. The exception stack includesensureBrowserUseSessionRoute→getInfo.These observations support investigating route resolution between temporary and persisted conversation identities, but do not prove that reassignment or session-end events are the root cause. I have read the later comments about durable connectivity and the TUN workaround; no controlled network/TUN comparison has been performed for this incident, so network involvement is not ruled out.
Expected: a valid local chat can discover and use its built-in browser, or receives actionable recovery guidance when route resolution fails. Please consider this reproduction alongside the existing Windows and macOS reports.
Submitted with Codex assistance at the affected user's request. Only the relevant sanitized log excerpt is included; no full logs, credentials, or conversation transcript are attached.