26 Commits

• Persist Cloudflare affinity cookies for MCP HTTP (#29516)

  [Codex Thread
  019ef1f9-36e2-7e91-9337-504f097b9dc1](https://codex-thread-link.openai.chatgpt-team.site/thread/019ef1f9-36e2-7e91-9337-504f097b9dc1)
  
  ## Why
  
  Hosted plugin-service Streamable HTTP MCP traffic uses
  `https://chatgpt.com/backend-api/ps/mcp` and depends on Cloudflare's
  `__cflb` cookie for load-balancer affinity. The local and exec-server
  `http/request` path built a fresh reqwest client for each request
  without installing Codex's existing shared ChatGPT Cloudflare cookie
  store, so affinity could be lost between calls.
  
  This is an affinity-hardening change motivated by an incident
  investigation. It does not establish the broader connector-cache
  incident RCA or claim to fix that incident in full.
  
  ## What changed
  
  - Install the existing process-local, strictly allowlisted ChatGPT
  Cloudflare cookie store on the reqwest client used by
  `ReqwestHttpClient`.
  - Fresh clients now share allowed Cloudflare infrastructure cookies
  within the process that originates the local or exec-server network
  request.
  - Keep the existing HTTPS ChatGPT-host and Cloudflare-cookie-name
  restrictions. This does not introduce a general cookie jar or send
  ChatGPT Cloudflare cookies to unrelated hosts.
  
  ## Test coverage
  
  - `codex-client` unit coverage verifies that the existing strict store
  accepts and returns `__cflb` for HTTPS ChatGPT URLs.
  - The exec-server HTTPS integration test sends four independent
  `http/request` calls through a local TLS-intercepting proxy and verifies
  that:
  - `Set-Cookie: __cflb=west` is sent on the next plugin-service request;
    - a later `Set-Cookie: __cflb=central` replaces the stored value;
    - non-Cloudflare session cookies are discarded;
    - no stored ChatGPT Cloudflare cookie is sent to a non-ChatGPT host.
  - `just test -p codex-client` — 38 passed.
  - `just test -p codex-exec-server --test chatgpt_cloudflare_affinity` —
  1 passed.
  - `just bazel-lock-check` — passed.
  
  ## Non-goals
  
  - No persistence of ChatGPT auth, account, session, residency, or
  arbitrary cookies.
  - No cookie persistence for third-party MCP servers.
  - No special composition of caller-provided `Cookie` headers.
  - No plugin-service, connector-cache, Habitat/habicache, routing,
  redirect, or API-contract changes.
  - No broader incident RCA conclusions.

  stevenlee-oai · 2026-06-26 02:23:24 -04:00
  b5866eebd6
• PAC 4 - Add macOS system proxy resolver (#26709)

  ## Summary
  
  Stacked on #26708.
  
  Adds the macOS implementation of the shared system-proxy contract. This
  allows Codex-owned auth clients to use the route macOS selects for each
  auth URL through SystemConfiguration and CFNetwork, including PAC and
  WPAD results.
  
  The `respect_system_proxy` feature is disabled by default, so existing
  client behavior remains unchanged unless explicitly enabled.
  
  ## Implementation
  
  - Adds the macOS-only `system-configuration` dependency to
  `codex-client`.
  - Dispatches system-proxy resolution to `outbound_proxy/macos.rs` on
  macOS.
  - Reads system proxy settings from `SCDynamicStore` and resolves the
  target URL with `CFNetworkCopyProxiesForURL`.
  - Executes PAC URLs and inline PAC JavaScript through a bounded run loop
  with a five-second timeout.
  - Handles `DIRECT`, HTTP proxies, and CFNetwork HTTPS entries using HTTP
  CONNECT; unsupported SOCKS entries map to `UnsupportedProxyScheme`.
  - Builds concrete proxy URLs from host and port entries, including IPv6
  host bracketing.
  - Maps results into the shared `SystemProxyDecision::{Direct, Proxy,
  Unavailable}` contract.
  - Hashes URL-specific cache keys so PAC decisions remain distinct
  without retaining raw request URLs or query strings.
  
  ## End-user behavior
  
  - Disabled/default: existing client behavior is unchanged.
  - Enabled with `[features.respect_system_proxy]`:
    - macOS auth clients honor system proxy configuration, PAC, and WPAD;
    - valid OS/PAC `DIRECT` decisions use a direct connection;
  - unavailable system resolution falls back to explicit environment proxy
  variables, then `DIRECT`, through the shared contract from #26707.
  - Unsupported proxy schemes are not silently translated into another
  route.
  - Custom CA handling remains separate from proxy selection.
  - Known limitation: only the first supported system/PAC candidate is
  used. Subsequent proxy or `DIRECT` candidates are not attempted after a
  connection failure. This matches the current Windows behavior and leaves
  room for future ordered-fallback support.
  
  ## Tests
  
  - `just test -p codex-client` — 34 tests passed.
  - `just clippy -p codex-client`
  - `just fmt`
  - `just bazel-lock-check`

  canvrno-oai · 2026-06-22 17:56:04 -07:00
  b16d2858f5
• PAC 3 - Add Windows system proxy resolver (#26708)

  ## Summary
  
  Stacked on #26707.
  
  Adds the Windows implementation of the shared system-proxy contract.
  This allows Codex-owned auth clients to use the route Windows selects
  for each auth URL, including explicit PAC configuration, WPAD
  auto-detection, static proxies, and bypass rules.
  
  The `respect_system_proxy` feature is disabled by default, so existing
  client behavior remains unchanged unless explicitly enabled.
  
  ## Implementation
  
  - Adds Windows-only `codex-client` dependencies:
  - `windows-sys` with `Win32_Foundation` and `Win32_Networking_WinHttp`;
    - `sha2` for redacted cache keys.
  - Dispatches system-proxy resolution to `outbound_proxy/windows.rs` on
  Windows.
  - Reads the current-user WinHTTP/IE proxy configuration via
  `WinHttpGetIEProxyConfigForCurrentUser`.
  - Resolves explicit PAC URLs first, then OS-enabled WPAD auto-detection,
  then static proxy and bypass settings.
  - Uses `WinHttpGetProxyForUrl` for PAC/WPAD and maps results into the
  shared `SystemProxyDecision::{Direct, Proxy, Unavailable}` contract.
  - Parses `DIRECT`, `PROXY`, `HTTPS`, and keyed static proxy entries.
  - Treats unsupported schemes such as SOCKS as unavailable so the shared
  resolver can apply its environment-proxy fallback.
  - Handles Windows bypass entries, including `<local>` and host, suffix,
  wildcard, and port matching.
  - Releases WinHTTP-owned strings with `GlobalFree` and closes sessions
  with `WinHttpCloseHandle`.
  - Hashes URL-specific cache keys with SHA-256 so PAC decisions remain
  URL-specific without retaining raw request URLs or query strings.
  
  ## End-user behavior
  
  - Disabled/default: existing client behavior is unchanged.
  - Enabled with `[features.respect_system_proxy]`:
  - Windows auth clients honor explicit PAC configuration, OS-enabled
  WPAD, static proxies, and bypass rules;
    - valid OS/PAC `DIRECT` decisions use a direct connection;
  - unavailable system resolution falls back to explicit environment proxy
  variables, then `DIRECT`, through the shared contract from #26707.
  - Unsupported proxy schemes are not silently translated into a different
  route.
  - Custom CA handling remains separate from proxy selection.
  
  ## Tests
  
  Adds coverage for:
  
  - PAC-style proxy tokens such as `PROXY proxy.internal:8080` and `HTTPS
  proxy.internal:8443`;
  - static WinHTTP proxy entries keyed by target scheme;
  - `DIRECT` and unsupported proxy-token behavior;
  - Windows bypass matching, including `<local>`, wildcard, suffix, and
  port-qualified entries;
  - preserving URL-specific PAC cache decisions without retaining the raw
  URL on Windows.

  canvrno-oai · 2026-06-22 14:38:33 -07:00
  5f129a4703
• PAC 2 - Add shared auth system proxy contract (#26707)

  ## Summary
  
  Stacked on #26706.
  
  Adds the shared auth/system-proxy contract that later platform resolver
  PRs plug into. This PR moves Codex-owned auth and startup HTTP clients
  through a common route-aware boundary, but does not yet add Windows or
  macOS system proxy resolution.
  
  The default path remains unchanged when `respect_system_proxy` is absent
  or disabled.
  
  ## Implementation
  
  - Adds `codex-client/src/outbound_proxy.rs` with the shared
  route-selection model:
    - `OutboundProxyConfig`;
    - `ClientRouteClass`;
    - `RouteFailureClass`;
    - `build_reqwest_client_for_route`.
  - Preserves the existing reqwest/default-client behavior when no route
  config is supplied.
  - Uses the fixed MVP routing policy when route config is supplied:
  platform system/PAC/WPAD discovery, then explicit env proxy variables,
  then direct connection.
  - Keeps platform-specific system discovery behind the shared client
  boundary. This PR provides the contract and fallback behavior; later
  resolver PRs plug in Windows and macOS discovery.
  - Adds `login::AuthRouteConfig` so auth call sites depend on a small
  policy type instead of platform resolver details.
  - Maps the resolved `Config.respect_system_proxy` boolean into
  `AuthRouteConfig` for auth-owned clients.
  - Wires the route config through browser login, device-code login,
  access-token login, login status, logout/revoke, token refresh, API-key
  exchange, app-server account login, TUI/app startup, cloud-config
  bootstrap, cloud tasks, plugin auth, and exec startup config loading.
  
  ## End-user behavior
  
  - No behavior changes by default.
  - When `respect_system_proxy = true`, auth-owned clients opt into the
  shared route-aware client path.
  - On platforms without a resolver implementation in this PR, system
  discovery is unavailable and the route-aware path falls back to explicit
  env proxy handling, then direct connection.
  - Custom CA handling remains separate from proxy route selection and
  still runs through the shared client builder.
  - No proxy URLs, PAC contents, or resolved platform details are exposed
  through the public config surface introduced here.
  
  ## Tests
  
  Adds or updates coverage for:
  
  - preserving default auth-client fallback behavior when no route config
  is provided;
  - injected environment-proxy fallback without mutating process
  environment;
  - existing login-server E2E flows using explicit `auth_route_config:
  None` to guard unchanged default behavior;
  - updated auth manager, login, logout, cloud-config, startup, and
  plugin-auth call sites passing route config explicitly.

  canvrno-oai · 2026-06-22 13:03:11 -07:00
  1659c4a629
• [codex] Use expect in integration tests (#28441)

  The workspace denies `clippy::expect_used` in production. Although
  `clippy.toml` allows `expect` in tests, Bazel Clippy compiles
  integration-test helper code in a way that does not receive that
  exemption, which encouraged verbose `unwrap_or_else(... panic!(...))`
  and equivalent `match`/`let else` forms.
  
  This allows `clippy::expect_used` once at each integration-test crate
  root (including aggregated suites and test-support libraries), then
  replaces manual panic-based Result and Option unwraps with
  `expect`/`expect_err`. Standalone `tests/*.rs` files remain their own
  crate roots. Intentional assertion and unexpected-variant panics remain
  unchanged, and the production `expect_used = "deny"` lint remains in
  place.
  
  The cleanup is mechanical and net-negative in line count.

  pakrym-oai · 2026-06-15 21:53:47 -07:00
  e752f7b4ae
• reuse encoded Responses request bodies (#28327)

  ## Why
  
  Responses HTTP requests were converted from `ResponsesApiRequest` into a
  full `serde_json::Value`. `EndpointSession` then deep-cloned that value
  for each retry, and the transport serialized and compressed it again
  before every send.
  
  Large histories make those copies expensive. Retry attempts should reuse
  the same immutable request bytes.
  
  ## What
  
  - Serialize standard Responses requests directly into a ref-counted
  `EncodedJsonBody`.
  - Preserve the Azure path that attaches item IDs before encoding.
  - Prepare JSON, compression, and derived content headers once before the
  retry loop.
  - Clone the prepared request per attempt so body clones only bump the
  `Bytes` reference count.
  - Keep auth inside the retry loop. Signing auth sees the exact final
  headers and body bytes that the transport sends.
  - Preserve request-body TRACE output. With TRACE plus compression,
  retain the original JSON bytes for logging; normal requests keep only
  the final wire bytes.
  - Leave non-Responses endpoint bodies on the existing `Value` path.
  
  ## Performance
  
  A temporary release-mode measurement used a 10 MiB JSON body and 10
  retry preparations:
  
  - old `Value` clone + serialize path: 30 ms total
  - prepared shared-byte path: less than 1 ms total
  
  That is about 3 ms avoided per retry for this payload on the test
  machine. Each retry also stops allocating another request-sized JSON
  tree and serialized buffer. Without TRACE, compressed requests retain
  only the final compressed wire bytes.
  
  ## Validation
  
  - `just test -p codex-client` — 28 passed
  - `just test -p codex-api` — 125 passed
  - `just fix -p codex-client`
  - `just fix -p codex-api`

  jif · 2026-06-15 19:11:26 +02:00
  495da45643
• build: run buildifier from just fmt (#28125)

  ## Intent
  
  Keep Bazel and Starlark files consistently formatted without requiring
  contributors to install or version buildifier themselves.
  
  ## Implementation
  
  - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
  v8.5.1.
  - Run buildifier from the shared `just fmt` and `just fmt-check` driver,
  with Windows-safe explicit DotSlash invocation.
  - Provision DotSlash in formatting CI and contributor devcontainers, and
  document the source-build prerequisite.
  - Apply the initial mechanical buildifier formatting baseline.

  Adam Perry @ OpenAI · 2026-06-13 21:43:39 -07:00
  740c4f269d
• [codex] Remove async_trait from first-party code (#27475)

  ## Why
  
  First-party async traits should expose their `Send` contracts explicitly
  without requiring `async_trait`. This completes the migration pattern
  established in #27303 and #27304.
  
  ## What changed
  
  - Replaced the remaining first-party `async_trait` traits with native
  return-position `impl Future + Send` where statically dispatched and
  explicit boxed `Send` futures where object safety is required.
  - Kept implementations behavior-preserving, outlining existing async
  bodies into inherent methods where that keeps the diff reviewable.
  - Removed all direct first-party `async-trait` dependencies and the
  workspace dependency declaration.
  - Added a cargo-deny policy that permits `async-trait` only through the
  remaining transitive wrapper crates.
  - Updated `rand` from 0.8.5 to 0.8.6 to resolve RUSTSEC-2026-0097 and
  keep the full cargo-deny check passing.
  
  ## Validation
  
  - `just test -p codex-exec-server`: 216 passed, 2 skipped.
  - `just test -p codex-model-provider`: 39 passed.
  - `just test -p codex-core` and `just test`: changed tests passed;
  remaining failures are environment-sensitive suites unrelated to this
  migration.
  - `cargo deny check`
  - `just fix`
  - `just fmt`
  - `cargo shear`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• Disable empty Cargo test targets (#21584)

  ## Summary
  
  `cargo test` has entails both running standard Rust tests and doctests.
  It turns out that the doctest discovery is fairly slow, and it's a cost
  you pay even for crates that don't include any doctests.
  
  This PR disables doctests with `doctest = false` for crates that lack
  any doctests.
  
  For the collection of crates below, this speeds up test execution by
  >4x.
  
  E.g., before this PR:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):      1.849 s ±  4.455 s    [User: 0.752 s, System: 1.367 s]
    Range (min … max):    0.418 s … 14.529 s    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test     -p codex-utils-absolute-path     -p codex-utils-cache     -p codex-utils-cli     -p codex-utils-home-dir     -p codex-utils-output-truncation     -p codex-utils-path     -p codex-utils-string     -p codex-utils-template     -p codex-utils-elapsed     -p codex-utils-json-to-toml
    Time (mean ± σ):     428.6 ms ±   6.9 ms    [User: 187.7 ms, System: 219.7 ms]
    Range (min … max):   418.0 ms … 436.8 ms    10 runs
  ```
  
  For a single crate, with >2x speedup, before:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     491.1 ms ±   9.0 ms    [User: 229.8 ms, System: 234.9 ms]
    Range (min … max):   480.9 ms … 512.0 ms    10 runs
  ```
  
  And after:
  
  ```
  Benchmark 1: cargo test -p codex-utils-string
    Time (mean ± σ):     213.9 ms ±   4.3 ms    [User: 112.8 ms, System: 84.0 ms]
    Range (min … max):   206.8 ms … 221.0 ms    13 runs
  ```
  
  Co-authored-by: Codex <noreply@openai.com>

  Charlie Marsh · 2026-05-07 15:44:17 -07:00
  54ef99a365
• Fix custom CA login behind TLS-inspecting proxies (#20676)

  Refs:
  https://linear.app/openai/issue/SE-6311/login-fails-for-experian-users-behind-tls-inspecting-proxy
  
  ## Summary
  - When a custom CA bundle is configured, force the shared `codex-client`
  reqwest builder onto rustls before registering custom roots.
  - Add the `rustls-tls-native-roots` reqwest feature so the rustls client
  preserves native roots plus the enterprise CA bundle.
  - Add subprocess TLS coverage for both a direct local TLS 1.3 server and
  a hermetic local CONNECT TLS-intercepting proxy that forwards a
  token-exchange-shaped POST to a local origin.
  
  ## Plain-language explanation
  Experian users are behind a TLS-inspecting proxy, so the login token
  exchange needs to trust the enterprise CA bundle from
  `CODEX_CA_CERTIFICATE` or `SSL_CERT_FILE`. Before this change, that
  custom-CA branch still used reqwest default TLS selection, which could
  fail in the proxy environment. Now, only when a custom CA is configured,
  Codex selects rustls first and then adds the custom CA roots, matching
  the validated behavior from the Experian test build while leaving normal
  system-root clients unchanged.
  
  The new regression test recreates the enterprise-proxy shape locally:
  the probe client sends an HTTPS `POST /oauth/token` through an explicit
  HTTP CONNECT proxy, the proxy presents a leaf certificate signed by a
  runtime-generated test CA, decrypts the request, forwards it to a local
  origin, and relays the `ok` response back.
  
  ## Scope note
  - The actual production fix is the first commit: `8368119282 Fix custom
  CA reqwest clients to use rustls`.
  - The second commit is integration-test coverage only. It generates all
  test CA and localhost certificate material at runtime.
  
  ## Validation
  - `cd codex-rs && cargo test -p codex-client --test ca_env
  posts_to_token_origin_through_tls_intercepting_proxy_with_custom_ca_bundle
  -- --nocapture`
  - `cd codex-rs && cargo test -p codex-client`
  - `cd codex-rs && cargo test -p codex-login`
  - `cd codex-rs && just fmt`
  - `cd codex-rs && just bazel-lock-update`
  - `cd codex-rs && just bazel-lock-check`
  - `cd codex-rs && just fix -p codex-client`

  jgershen-oai · 2026-05-01 17:51:49 -07:00
  9e905528bb
• feat: add AWS SigV4 auth for OpenAI-compatible model providers (#17820)

  ## Summary
  
  Add first-class Amazon Bedrock Mantle provider support so Codex can keep
  using its existing Responses API transport with OpenAI-compatible
  AWS-hosted endpoints such as AOA/Mantle.
  
  This is needed for the AWS launch path, where provider traffic should
  authenticate with AWS credentials instead of OpenAI bearer credentials.
  Requests are authenticated immediately before transport send, so SigV4
  signs the final method, URL, headers, and body bytes that `reqwest` will
  send.
  
  ## What Changed
  
  - Added a new `codex-aws-auth` crate for loading AWS SDK config,
  resolving credentials, and signing finalized HTTP requests with AWS
  SigV4.
  - Added a built-in `amazon-bedrock` provider that targets Bedrock Mantle
  Responses endpoints, defaults to `us-east-1`, supports region/profile
  overrides, disables WebSockets, and does not require OpenAI auth.
  - Added Amazon Bedrock auth resolution in `codex-model-provider`: prefer
  `AWS_BEARER_TOKEN_BEDROCK` when set, otherwise use AWS SDK credentials
  and SigV4 signing.
  - Added `AuthProvider::apply_auth` and `Request::prepare_body_for_send`
  so request-signing providers can sign the exact outbound request after
  JSON serialization/compression.
  - Determine the region by taking the `aws.region` config first (required
  for bearer token codepath), and fallback to SDK default region.
  
  ## Testing
  Amazon Bedrock Mantle Responses paths:
  
  - Built the local Codex binary with `cargo build`.
  - Verified the custom proxy-backed `aws` provider using `env_key =
  "AWS_BEARER_TOKEN_BEDROCK"` streamed raw `responses` output with
  `response.output_text.delta`, `response.completed`, and `mantle-env-ok`.
  - Verified a full `codex exec --profile aws` turn returned
  `mantle-env-ok`.
  - Confirmed the custom provider used the bearer env var, not AWS profile
  auth: bogus `AWS_PROFILE` still passed, empty env var failed locally,
  and malformed env var reached Mantle and failed with `401
  invalid_api_key`.
  - Verified built-in `amazon-bedrock` with `AWS_BEARER_TOKEN_BEDROCK` set
  passed despite bogus AWS profiles, returning `amazon-bedrock-env-ok`.
  - Verified built-in `amazon-bedrock` SDK/SigV4 auth passed with
  `AWS_BEARER_TOKEN_BEDROCK` unset and temporary AWS session env
  credentials, returning `amazon-bedrock-sdk-env-ok`.

  Celia Chen · 2026-04-22 01:11:17 +00:00
  1cd3ad1f49
• Preserve Cloudfare HTTP cookies in codex (#17783)

  ## Summary
  - Adds a process-local, in-memory cookie store for ChatGPT HTTP clients.
  - Limits cookie storage and replay to a shared ChatGPT host allowlist.
  - Wires the shared store into the default Codex reqwest client and
  backend client.
  - Shares the ChatGPT host allowlist with remote-control URL validation
  to avoid drift.
  - Enables reqwest cookie support and updates lockfiles.

  Shijie Rao · 2026-04-21 14:40:15 -07:00
  c5e9c6f71f
• Add WebRTC transport to realtime start (#16960)

  Adds WebRTC startup to the experimental app-server
  `thread/realtime/start` method with an optional transport enum. The
  websocket path remains the default; WebRTC offers create the realtime
  session through the shared start flow and emit the answer SDP via
  `thread/realtime/sdp`.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-07 15:43:38 -07:00
  fb3dcfde1d
• feat(app-server, core): add more spans (#14479)

  ## Description
  
  This PR expands tracing coverage across app-server thread startup, core
  session initialization, and the Responses transport layer. It also gives
  core dispatch spans stable operation-specific names so traces are easier
  to follow than the old generic `submission_dispatch` spans.
  
  Also use `fmt::Display` for types that we serialize in traces so we send
  strings instead of rust types

  Owen Lin · 2026-03-13 13:16:33 -07:00
  014e19510d
• client: extend custom CA handling across HTTPS and websocket clients (#14239)

  ## Stacked PRs
  
  This work is now effectively split across two steps:
  
  - #14178: add custom CA support for browser and device-code login flows,
  docs, and hermetic subprocess tests
  - #14239: extend that shared custom CA handling across Codex HTTPS
  clients and secure websocket TLS
  
  Note: #14240 was merged into this branch while it was stacked on top of
  this PR. This PR now subsumes that websocket follow-up and should be
  treated as the combined change.
  
  Builds on top of #14178.
  
  ## Problem
  
  Custom CA support landed first in the login path, but the real
  requirement is broader. Codex constructs outbound TLS clients in
  multiple places, and both HTTPS and secure websocket paths can fail
  behind enterprise TLS interception if they do not honor
  `CODEX_CA_CERTIFICATE` or `SSL_CERT_FILE` consistently.
  
  This PR broadens the shared custom-CA logic beyond login and applies the
  same policy to websocket TLS, so the enterprise-proxy story is no longer
  split between “HTTPS works” and “websockets still fail”.
  
  ## What This Delivers
  
  Custom CA support is no longer limited to login. Codex outbound HTTPS
  clients and secure websocket connections can now honor the same
  `CODEX_CA_CERTIFICATE` / `SSL_CERT_FILE` configuration, so enterprise
  proxy/intercept setups work more consistently end-to-end.
  
  For users and operators, nothing new needs to be configured beyond the
  same CA env vars introduced in #14178. The change is that more of Codex
  now respects them, including websocket-backed flows that were previously
  still using default trust roots.
  
  I also manually validated the proxy path locally with mitmproxy using:
  `CODEX_CA_CERTIFICATE=~/.mitmproxy/mitmproxy-ca-cert.pem
  HTTPS_PROXY=http://127.0.0.1:8080 just codex`
  with mitmproxy installed via `brew install mitmproxy` and configured as
  the macOS system proxy.
  
  ## Mental model
  
  `codex-client` is now the owner of shared custom-CA policy for outbound
  TLS client construction. Reqwest callers start from the builder
  configuration they already need, then pass that builder through
  `build_reqwest_client_with_custom_ca(...)`. Websocket callers ask the
  same module for a rustls client config when a custom CA bundle is
  configured.
  
  The env precedence is the same everywhere:
  - `CODEX_CA_CERTIFICATE` wins
  - otherwise fall back to `SSL_CERT_FILE`
  - otherwise use system roots
  
  The helper is intentionally narrow. It loads every usable certificate
  from the configured PEM bundle into the appropriate root store and
  returns either a configured transport or a typed error that explains
  what went wrong.
  
  ## Non-goals
  
  This does not add handshake-level integration tests against a live TLS
  endpoint. It does not validate that the configured bundle forms a
  meaningful certificate chain. It also does not try to force every
  transport in the repo through one abstraction; it extends the shared CA
  policy across the reqwest and websocket paths that actually needed it.
  
  ## Tradeoffs
  
  The main tradeoff is centralizing CA behavior in `codex-client` while
  still leaving adoption up to call sites. That keeps the implementation
  additive and reviewable, but it means the rule "outbound Codex TLS that
  should honor enterprise roots must use the shared helper" is still
  partly enforced socially rather than by types.
  
  For websockets, the shared helper only builds an explicit rustls config
  when a custom CA bundle is configured. When no override env var is set,
  websocket callers still use their ordinary default connector path.
  
  ## Architecture
  
  `codex-client::custom_ca` now owns CA bundle selection, PEM
  normalization, mixed-section parsing, certificate extraction, typed
  CA-loading errors, and optional rustls client-config construction for
  websocket TLS.
  
  The affected consumers now call into that shared helper directly rather
  than carrying login-local CA behavior:
  - backend-client
  - cloud-tasks
  - RMCP client paths that use `reqwest`
  - TUI voice HTTP paths
  - `codex-core` default reqwest client construction
  - `codex-api` websocket clients for both responses and realtime
  websocket connections
  
  The subprocess CA probe, env-sensitive integration tests, and shared PEM
  fixtures also live in `codex-client`, which is now the actual owner of
  the behavior they exercise.
  
  ## Observability
  
  The shared CA path logs:
  - which environment variable selected the bundle
  - which path was loaded
  - how many certificates were accepted
  - when `TRUSTED CERTIFICATE` labels were normalized
  - when CRLs were ignored
  - where client construction failed
  
  Returned errors remain user-facing and include the relevant env var,
  path, and remediation hint. That same error model now applies whether
  the failure surfaced while building a reqwest client or websocket TLS
  configuration.
  
  ## Tests
  
  Pure unit tests in `codex-client` cover env precedence and PEM
  normalization behavior. Real client construction remains in subprocess
  tests so the suite can control process env and avoid the macOS seatbelt
  panic path that motivated the hermetic test split.
  
  The subprocess coverage verifies:
  - `CODEX_CA_CERTIFICATE` precedence over `SSL_CERT_FILE`
  - fallback to `SSL_CERT_FILE`
  - single-cert and multi-cert bundles
  - malformed and empty-file errors
  - OpenSSL `TRUSTED CERTIFICATE` handling
  - CRL tolerance for well-formed CRL sections
  
  The websocket side is covered by the existing `codex-api` / `codex-core`
  websocket test suites plus the manual mitmproxy validation above.
  
  ---------
  
  Co-authored-by: Ivan Zakharchanka <3axap4eHko@gmail.com>
  Co-authored-by: Codex <noreply@openai.com>

  Josh McKinney · 2026-03-13 00:59:26 +00:00
  6912da84a8
• Log headers in trace mode (#9214)

  To enable:
  
  ```
  export RUST_LOG="warn,codex_=trace"
  ```
  
  Sample: 
  ```
  Request completed method=POST url=https://chatgpt.com/backend-api/codex/responses status=200 OK headers={"date": "Wed, 14 Jan 2026 18:21:21 GMT", "transfer-encoding": "chunked", "connection": "keep-alive", "x-codex-plan-type": "business", "x-codex-primary-used-percent": "3", "x-codex-secondary-used-percent": "6", "x-codex-primary-window-minutes": "300", "x-codex-primary-over-secondary-limit-percent": "0", "x-codex-secondary-window-minutes": "10080", "x-codex-primary-reset-after-seconds": "9944", "x-codex-secondary-reset-after-seconds": "171121", "x-codex-primary-reset-at": "1768424824", "x-codex-secondary-reset-at": "1768586001", "x-codex-credits-has-credits": "False", "x-codex-credits-balance": "", "x-codex-credits-unlimited": "False", "x-models-etag": "W/\"7a7ffbc83c159dbd7a2a73aaa9c91b7a\"", "x-oai-request-id": "ffedcd30-6d8a-4c4d-be10-8ebb23c142c8", "x-envoy-upstream-service-time": "417", "x-openai-proxy-wasm": "v0.1", "cf-cache-status": "DYNAMIC", "set-cookie": "__cf_bm=xFKeaMbWNbKO5ZX.K5cJBhj34OA1QvnF_3nkdMThjlA-1768414881-1.0.1.1-uLpsE_BDkUfcmOMaeKVQmv_6_2ytnh_R3lO_il5N5K3YPQEkBo0cOMTdma6bK0Gz.hQYcIesFwKIJht1kZ9JKqAYYnjgB96hF4.sii2U3cE; path=/; expires=Wed, 14-Jan-26 18:51:21 GMT; domain=.chatgpt.com; HttpOnly; Secure; SameSite=None", "report-to": "{\"endpoints\":[{\"url\":\"https:\/\/a.nel.cloudflare.com\/report\/v4?s=4Kc7g4zUhKkIm3xHuB6ba4jyIUqqZ07ETwIPAYQASikRjA8JesbtUKDP9tSrZ5PnzWldaiSz5dZVQFI579LEsCMlMUSelTvmyQ8j4FbFDawi%2FprWZ5iRePiaSalr\"}],\"group\":\"cf-nel\",\"max_age\":604800}", "nel": "{\"success_fraction\":0.01,\"report_to\":\"cf-nel\",\"max_age\":604800}", "strict-transport-security": "max-age=31536000; includeSubDomains; preload", "x-content-type-options": "nosniff", "cross-origin-opener-policy": "same-origin-allow-popups", "referrer-policy": "strict-origin-when-cross-origin", "server": "cloudflare", "cf-ray": "9bdf270adc7aba3a-SEA"} version=HTTP/1.1
  ```

  pakrym-oai · 2026-01-14 18:38:12 +00:00
  e958d0337e
• Add URL to responses error messages (#8984)

  Put the URL in error messages, to aid debugging Codex pointing at wrong
  endpoints.
  
  <img width="759" height="164" alt="Screenshot 2026-01-09 at 16 32 49"
  src="https://github.com/user-attachments/assets/77a0622c-955d-426d-86bb-c035210a4ecc"
  />

  gt-oai · 2026-01-10 00:53:47 +00:00
  cc0b5e8504
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• Add feature for optional request compression (#8767)

  Adds a new feature
  `enable_request_compression` that will compress using zstd requests to
  the codex-backend. Currently only enabled for codex-backend so only enabled for openai providers when using chatgpt::auth even when the feature is enabled
  
  Added a new info log line too for evaluating the compression ratio and
  overhead off compressing before requesting. You can enable with
  `RUST_LOG=$RUST_LOG,codex_client::transport=info`
  
  ```
  2026-01-06T00:09:48.272113Z  INFO codex_client::transport: Compressed request body with zstd pre_compression_bytes=28914 post_compression_bytes=11485 compression_duration_ms=0
  ```

  Channing Conger · 2026-01-07 13:21:40 -08:00
  21c6d40a44
• Log compaction request bodies (#8676)

  We already log request bodies for normal requests, logging for
  compaction helps with debugging.

  pakrym-oai · 2026-01-02 11:27:37 -08:00
  7078a0b676
• nit: trace span for regular task (#8053)

  Logs are too spammy
  
  ---------
  
  Co-authored-by: Anton Panasenko <apanasenko@openai.com>

  jif-oai · 2025-12-16 16:53:15 +00:00
  d7482510b1
• [codex] add otel tracing (#7844)
  Anton Panasenko · 2025-12-12 17:07:17 -08:00
  ad7b9d63c3
• Remove conversation_id and bring back request ID logging (#7830)
  pakrym-oai · 2025-12-10 10:44:12 -08:00
  4b684c53ae
• Add request logging back (#7471)

  Having full requests helps debugging

  pakrym-oai · 2025-12-02 07:57:55 -08:00
  8b1e397211
• chore: proper client extraction (#6996)
  jif-oai · 2025-11-25 18:06:12 +00:00
  4502b1b263