[Regression] In-app Browser and Chrome extension still wait ~30s on ab.chatgpt.com Statsig timeouts in VPN TUN mode

Try adding the config below to ~/.codex/config.toml:

[mcp_servers.node_repl.env]
BROWSER_USE_DISABLE_AMBIENT_NETWORK = "1"
NODE_REPL_UNTRUSTED_ENV_ALLOWLIST = "BROWSER_USE_DISABLE_AMBIENT_NETWORK"

Resolved on my side. The working setup and restart-persistent system-level node_repl proxy configuration are documented here:

https://github.com/openai/codex/issues/30841#issuecomment-5035475747

Additional reproducible data from Codex Desktop 26.803.41515 on macOS:

Before the workaround, setting only BROWSER_USE_DISABLE_AMBIENT_NETWORK=1 removed visible Statsig errors, but page-execution commands still had a fixed ~30s tail: goto 31.5s, DOM snapshot 30.0s, evaluate 30.0s, screenshot 30.0s, and console logs 30.0s.

The durable workaround was to configure the managed node_repl environment at the system level, because Codex Desktop rewrote/removed the proxy variables from the user-level managed block after restart:

[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"

After placing this in /etc/codex/config.toml and fully restarting the app, every fresh node_repl inherited all four values. A clean in-app-browser run against https://example.com/ measured:

• tab creation: 355.7ms
• navigation: 5.67s
• DOM snapshot: 23.0ms
• evaluate: 16.1ms
• screenshot: 23.5ms
• console logs: 7.6ms
• URL/title reads: 0.6ms / 0.4ms

The DOM/evaluate results were correct, the screenshot was valid, console logs contained no Statsig errors, and there were no ab.chatgpt.com OTLP timeout entries after restart. The fixed ~30s command tail is gone.

This suggests two product fixes would be valuable:

1. Reliably preserve/propagate configured proxy variables to the managed browser execution process without requiring /etc/codex/config.toml.
2. Ensure telemetry export can never delay the completion of DOM, evaluate, screenshot, or console commands; a short timeout plus session-level circuit breaker would make the failure mode safer.

Additional no-TUN data from a newer build

Adding a narrower data point from observed behavior; I cannot identify the internal root cause.

Environment

• macOS 26.6 (25G72), Apple Silicon
• Codex desktop 26.803.61601 (build 6396)
• Bundled Node.js v24.14.0
• The macOS HTTP/HTTPS system proxy already points to an existing local proxy at 127.0.0.1:7891
• No TUN was active during these reproductions or the bounded A/B test

Observed behavior

• A separate non-Browser HTTPS request to https://example.com/ was fast, so this was not a general loss of network connectivity.
• A fresh in-app Browser operation took about 64.8 seconds.
• A fresh Chrome-control operation took about 60.8 seconds.
• In ordinary runs, I observed repeated 10-second Statsig initialization/registration timeouts to ab.chatgpt.com. I did not establish that Statsig was the sole cause of the Browser delay.
• An isolated empty-environment fetch to https://ab.chatgpt.com/ using the exact bundled Node binary reached my 8-second test deadline without environment-proxy support, but completed in about 0.7 seconds through the existing local proxy when Node's built-in environment-proxy support was enabled.

One bounded integrated test

I ran one non-persistent test of a child-only proxy setup:

1. I quit the ordinary app completely and launched the same signed build from a clean parent environment.
2. The launch was configured with a pinned child selector pointing to a preflight-checked wrapper designed to scrub inherited proxy/Node overrides, then enable environment-proxy support only for the final child Node.
3. The experimental app became operational.
4. A fresh in-app Browser navigation to https://example.com/ did not return usable content within my predeclared <10s success threshold and reached my predeclared 25-second client-side tool-call deadline.

I did not independently verify that this Browser call invoked the selected wrapper. The attempted setup did not make this operation pass the threshold, but it does not identify the failing internal runtime or request path.

Per the predeclared stop rule, I did not retry, change parameters, or continue to the Chrome test. I quit the experimental instance and reopened Codex normally; network configuration and the global environment remained unchanged.

Expected / request

Could Codex provide documented proxy behavior, or a supported process-scoped proxy setting, for in-app Browser and Chrome-control subprocesses without requiring system-level configuration or global environment changes? It would also help to have timeout isolation between auxiliary requests, such as Statsig or telemetry, and a user-requested browser operation, plus a secret-safe diagnostic of the effective runtime and proxy mode.

Adding a Windows A/B data point that appears to match this issue.

Environment: Codex Desktop / browser plugin 26.810.52044 on Windows. The browser extension was installed and signed in through Microsoft Edge. Edge is not currently supported by the Chrome extension documentation, so this is diagnostic evidence for the shared browser-client path, not a supported-browser confirmation.

Prerequisite: an HTTP(S) proxy was already running, and NODE_USE_ENV_PROXY=1, HTTP_PROXY, HTTPS_PROXY, and NO_PROXY were already set in the environment inherited by Codex. The configuration below does not define a proxy or any proxy values; it only whitelists those existing variables into the node_repl MCP child. Without those pre-existing variables, this snippet alone has no effect.

Before the workaround, three lightweight DOM list reads took 21.216 s, 21.188 s, and 21.159 s (median 21.188 s). Local parsing was only 2–4 ms; almost all time was inside domSnapshot / browser control. Logs repeatedly showed:

[Statsig] POST https://ab.chatgpt.com/v1/rgstr
Timeout of 10000ms expired

This usually occurred twice per call. Inspection indicated that this Statsig path used privileged globalThis.nodeRepl.fetch, while the node_repl child did not receive NODE_USE_ENV_PROXY, HTTP_PROXY, HTTPS_PROXY, or NO_PROXY.

As a project-scoped workaround, I added only the environment-variable names below to the trusted project's .codex/config.toml, then fully quit and restarted Codex:

[mcp_servers.node_repl]
env_vars = ["NODE_USE_ENV_PROXY", "HTTP_PROXY", "HTTPS_PROXY", "NO_PROXY"]

This differs from defining values under [mcp_servers.node_repl.env]: the project config contains no proxy address or credentials and relies on the already configured host environment.

After restart, three equivalent reads took 0.922 s, 0.623 s, and 1.042 s (median 0.922 s, about 23× faster). The Statsig timeout disappeared, and all 14/14 list items were returned with no warning.

One persistence detail: the plugin-managed node_repl block in the user-level config had previously been regenerated on restart and removed a manual env_vars edit; the trusted project-level override persisted. The config reference documents mcp_servers.<id>.env_vars as the allowlist for additional variables passed to an MCP stdio server: https://learn.chatgpt.com/docs/config-file/config-reference

This is a workaround and root-cause data point, not an official fix. Chrome/Edge support boundary: https://learn.chatgpt.com/docs/chrome-extension

Disclosure: This comment is being posted by the user's Codex assistant, with the user's explicit authorization and on their behalf after reviewing local task evidence. Task/thread IDs, website URL, account details, machine names, IP addresses, page content, and local paths have been intentionally omitted.

Adding a distinct same-session cold-start data point from the current macOS build.

Environment

• macOS 26.6.1 (25G76), Apple Silicon
• Codex Desktop 26.810.52044 (build 6662)
• Bundled in-app Browser plugin 26.810.52044
• A local proxy environment was active

First operations in a fresh in-app Browser session

Without changing the proxy or Codex configuration:

• creating a new in-app Browser tab and navigating to an authenticated third-party admin site took 37.676 s
• the browser-client output included a 10-second Statsig registration timeout to ab.chatgpt.com/v1/rgstr
• the first dom_cua.get_visible_dom() call took 30.020 s
• that call emitted multiple 10-second Statsig initialization/registration timeout messages

The requested page itself did load correctly.

Same session after the initial timeout period

The user signed in directly in the in-app Browser's separate profile. The Browser Use runtime was not recreated, Codex was not restarted, and no proxy/configuration change was made between these measurements.

Subsequent operations on the same in-app Browser tab were consistently fast:

• URL/title read: 32 ms
• visible DOM reads: 124-221 ms
• DOM snapshot: 344 ms
• clicks, form interaction, and confirmed submissions: 325 ms-1.869 s
• final confirmed state-changing operation and DOM verification: 1.706 s

Several state-changing operations completed successfully and returned explicit success UI.

Interpretation

This suggests that the approximately 30-second ambient-network delay can sometimes be concentrated in the first Browser Use operations of a session and then disappear without a restart or configuration change. A likely explanation is that ambient initialization finishes, times out, or enters retry backoff/circuit-breaker behavior, but the exact internal mechanism is not visible from the public diagnostics.

This does not resolve the separate Chrome extension deep-control problem. In the same overall workflow, Chrome tab discovery remained fast while DOM, clipboard, and input operations continued to time out. That separate macOS evidence is documented here: #36278 (https://github.com/openai/codex/issues/36278#issuecomment-5326928482).

Request

Please keep Statsig/telemetry initialization completely outside the critical path for navigation, DOM, screenshot, and input operations. A privacy-safe diagnostic showing the browser runtime's effective proxy mode and ambient-network initialization state would also make this much easier to isolate.

Even when the session eventually recovers, the initial 30-38 second ambiguity is disruptive because it can exceed the outer browser-call deadline and look indistinguishable from a failed page operation.