51 Commits

• Add auth env observability (#14905)

  CXC-410 Emit Env Var Status with `/feedback` report
  
  Add more observability on top of #14611 
  
  [Unset](https://openai.sentry.io/issues/7340419168/?project=4510195390611458&query=019cfa8d-c1ba-7002-96fa-e35fc340551d&referrer=issue-stream)
  
  [Set](https://openai.sentry.io/issues/7340426331/?project=4510195390611458&query=019cfa91-aba1-7823-ab7e-762edfbc0ed4&referrer=issue-stream)
  <img width="1063" height="610" alt="image"
  src="https://github.com/user-attachments/assets/937ab026-1c2d-4757-81d5-5f31b853113e"
  />
  
  
  ###### Summary
  - Adds auth-env telemetry that records whether key auth-related env
  overrides were present on session start and request paths.
  - Threads those auth-env fields through `/responses`, websocket, and
  `/models` telemetry and feedback metadata.
  - Buckets custom provider `env_key` configuration to a safe
  `"configured"` value instead of emitting raw config text.
  - Keeps the slice observability-only: no raw token values or raw URLs
  are emitted.
  
  ###### Rationale (from spec findings)
  - 401 and auth-path debugging needs a way to distinguish env-driven auth
  paths from sessions with no auth env override.
  - Startup and model-refresh failures need the same auth-env diagnostics
  as normal request failures.
  - Feedback and Sentry tags need the same auth-env signal as OTel events
  so reports can be triaged consistently.
  - Custom provider config is user-controlled text, so the telemetry
  contract must stay presence-only / bucketed.
  
  ###### Scope
  - Adds a small `AuthEnvTelemetry` bundle for env presence collection and
  threads it through the main request/session telemetry paths.
  - Does not add endpoint/base-url/provider-header/geo routing attribution
  or broader telemetry API redesign.
  
  ###### Trade-offs
  - `provider_env_key_name` is bucketed to `"configured"` instead of
  preserving the literal configured env var name.
  - `/models` is included because startup/model-refresh auth failures need
  the same diagnostics, but broader parity work remains out of scope.
  - This slice keeps the existing telemetry APIs and layers auth-env
  fields onto them rather than redesigning the metadata model.
  
  ###### Client follow-up
  - Add the separate endpoint/base-url attribution slice if routing-source
  diagnosis is still needed.
  - Add provider-header or residency attribution only if auth-env presence
  proves insufficient in real reports.
  - Revisit whether any additional auth-related env inputs need safe
  bucketing after more 401 triage data.
  
  ###### Testing
  - `cargo test -p codex-core emit_feedback_request_tags -- --nocapture`
  - `cargo test -p codex-core
  collect_auth_env_telemetry_buckets_provider_env_key_name -- --nocapture`
  - `cargo test -p codex-core
  models_request_telemetry_emits_auth_env_feedback_tags_on_failure --
  --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_api_request_auth_observability --
  --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_websocket_connect_auth_observability
  -- --nocapture`
  - `cargo test -p codex-otel
  otel_export_routing_policy_routes_websocket_request_transport_observability
  -- --nocapture`
  - `cargo test -p codex-core --no-run --message-format short`
  - `cargo test -p codex-otel --no-run --message-format short`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Colin Young · 2026-03-17 14:26:27 -07:00
  0d2ff40a58
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• Add auth 401 observability to client bug reports (#14611)

  CXC-392
  
    [With
    401](https://openai.sentry.io/issues/7333870443/?project=4510195390611458&query=019ce8f8-560c-7f10-a00a-c59553740674&referrer=issue-stream)
    <img width="1909" height="555" alt="401 auth tags in Sentry"
    src="https://github.com/user-attachments/assets/412ea950-61c4-4780-9697-15c270971ee3"
    />
  
  
    - auth_401_*: preserved facts from the latest unauthorized response snapshot
    - auth_*: latest auth-related facts from the latest request attempt
    - auth_recovery_*: unauthorized recovery state and follow-up result
  
  
    Without 401
    <img width="1917" height="522" alt="happy-path auth tags in Sentry"
    src="https://github.com/user-attachments/assets/3381ed28-8022-43b0-b6c0-623a630e679f"
    />
  
    ###### Summary
    - Add client-visible 401 diagnostics for auth attachment, upstream auth classification, and 401 request id / cf-ray correlation.
    - Record unauthorized recovery mode, phase, outcome, and retry/follow-up status without changing auth behavior.
    - Surface the highest-signal auth and recovery fields on uploaded client bug reports so they are usable in Sentry.
    - Preserve original unauthorized evidence under `auth_401_*` while keeping follow-up result tags separate.
  
    ###### Rationale (from spec findings)
    - The dominant bucket needed proof of whether the client attached auth before send or upstream still classified the request as missing auth.
    - Client uploads needed to show whether unauthorized recovery ran and what the client tried next.
    - Request id and cf-ray needed to be preserved on the unauthorized response so server-side correlation is immediate.
    - The bug-report path needed the same auth evidence as the request telemetry path, otherwise the observability would not be operationally useful.
  
    ###### Scope
    - Add auth 401 and unauthorized-recovery observability in `codex-rs/core`, `codex-rs/codex-api`, and `codex-rs/otel`, including feedback-tag surfacing.
    - Keep auth semantics, refresh behavior, retry behavior, endpoint classification, and geo-denial follow-up work out of this PR.
  
    ###### Trade-offs
    - This exports only safe auth evidence: header presence/name, upstream auth classification, request ids, and recovery state. It does not export token values or raw upstream bodies.
    - This keeps websocket connection reuse as a transport clue because it can help distinguish stale reused sessions from fresh reconnects.
    - Misroute/base-url classification and geo-denial are intentionally deferred to a separate follow-up PR so this review stays focused on the dominant auth 401 bucket.
  
    ###### Client follow-up
    - PR 2 will add misroute/provider and geo-denial observability plus the matching feedback-tag surfacing.
    - A separate host/app-server PR should log auth-decision inputs so pre-send host auth state can be correlated with client request evidence.
    - `device_id` remains intentionally separate until there is a safe existing source on the feedback upload path.
  
    ###### Testing
    - `cargo test -p codex-core refresh_available_models_sorts_by_priority`
    - `cargo test -p codex-core emit_feedback_request_tags_`
    - `cargo test -p codex-core emit_feedback_auth_recovery_tags_`
    - `cargo test -p codex-core auth_request_telemetry_context_tracks_attached_auth_and_retry_phase`
    - `cargo test -p codex-core extract_response_debug_context_decodes_identity_headers`
    - `cargo test -p codex-core identity_auth_details`
    - `cargo test -p codex-core telemetry_error_messages_preserve_non_http_details`
    - `cargo test -p codex-core --all-features --no-run`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_api_request_auth_observability`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_websocket_connect_auth_observability`
    - `cargo test -p codex-otel otel_export_routing_policy_routes_websocket_request_transport_observability`

  Colin Young · 2026-03-14 15:38:51 -07:00
  d692b74007
• Start TUI on embedded app server (#14512)

  This PR is part of the effort to move the TUI on top of the app server.
  In a previous PR, we introduced an in-process app server and moved
  `exec` on top of it.
  
  For the TUI, we want to do the migration in stages. The app server
  doesn't currently expose all of the functionality required by the TUI,
  so we're going to need to support a hybrid approach as we make the
  transition.
  
  This PR changes the TUI initialization to instantiate an in-process app
  server and access its `AuthManager` and `ThreadManager` rather than
  constructing its own copies. It also adds a placeholder TUI event
  handler that will eventually translate app server events into TUI
  events. App server notifications are accepted but ignored for now. It
  also adds proper shutdown of the app server when the TUI terminates.

  Eric Traut · 2026-03-13 12:04:41 -06:00
  9dba7337f2
• fix: move inline codex-rs/core unit tests into sibling files (#14444)

  ## Why
  PR #13783 moved the `codex.rs` unit tests into `codex_tests.rs`. This
  applies the same extraction pattern across the rest of `codex-rs/core`
  so the production modules stay focused on runtime code instead of large
  inline test blocks.
  
  Keeping the tests in sibling files also makes follow-up edits easier to
  review because product changes no longer have to share a file with
  hundreds or thousands of lines of test scaffolding.
  
  ## What changed
  - replaced each inline `mod tests { ... }` in `codex-rs/core/src/**`
  with a path-based module declaration
  - moved each extracted unit test module into a sibling `*_tests.rs`
  file, using `mod_tests.rs` for `mod.rs` modules
  - preserved the existing `cfg(...)` guards and module-local structure so
  the refactor remains structural rather than behavioral
  
  ## Testing
  - `cargo test -p codex-core --lib` (`1653 passed; 0 failed; 5 ignored`)
  - `just fix -p codex-core`
  - `cargo fmt --check`
  - `cargo shear`

  Michael Bolin · 2026-03-12 08:16:36 -07:00
  0c8a36676a
• Log ChatGPT user ID for feedback tags (#13901)

  There are some bug investigations that currently require us to ask users
  for their user ID even though they've already uploaded logs and session
  details via `/feedback`. This frustrates users and increases the time
  for diagnosis.
  
  This PR includes the ChatGPT user ID in the metadata uploaded for
  `/feedback` (both the TUI and app-server).

  Eric Traut · 2026-03-11 12:33:07 -07:00
  f9cba5cb16
• [apps] Fix apps enablement condition. (#14011)

  - [x] Fix apps enablement condition to check both the feature flag and
  that the user is not an API key user.

  Matthew Zeng · 2026-03-09 22:25:43 -07:00
  566e4cee4b
• add new scopes to login (#12383)

  Validated login + refresh flows. Removing scopes from the refresh
  request until we have upgrade flow in place. Confirmed that tokens
  refresh with existing scopes.

  Alex Daley · 2026-03-04 16:41:54 +00:00
  8a59386273
• Handle missing plan info for ChatGPT accounts (#13072)

  Addresses https://github.com/openai/codex/issues/13007 and
  https://github.com/openai/codex/issues/12170
  
  There are situations where the ChatGPT auth backend might return a JWT
  that contains no plan information. Most code paths already handle this
  case well, but the internal implementation of the "account/read" app
  server call was failing in this case (returning an error rather than
  properly returning None for the plan).
  
  This resulted in a situation where users needed to log in every time the
  extension or app started even if they successfully logged in the last
  time.
  
  Summary
  - allow ChatGPT-authenticated accounts to fall back to
  `AccountPlanType::Unknown` when the token omits the plan claim
  - add regression coverage in `app-server/tests/suite/v2/account.rs` to
  confirm `account/read` returns `plan_type: Unknown` when the claim is
  absent
  - ensure the Rust auth helpers and fixtures treat missing plan claims as
  Optional and default to `Unknown`

  Eric Traut · 2026-02-27 17:51:21 -07:00
  ff5cbfd7d4
• Fixed a hole in token refresh logic for app server (#11802)

  We've continued to receive reports from users that they're seeing the
  error message "Your access token could not be refreshed because your
  refresh token was already used. Please log out and sign in again." This
  PR fixes two holes in the token refresh logic that lead to this
  condition.
  
  Background: A previous change in token refresh introduced the
  `UnauthorizedRecovery` object. It implements a state machine in the core
  agent loop that first performs a load of the on-disk auth information
  guarded by a check for matching account ID. If it finds that the on-disk
  version has been updated by another instance of codex, it uses the
  reloaded auth tokens. If the on-disk version hasn't been updated, it
  issues a refresh request from the token authority.
  
  There are two problems that this PR addresses:
  
  Problem 1: We weren't doing the same thing for the code path used by the
  app server interface. This PR effectively replicates the
  `UnauthorizedRecovery` logic for that code path.
  
  Problem 2: The `UnauthorizedRecovery` logic contained a hole in the
  `ReloadOutcome::Skipped` case. Here's the scenario. A user starts two
  instances of the CLI. Instance 1 is active (working on a task), instance
  2 is idle. Both instances have the same in-memory cached tokens. The
  user then runs `codex logout` or `codex login` to log in to a separate
  account, which overwrites the `auth.json` file. Instance 1 receives a
  401 and refreshes its token, but it doesn't write the new token to the
  `auth.json` file because the account ID doesn't match. Instance 2 is
  later activated and presented with a new task. It immediately hits a 401
  and attempts to refresh its token but fails because its cached refresh
  token is now invalid. To avoid this situation, I've changed the logic to
  immediately fail a token refresh if the user has since logged out or
  logged in to another account. This will still be seen as an error by the
  user, but the cause will be clearer.
  
  I also took this opportunity to clean up the names of existing functions
  to make their roles clearer.
  * `try_refresh_token` is renamed `request_chatgpt_token_refresh`
  * the existing `refresh_token` is renamed `refresh_token_from_authority`
  (there's a new higher-level function named `refresh_token` now)
  * `refresh_tokens` is renamed `refresh_and_persist_chatgpt_token`, and
  it now implicitly reloads
  * `update_tokens` is renamed `persist_tokens`

  Eric Traut · 2026-02-18 09:27:04 -08:00
  999576f7b8
• Remove test-support feature from codex-core and replace it with explicit test toggles (#11405)

  ## Why
  
  `codex-core` was being built in multiple feature-resolved permutations
  because test-only behavior was modeled as crate features. For a large
  crate, those permutations increase compile cost and reduce cache reuse.
  
  ## Net Change
  
  - Removed the `test-support` crate feature and related feature wiring so
  `codex-core` no longer needs separate feature shapes for test consumers.
  - Standardized cross-crate test-only access behind
  `codex_core::test_support`.
  - External test code now imports helpers from
  `codex_core::test_support`.
  - Underlying implementation hooks are kept internal (`pub(crate)`)
  instead of broadly public.
  
  ## Outcome
  
  - Fewer `codex-core` build permutations.
  - Better incremental cache reuse across test targets.
  - No intended production behavior change.

  Michael Bolin · 2026-02-10 22:44:02 -08:00
  476c1a7160
• fix(app-server): for external auth, replace id_token with chatgpt_acc… (#11240)

  …ount_id and chatgpt_plan_type
  
  ### Summary
  Following up on external auth mode which was introduced here:
  https://github.com/openai/codex/pull/10012
  
  Turns out some clients have a differently shaped ID token and don't have
  a chosen workspace (aka chatgpt_account_id) encoded in their ID token.
  So, let's replace `id_token` param with `chatgpt_account_id` and
  `chatgpt_plan_type` (optional) when initializing the external ChatGPT
  auth mode (`account/login/start` with `chatgptAuthTokens`).
  
  The client was able to test end-to-end with a Codex build from this
  branch and verified it worked!

  Owen Lin · 2026-02-09 20:48:58 -08:00
  53741013ab
• fix(auth): isolate chatgptAuthTokens concept to auth manager and app-server (#10423)

  So that the rest of the codebase (like TUI) don't need to be concerned
  whether ChatGPT auth was handled by Codex itself or passed in via
  app-server's external auth mode.

  Owen Lin · 2026-02-05 10:46:06 -08:00
  3582b74d01
• chore: rename ChatGpt -> Chatgpt in type names (#10244)

  When using ChatGPT in names of types, we should be consistent, so this
  renames some types with `ChatGpt` in the name to `Chatgpt`. From
  https://rust-lang.github.io/api-guidelines/naming.html:
  
  > In `UpperCamelCase`, acronyms and contractions of compound words count
  as one word: use `Uuid` rather than `UUID`, `Usize` rather than `USize`
  or `Stdin` rather than `StdIn`. In `snake_case`, acronyms and
  contractions are lower-cased: `is_xid_start`.
  
  This PR updates existing uses of `ChatGpt` and changes them to
  `Chatgpt`. Though in all cases where it could affect the wire format, I
  visually inspected that we don't change anything there. That said, this
  _will_ change the codegen because it will affect the spelling of type
  names.
  
  For example, this renames `AuthMode::ChatGPT` to `AuthMode::Chatgpt` in
  `app-server-protocol`, but the wire format is still `"chatgpt"`.
  
  This PR also updates a number of types in `codex-rs/core/src/auth.rs`.

  Michael Bolin · 2026-01-30 11:18:39 -08:00
  e6d913af2d
• feat: refactor CodexAuth so invalid state cannot be represented (#10208)

  Previously, `CodexAuth` was defined as follows:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L39-L46
  
  But if you looked at its constructors, we had creation for
  `AuthMode::ApiKey` where `storage` was built using a nonsensical path
  (`PathBuf::new()`) and `auth_dot_json` was `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L212-L220
  
  By comparison, when `AuthMode::ChatGPT` was used, `api_key` was always
  `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L665-L671
  
  https://github.com/openai/codex/pull/10012 took things further because
  it introduced a new `ChatgptAuthTokens` variant to `AuthMode`, which is
  important in when invoking `account/login/start` via the app server, but
  most logic _internal_ to the app server should just reason about two
  `AuthMode` variants: `ApiKey` and `ChatGPT`.
  
  This PR tries to clean things up as follows:
  
  - `LoginAccountParams` and `AuthMode` in `codex-rs/app-server-protocol/`
  both continue to have the `ChatgptAuthTokens` variant, though it is used
  exclusively for the on-the-wire messaging.
  - `codex-rs/core/src/auth.rs` now has its own `AuthMode` enum, which
  only has two variants: `ApiKey` and `ChatGPT`.
  - `CodexAuth` has been changed from a struct to an enum. It is a
  disjoint union where each variant (`ApiKey`, `ChatGpt`, and
  `ChatGptAuthTokens`) have only the associated fields that make sense for
  that variant.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10208).
  * #10224
  * __->__ #10208

  Michael Bolin · 2026-01-30 09:33:23 -08:00
  377ab0c77c
• add error messages for the go plan type (#10181)

  Adds support for the Go plan type
  Updates rate limit error messages to point to the usage page

  willwang-openai · 2026-01-30 01:17:25 +00:00
  a9cf449a80
• feat(app-server): support external auth mode (#10012)

  This enables a new use case where `codex app-server` is embedded into a
  parent application that will directly own the user's ChatGPT auth
  lifecycle, which means it owns the user’s auth tokens and refreshes it
  when necessary. The parent application would just want a way to pass in
  the auth tokens for codex to use directly.
  
  The idea is that we are introducing a new "auth mode" currently only
  exposed via app server: **`chatgptAuthTokens`** which consist of the
  `id_token` (stores account metadata) and `access_token` (the bearer
  token used directly for backend API calls). These auth tokens are only
  stored in-memory. This new mode is in addition to the existing `apiKey`
  and `chatgpt` auth modes.
  
  This PR reuses the shape of our existing app-server account APIs as much
  as possible:
  - Update `account/login/start` with a new `chatgptAuthTokens` variant,
  which will allow the client to pass in the tokens and have codex
  app-server use them directly. Upon success, the server emits
  `account/login/completed` and `account/updated` notifications.
  - A new server->client request called
  `account/chatgptAuthTokens/refresh` which the server can use whenever
  the access token previously passed in has expired and it needs a new one
  from the parent application.
  
  I leveraged the core 401 retry loop which typically triggers auth token
  refreshes automatically, but made it pluggable:
  - **chatgpt** mode refreshes internally, as usual.
  - **chatgptAuthTokens** mode calls the client via
  `account/chatgptAuthTokens/refresh`, the client responds with updated
  tokens, codex updates its in-memory auth, then retries. This RPC has a
  10s timeout and handles JSON-RPC errors from the client.
  
  Also some additional things:
  - chatgpt logins are blocked while external auth is active (have to log
  out first. typically clients will pick one OR the other, not support
  both)
  - `account/logout` clears external auth in memory
  - Ensures that if `forced_chatgpt_workspace_id` is set via the user's
  config, we respect it in both:
  - `account/login/start` with `chatgptAuthTokens` (returns a JSON-RPC
  error back to the client)
  - `account/chatgptAuthTokens/refresh` (fails the turn, and on next
  request app-server will send another `account/chatgptAuthTokens/refresh`
  request to the client).

  Owen Lin · 2026-01-29 23:46:04 +00:00
  81a17bb2c1
• [connectors] Support connectors part 1 - App server & MCP (#9667)

  In order to make Codex work with connectors, we add a built-in gateway
  MCP that acts as a transparent proxy between the client and the
  connectors. The gateway MCP collects actions that are accessible to the
  user and sends them down to the user, when a connector action is chosen
  to be called, the client invokes the action through the gateway MCP as
  well.
  
   - [x] Add the system built-in gateway MCP to list and run connectors.
   - [x] Add the app server methods and protocol

  Matthew Zeng · 2026-01-22 16:48:43 -08:00
  a2c829a808
• Attempt to reload auth as a step in 401 recovery (#8880)

  When authentication fails, first attempt to reload the auth from file
  and then attempt to refresh it.

  pakrym-oai · 2026-01-08 15:06:44 -08:00
  62a73b6d58
• Immutable CodexAuth (#8857)

  Historically we started with a CodexAuth that knew how to refresh it's
  own tokens and then added AuthManager that did a different kind of
  refresh (re-reading from disk).
  
  I don't think it makes sense for both `CodexAuth` and `AuthManager` to
  be mutable and contain behaviors.
  
  Move all refresh logic into `AuthManager` and keep `CodexAuth` as a data
  object.

  pakrym-oai · 2026-01-08 11:43:56 -08:00
  634764ece9
• Stop using AuthManager as the source of codex_home (#8846)
  pakrym-oai · 2026-01-07 18:56:20 +00:00
  018de994b0
• Move tests below auth manager (#8840)

  To simplify future diffs

  pakrym-oai · 2026-01-07 17:36:44 +00:00
  fedcb8f63c
• chore: migrate from Config::load_from_base_config_with_overrides to ConfigBuilder (#8276)

  https://github.com/openai/codex/pull/8235 introduced `ConfigBuilder` and
  this PR updates all call non-test call sites to use it instead of
  `Config::load_from_base_config_with_overrides()`.
  
  This is important because `load_from_base_config_with_overrides()` uses
  an empty `ConfigRequirements`, which is a reasonable default for testing
  so the tests are not influenced by the settings on the host. This method
  is now guarded by `#[cfg(test)]` so it cannot be used by business logic.
  
  Because `ConfigBuilder::build()` is `async`, many of the test methods
  had to be migrated to be `async`, as well. On the bright side, this made
  it possible to eliminate a bunch of `block_on_future()` stuff.

  Michael Bolin · 2025-12-18 16:12:52 -08:00
  3d4ced3ff5
• Fixes mcp elicitation test that fails for me when run locally (#8020)
  Eric Traut · 2025-12-15 16:23:04 -08:00
  d9554c8191
• Reimplement skills loading using SkillsManager + skills/list op. (#7914)

  refactor the way we load and manage skills:
  1. Move skill discovery/caching into SkillsManager and reuse it across
  sessions.
  2. Add the skills/list API (Op::ListSkills/SkillsListResponse) to fetch
  skills for one or more cwds. Also update app-server for VSCE/App;
  3. Trigger skills/list during session startup so UIs preload skills and
  handle errors immediately.

  xl-openai · 2025-12-14 09:58:17 -08:00
  5d77d4db6b
• Remove conversation_id and bring back request ID logging (#7830)
  pakrym-oai · 2025-12-10 10:44:12 -08:00
  4b684c53ae
• load models from disk and set a ttl and etag (#7722)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  Ahmed Ibrahim · 2025-12-08 13:43:04 -08:00
  222a491570
• fix: taking plan type from usage endpoint instead of thru auth token (#7610)

  pull plan type from the usage endpoint, persist it in session state /
  tui state, and propagate through rate limit snapshots

  zhao-oai · 2025-12-04 23:34:13 -08:00
  b8eab7ce90
• Introduce ModelsManager and migrate app-server to use it. (#7552)
  Ahmed Ibrahim · 2025-12-03 17:17:56 -08:00
  00cc00ead8
• Fixed status output to use auth information from AuthManager (#6529)

  This PR addresses https://github.com/openai/codex/issues/6360. The root
  problem is that the TUI was directly loading the `auth.json` file to
  access the auth information. It should instead be using the AuthManager,
  which records the current auth information. The `auth.json` file can be
  overwritten at any time by other instances of the CLI or extension, so
  its information can be out of sync with the current instance. The
  `/status` command should always report the auth information associated
  with the current instance.
  
  An alternative fix for this bug was submitted by @chojs23 in [this
  PR](https://github.com/openai/codex/pull/6495). That approach was only a
  partial fix.

  Eric Traut · 2025-11-12 10:26:50 -08:00
  ad09c138b9
• [App-server] Implement account/read endpoint (#6336)

  This PR does two things:
  1. add a new function in core that maps the core-internal plan type to
  the external plan type;
  2. implement account/read that get account status (v2 of
  `getAuthStatus`).

  Celia Chen · 2025-11-06 19:43:13 -08:00
  e84e39940b
• Improved token refresh handling to address "Re-connecting" behavior (#6231)

  Currently, when the access token expires, we attempt to use the refresh
  token to acquire a new access token. This works most of the time.
  However, there are situations where the refresh token is expired,
  exhausted (already used to perform a refresh), or revoked. In those
  cases, the current logic treats the error as transient and attempts to
  retry it repeatedly.
  
  This PR changes the token refresh logic to differentiate between
  permanent and transient errors. It also changes callers to treat the
  permanent errors as fatal rather than retrying them. And it provides
  better error messages to users so they understand how to address the
  problem. These error messages should also help us further understand why
  we're seeing examples of refresh token exhaustion.
  
  Here is the error message in the CLI. The same text appears within the
  extension.
  
  <img width="863" height="38" alt="image"
  src="https://github.com/user-attachments/assets/7ffc0d08-ebf0-4900-b9a9-265064202f4f"
  />
  
  I also correct the spelling of "Re-connecting", which shouldn't have a
  hyphen in it.
  
  Testing: I manually tested these code paths by adding temporary code to
  programmatically cause my refresh token to be exhausted (by calling the
  token refresh endpoint in a tight loop more than 50 times). I then
  simulated an access token expiration, which caused the token refresh
  logic to be invoked. I confirmed that the updated logic properly handled
  the error condition.
  
  Note: We earlier discussed the idea of forcefully logging out the user
  at the point where token refresh failed. I made several attempts to do
  this, and all of them resulted in a bad UX. It's important to surface
  this error to users in a way that explains the problem and tells them
  that they need to log in again. We also previously discussed deleting
  the auth.json file when this condition is detected. That also creates
  problems because it effectively changes the auth status from logged in
  to logged out, and this causes odd failures and inconsistent UX. I think
  it's therefore better not to delete auth.json in this case. If the user
  closes the CLI or VSCE and starts it again, we properly detect that the
  access token is expired and the refresh token is "dead", and we force
  the user to go through the login flow at that time.
  
  This should address aspects of #6191, #5679, and #5505

  Eric Traut · 2025-11-05 10:51:57 -08:00
  c4ebe4b078
• Refresh tokens more often and log a better message when both auth and token refresh fails (#5655)

  <img width="784" height="153" alt="image"
  src="https://github.com/user-attachments/assets/c44b0eb2-d65c-4fc2-8b54-b34f7e1c4d95"
  />

  pakrym-oai · 2025-10-28 18:55:53 -07:00
  ef3e075ad6
• [Auth] Choose which auth storage to use based on config (#5792)

  This PR is a follow-up to #5591. It allows users to choose which auth
  storage mode they want by using the new
  `cli_auth_credentials_store_mode` config.

  Celia Chen · 2025-10-27 19:41:49 -07:00
  4a42c4e142
• [Auth] Introduce New Auth Storage Abstraction for Codex CLI (#5569)

  This PR introduces a new `Auth Storage` abstraction layer that takes
  care of read, write, and load of auth tokens based on the
  AuthCredentialsStoreMode. It is similar to how we handle MCP client
  oauth
  [here](https://github.com/openai/codex/blob/main/codex-rs/rmcp-client/src/oauth.rs).
  Instead of reading and writing directly from disk for auth tokens, Codex
  CLI workflows now should instead use this auth storage using the public
  helper functions.
  
  This PR is just a refactor of the current code so the behavior stays the
  same. We will add support for keyring and hybrid mode in follow-up PRs.
  
  I have read the CLA Document and I hereby sign the CLA

  Celia Chen · 2025-10-27 11:01:14 -07:00
  eb5b1b627f
• Made token refresh code resilient to missing id_token (#5782)

  This PR does the following:
  1. Changes `try_refresh_token` to handle the case where the endpoint
  returns a response without an `id_token`. The OpenID spec indicates that
  this field is optional and clients should not assume it's present.
  2. Changes the `attempt_stream_responses` to propagate token refresh
  errors rather than silently ignoring them.
  3. Fixes a typo in a couple of error messages (unrelated to the above,
  but something I noticed in passing) - "reconnect" should be spelled
  without a hyphen.
  
  This PR does not implement the additional suggestion from @pakrym-oai
  that we should sign out when receiving `refresh_token_expired` from the
  refresh endpoint. Leaving this as a follow-on because I'm undecided on
  whether this should be implemented in `try_refresh_token` or its
  callers.

  Eric Traut · 2025-10-27 10:09:53 -07:00
  0c1ff1d3fd
• Log more types of request IDs (#5645)

  Different services return different sets of IDs, log all of them to
  simplify debugging.

  pakrym-oai · 2025-10-24 19:12:03 +00:00
  a4be4d78b9
• Add CodexHttpClient wrapper with request logging (#5564)

  ## Summary
  - wrap the default reqwest::Client inside a new
  CodexHttpClient/CodexRequestBuilder pair and log the HTTP method, URL,
  and status for each request
  - update the auth/model/provider plumbing to use the new builder helpers
  so headers and bearer auth continue to be applied consistently
  - add the shared `http` dependency that backs the header conversion
  helpers
  
  ## Testing
  - `CODEX_SANDBOX=seatbelt CODEX_SANDBOX_NETWORK_DISABLED=1 cargo test -p
  codex-core`
  - `CODEX_SANDBOX=seatbelt CODEX_SANDBOX_NETWORK_DISABLED=1 cargo test -p
  codex-chatgpt`
  - `CODEX_SANDBOX=seatbelt CODEX_SANDBOX_NETWORK_DISABLED=1 cargo test -p
  codex-tui`
  
  ------
  https://chatgpt.com/codex/tasks/task_i_68fa5038c17483208b1148661c5873be

  pakrym-oai · 2025-10-24 09:47:52 -07:00
  061862a0e2
• Fix flaky auth tests (#5461)

  This #[serial] approach is not ideal. I am tracking a separate issue to
  create an injectable env var provider but I want to fix these tests
  first.
  
  Fixes #5447

  Gabriel Peal · 2025-10-21 09:08:34 -07:00
  a517f6f55b
• Add forced_chatgpt_workspace_id and forced_login_method configuration options (#5303)

  This PR adds support for configs to specify a forced login method
  (chatgpt or api) as well as a forced chatgpt account id. This lets
  enterprises uses [managed
  configs](https://developers.openai.com/codex/security#managed-configuration)
  to force all employees to use their company's workspace instead of their
  own or any other.
  
  When a workspace id is set, a query param is sent to the login flow
  which auto-selects the given workspace or errors if the user isn't a
  member of it.
  
  This PR is large but a large % of it is tests, wiring, and required
  formatting changes.
  
  API login with chatgpt forced
  <img width="1592" height="116" alt="CleanShot 2025-10-19 at 22 40 04"
  src="https://github.com/user-attachments/assets/560c6bb4-a20a-4a37-95af-93df39d057dd"
  />
  
  ChatGPT login with api forced
  <img width="1018" height="100" alt="CleanShot 2025-10-19 at 22 40 29"
  src="https://github.com/user-attachments/assets/d010bbbb-9c8d-4227-9eda-e55bf043b4af"
  />
  
  Onboarding with api forced
  <img width="892" height="460" alt="CleanShot 2025-10-19 at 22 41 02"
  src="https://github.com/user-attachments/assets/cc0ed45c-b257-4d62-a32e-6ca7514b5edd"
  />
  
  Onboarding with ChatGPT forced
  <img width="1154" height="426" alt="CleanShot 2025-10-19 at 22 41 27"
  src="https://github.com/user-attachments/assets/41c41417-dc68-4bb4-b3e7-3b7769f7e6a1"
  />
  
  Logging in with the wrong workspace
  <img width="2222" height="84" alt="CleanShot 2025-10-19 at 22 42 31"
  src="https://github.com/user-attachments/assets/0ff4222c-f626-4dd3-b035-0b7fe998a046"
  />

  Gabriel Peal · 2025-10-20 08:50:54 -07:00
  d87f87e25b
• [codex][otel] propagate user email in otel events (#5223)

  include user email into otel events for proper user-level attribution in
  case of workspace setup

  Anton Panasenko · 2025-10-15 17:53:33 -07:00
  c146585cdb
• Support CODEX_API_KEY for codex exec (#4615)

  Allows to set API key per invocation of `codex exec`

  pakrym-oai · 2025-10-02 09:59:45 -07:00
  2f6fb37d72
• fix: remove mcp-types from app server protocol (#4537)

  We continue the separation between `codex app-server` and `codex
  mcp-server`.
  
  In particular, we introduce a new crate, `codex-app-server-protocol`,
  and migrate `codex-rs/protocol/src/mcp_protocol.rs` into it, renaming it
  `codex-rs/app-server-protocol/src/protocol.rs`.
  
  Because `ConversationId` was defined in `mcp_protocol.rs`, we move it
  into its own file, `codex-rs/protocol/src/conversation_id.rs`, and
  because it is referenced in a ton of places, we have to touch a lot of
  files as part of this PR.
  
  We also decide to get away from proper JSON-RPC 2.0 semantics, so we
  also introduce `codex-rs/app-server-protocol/src/jsonrpc_lite.rs`, which
  is basically the same `JSONRPCMessage` type defined in `mcp-types`
  except with all of the `"jsonrpc": "2.0"` removed.
  
  Getting rid of `"jsonrpc": "2.0"` makes our serialization logic
  considerably simpler, as we can lean heavier on serde to serialize
  directly into the wire format that we use now.

  Michael Bolin · 2025-10-01 02:16:26 +00:00
  5881c0d6d4
• Fixed login failure with API key in IDE extension when a .codex directory doesn't exist (#4258)

  This addresses bug #4092
  
  Testing:
  * Confirmed error occurs prior to fix if logging in using API key and no
  `~/.codex` directory exists
  * Confirmed after fix that `~/.codex` directory is properly created and
  error doesn't occur

  Eric Traut · 2025-09-25 16:53:28 -07:00
  9f2ab97fbc
• When logging in using ChatGPT, make sure to overwrite API key (#3611)

  When logging in using ChatGPT using the `codex login` command, a
  successful login should write a new `auth.json` file with the ChatGPT
  token information. The old code attempted to retain the API key and
  merge the token information into the existing `auth.json` file. With the
  new simplified login mechanism, `auth.json` should have auth information
  for only ChatGPT or API Key, not both.
  
  The `codex login --api-key <key>` code path was already doing the right
  thing here, but the `codex login` command was incorrect. This PR fixes
  the problem and adds test cases for both commands.

  Eric Traut · 2025-09-14 19:48:18 -07:00
  900bb01486
• Use PlanType enum when formatting usage-limit CTA (#3495)

  - Started using Play type struct
  - Added CTA for team/business 
  - Refactored a bit to unify the logic

  Ahmed Ibrahim · 2025-09-11 22:01:25 +00:00
  44587c2443
• chore: enable clippy::redundant_clone (#3489)

  Created this PR by:
  
  - adding `redundant_clone` to `[workspace.lints.clippy]` in
  `cargo-rs/Cargol.toml`
  - running `cargo clippy --tests --fix`
  - running `just fmt`
  
  Though I had to clean up one instance of the following that resulted:
  
  ```rust
  let codex = codex;
  ```

  Michael Bolin · 2025-09-11 11:59:37 -07:00
  bec51f6c05
• Simplify auth flow and reconcile differences between ChatGPT and API Key auth (#3189)

  This PR does the following:
  * Adds the ability to paste or type an API key.
  * Removes the `preferred_auth_method` config option. The last login
  method is always persisted in auth.json, so this isn't needed.
  * If OPENAI_API_KEY env variable is defined, the value is used to
  prepopulate the new UI. The env variable is otherwise ignored by the
  CLI.
  * Adds a new MCP server entry point "login_api_key" so we can implement
  this same API key behavior for the VS Code extension.
  <img width="473" height="140" alt="Screenshot 2025-09-04 at 3 51 04 PM"
  src="https://github.com/user-attachments/assets/c11bbd5b-8a4d-4d71-90fd-34130460f9d9"
  />
  <img width="726" height="254" alt="Screenshot 2025-09-04 at 3 51 32 PM"
  src="https://github.com/user-attachments/assets/6cc76b34-309a-4387-acbc-15ee5c756db9"
  />

  Eric Traut · 2025-09-11 09:16:34 -07:00
  e13b35ecb0
• Replace config.responses_originator_header_internal_override with CODEX_INTERNAL_ORIGINATOR_OVERRIDE_ENV_VAR (#3388)

  The previous config approach had a few issues:
  1. It is part of the config but not designed to be used externally
  2. It had to be wired through many places (look at the +/- on this PR
  3. It wasn't guaranteed to be set consistently everywhere because we
  don't have a super well defined way that configs stack. For example, the
  extension would configure during newConversation but anything that
  happened outside of that (like login) wouldn't get it.
  
  This env var approach is cleaner and also creates one less thing we have
  to deal with when coming up with a better holistic story around configs.
  
  One downside is that I removed the unit test testing for the override
  because I don't want to deal with setting the global env or spawning
  child processes and figuring out how to introspect their originator
  header. The new code is sufficiently simple and I tested it e2e that I
  feel as if this is still worth it.

  Gabriel Peal · 2025-09-09 17:23:23 -04:00
  5eab4c7ab4
• Add a common way to create HTTP client (#3110)

  Ensure User-Agent and originator are always sent.

  pakrym-oai · 2025-09-03 10:11:02 -07:00
  c636f821ae