Repository navigation
In-app browser: URL/title works but DOM inspection times out on real pages #22797
Description
What happened?
Codex Desktop in-app browser can navigate to real webpages and read tab metadata, but Browser Use DOM inspection hangs/timeouts on real pages.
Observed behavior:
- For
https://www.baidu.com/:tab.url()succeeds and returnshttps://www.baidu.com/tab.title()succeeds and returns百度一下，你就知道tab.playwright.locator("body").innerText(...)times outtab.playwright.domSnapshot()times out
- For a WeChat article page:
tab.url()succeedstab.title()succeeds#activity-name,#js_content,domSnapshot(), visible DOM, screenshot, and clipboard-based extraction time out
- For
about:blank:tab.playwright.locator("body").count()succeeds and returns1body.innerText()succeeds with empty text
So the in-app browser page and metadata channel work, but DOM inspection for real webpages appears stuck.
Expected behavior
The in-app browser Browser Use backend should support DOM inspection for rendered pages, at least for simple public pages like https://www.baidu.com/.
Environment
- OS: macOS on Apple Silicon
- Codex Desktop App: current desktop app session
- Codex CLI:
0.131.0-alpha.9 - Browser plugin:
openai-bundled/browser/0.1.0-alpha2 - Chrome plugin also installed and working
- In-app browser visible and able to navigate manually
Diagnostics already tried
- Restarted Codex Desktop.
- Installed matching npm CLI version:
@openai/codex@0.131.0-alpha.9. - Recreated the managed standalone path expected by app-server daemon.
- Started app-server daemon successfully.
Daemon status after fix:
{
"status": "running",
"cliVersion": "0.131.0-alpha.9",
"appServerVersion": "0.131.0-alpha.9",
"socketPath": "$HOME/.codex/app-server-control/app-server-control.sock"
}Even after daemon is running, real-page DOM inspection still times out.
Minimal repro
- Open Codex Desktop.
- Open the in-app browser.
- Navigate to
https://www.baidu.com/manually or via Browser Use. - Run Browser Use against the selected IAB tab:
const tab = await browser.tabs.selected();
await tab.url(); // succeeds
await tab.title(); // succeeds
const body = tab.playwright.locator("body");
await body.count();
await body.innerText({ timeoutMs: 15000 });Actual: DOM calls time out / tool execution times out.
Notes
Chrome extension backend works on the same machine for the same WeChat article, so the issue seems specific to the Codex in-app browser Browser Use DOM bridge, not webpage availability.
Activity
caaaptaintop commentedon Aug 31, 2026
Additional macOS reproduction with controlled A/B results.
Environment
26.825.51511(build7377)26.6.2, Apple Silicon / arm6426.825.51511iab)Reproduction and timings
The behavior closely matches this issue:
about:blankhttps://example.com/goto()returned after 30.073 sdomSnapshot()then took another 30.063 sThe desktop lifecycle log showed that the Browser webview attached in about 9 ms and
about:blankreached DOM-ready immediately. The real page reached DOM-ready only after the fixed delay.A fully local page at
http://127.0.0.1:8765/behaved differently:goto(): 5.936 sdomSnapshot(): 132 msA/B checks
Full CDP / Developer mode
full_cdp_access_enabled, fully quit and restarted the app.Network and system proxy
curl https://example.com: 1.01 sexample.comto the macOS proxy bypass list, leaving ChatGPT traffic on the proxy.goto()and another 30.063 s for the DOM snapshot.These results do not look like normal network latency, proxy throughput, machine performance, or full-CDP overhead.
Route/session evidence
Desktop logs repeatedly contain:
Counts observed across separate application processes:
The previous process also recorded repeated:
The fixed 30-second DOM/control delay appears correlated with Browser Use route registration or stale session ownership rather than webpage reachability.
Potentially related:
Could maintainers confirm whether this is a known IAB route/session regression and whether a fixed build or supported route-reset procedure exists? A useful product fix would be to rebuild the session-owned route or fail with a bounded actionable error instead of waiting for repeated 30-second timeouts.