Route exec-server HTTP through configured proxy policy (#35023)

## Why

Delegated HTTP requests need to honor the same outbound proxy policy as the
Codex process that starts the exec server.

## What changed

- Pass the configured `HttpClientFactory` through local and remote exec-server
  startup and use route-aware client pools for delegated HTTP and local MCP
  requests.
- Preserve per-request timeouts and follow-or-stop redirect behavior while
  keeping request URLs and sensitive response headers out of diagnostics.

## Testing

- Cover configured system-proxy routing across the exec-server transport.
- Cover both redirect policies and verify that success and failure logs do not
  expose request or response secrets.

GitOrigin-RevId: 4af6aec1d265c4db62dfcb6e1fb076fb31736137
This commit is contained in:
Celia Chen
2026-07-23 22:39:28 +00:00
committed by copyberry
parent fe0d472c4c
commit 1ee8f49175
25 changed files with 569 additions and 85 deletions
+7 -5
View File
@@ -400,11 +400,13 @@ The crate exports:
- `RemoteEnvironmentConfig` and `run_remote_environment()` for embedding remote
registration mode
Callers must pass `ExecServerRuntimePaths` to `run_main()`. The top-level
`codex exec-server` command builds these paths from the `codex` arg0 dispatch
state. `RemoteEnvironmentConfig::new(...)` also takes the auth provider that
remote registration should use; the CLI builds that provider from Codex auth
state before starting remote mode.
Callers must pass `ExecServerRuntimePaths` and an explicitly configured
`HttpClientFactory` to `run_main()`. The top-level `codex exec-server` command
builds these paths from the `codex` arg0 dispatch state and resolves its HTTP
client factory from the effective Codex configuration.
`RemoteEnvironmentConfig::new(...)` also takes the auth provider and HTTP client
factory that remote registration mode should use; the CLI builds the auth
provider from Codex auth state before starting remote mode.
## Example session