[macOS][26.908.70816] In-app browser AX/DOM reads hang on example.com; discovery works, persists after reinstall
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
Summary
The desktop in-app browser visibly loads pages, but structured page-reading operations repeatedly hang until the outer CUA tool times out and resets its JavaScript kernel. This also reproduces on the public, unauthenticated https://example.com/ page, across a separate diagnostic task, and after the user uninstalled and reinstalled the app.
No specific root cause is established. This report is submitted at the affected user's explicit request.
Environment
- macOS, Apple Silicon (arm64).
- Installed app: ChatGPT.app, bundle identifier
com.openai.codex. - Version verified before reinstall:
26.908.70816, build9275. - The app-configured production update feed listed the same version when checked on 2026-09-16.
- Exact post-reinstall app version and subscription were not re-verified.
Minimal public reproduction
- Manually open
https://example.com/in the desktop in-app browser; the page visibly loads. - In a task, run
await cua.getState()throughmcp__cua_repl.js. - Use the actual browser and tab IDs returned by that inventory, then run:
var tab = await cua.getTab(actualTabId, { browser: actualBrowserId }); - With an outer tool timeout of 25,000 ms, the call does not return page state. The tool reports:
js execution timed out; kernel reset, rerun your request
After reinstall, inventory succeeded in approximately 0.32 s and returned Example Domain / https://example.com/. The subsequent getTab call with the newly observed ID timed out after approximately 25.02 s. This was not a retry against an old tab handle.
Additional controlled observations
On another loaded website, tested in both the original task and a newly created independent diagnostic task:
| Operation | Observed result |
|---|---|
| Browser/tab inventory | Success |
browser.tabs.get(id) without automatic AX collection |
Success; about 2 ms in the independent task |
| Tab URL/title | Success; about 2 ms in the independent task |
tab.screenshot() |
Success; about 8.05 s in the independent task, showing the loaded page |
| Create tab with automatic initial AX collection | 30 s outer timeout; tab was actually created |
tab.playwright.domSnapshot() |
30 s outer timeout and kernel reset |
tab.playwright.evaluate(() => document.body.innerText, undefined, { timeoutMs: 10000 }) |
Still did not return within the 30 s outer timeout |
These are individual observed measurements, not benchmark averages. A blank-page DOM snapshot also succeeded once in approximately 0.03 s. Screenshot success was verified on the other website, not separately claimed for example.com.
Recovery attempts and boundaries
- User reported manual refresh, reopening pages and restarting the desktop app did not recover the behavior.
- Resetting the CUA JavaScript environment did not recover it.
- A separate diagnostic task reproduced the loaded-page structured-reading failures.
- User confirmed there was no visible pending browser approval prompt.
- User uninstalled/reinstalled the app; the public example.com test still failed afterward.
- Before reinstall,
codesign --verify --deep --strict --verbose=4 /Applications/ChatGPT.appoutside the execution sandbox passed (valid on disk; satisfies Designated Requirement). A sandbox-only signature failure was contradicted by that check and is not evidence of app corruption. - No application files or permission settings were patched; no access checks were disabled and no website forms were submitted.
Expected behavior
AX/DOM/text reads should return page content, or fail within the requested timeout with an actionable error identifying the failing layer. An internal 10-second timeout should not silently remain pending until a 30-second outer timeout resets the kernel.
Requested investigation
Please trace where the structured-read request stops progressing, contrasting it with successful tab metadata/screenshot requests, including timeout/cancellation propagation. Current evidence does not identify whether access checks, execution setup, dispatch, or result delivery is responsible.
Related but not identical: #42459 (macOS in-app URL-open timeout), #45576 (Windows Chrome transport failure; in-app DOM reportedly works there).
Privacy
This report intentionally excludes account names, private/enterprise URLs, local user paths, task/session identifiers, screenshots, cookies, credentials, browser storage, and raw logs. Only the public example.com URL is included.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Run the example.com reproduction through mcp__cua_repl.js, beginning with cua.getState() and the actual IDs passed to cua.getTab(). Compare the successful browser.tabs.get metadata and screenshot paths with tab.playwright.domSnapshot() and evaluate(), then trace timeout and cancellation behavior. Done means structured AX/DOM/text reads return page content or fail within the requested timeout with an actionable layer-specific error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100