›_ Codex Issues
Codex Issues / #4242

Use proxy environment variables across Codex HTTP clients

Open 💬 5 comments Opened Sep 25, 2025 by orbli

What feature would you like to see?

Codex CLI should automatically honor HTTPS_PROXY, HTTP_PROXY, and ALL_PROXY for every outgoing reqwest client. Today users behind corporate proxies must patch individual call sites (login, Ollama, etc.), and inconsistent headers creep in. I’d like a shared helper (e.g., codex_core::default_client::apply_env_proxy) that reads those variables in priority order, applies reqwest::Proxy::all, and gracefully logs when a value can’t be parsed, so every HTTP client benefits without extra boilerplate.

Are you interested in implementing this feature?

Yes. I have a branch (feat/env-proxy-client) https://github.com/openai/codex/pull/3455 that adds apply_env_proxy, wires it into create_client(), and updates codex-login and codex-ollama to go through the centralized builder. I’m happy to iterate once the team confirms the approach fits the roadmap.

Additional information

I searched existing issues for “proxy env var” and “HTTP_PROXY”; the closest matches (#3510, #2939, #2414) cover different proxy problems, so I believe this is new. Longer term we could also support lowercase variants and NO_PROXY, but I’m scoping this request to the upper-case variables to keep review focused.

View original on GitHub ↗

5 Comments

enerai · 8 months ago

Agreed. The Codex CLI should support its own proxy configuration (including HTTP proxies), separate from system/global proxy variables. This is important for enterprise environments where different tools need different proxy rules and credentials.

HardyPotato · 8 months ago

as a workaround, you can make a proxy-wrapped launcher where you define the proxy environment variables/values.

cornellsh · 6 months ago

Fixed, use this https://github.com/cornellsh/codex-proxy

psumbera · 3 months ago

I hit a related NO_PROXY case in the exec-server forwarded HTTP path.

In an environment with a general HTTPS proxy configured, Streamable HTTP MCP requests to hosts listed in NO_PROXY/no_proxy can still be routed through the system proxy. The failure happens before MCP authentication/handshake completes.

Root cause appears to be that ReqwestHttpRequestRunner currently builds and stores one reqwest::Client from only timeout_ms, before the request URL is known. That means Codex cannot decide per request whether the destination should bypass proxy autodetection.

I have a small branch that changes the exec-server HTTP runner to:

  • parse and validate the request URL first
  • evaluate NO_PROXY/no_proxy against that URL
  • call ClientBuilder::no_proxy() only for matching destinations
  • preserve existing proxy behavior for all other destinations
  • add tests for exact host, parent domain, partial suffix rejection, optional ports, IPv4/IPv6 CIDR, and bracketed IPv6-with-port entries

Branch: https://github.com/psumbera/codex/tree/noproxy

Commit: https://github.com/psumbera/codex/commit/0157d132e50f756095216d917c54afb71f4d5dbe

I saw docs/contributing.md says PRs are by invitation only, so I am not opening one unless this is a direction maintainers want. If this approach fits the intended proxy handling model, I can open a focused PR for the exec-server HTTP path.

panga · 2 months ago

I have issues using MCP https://github.com/openai/codex/issues/22667