›_ Codex Issues
Codex Issues / #39237

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

Open 💬 5 comments Opened Aug 18, 2026 by sunnyboyChou
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

``toml
[features]
respect_system_proxies = true
``

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

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

  1. 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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 9 days ago

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

  • #38768

Powered by Codex Action

sunnyboyChou · 9 days ago

Verified: respect_system_proxies = true does NOT work (tested 2026-08-18)

Confirmed with concrete experiment on macOS + codex-cli 0.148.0-alpha.9:

| Step | Result |
|---|---|
| macOS system proxy set (scutil --proxy shows HTTP/HTTPS → 127.0.0.1:7897) | ✅ |
| ~/.codex/config.toml has [features] respect_system_proxies = true | ✅ |
| Run CLI with ALL proxy env removed (env -u HTTPS_PROXY -u HTTP_PROXY -u ALL_PROXY -u NO_PROXY) | ❌ times out >120s |
| Connection observation | only chatgpt.com goes through Clash rules (lucky rule match); Twitter/X etc. still connect directly |

Why the experiment is conclusive:

  1. System proxy was definitely on (scutil confirmed) — if the feature worked, codex would read it.
  2. All proxy env vars were removed — isolating the feature's effect.
  3. Observed at the connection layer (mihomo connections + lsof) — confirmed real direct connects, not just slowness.
  4. CLI and Desktop App share the same binary — if CLI doesn't honor it, App won't either (App additionally suffers from not inheriting shell env).

This confirms the feature gate is implemented but not functional yet. The Desktop App path is the most impactful for users behind restricted networks, since its app-server cannot see shell env at all. Looking forward to this becoming fully functional — it is the correct scoped fix. Happy to provide more details or test a build.

tsuvic · 9 days ago

Possible config-key mismatch: the feature key is singular, and unknown [features] keys are silently ignored.

On current main (@67ed4e7), the gate is [features] respect_system_proxy (singular):

  • resolved via features.enabled(Feature::RespectSystemProxy) keyed on respect_system_proxy (codex-rs/core/src/config/config_loader_tests.rs:3494, config_tests.rs:1859–1917)
  • only that key flips OutboundProxyPolicy from ReqwestDefault to RespectSystemProxy (codex-rs/core/src/config/mod.rs:1562, 3247)

[features] parses as a free-form key→bool map, so respect_system_proxies (plural, as in the report and the verification experiment) parses without error but matches no known feature — the policy stays ReqwestDefault, i.e. reqwest's own proxy selection, which with all proxy env vars removed means direct connections. That matches the observed SYN_SENT hangs and the >120 s timeouts.

Suggested re-test: set [features] respect_system_proxy = true (singular) and re-run the same env -u HTTPS_PROXY -u HTTP_PROXY -u ALL_PROXY -u NO_PROXY codex exec … command; connections should then route via 127.0.0.1:7897. If they still don't, that would isolate a genuine RespectSystemProxy-mode gap instead.

Environment: macOS 26.5.2 arm64; standalone CLI 0.147.0 + desktop-bundled 0.148; source verified on main @67ed4e7 (2026-08-19).

sunnyboyChou · 9 days ago

Thanks for the source-level diagnosis — confirmed correct, and now verified end-to-end.

Key-name fix confirmed: the feature key is singular respect_system_proxy (not respect_system_proxies). The plural key is silently ignored by the free-form [features] map, so OutboundProxyPolicy stays ReqwestDefault (env-only → direct when env is unset). That fully explains the original SYN_SENT hangs and >120s timeouts.

Verification (2026-08-19, codex 0.148.0-alpha.9 / ChatGPT.app 26.810.52044, macOS, Clash on 127.0.0.1:7897) — with respect_system_proxy = true (singular) and ALL proxy env removed (launchctl unsetenv HTTPS_PROXY/HTTP_PROXY/ALL_PROXY):

| Path | Result |
|---|---|
| CLI: env -u HTTPS_PROXY -u HTTP_PROXY -u ALL_PROXY -u NO_PROXY codex exec "Reply OK" | ✅ exit=0, ~11s |
| Connection layer (lsof on codex/app-server) | ✅ 3× ESTABLISHED → 127.0.0.1:7897, 0× SYN_SENT |
| Desktop App app-server (fully quit + relaunch, no env) | ✅ new session opens immediately |
| Subagent spawn (fresh app-server process, no env) | ✅ created on first try, zero retries |

One caveat for anyone testing inside a subagent: a bare curl child process does NOT read the macOS system proxy (it only honors -x or HTTPS_PROXY env), so curl to chatgpt.com timing out inside a subagent is expected — it doesn't indicate the feature is broken. The feature gates codex's own HTTP client only.

I've updated the issue's premise (the original experiment used the plural key) and my local docs accordingly. Thanks again for the pointer — this is now the preferred fix (no global launchctl setenv needed).

Yotghoe · 5 days ago

I can reproduce a very similar issue on an Intel Mac.

My setup:

  • macOS on Intel (x86_64)
  • Codex Desktop 26.818.41705
  • Clash Verge Rev
  • Local proxy: 127.0.0.1:7897

I verified that the proxy itself works. For example:

curl -s -x http://127.0.0.1:7897 \
https://www.cloudflare.com/cdn-cgi/trace

returns:

ip=
colo=NRT
loc=JP

More importantly, the OAuth token endpoint itself is reachable through exactly the same proxy:

curl -sS -x http://127.0.0.1:7897 \
https://auth.openai.com/oauth/token \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data 'grant_type=authorization_code'

This successfully reaches OpenAI and returns the expected:

"Missing 'client_id'"

I also explicitly set:

HTTP_PROXY=http://127.0.0.1:7897
HTTPS_PROXY=http://127.0.0.1:7897
ALL_PROXY=http://127.0.0.1:7897

(and the lowercase variants)

I confirmed that the actual Codex app-server process inherited all of these environment variables.

However, Codex still fails authentication with:

Failed to refresh token: error sending request for url
(https://auth.openai.com/oauth/token)

I also see similar transport errors for:

https://chatgpt.com/backend-api/plugins/featured?platform=codex

So in my case, even when the Codex app-server definitely inherits
HTTP_PROXY / HTTPS_PROXY / ALL_PROXY, its internal HTTP requests still fail,
while curl through the exact same proxy works correctly.

I have also tried reinstalling Codex, updating to 26.818.41705,
changing browsers, clearing Codex data/cache, and different network setups,
but the issue persists.

Happy to provide additional logs or run any diagnostic commands if useful.