respect_system_proxies=true does not make Codex use the macOS system proxy (CLI & Desktop App still connect directly)

What issue are you seeing?

respect_system_proxies = true in ~/.codex/config.toml does not make Codex (both CLI and Desktop App) actually respect the system proxy. Even with the macOS system proxy set (HTTP/HTTPS proxy at 127.0.0.1:7897) and [features] respect_system_proxies = true configured, Codex still makes direct connections (not through the proxy) to domains that are not covered by the local proxy rules — e.g. Twitter/X (104.244.46.246:443) — which hang forever in SYN_SENT in restricted networks, blocking requests and causing every new session to retry ~5 times and take ~2 minutes to respond.

This is a real-world blocker: in regions where direct connections to many foreign domains are blocked, the Desktop App is nearly unusable unless we inject proxy env vars globally via launchctl setenv (which affects all GUI apps — a workaround, not a proper fix).

What steps can reproduce the bug?

1. On macOS with a local proxy (e.g. Clash/Verge) listening on 127.0.0.1:7897, set the macOS system proxy to use it (scutil --proxy shows HTTP/HTTPS enabled at 7897).
2. Add to ~/.codex/config.toml:

   [features]
   respect_system_proxies = true
   

3. Without setting HTTPS_PROXY/HTTP_PROXY env vars, run the CLI:

   env -u HTTPS_PROXY -u HTTP_PROXY codex exec -c model=gpt-5.6-sol --skip-git-repo-check "Reply with exactly: OK"
   

4. Observed: the command times out (>120s). During the hang, lsof shows the codex process has direct SYN_SENT connections to 104.244.46.246:443 (Twitter/X) and similar foreign IPs that are NOT routed through the system proxy.

The same happens with the Desktop App's app-server process: direct SYN_SENT connections to non-OpenAI foreign domains, blocking session creation.

What is the expected behavior?

respect_system_proxies = true should make Codex (both CLI and Desktop App app-server) route ALL outbound HTTP/HTTPS/WebSocket requests through the macOS system proxy (or the proxy configured via network_proxy), exactly as documented for an experimental feature. Setting it should NOT require also setting HTTPS_PROXY/HTTP_PROXY env vars.

Additional information

• Codex version: codex-cli 0.148.0-alpha.9 (bundled in ChatGPT.app 26.810.52044)
• This appears to affect the ReqwestDefault outbound proxy policy: when no proxy env vars are present, requests go direct instead of reading the macOS system proxy — even with respect_system_proxies = true.
• The Desktop App's app-server process (launched by ChatGPT.app via launchd) does not inherit shell env vars, so it can never see HTTPS_PROXY unless injected globally — making a working respect_system_proxies (or equivalent) essential for GUI users in restricted networks.
• Workaround used today: launchctl setenv HTTPS_PROXY/HTTP_PROXY/ALL_PROXY http://127.0.0.1:7897 (global, affects all GUI apps). A proper per-codex fix is desired.
• Impacted: new session creation (retries ~5x, ~2min), subagent spawns, overall responsiveness in restricted networks.

Feature request aspect: if respect_system_proxies is intended as an experimental gate, please prioritize making it fully functional — it is the correct, scoped fix for GUI/App users behind proxies. Happy to provide more logs or test builds.

Start with the ReqwestDefault outbound proxy policy and the [features] respect_system_proxies setting in ~/.codex/config.toml. Reproduce with the provided env -u command on macOS and inspect the CLI and Desktop App app-server connections. Done means CLI and app-server HTTP, HTTPS, and WebSocket requests use the macOS system proxy or network_proxy without proxy environment variables.