codex - 💡(How to fix) Fix Chrome/browser-use setupAtlasRuntime can hang when ambient /backend-api/me probe does not complete

Environment

• Codex Desktop App: 26.506.21252 (build 2575)
• Bundled codex-cli: 0.129.0-alpha.15
• Platform: macOS 26.3.1, Darwin 25.3.0, Apple Silicon
• Chrome: 148.0.7778.97
• Plugin: openai-bundled Chrome plugin 0.1.7; Chrome extension installed/enabled, extension package version 1.1.4_0

Summary

The openai-bundled Chrome/browser-use plugin cannot initialize in Codex Desktop. Calling the official setupAtlasRuntime() from browser-client.mjs hangs until the JavaScript execution environment times out with:

js execution timed out; kernel reset, rerun your request

In this reproduction, the failure appears to occur during browser-use bootstrap before any browser tab work. The local extension and native messaging host appear installed correctly, and the bundled browser client file matches the packaged marketplace hash. Local code inspection indicates that setupAtlasRuntime() starts an ambient account/network initialization branch that performs a non-browser nodeRepl.fetch() to https://chatgpt.com/backend-api/me. In this environment, that request remains pending/hangs in the Node REPL path.

Minimal reproduction

In a Codex Desktop thread with the Chrome/browser-use plugin available:

const { setupAtlasRuntime } = await import("<bundled-chrome-plugin>/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });

Observed result:

js execution timed out; kernel reset, rerun your request

Additional local probes:

• Importing browser-client.mjs alone returns quickly.
• Calling setupAtlasRuntime({ globals: globalThis }) hangs before browser tab operations.
• Direct nodeRepl.fetch("https://chatgpt.com/backend-api/me") shows the same timeout behavior in this environment.
• A disallowed URL such as https://example.com fails quickly with an allowlist error, so nodeRepl.fetch can return quickly on other paths.

Local code path evidence

In the bundled browser-client.mjs:

• Sn resolves to globalThis.nodeRepl.fetch when available.
• The exported setupAtlasRuntime function is minified as zse and executes vc(), Dy() during setup.
• Dy() starts ambient network initialization unless Ps() returns true.
• The ambient branch calls ep() without awaiting it.
• ep() calls Ry().
• Ry() calls:

Sn("https://chatgpt.com/backend-api/me")

So the precise claim is: setup starts a pending ambient non-browser fetch to /backend-api/me; it is not a user-authored JS call, and it appears before the browser client becomes usable in this reproduction.

Network observation

In this network environment, requests to both of the following URLs return a Cloudflare challenge page instead of the expected application/API response:

https://chatgpt.com/
https://chatgpt.com/backend-api/me

Relevant headers observed from command-line HTTP probes:

HTTP/2 403
cf-mitigated: challenge
server: cloudflare
content-type: text/html; charset=UTF-8

I do not want to overstate causality: the Cloudflare challenge is an observed external symptom and a plausible trigger for the non-browser nodeRepl.fetch path to fail or hang, but the timeout alone does not prove Cloudflare is the only root cause. The user-visible bug is that browser-use setup hangs instead of failing fast or degrading when this ambient probe cannot complete normally.

Diagnostics already checked

• The browser_use feature is enabled.
• Chrome extension check reports installed, registered, enabled.
• Native messaging manifest exists and points to the expected host origin.
• Native host binary exists and is executable.
• browser-client.mjs SHA-256 matches the bundled marketplace copies:

166098b9d347eab529245458a72c84f666c56a9d357a0e8c86cb72ae70f0e9c8

• Restarting Codex Desktop and Chrome did not fix the issue.
• Reinstalling the Chrome plugin did not fix the issue.

Internal switch observation

The bundled client appears to have a code-level request metadata switch:

x-codex-browser-use-disable-ambient-network

The ambient branch is skipped only when:

globalThis.nodeRepl?.requestMeta?.["x-codex-browser-use-disable-ambient-network"] === true

In the packaged app, nodeRepl.requestMeta is not user-mutatable from JS, and I could not find evidence of a supported user config/UI path to inject this request metadata key.

Expected behavior

setupAtlasRuntime() should not be able to hang indefinitely because an optional ambient account/telemetry/user probe cannot complete. It should do one of the following:

1. fail fast with a clear browser-use initialization diagnostic,
2. put a short timeout around the ambient nodeRepl.fetch calls,
3. treat non-JSON/403/HTML challenge responses as a recoverable ambient probe failure,
4. skip/degrade optional ambient initialization and still allow browser backend discovery where safe, or
5. expose a supported way for the host/user configuration to set x-codex-browser-use-disable-ambient-network.

Why this matters

The current failure mode looks like a generic JavaScript execution timeout even though the Chrome extension and native host are installed correctly. This makes the issue hard to distinguish from a broken Chrome plugin install, while in this reproduction the failure appears to occur during browser-use bootstrap before any browser tab work.