Image generation and web search bypass the system proxy when respect_system_proxy is enabled

What version of Codex CLI is running?

codex-cli 0.153.4 (measured). The same code is unchanged in rust-v0.154.0 and on main as of 2026-09-16.

What subscription do you have?

ChatGPT Team

Which model were you using?

The default model for codex exec (not recorded)

What platform is your computer?

macOS 15.7.7, arm64

What terminal emulator and version are you using (if applicable)?

Not applicable (codex exec over SSH)

Codex doctor report

not captured

What issue are you seeing?

With respect_system_proxy enabled and a system proxy configured through a PAC file, Codex sends its model traffic through the system proxy, but the built-in image generation and web search tools connect directly to chatgpt.com and bypass it. Those requests carry the user's image prompt, and for search the query plus recent conversation messages.

In an environment where outbound traffic is expected to pass through the system proxy, those requests leave the machine without going through it.

In the same codex exec turn:

POST/WebSocket chatgpt.com /backend-api/codex/responses          -> through the PAC-selected proxy
POST chatgpt.com /backend-api/codex/images/generations           -> direct TLS connection to chatgpt.com
POST chatgpt.com /backend-api/codex/alpha/search (web search on) -> direct TLS connections to chatgpt.com

Setting HTTPS_PROXY in Codex's environment does route the image request (we confirmed this for image generation; web search uses the same client), so the client honours environment variables but not the system/PAC route.

Cause, from the source (rust-v0.154.0):

• codex-rs/ext/image-generation/src/backend.rs:74 builds its transport with ReqwestTransport::from_http_client(create_client()).
• codex-rs/ext/web-search/src/tool.rs:112 does the same.
• codex-rs/login/src/auth/default_client.rs:223-226 documents create_client() as preserving "the transport's existing proxy behavior" and not opting "into Codex's route-aware system/PAC resolution".
• codex-rs/http-client/README.md says product traffic should normally use build_respecting_outbound_proxy_policy, so these two call sites look like they have not yet moved to the route-aware client.

What steps can reproduce the bug?

1. On macOS, set an automatic proxy configuration (PAC) URL for the active network service that sends chatgpt.com to a local HTTPS proxy. Do not set HTTPS_PROXY/ALL_PROXY in the environment.
2. Enable respect_system_proxy (we set it in the managed requirements file, /etc/codex/requirements.toml, under [features]).
3. Run codex exec "generate an image of a wooden sign that says hello" while logging the proxy's requests and the process's TCP connections (for example lsof -i -a -p <codex pid> or a packet capture).
4. The proxy logs the /backend-api/codex/responses traffic but never /backend-api/codex/images/generations; the capture shows a direct TLS connection from codex to chatgpt.com:443 at the moment the tool runs.
5. Repeat with the web search feature enabled and a prompt that searches: the /backend-api/codex/alpha/search requests also go direct.

What is the expected behavior?

With respect_system_proxy enabled, the image generation and web search requests follow the same system/PAC route as the model traffic.

Additional information

• In the same runs, requests to /backend-api/codex/analytics-events/events went through the same environment-only client and also bypassed the PAC route.
• Possibly related, but a different path: #29958 (WebSocket transport with respect_system_proxy on Windows).

Start with codex-rs/http-client/README.md and compare the clients used in codex-rs/ext/image-generation/src/backend.rs:74 and codex-rs/ext/web-search/src/tool.rs:112 with the route-aware client guidance. Check the related client construction in codex-rs/login/src/auth/default_client.rs:223-226. Done means image-generation and web-search requests follow the system/PAC route when respect_system_proxy is enabled, without regressing environment proxy behavior.