2 Commits

Include renames

Author	SHA1	Message	Date
Michael Bolin	6d3cde7fcd	login: route raw auth flows through HTTP client (#31637) ... ## Why Login already honors `respect_system_proxy`, but several login-owned auth flows still construct and pass around raw `reqwest::Client` values. That keeps those request paths coupled to the underlying transport and leaves `codex-login` on the temporary direct-`reqwest` allowlist introduced by #31431. Auth endpoints also have a stricter logging boundary than ordinary API requests: custom issuer URLs and response headers may contain credentials. Moving these requests behind the shared HTTP abstraction must preserve that boundary while retaining route-aware proxy and custom-CA behavior. This is a bounded login migration. The separate Agent Identity and shared default-client compatibility migrations remain follow-up work. ## What changed - Add `HttpClientFactory::build_client` to construct the shared `HttpClient` abstraction for a resolved destination and route class. - Add a route-aware construction path that suppresses request URL, response-header, and transport-error diagnostics for sensitive auth endpoints. - Route device-code user-code/polling requests, OAuth authorization-code exchange, and API-key token exchange through `HttpClient`. - Build the revoke timeout test client through the same factory API. - Use the transport-neutral `http::StatusCode` in the migrated device-code flow. - Add an end-to-end log-capture regression test covering successful responses and transport failures after `RequestBuilder` transformations. ## Review guidance The request behavior is intended to be unchanged: each issuer/token endpoint selects the same auth route, including the existing system/PAC proxy and custom-CA handling, and raw auth clients still omit Codex default headers. The intentional logging change is limited to raw auth requests, whose URL userinfo, query credentials, response headers, and transport errors must not cross the auth redaction boundary. This PR deliberately does **not** remove `codex-login` from #31431's allowlist. The remaining direct `reqwest` surface belongs primarily to: - Agent Identity APIs that still accept `reqwest::Client`. - Exported default-client compatibility helpers used by other workspace crates. - A small number of tests and concrete error/header types. ## Testing - `cargo check -p codex-http-client -p codex-login --tests` - `just test -p codex-http-client` (41 tests) - `just test -p codex-login` (155 tests) - `just bazel-lock-check` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31637). * #31837 * #31828 * #31825 * #31821 * __->__ #31637	2026-07-09 14:26:20 -07:00
Michael Bolin	9acfe8965d	Extract shared HTTP transport into codex-http-client (#31323) ... ## Why Codex-owned HTTP construction currently lives in `codex-client` alongside higher-level retry, SSE, and request-telemetry policy. That makes it difficult to apply shared network behavior consistently across crates, particularly system proxy/PAC resolution, custom CA handling, and the ChatGPT Cloudflare cookie policy. It also leaves no clear crate boundary for migrating direct `reqwest` usage behind a single Codex abstraction. This change establishes that low-level ownership boundary without changing request behavior. It builds on the system proxy support introduced in #26706, #26707, #26708, and #26709. ## What changed - Added `codex-rs/http-client` as the `codex-http-client` crate. - Moved request/response types, the concrete `reqwest` transport, custom CA handling, Cloudflare cookie policy, and macOS/Windows proxy resolution into the new crate. - Kept retry, SSE, and request-telemetry policy in `codex-client`. - Re-exported the moved API from `codex-client`, including compatibility aliases for `CodexHttpClient` and `CodexRequestBuilder`, so existing consumers do not change in this PR. - Moved the existing proxy and custom-CA tests with their implementation. ## Scope boundary This PR deliberately stops at the crate extraction. Stacked follow-up #31331 migrates downstream imports from `codex-client` to `codex-http-client`, keeping this change focused on ownership and compatibility rather than mixing in repository-wide call-site churn. ## Review guide GitHub reports 30 changed files, of which 17 are detected renames. A useful review order is: 1. Review the new boundary in `codex-rs/http-client/Cargo.toml` and `codex-rs/http-client/src/lib.rs`. 2. Review `codex-rs/codex-client/Cargo.toml` and `codex-rs/codex-client/src/lib.rs` for what remains in the higher-level crate and how compatibility is preserved. 3. Treat the renamed implementation and test files as moves. Their meaningful edits are limited to crate paths and normalizing the new crate's type names to `HttpClient` and `RequestBuilder`. 4. Review `codex-rs/Cargo.toml`, `codex-rs/Cargo.lock`, and the two `BUILD.bazel` files as mechanical workspace integration. ## Test plan - `just test -p codex-http-client -p codex-client` (38 tests) - Compile-checked the unchanged `codex-api`, `codex-backend-client`, `codex-cloud-tasks`, `codex-exec-server`, `codex-login`, and `codex-model-provider` consumers against the compatibility re-exports. --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/31323). * #31331 * __->__ #31323	2026-07-07 01:12:24 +00:00