[macOS][26.908.70816] In-app browser AX/DOM reads hang on example.com; discovery works, persists after reinstall #45868

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   browser

   tool-callsIssues related to tool callingIssues related to tool calling

   on Sep 16, 2026
2. ielseu commented on Sep 17, 2026

   

   ielseu

   on Sep 17, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up after a full desktop-app restart: the problem still reproduces on 26.911.61220 (build 9647), bundle identifier com.openai.codex, macOS 26.6.2 / arm64. Version and build were read from the installed app's Info.plist.

   The user manually has a loaded page open in the in-app browser. This round tested that page; example.com was not retested, so the measurements below should not be interpreted as a fresh public-site reproduction.

   Operation after restart	Observed result
   cua.getState()	Outer 30-second timeout, kernel reset (~30.04 s)
   cua.listBrowsers()	Success (~0.07 s); the task's in-app browser was present
   cua.listTabs({browser: actualBrowserId})	Success (~0.05 s); the expected loaded tab was listed
   browser.tabs.get(actualTabId)	Success without automatic page-state collection (~0.05 s for browser selection + tab acquisition)
   Read-only tab.playwright.evaluate(..., undefined, {timeoutMs: 10000}) for basic page controls	Did not return before the 20-second outer timeout; kernel reset
   tab.screenshot({clip:{x:0,y:0,width:800,height:80}})	Did not return before the 20-second outer timeout; kernel reset

   These are single tool-reported timings, not benchmark averages. The last screenshot attempt returned no image, unlike the earlier screenshot success described in the original report.

   Recovery attempted: an explicit CUA session reset, fresh browser/tab discovery, direct tab-handle acquisition, and the documented non-Playwright screenshot alternative. These did not restore usable page reading. Local desktop diagnostics recorded the page's DOM-ready event and the CUA MCP service as ready; those markers alone did not predict successful page operations.

   No root cause is established. Please investigate where loaded-page requests stop progressing and why the inner 10-second read timeout does not return an actionable error before the outer tool reset.

   Submitted at the affected user's explicit request. No account details, private URLs, local user paths, task/session identifiers, raw logs, screenshots, credentials, browser storage, or page/list contents are included.
3. ninadelrey commented on Sep 28, 2026

   

   ninadelrey

   on Sep 28, 2026

   More actions

   Reproduction persists on 26.924.22138 (build 11645), macOS arm64 — 2026-09-28

   This is an additional reproduction of the loaded-page control hang described in this issue. The affected user authorized diagnosis and submission to the official issue tracker. Browser control is still unusable; no root cause or successful fix is claimed.

   Verified environment

   • ChatGPT.app, bundle identifier com.openai.codex.
   • Installed version 26.924.22138, build 11645, read from Info.plist.
   • macOS 26.6.2 (25G83), arm64, verified with sw_vers/uname.
   • Public, unauthenticated page: https://example.com/.
   • The earlier local diagnostic record documented the same symptoms on 26.911.61220 (build 9647) after a full application restart. The new installed version still reproduces them.

   Current measurements

   Each timing is one tool-reported observation, not an average.

   Operation	Result
   cua.getState()	Outer 15 s timeout (~15.05 s), JS kernel reset
   cua.getTab({url:'https://example.com/'},{browser:'iab'})	Outer 15 s timeout (~15.05 s), kernel reset
   cua.getBrowser({url:'https://example.com/'})	Success (~1.24 s)
   browser.tabs.list() plus reading packaged troubleshooting guidance	Success (~0.02 s); Example Domain listed
   browser.tabs.get(actualTabId), capability discovery and tab.title()	Success (~0.01 s); title Example Domain
   tab.screenshot({fullPage:false})	Outer 12 s timeout (~12.02 s), no image, kernel reset
   tab.reload() followed by a DOM snapshot	Outer 15 s timeout (~15.02 s); execution did not reach the marker printed after reload, so reload itself did not return. This is not a separately measured DOM-snapshot failure.

   Minimal reproduction

   1. Open https://example.com/ in the desktop in-app browser.
   2. Select that browser through the documented API.
   3. List tabs and use the actual returned tab ID:

      const tabs = await browser.tabs.list();
      const tab = await browser.tabs.get(actualTabId);
      await tab.title(); // returns Example Domain

   4. In a separate tool invocation, run:

      await tab.screenshot({fullPage:false});

   5. Observe no result before the outer tool timeout, followed by:

      js execution timed out; kernel reset, rerun your request
      

   6. The higher-level cua.getTab call, which automatically collects page state, also times out.

   Recovery attempts

   • Timeout-triggered JS resets and newly acquired tab handles did not restore page operations.
   • Selecting the existing task through the app navigation tool returned success. Requesting the public page through open_in_codex returned queued; this does not establish that reopening completed. The later reload attempt still hung.
   • The historical local record reports a full desktop restart failed on the earlier version. A fresh full restart was not performed in this round.
   • No application binaries, cookies, permissions, proxies or connector settings were modified in this round.

   Sanitized local log observations

   During the current reproduction the app logged both completed getInfo requests and repeated warnings:

   [browser-use-iab-api] IAB_LIFECYCLE iab backend info request failed
   No ChatGPT browser route is available for browser session <redacted>
   

   The same task's earlier startup logged:

   IAB_LIFECYCLE captured session route ... disposeAfterSessionActivity=false
   browser_use_iab_backend_startup_ready ... release=26.924.22138
   IAB_LIFECYCLE created browser use host
   IAB_LIFECYCLE ended browser use session activity ... disposeAfterSessionActivity=false
   

   These observations do not prove that route loss is the cause of the hang: metadata succeeds, getInfo has successes and failures, and no causal trace has been established. Please correlate route selection and request dispatch with page-operation completion/cancellation.

   Expected behavior and impact

   Page state, screenshot and reload should complete or return an actionable error within a bounded timeout. Successful metadata discovery should not mask a page-operation transport failure. The issue blocks browser-based acceptance tests and signed-in workflows even though the public test page can be found and its title read.

   Privacy

   Only this public-page reproduction and sanitized technical observations are included. No private URLs, local user paths, account details, task/session IDs, browser contents, screenshots, credentials, reimbursement data or raw logs are attached. No policy bypass is requested.
