Codex Desktop Node REPL does not inherit proxy environment, causing nodeRepl.fetch and Chrome backend setup to hang on macOS

[gezi-antony]

What issue are you seeing?

On macOS, Codex Desktop's built-in Node REPL runtime does not appear to inherit proxy environment variables, even after the variables are available to the app's shell subprocesses and to launchctl.

This causes nodeRepl.fetch() calls to OpenAI endpoints to hang, and it appears to block Chrome/Browser Use backend setup paths that depend on the Node REPL runtime.

Environment

Codex Desktop: 26.506.21252, build 2575
App-bundled codex-cli: 0.129.0-alpha.15
App-bundled Node: v24.14.0
Chrome plugin: openai-bundled/chrome/0.1.7
OS: macOS 15.2, arm64
Proxy endpoint: local HTTP proxy on 127.0.0.1

No account identifiers, emails, local usernames, or full local paths are included in this report.

What I configured

Proxy variables were configured at both the launchctl level and in Codex config for shell subprocesses:

HTTP_PROXY=http://127.0.0.1:<port>
HTTPS_PROXY=http://127.0.0.1:<port>
ALL_PROXY=http://127.0.0.1:<port>
NO_PROXY=localhost,127.0.0.1,::1

The same lowercase variants were also configured.

In ~/.codex/config.toml, shell_environment_policy.set contains the same values. After restarting Codex Desktop, shell subprocesses launched by Codex do receive these proxy variables.

Steps to reproduce

1. On macOS, use a local HTTP proxy and configure proxy variables via launchctl setenv and ~/.codex/config.toml shell_environment_policy.set.
2. Restart Codex Desktop.
3. In the discovered Node REPL tool, inspect proxy-related environment variables:

const proxyKeys = [
  "HTTP_PROXY", "HTTPS_PROXY", "ALL_PROXY", "NO_PROXY",
  "http_proxy", "https_proxy", "all_proxy", "no_proxy",
];
const env = Object.fromEntries(proxyKeys.map((key) => [key, globalThis.process?.env?.[key] ?? null]));
nodeRepl.write(JSON.stringify(env, null, 2));

4. Attempt a fetch from the same Node REPL runtime:

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

5. Attempt Chrome plugin bootstrap or a lightweight Chrome browser-client call, such as listing open tabs.

Actual behavior

The built-in Node REPL runtime reports all proxy variables as null:

{
  "HTTP_PROXY": null,
  "HTTPS_PROXY": null,
  "ALL_PROXY": null,
  "NO_PROXY": null,
  "http_proxy": null,
  "https_proxy": null,
  "all_proxy": null,
  "no_proxy": null
}

nodeRepl.fetch("https://chatgpt.com/backend-api/me") hangs until the Node REPL tool call times out and resets the kernel. A JavaScript AbortController timeout did not reliably interrupt the hang.

The Node REPL process environment, inspected from the host, appears to be a fixed allowlist containing CODEX_*, NODE_REPL_*, PATH, HOME, and a few standard variables, but not HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, or lowercase variants.

Chrome plugin setup also times out, even though the local Chrome checks pass:

Google Chrome running: yes
Codex Chrome Extension installed and enabled: yes
Native messaging host manifest: valid

Control checks

The proxy itself is working:

• Shell subprocesses launched by Codex receive the proxy variables.
• launchctl getenv HTTP_PROXY and launchctl getenv HTTPS_PROXY return the configured local proxy.
• A separately launched app-bundled Node REPL process with the same proxy variables can complete nodeRepl.fetch("https://chatgpt.com/backend-api/me") successfully. The response body was intentionally not logged.

This suggests the issue is specific to how Codex Desktop launches or sanitizes the built-in Node REPL runtime used by plugins/browser tooling.

Expected behavior

One of the following should happen:

• The built-in Node REPL runtime should inherit documented proxy configuration from Codex Desktop or from the shell environment policy.
• Or Codex Desktop should provide a documented config field for proxy variables used by built-in plugin runtimes such as Node REPL.
• Or OpenAI/ChatGPT network calls made during local browser backend setup should be isolated so they cannot hang local Chrome/Browser Use discovery.

At minimum, nodeRepl.fetch() and browser backend setup should fail with a bounded diagnostic instead of hanging until the tool call timeout resets the kernel.

Related issues

This looks related to, but more specific than, existing macOS proxy and Browser Use reports:

• Codex App GUI no longer works with Clash Verge macOS system proxy, while bundled TUI works with env proxy #13682
• Responses websocket is unstable on macOS launchd/system-proxy setups while HTTP works #14080
• fix(browser): Browser Use cannot connect to IAB from Node REPL on macOS #20678

Those issues describe Codex Desktop GUI proxy behavior and Browser Use/Chrome backend hangs. This report narrows one reproducible cause: the built-in Node REPL runtime does not receive proxy environment variables even after the app is restarted and shell subprocesses do receive them.

[github-actions]

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

• Chrome/browser-use setupAtlasRuntime can hang when ambient /backend-api/me probe does not complete #21704

Powered by Codex Action

[gezi-antony]

Adding the concrete user-facing scenario that led to this report:

The issue was first observed while trying to use the Codex Chrome plugin to control the user's existing Google Chrome session. The requested task was a normal authenticated-browser workflow: open a regular website in Chrome and proceed with the page interaction.

From the user's perspective, the Chrome plugin simply did not respond. Lightweight Chrome plugin operations such as listing open tabs / initializing the browser client never returned and eventually ended as a Node REPL JavaScript timeout:

js execution timed out; kernel reset, rerun your request

This happened even after restarting Codex Desktop and Chrome, and after reinstalling the Chrome plugin. The local Chrome setup checks passed:

Google Chrome running: yes
Codex Chrome Extension installed and enabled: yes
Native messaging host manifest: valid

So the user-visible failure is not just that a manually invoked nodeRepl.fetch() hangs. The practical failure is that the Chrome plugin appears unresponsive even though Chrome, the extension, and the native messaging host are present. The proxy inheritance problem in the built-in Node REPL is the lower-level symptom that seems to explain why the plugin bootstrap / ambient setup path cannot complete in this environment.