openai / openai/codex

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

Open
#45,868 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app browser bug tool-calls
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, build 9275.
  • 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

  1. Manually open https://example.com/ in the desktop in-app browser; the page visibly loads.
  2. In a task, run await cua.getState() through mcp__cua_repl.js.
  3. Use the actual browser and tab IDs returned by that inventory, then run:
    var tab = await cua.getTab(actualTabId, { browser: actualBrowserId });
    
  4. 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.app outside 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.