Chrome extension deep control hangs while direct chrome.debugger works; ambient network adds ~30s delay

Open 💬 3 comments Opened Jul 1, 2026 by wangjingu

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.81905 (CFBundleVersion 4598)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

There seem to be two separate issues in the Codex Desktop Chrome extension/browser-client path.

A. Ambient/privileged network initialization delays normal browser actions by about 30s in a managed proxy network.

  • tab.goto("https://www.baidu.com/") eventually succeeds but takes about 30s.
  • During the operation, Codex browser-client logs timeouts to https://ab.chatgpt.com/v1/initialize / Statsig.
  • On the same machine, shell proxy access to that endpoint returns quickly with 401, while direct access times out.
  • Setting NODE_USE_ENV_PROXY=1 plus proxy env via shell and launchctl did not make Codex Desktop browser-client privileged fetch honor the proxy.
  • In this packaged Desktop node_repl, globalThis.nodeRepl.env is frozen as an empty non-extensible object, so BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 cannot be injected at runtime.

B. Deep control hangs independently of Chrome debugger itself.
The extension/native-host path is healthy enough for basic tab discovery and metadata, and direct CDP through the extension Service Worker works. However page-level operations through Codex browser-client Playwright/CDP hang, return empty results, or ignore timeoutMs.

What works:

  • browser.nameSession: OK
  • browser.user.openTabs: OK
  • claimTab: OK
  • tab.url: OK
  • tab.title: OK
  • tabs.new: OK
  • tab.goto: OK but slow, about 30s
  • Direct extension Service Worker chrome.debugger.attach: OK
  • Direct Service Worker Runtime.evaluate: OK
  • Direct Service Worker Page.getFrameTree: OK
  • Direct Service Worker detach: OK

What fails via Codex browser-client on the same target tab:

  • tab.playwright.evaluate("document.title"): hangs / empty result / outer timeout
  • raw cdp.send("Runtime.evaluate", ...): hangs for >65s and sometimes causes the JS kernel to reset
  • raw cdp.send("Page.getFrameTree", ..., { timeoutMs: 8000 }): hangs; timeoutMs does not appear to bound the lower native/message bridge pending request

After the deep-control timeout, the extension-host process, the Unix socket under /tmp/codex-browser-use/...sock, and node_repl remain alive. This looks like a pending request that never resolves rather than a host crash.

What steps can reproduce the bug?

Minimal repro A: ambient network delay

  1. In a network where ab.chatgpt.com requires the system proxy, use Codex Desktop browser-client against the Chrome extension.
  2. Run tab.goto("https://www.baidu.com/").
  3. Observe it eventually succeeds after about 30s.
  4. Observe ab.chatgpt.com/v1/initialize / Statsig 10s timeout(s) during the operation.
  5. Verify from shell that proxy access to ab.chatgpt.com/v1/initialize returns quickly with 401, while direct access times out.
  6. Set NODE_USE_ENV_PROXY=1 plus HTTP(S)/ALL proxy via shell/launchctl, restart Codex and Chrome, and observe the same about-30s delay.

Minimal repro B: deep-control bridge

  1. Open a normal page in Chrome, e.g. https://www.baidu.com/.
  2. In the Codex extension Service Worker DevTools, run direct chrome.debugger CDP calls:
  • attach to the page tab
  • Runtime.evaluate for document.title
  • Page.getFrameTree
  • detach

All succeed.

  1. From Codex browser-client, use the same Chrome extension connection:
  • openTabs
  • claimTab
  • tab.title
  • tab.url

These succeed.

  1. On the same claimed tab, run:
  • tab.playwright.evaluate("document.title")
  • raw CDP Runtime.evaluate
  • raw CDP Page.getFrameTree with { timeoutMs: 8000 }
  1. Observe these calls hang/return empty or run until the outer JS kernel times out/resets.

What is the expected behavior?

  • Ambient initialization should respect the managed proxy configuration, or be timeout-isolated so user browser actions are not delayed by about 30s Statsig/ab.chatgpt.com timeouts.
  • Browser-client Playwright/CDP calls should return the same results as direct extension Service Worker chrome.debugger CDP calls on the same tab.
  • If the bridge cannot complete a request, timeoutMs should bound the full browser-client -> native host -> extension -> debugger request and reject with diagnostics identifying the failing layer: extension bridge, target/session mapping, page runtime/readiness, or native/message pending request.

Additional information

Potential duplicate note: GitHub suggested #29385, which appears to cover the ambient ab.chatgpt.com / about-30s navigation delay. This report intentionally includes that evidence but the additional focus is the independent deep-control failure: direct extension Service Worker chrome.debugger CDP succeeds while Codex browser-client Playwright/CDP calls hang on the same tab.

Environment details:

  • Codex App: 26.623.81905 (CFBundleVersion 4598)
  • Codex CLI: 0.142.4
  • Chrome: 149.0.7827.201
  • Platform: Darwin 25.5.0 arm64 arm
  • Chrome plugin package: openai-bundled/chrome/26.623.81905
  • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Chrome extension version: 1.1.5
  • Native host: com.openai.codexextension
  • Browser client: .codex/plugins/cache/openai-bundled/chrome/26.623.81905/scripts/browser-client.mjs

Suspected layer:
Since direct Service Worker chrome.debugger works, this does not look like extension installation/profile state, native host manifest, Chrome debugger permission, the Chrome Remote Debugging setting, or target-page debuggability.

The remaining suspect is the bridge path:
browser-client.mjs -> node_repl/browser-use runtime -> Codex app/browser-use bridge -> native messaging host -> extension service worker -> chrome.debugger -> response mapping back.

Possible failure modes: request/response id mismatch, target/session/tab id mapping issue, readiness/lifecycle wait on the wrong context, or a lower native/message bridge pending request not being aborted by wrapper timeoutMs.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