Michael Bolin

model-provider: route model discovery through HTTP client factory (#31361)

Respect system proxies during plugin startup sync (#34506) ## Why The curated plugin startup sync can fall back from Git to HTTP, but those requests did not use Codex's effective outbound proxy policy. ## What changed - Thread the configured HTTP client factory into curated plugin sync. - Route GitHub API, zipball, backup metadata, and returned download URLs through the route-aware client when system proxy support is enabled. - Preserve the existing default HTTP client behavior, including its custom CA fallback, when system proxy support is disabled. - Apply the standard Codex headers to startup-sync HTTP requests. ## Testing Add coverage that records route selection for repository, archive, metadata, and backend-supplied download URLs, and verifies standard headers are sent. GitOrigin-RevId: e1ea13bdab58a84c9948a2c8b82a5ec5c964ea99

Precompute app-server protocol exports (#36212) ## Why Normal app-server protocol builds do not need the `ts-rs` and `schemars` implementations used to generate schema exports. ## What changed - Embed compressed stable and experimental TypeScript and JSON schema exports, and serve the existing export APIs from those artifacts. - Use no-op schema derives in non-test builds while keeping the real generators available for fixture regeneration and tests. - Move schema fixture regeneration behind a Python helper and update `just write-app-server-schema --experimental` to refresh the experimental embedded exports. ## Testing - Verify embedded exports match freshly generated stable and experimental schemas. - Verify export options and on-disk output remain compatible. GitOrigin-RevId: e8536338b457e6eec34bdf29ec0684144bd13734

Route backend requests through the HTTP client factory (#34490) ## Why Backend-backed features need to use the same outbound routing configuration as the rest of Codex. ## What changed - Build the backend client on a route-aware client pool supplied by `HttpClientFactory`. - Pass the configured factory through app-server account requests, cloud config loading, cloud tasks, and memory rate-limit checks. - Preserve task query encoding, authentication headers, JSON request bodies, and ChatGPT cookie handling during the migration. ## Testing - Add backend-client tests for proxy-policy propagation, task query encoding, bearer authentication, and JSON request bodies. GitOrigin-RevId: c17d162e0dce9cec758df7cdeecf982207c6512b

Add a route-aware HTTP client pool (#34447) ## Why PAC and system-proxy resolution can select a different outbound route for each request URL. Request creation and route selection must use the same URL while still allowing transport clients to be reused. ## What changed - Add `RouteAwareClientPool` and a request builder that resolve the outbound proxy route when sending each request. - Reuse HTTP clients by resolved route, with a bounded cache of 16 routes. - Preserve request tracing, optional diagnostic logging, custom CA settings, Cloudflare cookies, and default transport redirect behavior. - Export route-aware response and error types, including status, timeout, and connection-error helpers. ## Testing Add tests for exact URL routing, client reuse and eviction, default redirects, and redaction of URL secrets from debug output. GitOrigin-RevId: a1688b64305a0bb276c371df63a039ccbe821b76

Honor system proxy settings in the daemon updater (#34495) ## Why The PID-managed daemon updater downloaded the standalone installer directly, bypassing Codex's configured outbound proxy policy. ## What changed - Build the updater's HTTP client from the effective Codex configuration so `features.respect_system_proxy` also applies to installer downloads. - Use the route-aware client pool for the installer request. - Warn and fall back to the default `reqwest` proxy behavior when configuration cannot be loaded, allowing updates to continue. ## Testing Added tests for proxy-policy selection, configuration-load fallback, exact installer URL usage, byte preservation, and non-success HTTP responses. GitOrigin-RevId: 559668eb40314d43afa6512da66e59e32cc1b93c

websocket-client: add proxy-aware connector (#31622) ## Why The route-aware WebSocket connection setup in #31441 is transport infrastructure rather than Responses API protocol logic. Landing it first in a dedicated crate keeps `codex-api` focused on request and response behavior and makes the transport reusable by future WebSocket clients. WebSockets must also apply the same effective outbound proxy and custom-CA policy as HTTP without disabling the lower-latency WebSocket path. Requiring an `HttpClientFactory` when constructing the connector makes proxy-policy resolution part of the API instead of an optional call-site convention. This PR is an independent prerequisite based directly on `main`. After it merges, #31441 can rebase onto it and replace its in-crate connector with this API. ## What changed - Add a new `codex-websocket-client` workspace crate with a `WebSocketConnector` constructed from the effective `HttpClientFactory`. - Resolve every destination through that factory before connecting, then support direct connections, transport-default routing, HTTP proxies, and TLS-encrypted HTTPS proxies. - Preserve custom-CA trust for proxy and target TLS handshakes and preserve Happy Eyeballs fallback for explicit direct and proxy routes. - Expose an established `WebSocketConnection` as a uniform `Stream` and `Sink`, hiding route-specific transport types from protocol clients. - Add focused integration-style coverage for the public connector and message stream, real WSS over direct and CONNECT routes, implicit and explicit HTTPS proxy ports, and stalled-address-family fallback. ## Review guide 1. `codex-rs/websocket-client/src/lib.rs` defines the small public API and the factory-required policy invariant. 2. `codex-rs/websocket-client/src/dialer.rs` contains DNS, TCP, proxy tunneling, TLS, and WebSocket handshake setup. 3. `codex-rs/websocket-client/src/dialer_tests.rs` verifies the public stream, direct and proxied WSS paths, HTTPS port preservation, and Happy Eyeballs timing. 4. There is intentionally no consumer migration here; #31441 will become the first consumer after this prerequisite merges. ## Test plan - `cargo check -p codex-websocket-client --tests` - `just test -p codex-websocket-client` - `cargo shear` - `just bazel-lock-check`

core: persist initial context window metadata (#29519) ## Why PR #29494 made context-window IDs visible to the model by wrapping the token-budget window payload in `<context_window>`, but rollout JSONL consumers still could not see the initial window identity by tailing the session file. Compacted rollout items carry window IDs only after compaction has happened, so a session with no compaction had no durable JSONL record for window 0. This change gives tailing consumers a stable initial-window record at session creation time. ## What Changed - Added `session_meta.context_window.window_id` for the initial context-window identity. - `CreateThreadParams` now requires `initial_window_id: String`, so thread-store callers cannot accidentally create new threads without window-0 metadata. - Live thread creation derives the persisted initial window ID from the same `AutoCompactWindowIds` used to initialize `SessionState`, keeping runtime state and JSONL metadata aligned. - Rollout reconstruction uses `session_meta.context_window.window_id` as the initial-window fallback and derives `window_number = 0`, `first_window_id = window_id`, and `previous_window_id = None` internally. - Fork reconstruction intentionally uses the same rollout reconstruction path; consumers that need to distinguish copied initial-window metadata can use the rollout `thread_id`. - Legacy compactions without `window_number` still use compaction-count fallback accounting instead of being reset to window 0 by the initial-window fallback. - Compacted rollout metadata still takes precedence once compaction records exist, preserving the richer chain fields there. ## JSONL Shape Real rollout JSONL is one object per line. This example is expanded for readability, but shows the new initial `session_meta.context_window` record followed by the existing compacted rollout item shape that also carries window IDs: ```jsonl { "timestamp": "2026-06-22T12:00:00.000Z", "type": "session_meta", "payload": { "session_id": "<THREAD_ID>", "id": "<THREAD_ID>", "timestamp": "2026-06-22T12:00:00.000Z", "cwd": "/repo", "originator": "codex", "cli_version": "0.0.0", "source": "cli", "model_provider": "<MODEL_PROVIDER>", "context_window": { "window_id": "<INITIAL_WINDOW_ID>" } } } ... { "timestamp": "2026-06-22T12:34:56.000Z", "type": "compacted", "payload": { "message": "<COMPACTION_SUMMARY>", "replacement_history": [ "..." ], "window_number": 1, "first_window_id": "<INITIAL_WINDOW_ID>", "previous_window_id": "<INITIAL_WINDOW_ID>", "window_id": "<NEXT_WINDOW_ID>" } } ``` The nested `context_window` object is intentional: it gives rollout consumers a stable namespace for context-window metadata while only writing the non-derivable initial `window_id`. For the initial window, `window_number`, `first_window_id`, and `previous_window_id` are derived internally instead of being written to the rollout. ## Verification - `just test -p codex-protocol` - `just test -p codex-rollout recorder_materializes_on_flush_with_pending_items` - `just test -p codex-core reconstruct_history` - `just test -p codex-core record_initial_history_reconstructs_forked_transcript` - `just test -p codex-thread-store` - `just test -p codex-state` - `just test -p codex-app-server thread_read_returns_summary_without_turns` - `just test -p codex-rollout persistence_metrics`

Log multi-agent communication lifecycle (#30872) ## Why [#30867](https://github.com/openai/codex/pull/30867) makes `submit_inter_agent_communication` the common outbound sink for multi-agent v2 communications. This follow-up uses that single point to log every communication lifecycle without requiring new hooks as spawn, messaging, follow-up, or result paths evolve. For each communication, the logs need to identify its type, sender and receiver threads, and content, while correlating the successful send with receipt by the destination mailbox. The logging path must not query externally supplied time providers because those calls can be expensive for app-server clients. ## What changed - Added structured `INFO` events on the OpenTelemetry-exported `codex_otel.agent_communication` target for `spawn`, `message`, `followup`, and `result` communications. - Logged successful sends from `submit_inter_agent_communication` with the communication kind, sender and receiver thread IDs, content, and submission ID. - Logged receives after the communication has been enqueued in the receiver mailbox, using the same submission ID. - Avoided time-provider calls and other asynchronous work in the logging path. - Narrowed ordinary spawn and send-input APIs to `Vec<UserInput>` so `Op::InterAgentCommunication` cannot bypass the context-bearing centralized path. The refactor does not change submission IDs, capacity checks, last-task bookkeeping, mailbox ordering, protocol types, rollout data, or model-visible context. ## Event shape Illustrative JSON representation of the two independently emitted records: ```json [ { "event.name": "codex.agent_communication", "communication_id": "019f20e1-40d1-7890-a123-456789abcdef", "kind": "spawn", "state": "send", "sender_thread_id": "019f20df-fbe1-7890-a123-456789abcdef", "receiver_thread_id": "019f20e1-3f79-7890-a123-456789abcdef", "content": "inspect the repository" }, { "event.name": "codex.agent_communication", "communication_id": "019f20e1-40d1-7890-a123-456789abcdef", "state": "receive" } ] ``` Consumers join the receive record to the send record by `communication_id` for the immutable communication metadata. ## Testing - Extended the existing end-to-end multi-agent v2 spawn test to verify content, both thread IDs, and a correlated send/receive submission ID. - Re-ran focused control and handler coverage for direct messages, follow-up tasks, and completion results.

Add a policy-aware HTTP client builder (#34630) ## What changed - Add `HttpClientBuilder` for configuring default headers, redirects, the Cloudflare cookie store, and request diagnostics without exposing the underlying transport. - Provide factory-backed construction for fixed destinations that respects outbound proxy policy, alongside explicit direct and legacy transport-default construction paths. - Preserve the request-logging setting in `ReqwestTransport`, so disabling diagnostics also suppresses transport-level URL and request-body traces. - Add `HEAD`, `DELETE`, and query-parameter helpers to the shared client wrappers. ## Testing - Verify builder configuration survives policy-aware construction and custom CA fallback. - Verify disabled request logging omits request URLs and bodies from transport traces. GitOrigin-RevId: 529c33abefeb88f38ff9a0ead374d29fcc872e6a