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

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #29385

Powered by Codex Action

你用的是codex + deepseek 吗？

Independent reproduction on macOS, including the raw Network domain.

Environment

• macOS, Apple Silicon
• ChatGPT Desktop downgraded to 26.707.62119
• Bundled Chrome plugin: chrome@26.707.62119
• Bundled Codex CLI from the newer installed build was previously observed as codex-cli 0.144.2
• Chrome extension site access: all sites
• Full CDP access enabled in the ChatGPT Chrome extension developer settings
• Target page: a normal authenticated HTTPS page on chanmama.com

The downgrade was necessary because Desktop/plugin 26.707.71524 has a separate bootstrap regression:

TypeError: Cannot redefine property: process
at scripts/browser-client.mjs:33:22

That regression is tracked in #32925.

What works after downgrading

• Browser runtime imports successfully
• agent.browsers.get("extension")
• browser.nameSession(...)
• browser.user.openTabs()
• The target tab is discovered with the correct title and URL
• browser.user.claimTab(...)
• tab.capabilities.get("cdp")
• The cdp capability documentation is returned and lists send() / readEvents()
• Basic screenshot against a GitHub tab worked before enabling/rebinding full CDP

What fails

The first raw CDP command hangs until the outer Node REPL call times out and resets:

const cdp = await tab.capabilities.get("cdp");
await cdp.send("Network.enable", {});

Observed result:

js execution timed out; kernel reset, rerun your request

The failure was reproduced after splitting the flow into separate calls:

1. openTabs() → succeeds immediately.
2. claimTab(tabInfo) → succeeds immediately.
3. tab.capabilities.get("cdp") → succeeds immediately.
4. cdp.send("Network.enable", {}) → hangs until the outer timeout resets the kernel.

This also reproduced with:

• cdp.send("Runtime.evaluate", ...)
• A fresh Chrome restart
• A newly opened user tab
• A brand-new agent-created tab using browser.tabs.new(), followed by navigation to the HTTPS target before the first CDP command, as required by the capability documentation
• Both the authenticated target site and a GitHub control tab

Therefore it is not specific to the target page or to claiming an existing user tab.

Other observations

Before the CDP hang, browser-client also logged timeouts to:

https://ab.chatgpt.com/v1/initialize
https://ab.chatgpt.com/v1/rgstr

However, the CDP hang persists independently and lasts until the outer JS execution timeout. Restarting Chrome, refreshing the page, enabling all-sites access, enabling full CDP access, and creating a fresh controlled tab did not resolve it.

This closely matches the deep-control bridge failure described in this issue: the browser/extension connection is healthy enough for discovery and claiming, but the first page-level/raw CDP request never returns.

Closing this after additional investigation and a successful end-to-end retest.

For my environment, the primary cause was the local macOS network-routing path. After moving to a network setup that provides consistent process-level routing for Codex and its native helper processes, both symptoms described in this issue stopped reproducing:

• Existing authenticated Chrome tab claim: 28 ms
• DOM snapshot on that tab: about 0.5 s
• Google navigation: about 0.9 s
• CDP Network.enable plus reload/event capture: 185 ms, HTTP 200, 0 failed requests
• Five Page.getFrameTree calls: 15 ms median
• Five DOM snapshots: 8 ms median
• No Statsig errors during an additional 12-second observation window

This retest did not rely on permanently disabling ambient networking.

The key networking detail is that Statsig requests to ab.chatgpt.com, made through the native nodeRepl.fetch path, did not appear to reliably follow the macOS system proxy in the original setup. A normal Chrome tab being able to reach the hostname—or a TUN dashboard showing that a connection matched a proxy rule—was not sufficient to prove that the Codex helper-process request path was actually healthy.

Recommended approach for the same symptoms:

1. Use a macOS VPN/proxy configuration that consistently routes Codex, Codex Service, and native helper-process traffic, not only browser traffic.
2. Validate ab.chatgpt.com:443 from the actual Codex/helper-process network context and check request latency.
3. Treat BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 only as a temporary diagnostic fallback. Remove it after fixing the network path so ambient networking is not permanently disabled.

This does not rule out separate bridge regressions in older builds or other environments, but the original issue is no longer reproducible for me once the network path is correct, so I am closing it.

Update: I found a durable workaround that survives a full ChatGPT/Codex Desktop restart on macOS.

Create the system-level Codex configuration:

sudo mkdir -p /etc/codex
sudoedit /etc/codex/config.toml

Add:

[mcp_servers.node_repl.env]
BROWSER_USE_DISABLE_AMBIENT_NETWORK = "1"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "BROWSER_USE_DISABLE_AMBIENT_NETWORK,HTTP_PROXY,HTTPS_PROXY"
HTTP_PROXY = "http://127.0.0.1:7890"
HTTPS_PROXY = "http://127.0.0.1:7890"

Replace 127.0.0.1:7890 with the HTTP proxy exposed by your local proxy client, then quit and reopen ChatGPT/Codex Desktop completely.

I tested this with Surge in macOS System Proxy mode, with TUN disabled.

Why /etc/codex/config.toml is important:

• Adding these keys to ~/.codex/config.toml was not durable: Desktop rewrote the managed bundled node_repl block on restart and removed the custom keys.
• launchctl setenv alone was not sufficient: the GUI process inherited the variables, but HTTP_PROXY / HTTPS_PROXY did not reach the bundled node_repl runtime.
• Project-level .codex/config.toml worked, but only for that project.
• The system config persisted across restarts and supplied the missing node_repl.env values without modifying the generated user config.

Validation after restart, with the previous LaunchAgent / launchctl variables removed and no proxy keys in ~/.codex/config.toml:

• node_repl received BROWSER_USE_DISABLE_AMBIENT_NETWORK=1, HTTP_PROXY, and HTTPS_PROXY
• Existing authenticated Chrome tab claim: 38 ms
• DOM read on Codeup: 529 ms
• Google navigation: 1.03 s; DOM read: 45 ms
• CDP Network.enable: 24 ms
• Reload: 312 ms; 17 requests, 12 responses, 0 failures; main document HTTP 200
• Repeated median: DOM 11 ms; CDP Page.getFrameTree 15 ms

So the original ~30 s delay and the page-level/CDP hangs are no longer reproducible in this setup.

This is still a workaround rather than a complete product fix. Ideally, Desktop should either preserve user-supplied node_repl.env keys for the bundled server or expose a supported proxy setting for the bundled browser runtime.

sudoedit /etc/codex/config.toml

For Windows users, the file path is: C:\ProgramData\OpenAI\Codex\config.toml