[Codex app] Allow stable cua_repl env overrides instead of replacing generated config on startup

What issue are you seeing?

After Codex Desktop migrated browser/computer-use control from node_repl to the generated cua_repl MCP server, existing proxy-related environment overrides no longer reach the new runtime.

The Chrome extension still connects and tab discovery can work, but page operations time out or report an unattached debugger. Manually adding the same environment variables to a complete cua_repl server definition restores Chrome, in-app Browser, and desktop control.

That workaround is not durable:

• the full cua_repl definition contains app-version-specific executable and plugin paths;
• Codex Desktop regenerates/replaces the cua_repl server configuration during startup;
• a startup config/batchWrite uses replace semantics, so a user cannot maintain a small overlay containing only environment variables.

At the time of the original report, this required rebuilding the full MCP definition after updates or downgrading. A later temporary launcher workaround is linked below; a supported environment override is still needed.

Environment

• macOS, Apple Silicon
• Reproduced with Codex Desktop 26.901.20858
• Bundled Codex runtime: 0.153.0-alpha.5
• Last known working build before the cua_repl migration on this machine: 26.810.52044 / 0.148.0-alpha.9
• Network requires a local HTTP(S) proxy

No account identifiers, credentials, local usernames, private paths, proxy ports, or private task contents are included in this report.

Steps to reproduce

1. Configure proxy variables for the existing node_repl server, including HTTP_PROXY, HTTPS_PROXY, and the Node REPL environment allowlist.
2. Upgrade to a Codex Desktop build that uses generated cua_repl for Chrome/Browser/Computer Use.
3. Verify that the Chrome extension connects and tabs may be listed, but page reads/actions time out.
4. Add the same proxy-related variables to a complete manual cua_repl definition.
5. Restart Codex and verify that Chrome, in-app Browser, and desktop control work.
6. Restart or update Codex again.
7. Observe that the generated cua_repl configuration is replaced/regenerated, while a manually maintained full definition also becomes stale because its executable/plugin paths are versioned.

Representative failures included:

js execution timed out; kernel reset
Debugger unattached

Expected behavior

Please support one of these two behaviors:

1. Preferred: provide a documented, stable user override layer for generated plugin runtimes, for example:

[mcp_servers.cua_repl.env]
HTTP_PROXY = "http://127.0.0.1:<port>"
HTTPS_PROXY = "http://127.0.0.1:<port>"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY"

Codex should continue to own and update the generated executable, arguments, and versioned plugin paths, while merging explicit user environment overrides on top.

2. Alternatively, do not replace a user-supplied cua_repl configuration on every startup.

A user should not need to copy the complete generated MCP definition or pin version-specific paths just to pass supported environment variables to the plugin runtime.

Why this matters

This makes Chrome, Browser, and Computer Use unusable in proxy-required environments even though the extension and local proxy are healthy. The temporary system-level launcher workaround below avoids hardcoding plugin versions, but still depends on internal plugin metadata/cache layout.

Current temporary workaround (updated 2026-09-13)

See the updated launcher/configuration instructions.

My current local system configuration uses only HTTP_PROXY, HTTPS_PROXY, and NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "HTTP_PROXY,HTTPS_PROXY". Disabling ambient networking is no longer required in my setup. I have removed BROWSER_USE_DISABLE_AMBIENT_NETWORK from both the configuration and the allowlist; the examples here have been corrected accordingly. If you copied my earlier example, remove that assignment and its allowlist entry rather than keeping ambient networking disabled.

For the newer generated cua_repl path, the legacy [mcp_servers.node_repl.env] block alone is not sufficient. The temporary approach uses /etc/codex/config.toml plus a local launcher that loads the current plugin-declared transport and overlays the proxy environment. The small env-only block in “Expected behavior” above is the requested product interface, not a claim that it already works by itself.

The earlier launcher verification covered MCP initialization, JS startup, and Chrome tab enumeration. This configuration update is not a new end-to-end retest or a guarantee that it fixes every debugger/attachment timeout. After a full app restart, verify that the live runtime actually uses the launcher, receives the proxy environment, and completes a real page read/action. A later Windows report in this thread found its live runtime still used the official launcher after restart.

Related issues

• #30841 — earlier browser/node_repl report, resolved in my original environment; newer cua_repl follow-up is tracked here
• #21713 — node_repl does not inherit proxy environment
• #42116 — startup config/batchWrite can replace/drop unmanaged config

Start by tracing the startup config/batchWrite flow and the generated cua_repl configuration described in the issue. Define how stable user environment overrides are merged without replacing generated executable, argument, and plugin-path fields, then verify behavior across restart and update scenarios.