Skip to content

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

Closed
Closed
Chrome extension deep control hangs while direct chrome.debugger works; ambient network adds ~30s delay#30841
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

Description

@hi-max-wang
hi-max-wang
opened on Jul 1, 2026

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.
  3. From Codex browser-client, use the same Chrome extension connection:
    • openTabs
    • claimTab
    • tab.title
    • tab.url
      These succeed.
  4. On the same claimed tab, run:
    • tab.playwright.evaluate("document.title")
    • raw CDP Runtime.evaluate
    • raw CDP Page.getFrameTree with { timeoutMs: 8000 }
  5. 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.

Activity

  1. hi-max-wang
    added
    appIssues related to the Codex desktop app
    on Jul 1, 2026
  2. github-actions
    added
    bugSomething isn't working
    browser
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jul 1, 2026

  3. github-actions commented on Jul 1, 2026

    @github-actions
    github-actionsbot
    on Jul 1, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. ghost-909 commented on Jul 10, 2026

    @ghost-909
    ghost-909
    on Jul 10, 2026

    你用的是codex + deepseek 吗？

  5. python-dy commented on Jul 14, 2026

    @python-dy
    python-dy
    on Jul 14, 2026 – with ChatGPT Codex Connector

    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.

  6. hi-max-wang commented on Jul 21, 2026

    @hi-max-wang
    hi-max-wang
    on Jul 21, 2026 – with ChatGPT Codex Connector
    Author

    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.

  7. hi-max-wang
    closed this as completedon Jul 21, 2026

  8. hi-max-wang commented on Jul 21, 2026

    @hi-max-wang
    hi-max-wang
    on Jul 21, 2026
    Author

    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.

  9. cesaryuan commented on Jul 22, 2026

    @cesaryuan
    cesaryuan
    on Jul 22, 2026

    sudoedit /etc/codex/config.toml

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

  10. sekiyaoshen-blip commented on Sep 13, 2026

    @sekiyaoshen-blip
    sekiyaoshen-blip
    on Sep 13, 2026

    在较新的 macOS 桌面版上复现了很相似的现象，想请教是否仍与辅助进程的代理继承有关，以及当前版本推荐的配置入口。

    环境：ChatGPT/Codex Desktop 26.901.51231（build 8109）、macOS 15.7.9 arm64、Chrome 153.0.8010.36。只使用官方浏览器工具和不含登录信息的 https://example.com 测试页。

    在重装 Chrome 扩展后，新建一个独立 Codex 任务，并将各步骤分开调用：

    步骤 实测结果
    浏览器/标签页识别 0.925 秒，成功
    新建 about:blank 0.648 秒，成功
    导航至 example.com 30.017 秒后成功返回
    单独读取正文 getAXState() 45.014 秒后 js execution timed out; kernel reset, rerun your request

    扩展重载、Chrome 完整重启、扩展重装、全新任务均已测试，仍出现上述延迟/超时。没有清除 Chrome 用户数据，也没有修改官方插件源码或调用未支持的调试方式。

    额外的只读检查：系统使用 PAC；终端已有 HTTP_PROXY/HTTPS_PROXY，但正在运行的 cua_repl 启动器及其 node_repl 子进程未显示这些代理环境变量。终端直连 ab.chatgpt.com 的连接测试在 5 秒上限超时，通过现有本机 HTTP 代理则约 1.1 秒返回 HTTP 403（这里只说明传输有响应，不表示初始化成功）。尚未证明这就是正文读取卡住的根因。

    请问有人在 26.901 或更新版本复现过吗？此前给出的 [mcp_servers.node_repl.env] workaround，在现在由 unified-computer-use 插件启动的 cua_repl 路径上是否仍适用？有没有无需修改 bundled plugin、且不长期禁用 ambient networking 的受支持配置方式？

    English summary: Similar reproduction on Desktop 26.901.51231, macOS 15.7.9 arm64, Chrome 153.0.8010.36. Discovery/new-tab calls complete in under a second; standalone navigation takes 30.017 s; a separate getAXState call hits the 45 s outer timeout. This persists after extension reinstall and in a fresh task. The shell has an existing HTTP proxy, but running cua_repl/node_repl helpers show no proxy environment variables. Is there a supported proxy configuration for the newer unified-computer-use/cua_repl path, without patching bundled plugins or permanently disabling ambient networking? No private logs, account details, or session identifiers are attached.

  11. hi-max-wang commented on Sep 13, 2026

    @hi-max-wang
    hi-max-wang
    on Sep 13, 2026
    Author

    @sekiyaoshen-blip 我原先在这个 Issue 中的问题已在当时的环境里解决。你提到的新版 unified-computer-use / cua_repl 代理配置问题，我后来单独提交在 #42454，建议到那里继续跟踪：

    新版 cua_repl 不能只沿用这里旧的 [mcp_servers.node_repl.env] 配置。我的 macOS 临时方案是在 /etc/codex/config.toml 中配置一个本地启动器，读取当前 unified-computer-use 插件的 MCP 定义，再传入代理环境变量，避免固定版本目录。新评论已补上启动器示例和使用步骤。

    另外，我现在已移除 BROWSER_USE_DISABLE_AMBIENT_NETWORK，不再需要通过禁用 ambient networking 来缓解；当前只保留 HTTP_PROXY、HTTPS_PROXY 和 NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY"。如果复制了我之前的配置，请同时删掉禁用开关和 allowlist 里的对应项。

    这仍是临时方案，不是官方已支持的配置入口，也不能据此确认你的 getAXState() 超时一定由代理继承引起。完全退出并重启后，需要确认实际运行的 cua_repl 确实使用该启动器并收到代理变量，再验证页面读取；仅能列出标签页不算恢复。欢迎在新 Issue 里补充验证结果。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions