Conversation
This was referenced Jul 7, 2026
This was referenced Jul 7, 2026
bolinfest
added a commit
that referenced
this pull request
Jul 7, 2026
## Why #31335 lets HTTP callers obtain proxy-aware clients from `HttpClientFactory`, but a non-HTTP transport such as WebSockets also needs two pieces of policy owned by `codex-http-client`: a concrete route decision for its destination and the same custom-CA-aware rustls trust configuration used by HTTPS. Keeping these prerequisites in the shared abstraction means the dependent Responses WebSocket change (#31441) cannot independently reinterpret `features.respect_system_proxy`, PAC results, or enterprise CA settings. ## What changed - Add a redaction-safe `OutboundProxyRoute` with explicit transport-default, direct, and concrete-proxy outcomes. - Add `HttpClientFactory::resolve_proxy_route()` so transports can resolve a destination through the already-selected outbound proxy policy. - Resolve `ws://` and `wss://` URLs through their HTTP equivalents so system and PAC rules apply consistently. - Add an always-returned rustls config builder that starts from native roots and layers in any configured Codex custom CA bundle. The existing optional builder remains available to callers that can delegate the default configuration to their transport. - Continue redacting proxy URLs from `Debug` output because they may contain credentials. ## Review guide 1. `http-client/src/outbound_proxy.rs` defines the transport-neutral route result and WebSocket URL normalization. 2. `http-client/src/custom_ca.rs` factors the native-root/custom-CA construction so callers that perform TLS themselves can always obtain a config. 3. `http-client/src/outbound_proxy_tests.rs` verifies WebSocket normalization and legacy transport-default behavior. ## Test plan - `just test -p codex-http-client outbound_proxy` - `just test -p codex-http-client custom_ca` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31342). * #31431 * #31363 * #31362 * #31361 * #31442 * #31441 * __->__ #31342
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
codex-http-clientmigration now has a shared implementation and several migrated request paths, but nothing prevents a new crate from adding another directreqwestdependency while the remaining call sites are being converted. The dependency graph should both enforce the direction of travel and make the remaining scope visible.This PR adds that ratchet on top of #31363. It does not claim the migration is complete: the allowlist deliberately records all 18 first-party crates that still depend on
reqwestdirectly.What changed
reqwestwith cargo-deny unless its immediate parent is an explicitly listed wrapper.codex-http-clientas the intended owner.reqwestdependency:oauth2,opentelemetry-http,opentelemetry-otlp,rmcp,sentry, andwebrtc-sys-build.reqwest0.12 and 0.13 with the same package-level rule.Migration rule
A new first-party crate cannot add
reqwest. When a listed crate finishes migrating, its direct Cargo dependency and its wrapper entry should be removed in the same PR, so the first-party list can only shrink.Review guide
The entire change is the new
reqwestentry incodex-rs/deny.toml:codex-http-clientis the permanent intended wrapper.Validation
cargo deny check bans --hide-inclusion-graph(bans ok; existing duplicate-version warnings remain warnings)Stack created with Sapling. Best reviewed with ReviewStack.