[macOS][26.820.60940][Chrome] Runtime.evaluate times out at ~30s while DOM/screenshot return after the same delay

What version of the Codex App are you using?

• ChatGPT/Codex Desktop: 26.820.60940
• Standalone Codex CLI: 0.149.1
• ChatGPT Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Chrome extension version: 1.2.27268.51612_0
• Platform: macOS, Apple Silicon / arm64
• Subscription: ChatGPT Plus

Browser-related features are enabled:

• browser_use: enabled
• browser_use_external: enabled
• in_app_browser: enabled
• browser_use_full_cdp_access: enabled

Full CDP access has also been enabled in the browser integration.

What issue are you seeing?

The Chrome backend can be discovered and can create/navigate tabs, read basic URL/title metadata, capture a DOM snapshot, and capture a screenshot. However, every page-context Runtime evaluation consistently fails after approximately 30 seconds.

On a fresh neutral HTTPS page (https://example.com/):

• Chrome backend discovery: ~52 ms
• backend get: ~35 ms
• tab creation: ~103 ms
• navigation: succeeds, but tool call takes ~37.6 s
• Runtime.evaluate equivalent for 1+1: fails after ~30.05 s
• document.readyState: fails after ~30.05 s
• document.title: fails after ~30.05 s
• body text check: fails after ~30.05 s
• DOM snapshot: succeeds, but only after ~30.07 s
• screenshot: succeeds, but only after ~30.07 s

The DOM snapshot is non-empty and contains Example Domain, and the screenshot is successfully captured. This means the page itself is loaded and the Chrome backend is not completely disconnected, but the deeper control path shows a very consistent ~30 s pending/deadline behavior.

No safe/actionable Runtime error text is surfaced; the calls simply return an error after the ~30 s delay.

Steps to reproduce

1. On macOS with ChatGPT/Codex Desktop 26.820.60940 and the bundled/official Chrome integration enabled, confirm the Chrome backend is available.

2. Start a fresh standalone Codex CLI session (codex-cli 0.149.1).

3. Confirm browser discovery returns Chrome and selecting the Chrome backend succeeds.

4. Create a brand-new controlled tab; do not use an existing user tab.

5. Navigate once to:

   https://example.com/

6. After navigation completes, independently run read-only page-context evaluations:

   • 1 + 1
   • document.readyState
   • document.title
   • document.body ? document.body.innerText.includes("Example Domain") : false

7. Independently request a DOM snapshot and a screenshot.

Observed result on this machine:

Probe	Result	Approx. latency
Chrome backend discovery	success	52 ms
Tab create	success	103 ms
Navigate to example.com	success	37.6 s
Runtime 1+1	error	30.05 s
Runtime readyState	error	30.05 s
Runtime document.title	error	30.05 s
Runtime body-text check	error	30.05 s
DOM snapshot	success	30.07 s
Screenshot	success	30.07 s

The DOM result contains Example Domain, proving the target page content is available despite the Runtime failures.

Expected behavior

• Page-context Runtime calls should return promptly on a trivial page such as example.com.
• 1+1 should return 2 and document.readyState should return complete without a ~30 s delay.
• DOM and screenshot operations should not require ~30 s when the page is already loaded.
• If the underlying bridge cannot complete a request, the failure should be bounded and report which layer timed out (ambient initialization, native message transport, target/session mapping, CDP command, etc.).
• Ambient/telemetry network failures should not block unrelated user-requested Browser Use operations.

Network/environment observation

There is a potentially relevant local network condition, so I am not claiming the bridge itself is definitively the root cause:

• the shell environment contains HTTP(S)/ALL proxy variables pointing at localhost proxy endpoints that are currently unavailable;
• direct external HTTPS requests succeed when those proxy variables are explicitly bypassed;
• Browser Use operations show a repeatable delay clustered around ~30 seconds.

This may be related to ambient network initialization or helper-process proxy routing. It would be useful if Browser Use exposed whether an ambient request (for example Statsig / ab.chatgpt.com) is the operation blocking the page-control call.

Additional context

There is also a separate IAB observation on the same install: the in-app browser backend remains unavailable in browser discovery even after one clean Desktop restart and from an independent new CLI session, while the Chrome backend is discovered normally. I am including this only as context; I am not asserting that it has the same root cause as the Chrome Runtime timeout.

The Chrome reproduction above does not depend on the production site that originally led to the investigation. It reproduces on https://example.com/.

Related issues

• #30841 — very similar split between healthy basic Chrome tab control and hanging deep-control/CDP calls. That issue was later closed after the reporter changed the local macOS process-level network routing and could no longer reproduce it.
• #29385 — documents ~30 s Browser Use delays when ab.chatgpt.com ambient requests time out in a restricted/proxied environment.

This report is on the newer 26.820.60940 / CLI 0.149.1 / extension 1.2.27268.51612_0 stack and provides a fresh neutral-page reproduction with four independent Runtime calls all failing at approximately the same 30-second boundary.

Safety / diagnostic scope

The reproduction was read-only. No cookies, tokens, Authorization headers, browser storage, passwords, or private page contents were collected or included.

Start with Chrome backend discovery, navigation, Runtime.evaluate, DOM snapshot, and screenshot using the listed example.com reproduction, then compare their timeout paths with the ambient proxy/network behavior. Done means trivial Runtime calls return promptly, DOM and screenshot operations avoid the unexplained delay, and any blocking layer reports a bounded, actionable timeout.