4. ninadelrey commented on Oct 3, 2026

   

   ninadelrey

   on Oct 3, 2026

   More actions

   Retested on 2026-10-04 (Asia/Shanghai) after an app update. Still reproducible.

   Environment: macOS 26.6.2 (25G83), arm64; ChatGPT/Codex desktop 26.930.31730, build 12947, prod channel. Built-in updater reports up_to_date.

   Minimal reproduction on https://example.com/ using the supported cua_repl API:

   1. getBrowser({id: "iab"}) succeeds; tabs.list returns Example Domain and its URL.
   2. tabs.get succeeds independently (printed an explicit completion marker).
   3. Browser visibility capability set(true) returns successfully, but playwright.domSnapshot still exceeds a 12-second outer timeout and resets the kernel. Thus requesting foreground visibility did not recover control.
   4. The tab CDP capability documentation is available. Page.getFrameTree with timeoutMs:3000 does not return before an 8-second outer timeout, which resets the kernel. This is not limited to the Playwright DOM snapshot layer.

   Local lifecycle logs show webview attachment, debugger-listener registration and dom-ready for example.com. They also contain "No ChatGPT browser route is available for browser session" alongside successful getInfo completions. That warning is a correlation, not a confirmed root cause.

   The earlier full application restart did not resolve this issue. No cookies, login state, security settings, application binaries or project implementation were changed. No private page contents, credentials, session identifiers or raw logs are included here.

   Could maintainers advise a supported repair or diagnostic for the per-tab debugger/control transport? Tab metadata works while page control requests hang, including their requested command timeout.
5. DSVinC commented on Oct 7, 2026

   

   DSVinC

   on Oct 7, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on October 7, 2026 (UTC+8), submitted by the affected user's Codex assistant at their explicit request.

   Environment: macOS; Codex desktop / bundled Computer Use release 26.930.61225, as reported by application logs and the bundled runtime. The About dialog and exact macOS version were not independently checked for this report.

   The user fully restarted the desktop app before this round. Application logs confirmed a new application session/process, but usable page observation was not restored.

   Each timing below is a single tool-reported observation, not a benchmark average:

   Operation after restart	Result
   Browser discovery and target tab listing	Success; tab listing ~0.069 s
   cua.getTab(actualTabId, {browser: actualBrowserId}), which automatically collects page state	~30.028 s outer timeout; kernel reset
   Create a fresh tab and read its about:blank DOM snapshot	Success; empty DOM returned in ~0.031 s
   Navigate that same fresh tab to the target public news website	~30.028 s outer timeout; kernel reset
   Subsequent combined tab-list / target DOM-read invocation	~30.026 s outer timeout; intermediate output was unavailable, so individual sub-operations are not independently classified
   Close the temporary test tab and read back the tab list	Success in ~0.063 s

   Exact outer error:

   js execution timed out; kernel reset, rerun your request
   

   The app log recorded a dom-ready event for the target URL after navigation, although the navigation tool call did not finish. DOM-ready does not prove full website readiness or establish the cause of the hang.

   Earlier on the same installation, target-page reading, refresh and screenshot capture succeeded intermittently, followed by recurrent observation/screenshot timeouts. The post-restart round did not produce a new target-page screenshot.

   This adds a newer-version occurrence and a useful blank-page comparison: basic discovery, tab lifecycle and blank-page DOM reading can work while loaded-page operations remain unusable. Restarting and replacing the tab did not recover the workflow. We have not established that the cause is identical to every occurrence in this issue, or that policy verification, networking, route selection or debugger transport is responsible. No explicit policy-denial error was returned in these tests.

   Could maintainers provide a supported diagnostic or recovery procedure, and investigate where loaded-page requests stop progressing and why they do not return an actionable error before the outer kernel reset?

   No app binaries, browser security controls, proxy settings, plugin configuration or website implementation were changed. No private URLs, account details, local paths, task/session IDs, raw logs, page contents, screenshots, cookies or credentials are included. The public target URL is omitted here; example.com was not tested in this round and is not claimed as our reproduction.
6. Timmycosmos commented on Oct 10, 2026

   

   Timmycosmos

   on Oct 10, 2026 – with ChatGPT Codex Connector

   More actions

   Update (2026-10-10): I can reproduce the same class of issue on the current macOS desktop app, version 26.1007.21159. The in-app browser inventory returns the visible tab and its metadata, but binding/reading that tab with cua.getTab() hangs until the outer 15-second timeout resets the CUA runtime. Restarting the app did not resolve it; it reproduces across multiple tasks.

   The desktop log repeatedly reports No ChatGPT browser route is available for browser session <redacted>. I found and repaired stale persisted browser-session mappings; after restart, the tab metadata matched the active conversation, but the runtime route error and timeout remained. This suggests the failure is still in session-route resolution. No causal root cause is confirmed.

   This may be related to #52472, which reports a browser route being captured and then displaced by a client-new-thread host. The symptom here is specifically the macOS in-app browser's page-read timeout.

   No account details, target URLs, conversation/session IDs, local paths, raw logs, or screenshots are included.