codex - 💡(How to fix) Fix Expose a supported way to disable browser-use ambient network initialization

Environment

• Codex Desktop App: 26.506.21252 / build 2575
• Platform: macOS 26.3.1, Darwin 25.3.0, Apple Silicon
• Chrome plugin: openai-bundled Chrome plugin 0.1.7
• Related issue: #21704

Summary

There appears to be an existing internal browser-use request metadata flag that can disable the ambient network/account initialization path:

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

When this flag is present in nodeRepl.requestMeta, the bundled browser-client.mjs skips the ambient branch that starts Sentry/Statsig/account initialization and eventually calls:

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

That is useful for cases like #21704, where the Chrome extension backend is healthy but setupAtlasRuntime() hangs because the non-browser nodeRepl.fetch() path gets stuck on the ambient /backend-api/me probe.

The problem is that there does not appear to be a supported way for a packaged Codex Desktop user to set this request metadata flag.

What I observed

browser-client.mjs contains the gate:

var j2 = "x-codex-browser-use-disable-ambient-network";
function Ps() {
  return globalThis.nodeRepl?.requestMeta?.[j2] === true;
}

var Ry = async () => {
  let e = await (await Sn("https://chatgpt.com/backend-api/me")).json();
  ...
};

var Dy = () => {
  Ps() || (Og(), Iy(), ep());
};

So when Ps() is true, the ambient network/account path is skipped.

The node_repl binary also appears to recognize BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 when launched directly. In a standalone MCP probe, launching node_repl with:

BROWSER_USE_DISABLE_AMBIENT_NETWORK=1

produced:

{
  "x-codex-browser-use-disable-ambient-network": true
}

However, setting this for Codex Desktop did not make the packaged app's built-in node_repl receive the flag. After restart, the node_repl process still only received request metadata similar to:

{
  "x-codex-browser-use-available-backends": ["chrome", "iab"]
}

I also tried shell_environment_policy.set in ~/.codex/config.toml; it parsed successfully but did not affect the built-in node_repl MCP server environment/request metadata.

Local validation of a possible fix

Without modifying the app bundle or browser-client.mjs, I tested a local wrapper via CODEX_NODE_REPL_PATH that:

1. preserves the NODE_REPL_REQUEST_META generated by Codex Desktop;
2. adds "x-codex-browser-use-disable-ambient-network": true;
3. execs the official bundled node_repl binary.

With that metadata present, Chrome browser-use setup started working again:

{
  "disableAmbient": true,
  "backend": "extension",
  "tabCount": 4
}

setupAtlasRuntime() no longer timed out on the ambient /backend-api/me path, and browser.user.openTabs() returned promptly.

This is only a local diagnostic workaround, not a supported fix, but it suggests that the existing metadata flag is sufficient to unblock Chrome extension discovery for this failure mode.

Suggested fixes

Any of these would make the internal flag usable without local wrappers:

1. In the packaged app's browser-use node_repl MCP configuration, honor BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 by adding:

{
  "x-codex-browser-use-disable-ambient-network": true
}

to the generated NODE_REPL_REQUEST_META.

1. Expose a supported Codex config key for this behavior, for example a browser-use setting that maps to the same request metadata flag.

2. Make the ambient /backend-api/me initialization non-blocking or bounded by a short timeout, so Chrome extension discovery can proceed even when the ambient account probe fails, returns HTML, returns a Cloudflare challenge, or otherwise cannot complete.

Expected behavior

If the Chrome extension/native host is healthy, setupAtlasRuntime() should be able to discover and use the Chrome extension backend even when optional ambient account/analytics initialization cannot complete.

Actual behavior

Without the metadata flag, setupAtlasRuntime() can hang until the JS execution kernel times out:

js execution timed out; kernel reset, rerun your request

This happens before any browser tab work, even though the extension-host socket can be healthy.