Managed network proxy injects unsupported YARN_NO_PROXY and breaks Yarn Berry

[dobesv]

What version of Codex CLI is running?

codex-cli 0.149.1 (npm-managed)

What platform is your computer?

Linux x86_64

What issue are you seeing?

When the managed network proxy is active, Codex injects YARN_NO_PROXY into every spawned command environment. Yarn Berry interprets every YARN_* variable as a Yarn configuration setting, maps this variable to noProxy, and rejects it because Yarn Berry has no such setting.

This prevents Yarn commands that load the full configuration from running.

$ yarn --version
4.17.1

$ env | grep "^YARN_.*_PROXY="
YARN_HTTPS_PROXY=http://127.0.0.1:<port>
YARN_HTTP_PROXY=http://127.0.0.1:<port>
YARN_NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

$ yarn config get httpProxy
Usage Error: Unrecognized or legacy configuration settings found: noProxy - run "yarn config" to see the list of settings supported in Yarn (in <environment>)

$ echo $?
1

Removing only the unsupported variable fixes the failure while retaining the managed HTTP proxy:

$ env -u YARN_NO_PROXY yarn config get httpProxy
http://127.0.0.1:<port>

$ echo $?
0

What steps can reproduce the bug?

1. Run Codex with the managed sandbox network proxy active. The spawned environment has CODEX_NETWORK_PROXY_ACTIVE=1.
2. Open a repository using Yarn Berry. This reproduction uses Yarn 4.17.1.
3. Run yarn config get httpProxy or yarn install --immutable inside the Codex sandbox.
4. Observe that Yarn exits because the injected YARN_NO_PROXY becomes the unsupported noProxy configuration key.
5. Run the same command through env -u YARN_NO_PROXY; it proceeds normally and continues to use YARN_HTTP_PROXY and YARN_HTTPS_PROXY.

What is the expected behavior?

Codex should not inject package-manager-specific environment variables that the package manager rejects. Yarn Berry commands should run normally while managed proxying remains enabled.

A likely fix is to remove YARN_NO_PROXY from NO_PROXY_ENV_KEYS. Alternatively, environment exclusions would need to run after managed proxy injection so users could exclude this one key without disabling the network proxy.

Additional information

The current network-proxy implementation explicitly includes YARN_NO_PROXY in NO_PROXY_ENV_KEYS and writes every key in that list into child environments:

• codex/codex-rs/network-proxy/src/proxy.rs

  Lines 652 to 658 in 7276d67

  	pub const NO_PROXY_ENV_KEYS: &[&str] = &[
  	"NO_PROXY",
  	"no_proxy",
  	"npm_config_noproxy",
  	"NPM_CONFIG_NOPROXY",
  	"YARN_NO_PROXY",
  	"BUNDLE_NO_PROXY",

• codex/codex-rs/network-proxy/src/proxy.rs

  Lines 710 to 758 in 7276d67

  	fn apply_proxy_env_overrides(
  	env: &mut HashMap<String, String>,
  	http_addr: SocketAddr,
  	socks_addr: SocketAddr,
  	socks_enabled: bool,
  	allow_local_binding: bool,
  	mitm_ca_trust_bundle: Option<&crate::certs::ManagedMitmCaTrustBundle>,
  	) {
  	let http_proxy_url = format!("http://{http_addr}");
  	let socks_proxy_url = format!("socks5h://{socks_addr}");
  	env.insert(PROXY_ACTIVE_ENV_KEY.to_string(), "1".to_string());
  	env.insert(
  	ALLOW_LOCAL_BINDING_ENV_KEY.to_string(),
  	if allow_local_binding {
  	"1".to_string()
  	} else {
  	"0".to_string()
  	},
  	);
  	// HTTP-based clients are best served by explicit HTTP proxy URLs.
  	set_env_keys(
  	env,
  	&[
  	"HTTP_PROXY",
  	"HTTPS_PROXY",
  	"http_proxy",
  	"https_proxy",
  	"YARN_HTTP_PROXY",
  	"YARN_HTTPS_PROXY",
  	"npm_config_http_proxy",
  	"npm_config_https_proxy",
  	"npm_config_proxy",
  	"NPM_CONFIG_HTTP_PROXY",
  	"NPM_CONFIG_HTTPS_PROXY",
  	"NPM_CONFIG_PROXY",
  	"BUNDLE_HTTP_PROXY",
  	"BUNDLE_HTTPS_PROXY",
  	"PIP_PROXY",
  	"DOCKER_HTTP_PROXY",
  	"DOCKER_HTTPS_PROXY",
  	],
  	&http_proxy_url,
  	);
  	// Some websocket clients look for dedicated WS/WSS proxy environment variables instead of
  	// HTTP(S)_PROXY. Keep them aligned with the managed HTTP proxy endpoint.
  	set_env_keys(env, WEBSOCKET_PROXY_ENV_KEYS, &http_proxy_url);
  	// Keep local targets direct only when local binding is enabled. Otherwise route them through

The documented shell_environment_policy.filters feature looks relevant, but managed proxy values are applied later in the spawn path. Related report: #40896.

Current workaround for every Yarn invocation:

env -u YARN_NO_PROXY yarn ...

[dobesv]

Example fix here: https://github.com/openai/codex/compare/main...dobesv:fix/yarn-no-proxy?expand=1

[dobesv]

Verified an additional workaround with Codex CLI 0.151.0 and Yarn 4.17.1.

Configure Codex to disable Yarn strict-setting validation for spawned commands:

[shell_environment_policy]
set = { YARN_ENABLE_STRICT_SETTINGS = "false" }

After restarting Codex, the sandbox environment still has the managed proxy active and still contains the unsupported variable:

CODEX_NETWORK_PROXY_ACTIVE=1
YARN_ENABLE_STRICT_SETTINGS=false
YARN_NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

The original reproduction now succeeds without unsetting anything:

$ yarn config get httpProxy
http://127.0.0.1:<port>
$ echo $?
0

This retains the managed HTTP proxy and avoids adding env -u to every Yarn invocation. The tradeoff is that Yarn ignores all unknown configuration settings in Codex-spawned commands, so this could hide unrelated configuration mistakes. Removing YARN_NO_PROXY upstream would still be the preferable fix.