100 Commits

• [codex-rs] support v2 personal access tokens (#25731)

  ## Summary
  
  - add v2 personal access token support for `codex login
  --with-access-token` and `CODEX_ACCESS_TOKEN`
  - classify opaque `at-` tokens separately from legacy Agent Identity
  JWTs
  - hydrate required ChatGPT account metadata through AuthAPI
  `/v1/user-auth-credential/whoami`
  - use PATs directly as bearer tokens while preserving existing ChatGPT
  account surfaces
  - expose PAT-backed auth as the explicit `personalAccessToken`
  app-server auth mode
  
  ## Implementation
  
  PAT auth is intentionally small and stateless. Loading a PAT performs
  one AuthAPI metadata request, stores the hydrated metadata in the
  in-memory auth object, and redacts the secret from debug output. Legacy
  Agent Identity JWT handling remains unchanged. The shared access-token
  classifier lives in a private neutral module because it dispatches
  between both credential types.
  
  PAT hydration fails closed when AuthAPI omits any required metadata,
  including email. Hydrated metadata is intentionally not persisted:
  startup performs a live `whoami` preflight so revoked tokens or changed
  account metadata are not accepted from a stale cache.
  
  ## Workspace restriction scope
  
  This change intentionally does **not** apply
  `forced_chatgpt_workspace_id` to PAT authentication. The setting is a
  client-side config guardrail, not an authorization boundary, and PAT
  does not currently require workspace-ID parity. The PAT login and
  `CODEX_ACCESS_TOKEN` paths therefore validate through AuthAPI without
  threading workspace-restriction state through access-token loading.
  Existing workspace checks for non-PAT auth remain on their established
  paths.
  
  ## App-server compatibility
  
  The public app-server `AuthMode` is shared across v1 and v2, and
  PAT-backed auth reports `personalAccessToken` through both APIs.
  Following human review, this intentionally removes the temporary v1
  compatibility mapping that reported PATs as `chatgpt`; the deprecated v1
  API is kept in parity with v2 rather than maintaining a separate closed
  enum. Clients with exhaustive auth-mode handling in either API version
  must add the new case and should generally treat it as ChatGPT-backed
  unless they need PAT-specific behavior.
  
  The v1 auth-status response still omits the raw PAT when `includeToken`
  is requested because that response cannot carry the account metadata
  needed to reuse the credential safely. Persisted PAT auth also omits the
  new enum value so older Codex builds can deserialize `auth.json` and
  infer PAT auth from the credential field after a rollback.
  
  ## Validation
  
  Latest review-fix validation:
  
  - `CARGO_INCREMENTAL=0 just test -p codex-login` (126 passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-cli` (263 passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-cli
  stored_auth_validation_handles_personal_access_token`
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server-protocol` (226
  passed)
  - `CARGO_INCREMENTAL=0 just test -p codex-models-manager
  refresh_available_models_uses_remote_only_catalog_for_chatgpt_auth`
  - `CARGO_INCREMENTAL=0 just test -p codex-tui
  existing_non_oauth_chatgpt_login_counts_as_signed_in`
  - `CARGO_INCREMENTAL=0 just fix -p codex-login -p
  codex-app-server-protocol -p codex-models-manager -p codex-tui -p
  codex-cli`
  - `just fmt`
  - `git diff --check`
  
  The broader `codex-tui` suite previously compiled and ran 2,834 tests.
  Three unrelated environment-sensitive guardian/IDE-socket tests failed
  after retries; the PAT-relevant TUI coverage passed.

  cooper-oai · 2026-06-05 17:36:18 -07:00
  df7818c7d1
• Surface TUI config write error causes (#26537)

  ## Summary
  
  TUI config writes currently wrap app-server failures with local context
  like `config/batchWrite failed in TUI`, but several user-visible paths
  only render the outer error. That hides the actionable app-server
  message, such as validation constraints or read-only `CODEX_HOME`
  failures, leaving users with a dead-end diagnostic.
  
  This change adds a small formatter next to the TUI config write helpers
  that renders the error source chain, then uses it for model persistence,
  feature persistence, project trust, status line writes, hook trust, and
  hook enablement.
  
  Fixes #26077

  Eric Traut · 2026-06-05 08:32:07 -07:00
  3acd71fedb
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• Move cloud requirements crate to cloud config (#24621)

  ## Summary
  
  - Moves the existing `codex-cloud-requirements` crate to
  `codex-cloud-config`.
  - Updates workspace dependencies and imports to the new crate name.
  - Intentionally keeps runtime behavior unchanged: this still fetches the
  legacy cloud requirements endpoint.
  
  ## Details
  
  This PR exists to make the lineage obvious before the bundle migration.
  GitHub should show the old `codex-rs/cloud-requirements/src/lib.rs`
  implementation as moved to `codex-rs/cloud-config/src/lib.rs`, rather
  than as unrelated new code.
  
  The follow-up PR adapts this moved crate to the new config bundle API
  and switches runtime consumers over.

  joeflorencio-openai · 2026-06-01 16:43:52 -07:00
  0b3a6f7185
• feat(tui): add OSC 8 web links to rich content (#24472)

  ## Why
  
  Wrapped URLs in rich TUI output, especially URLs rendered inside
  Markdown tables, are split across terminal rows. In terminals that
  support OSC 8 hyperlinks, treating each visible fragment as part of the
  complete destination enables reliable open-link and copy-link actions
  even after table layout wraps the URL.
  
  This addresses the semantic-link portion of #12200 and the behavior
  described in
  https://github.com/openai/codex/issues/12200#issuecomment-4535452980. It
  does not change ordinary drag-selection across bordered table rows.
  
  ## What Changed
  
  - Added shared TUI OSC 8 support that validates `http://` and `https://`
  destinations, sanitizes terminal payloads, and applies metadata
  separately from visible line width/layout.
  - Added semantic web-link annotations to assistant and proposed-plan
  Markdown, including explicit web links and bare web URLs in prose and
  table cells while excluding code and non-web Markdown destinations.
  - Preserved complete URL targets through table wrapping, narrow pipe
  fallback, streaming, transcript overlay rendering, history insertion,
  and resize replay.
  - Routed intentional Codex-owned links in notices,
  status/setup/app-link, feedback, onboarding, MCP/plugin help, memories,
  and update surfaces through the shared hyperlink handling.
  
  ## How to Test
  
  1. Run Codex in a terminal with OSC 8 link support, such as Ghostty, and
  request an assistant response containing a Markdown table whose last
  column contains a long `https://` URL.
  2. Make the terminal narrow enough for the URL to wrap across multiple
  bordered table rows.
  3. Use the terminal's open-link or copy-link action on more than one
  wrapped URL fragment and confirm each fragment resolves to the complete
  original URL.
  4. Resize the terminal after the table is rendered and repeat the link
  action to confirm the destination survives scrollback replay.
  5. Open the transcript overlay while rich output is present and confirm
  web links remain interactive there.
  6. As a regression check, render inline/fenced code containing URL text
  and a Markdown link such as
  `[https://example.com](mailto:support@example.com)`; confirm these do
  not acquire a web OSC 8 destination.
  
  Targeted automated coverage exercised Markdown links and exclusions,
  wrapped and pipe-fallback tables, streaming/transcript overlay
  propagation, status-link truncation, and rendered word-wrapping cell
  alignment. `just test -p codex-tui` was also run; it passed the
  hyperlink coverage and reproduced two unrelated existing guardian
  feature-flag test failures.

  Felipe Coury · 2026-05-27 20:14:55 +00:00
  7a26497836
• TUI config cleanup: trusted projects (#24255)

  ## Why
  TUI onboarding trusted-project persistence should go through the same
  app-server config write path as other config mutations. Writing
  `config.toml` directly from the trust widget bypasses that layer and can
  let onboarding proceed even when the trust decision was not actually
  persisted.
  
  ## What changed
  - Added a TUI config helper that writes the existing project trust
  structure through `config/batchWrite`.
  - Persists trust decisions as `projects.<project>.trust_level =
  "trusted"` using the existing project trust key helper.
  - Changed the trust directory widget to only record the user selection;
  onboarding performs the app-server write before reporting success.
  - Keeps the user on the trust screen and shows an error if app-server
  persistence fails.
  
  ## Verification
  - `cargo test -p codex-tui --lib
  trust_persistence_failure_keeps_trust_step_in_progress`
  - `cargo test -p codex-tui --lib
  trusted_project_edit_targets_project_trust_level`
  - Manual: built the local `codex-cli`, accepted the trust prompt in a
  temp project, confirmed `projects.<project>.trust_level = "trusted"`,
  and simulated an unwritable config to verify onboarding stays on the
  trust screen without writing trust.

  Eric Traut · 2026-05-25 09:54:05 -07:00
  bb55736906
• config: add strict config parsing (#20559)

  ## Why
  
  Codex intentionally ignores unknown `config.toml` fields by default so
  older and newer config files keep working across versions. That leniency
  also makes typo detection hard because misspelled or misplaced keys
  disappear silently.
  
  This change adds an opt-in strict config mode so users and tooling can
  fail fast on unrecognized config fields without changing the default
  permissive behavior.
  
  This feature is possible because `serde_ignored` exposes the exact
  signal Codex needs: it lets Codex run ordinary Serde deserialization
  while recording fields Serde would otherwise ignore. That avoids
  requiring `#[serde(deny_unknown_fields)]` across every config type and
  keeps strict validation opt-in around the existing config model.
  
  ## What Changed
  
  ### Added strict config validation
  
  - Added `serde_ignored`-based validation for `ConfigToml` in
  `codex-rs/config/src/strict_config.rs`.
  - Combined `serde_ignored` with `serde_path_to_error` so strict mode
  preserves typed config error paths while also collecting fields Serde
  would otherwise ignore.
  - Added strict-mode validation for unknown `[features]` keys, including
  keys that would otherwise be accepted by `FeaturesToml`'s flattened
  boolean map.
  - Kept typed config errors ahead of ignored-field reporting, so
  malformed known fields are reported before unknown-field diagnostics.
  - Added source-range diagnostics for top-level and nested unknown config
  fields, including non-file managed preference source names.
  
  ### Kept parsing single-pass per source
  
  - Reworked file and managed-config loading so strict validation reuses
  the already parsed `TomlValue` for that source.
  - For actual config files and managed config strings, the loader now
  reads once, parses once, and validates that same parsed value instead of
  deserializing multiple times.
  - Validated `-c` / `--config` override layers with the same
  base-directory context used for normal relative-path resolution, so
  unknown override keys are still reported when another override contains
  a relative path.
  
  ### Scoped `--strict-config` to config-heavy entry points
  
  - Added support for `--strict-config` on the main config-loading entry
  points where it is most useful:
    - `codex`
    - `codex resume`
    - `codex fork`
    - `codex exec`
    - `codex review`
    - `codex mcp-server`
    - `codex app-server` when running the server itself
    - the standalone `codex-app-server` binary
    - the standalone `codex-exec` binary
  - Commands outside that set now reject `--strict-config` early with
  targeted errors instead of accepting it everywhere through shared CLI
  plumbing.
  - `codex app-server` subcommands such as `proxy`, `daemon`, and
  `generate-*` are intentionally excluded from the first rollout.
  - When app-server strict mode sees invalid config, app-server exits with
  the config error instead of logging a warning and continuing with
  defaults.
  - Introduced a dedicated `ReviewCommand` wrapper in `codex-rs/cli`
  instead of extending shared `ReviewArgs`, so `--strict-config` stays on
  the outer config-loading command surface and does not become part of the
  reusable review payload used by `codex exec review`.
  
  ### Coverage
  
  - Added tests for top-level and nested unknown config fields, unknown
  `[features]` keys, typed-error precedence, source-location reporting,
  and non-file managed preference source names.
  - Added CLI coverage showing invalid `--enable`, invalid `--disable`,
  and unknown `-c` overrides still error when `--strict-config` is
  present, including compound-looking feature names such as
  `multi_agent_v2.subagent_usage_hint_text`.
  - Added integration coverage showing both `codex app-server
  --strict-config` and standalone `codex-app-server --strict-config` exit
  with an error for unknown config fields instead of starting with
  fallback defaults.
  - Added coverage showing unsupported command surfaces reject
  `--strict-config` with explicit errors.
  
  ## Example Usage
  
  Run Codex with strict config validation enabled:
  
  ```shell
  codex --strict-config
  ```
  
  Strict config mode is also available on the supported config-heavy
  subcommands:
  
  ```shell
  codex --strict-config exec "explain this repository"
  codex review --strict-config --uncommitted
  codex mcp-server --strict-config
  codex app-server --strict-config --listen off
  codex-app-server --strict-config --listen off
  ```
  
  For example, if `~/.codex/config.toml` contains a typo in a key name:
  
  ```toml
  model = "gpt-5"
  approval_polic = "on-request"
  ```
  
  then `codex --strict-config` reports the misspelled key instead of
  silently ignoring it. The path is shortened to `~` here for readability:
  
  ```text
  $ codex --strict-config
  Error loading config.toml:
  ~/.codex/config.toml:2:1: unknown configuration field `approval_polic`
    |
  2 | approval_polic = "on-request"
    | ^^^^^^^^^^^^^^
  ```
  
  Without `--strict-config`, Codex keeps the existing permissive behavior
  and ignores the unknown key.
  
  Strict config mode also validates ad-hoc `-c` / `--config` overrides:
  
  ```text
  $ codex --strict-config -c foo=bar
  Error: unknown configuration field `foo` in -c/--config override
  
  $ codex --strict-config -c features.foo=true
  Error: unknown configuration field `features.foo` in -c/--config override
  ```
  
  Invalid feature toggles are rejected too, including values that look
  like nested config paths:
  
  ```text
  $ codex --strict-config --enable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --disable does_not_exist
  Error: Unknown feature flag: does_not_exist
  
  $ codex --strict-config --enable multi_agent_v2.subagent_usage_hint_text
  Error: Unknown feature flag: multi_agent_v2.subagent_usage_hint_text
  ```
  
  Unsupported commands reject the flag explicitly:
  
  ```text
  $ codex --strict-config cloud list
  Error: `--strict-config` is not supported for `codex cloud`
  ```
  
  ## Verification
  
  The `codex-cli` `strict_config` tests cover invalid `--enable`, invalid
  `--disable`, the compound `multi_agent_v2.subagent_usage_hint_text`
  case, unknown `-c` overrides, app-server strict startup failure through
  `codex app-server`, and rejection for unsupported commands such as
  `codex cloud`, `codex mcp`, `codex remote-control`, and `codex
  app-server proxy`.
  
  The config and config-loader tests cover unknown top-level fields,
  unknown nested fields, unknown `[features]` keys, source-location
  reporting, non-file managed config sources, and `-c` validation for keys
  such as `features.foo`.
  
  The app-server test suite covers standalone `codex-app-server
  --strict-config` startup failure for an unknown config field.
  
  ## Documentation
  
  The Codex CLI docs on developers.openai.com/codex should mention
  `--strict-config` as an opt-in validation mode for supported
  config-heavy entry points once this ships.

  Michael Bolin · 2026-05-13 16:08:05 +00:00
  889ee018e7
• feat(tui): add PR summary statusline items (#20892)

  ## Why?
  
  The Codex App already exposes branch and PR context in its
  branch-details UI. This brings the same context into the CLI footer as
  opt-in statusline items, so users can choose the extra signal without
  making the default footer busier.
  
  ## What?
  
  Add optional `pull-request-number` and `branch-changes` items to the
  configurable TUI status line.
  
  - `pull-request-number` shows the open PR for the current checkout and
  renders as a clickable terminal hyperlink when OSC 8 links are
  supported.
  - `branch-changes` shows committed additions/deletions against the
  repository default branch, or `No changes` when the branch has no
  committed diff.
  
  <img width="1257" height="261" alt="CleanShot 2026-05-03 at 20 44 15"
  src="https://github.com/user-attachments/assets/10b4380b-c3e9-4729-9ee1-3f742068fa47"
  />
  
  ## Architecture
  
  This follows the same client/app-server split as the Codex App: the TUI
  owns presentation, caching, and optional rendering, while
  workspace-sensitive `git` and `gh` discovery runs through app-server.
  
  The new TUI-local `workspace_command` layer sends bounded,
  non-interactive `command/exec` requests to the active app-server. That
  makes the implementation remote-friendly: the TUI does not decide
  whether commands run in an embedded local workspace or a remote
  workspace, and it does not bypass app-server sandbox or permission
  policy.
  
  The branch summary logic stays internal to `codex-tui` because this PR
  only needs TUI statusline behavior. The command boundary is still
  isolated behind `WorkspaceCommandExecutor`, so the lookup code can be
  lifted or reused later without changing statusline rendering.
  
  ## How?
  
  - Add a TUI `WorkspaceCommandExecutor` abstraction backed by app-server
  `command/exec`.
  - Add branch summary probes for:
    - current branch name,
    - open PR metadata,
    - committed branch diff stats against the default branch.
  - Prefer remote-tracking default branch refs for diff stats, avoiding
  stale or absent local `main` branches.
  - Resolve PRs with `gh pr view` first, then fall back to
  commit-associated PR lookup across parent/fork repos.
  - Add `/statusline` picker entries, preview values, rendering, and OSC 8
  clickable PR links.
  - Keep all probes best-effort so missing `git`, missing `gh`, auth
  failures, or non-git directories hide optional items instead of
  surfacing footer errors.
  
  ## Validation
  
  - `cargo test -p codex-tui branch_summary -- --nocapture`
  - Snapshot coverage for the `/statusline` preview/setup rendering paths
  - Hyperlink rendering coverage for clickable PR statusline cells

  Felipe Coury · 2026-05-04 16:11:15 -03:00
  cc16995cc6
• state: pass state db handles through consumers (#20561)

  ## Why
  
  SQLite state was still being opened from consumer paths, including lazy
  `OnceCell`-backed thread-store call sites. That let one process
  construct multiple state DB connections for the same Codex home, which
  makes SQLite lock contention and `database is locked` failures much
  easier to hit.
  
  State DB lifetime should be chosen by main-like entrypoints and tests,
  then passed through explicitly. Consumers should use the supplied
  `Option<StateDbHandle>` or `StateDbHandle` and keep their existing
  filesystem fallback or error behavior when no handle is available.
  
  The startup path also needs to keep the rollout crate in charge of
  SQLite state initialization. Opening `codex_state::StateRuntime`
  directly bypasses rollout metadata backfill, so entrypoints should
  initialize through `codex_rollout::state_db` and receive a handle only
  after required rollout backfills have completed.
  
  ## What Changed
  
  - Initialize the state DB in main-like entrypoints for CLI, TUI,
  app-server, exec, MCP server, and the thread-manager sample.
  - Pass `Option<StateDbHandle>` through `ThreadManager`,
  `LocalThreadStore`, app-server processors, TUI app wiring, rollout
  listing/recording, personality migration, shell snapshot cleanup,
  session-name lookup, and memory/device-key consumers.
  - Remove the lazy local state DB wrapper from the thread store so
  non-test consumers use only the supplied handle or their existing
  fallback path.
  - Make `codex_rollout::state_db::init` the local state startup path: it
  opens/migrates SQLite, runs rollout metadata backfill when needed, waits
  for concurrent backfill workers up to a bounded timeout, verifies
  completion, and then returns the initialized handle.
  - Keep optional/non-owning SQLite helpers, such as remote TUI local
  reads, as open-only paths that do not run startup backfill.
  - Switch app-server startup from direct
  `codex_state::StateRuntime::init` to the rollout state initializer so
  app-server cannot skip rollout backfill.
  - Collapse split rollout lookup/list APIs so callers use the normal
  methods with an optional state handle instead of `_with_state_db`
  variants.
  - Restore `getConversationSummary(ThreadId)` to delegate through
  `ThreadStore::read_thread` instead of a LocalThreadStore-specific
  rollout path special case.
  - Keep DB-backed rollout path lookup keyed on the DB row and file
  existence, without imposing the filesystem filename convention on
  existing DB rows.
  - Verify readable DB-backed rollout paths against `session_meta.id`
  before returning them, so a stale SQLite row that points at another
  thread's JSONL falls back to filesystem search and read-repairs the DB
  row.
  - Keep `debug prompt-input` filesystem-only so a one-off debug command
  does not initialize or backfill SQLite state just to print prompt input.
  - Keep goal-session test Codex homes alive only in the goal-specific
  helper, rather than leaking tempdirs from the shared session test
  helper.
  - Update tests and call sites to pass explicit state handles where DB
  behavior is expected and explicit `None` where filesystem-only behavior
  is intended.
  
  ## Validation
  
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo check -p
  codex-rollout -p codex-thread-store -p codex-app-server -p codex-core -p
  codex-tui -p codex-exec -p codex-cli --tests`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout state_db_`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout find_thread_path`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout find_thread_path -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout try_init_ -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-rollout`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo clippy -p
  codex-rollout --lib -- -D warnings`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-thread-store
  read_thread_falls_back_when_sqlite_path_points_to_another_thread --
  --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-thread-store`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  shell_snapshot`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all personality_migration`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find`
  - `RUST_MIN_STACK=8388608 CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find::find_prefers_sqlite_path_by_id --
  --nocapture`
  - `RUST_MIN_STACK=8388608 CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  --test all rollout_list_find -- --nocapture`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p codex-core
  interrupt_accounts_active_goal_before_pausing`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-app-server get_auth_status -- --test-threads=1`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo test -p
  codex-app-server --lib`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db cargo check -p codex-rollout
  -p codex-app-server --tests`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-rollout
  -p codex-thread-store -p codex-core -p codex-app-server -p codex-tui -p
  codex-exec -p codex-cli`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-rollout -p
  codex-app-server`
  - `CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p
  codex-rollout`
  - `CODEX_SKIP_VENDORED_BWRAP=1
  CARGO_TARGET_DIR=/tmp/codex-target-state-db just fix -p codex-core`
  - `just argument-comment-lint -p codex-core`
  - `just argument-comment-lint -p codex-rollout`
  
  Focused coverage added in `codex-rollout`:
  
  - `recorder::tests::state_db_init_backfills_before_returning` verifies
  the rollout metadata row exists before startup init returns.
  - `state_db::tests::try_init_waits_for_concurrent_startup_backfill`
  verifies startup waits for another worker to finish backfill instead of
  disabling the handle for the process.
  -
  `state_db::tests::try_init_times_out_waiting_for_stuck_startup_backfill`
  verifies startup does not hang indefinitely on a stuck backfill lease.
  -
  `tests::find_thread_path_accepts_existing_state_db_path_without_canonical_filename`
  verifies DB-backed lookup accepts valid existing rollout paths even when
  the filename does not include the thread UUID.
  -
  `tests::find_thread_path_falls_back_when_db_path_points_to_another_thread`
  verifies DB-backed lookup ignores a stale row whose existing path
  belongs to another thread and read-repairs the row after filesystem
  fallback.
  
  Focused coverage updated in `codex-core`:
  
  - `rollout_list_find::find_prefers_sqlite_path_by_id` now uses a
  DB-preferred rollout file with matching `session_meta.id`, so it still
  verifies that valid SQLite paths win without depending on stale/empty
  rollout contents.
  
  `cargo test -p codex-app-server thread_list_respects_search_term_filter
  -- --test-threads=1 --nocapture` was attempted locally but timed out
  waiting for the app-server test harness `initialize` response before
  reaching the changed thread-list code path.
  
  `bazel test //codex-rs/thread-store:thread-store-unit-tests
  --test_output=errors` was attempted locally after the thread-store fix,
  but this container failed before target analysis while fetching `v8+`
  through BuildBuddy/direct GitHub. The equivalent local crate coverage,
  including `cargo test -p codex-thread-store`, passes.
  
  A plain local `cargo check -p codex-rollout -p codex-app-server --tests`
  also requires system `libcap.pc` for `codex-linux-sandbox`; the
  follow-up app-server check above used `CODEX_SKIP_VENDORED_BWRAP=1` in
  this container.

  Ruslan Nigmatullin · 2026-05-04 11:46:03 -07:00
  4d201e340e
• Enforce animations = false for screen readers (#20564)

  ## Why
  
  Issue #20489 calls out that animated TUI affordances can be noisy for
  screen-reader users. Codex already has `tui.animations = false` as a
  reduced-motion setting, but some live activity rows render spinner-style
  prefixes in that mode. These were relatively recent regressions.
  
  We have also regressed this pattern more than once by adding new
  spinner/shimmer callsites that do not think through the reduced-motion
  path, so this PR adds a small guardrail while fixing the current
  surfaces.
  
  ## What changed
  
  - Omit the live status-row spinner when animations are disabled, so the
  row starts with stable text like `Working (...)`.
  - Render running hook headers without the spinner prefix when animations
  are disabled, while preserving shimmer/spinner behavior when animations
  are enabled.
  - Centralize TUI activity indicators in `tui/src/motion.rs`, with
  explicit reduced-motion choices for hidden prefixes, static bullets, and
  plain shimmer-text fallbacks.
  - Route existing spinner/shimmer callsites through the central motion
  helper, including exec rows, MCP/web-search/loading rows, hook rows,
  plugin loading, and onboarding loading text.
  - Add a source-scan regression test that rejects direct `spinner(...)`
  or `shimmer_spans(...)` usage outside the central module and primitive
  definition.
  - Add focused coverage that reduced-motion active exec rows are stable,
  status rows start without a spinner, running hooks omit the spinner, and
  MCP inventory loading stays stable.
  - Update the one affected status-indicator snapshot; the existing detail
  tree prefix remains unchanged.
  
  ## Verification
  
  - `cargo test -p codex-tui`

  Eric Traut · 2026-05-01 09:07:56 -07:00
  227bee0445
• Remove core protocol dependency [2/2] (#20325)

  ## Why
  
  With the local model layer and app-server routing in place from PR1,
  this PR moves the active TUI runtime onto app-server notifications. The
  affected pieces share the same event flow, so the command surface,
  session state, bottom-pane prompts, chat rendering, history/status
  views, and tests move together to keep the stacked branch buildable.
  
  This PR also removes the obsolete compatibility surface that is no
  longer used after the migration. The proposed protocol-boundary verifier
  layer was dropped from the stack; enforcing that final boundary will be
  simpler once `codex-tui` no longer needs any `codex_protocol`
  references.
  
  This PR is part 2 of a 2-PR stack:
  
  1. Add TUI-owned replacement models and extract app-server event
  routing.
  2. Move the active TUI flow to app-server notifications and delete
  obsolete adapter code.
  
  ## What changed
  
  - Rewired app command and session handling to use app-server request and
  notification shapes.
  - Moved approval overlays, request-user-input flows, MCP elicitation,
  realtime events, and review commands onto the app-server-facing model
  surface.
  - Updated chat rendering, history cells, status views, multi-agent UI,
  replay state, and TUI tests to use app-server notifications plus the
  local models introduced in PR1.
  - Deleted `codex-rs/tui/src/app/app_server_adapter.rs` and the
  superseded `chatwidget/tests/background_events.rs` fixture path.
  
  ## Verification
  
  - `cargo check -p codex-tui --tests`
  - Top of stack: `cargo test -p codex-tui`

  Eric Traut · 2026-04-30 11:34:34 -07:00
  f2bc2f26a9
• Update Codex login success page UX (#20136)

  ## Summary
  
  update the local login success page to match the Codex desktop auth UX
  use theme-aware colors and an inline 20px Codex mark
  keep the actual localhost success page aligned with the browser auth UX
  PR
  
  ## Tests
  
  <img width="1728" height="1117" alt="Screenshot 2026-04-29 at 12 00
  34 PM"
  src="https://github.com/user-attachments/assets/76a40c3f-07c3-452c-97da-e7c43717cd2c"
  />

  rafael-jac · 2026-04-29 19:14:53 -04:00
  98f67b15d3
• feat(tui): add configurable keymap support (#18593)

  ## Why
  
  The TUI currently handles keyboard shortcuts as hard-coded event matches
  spread across app, composer, pager, list, approval, and navigation code.
  That makes shortcuts hard to customize, makes displayed hints easy to
  drift from actual behavior, and makes future keymap work riskier because
  there is no central action inventory.
  
  This PR adds the foundation for configurable, action-based keymaps
  without adding the interactive remapping UI yet. Onboarding
  intentionally stays on fixed startup shortcuts because users cannot
  reasonably configure keymaps before completing onboarding.
  
  This is PR1 in the keymap stack:
  
  - PR1: #18593: configurable keymap foundation
  - PR2: #18594: `/keymap` picker and guided remapping UI
  - PR3: #18595: Vim composer mode and the remap option
  
  ## Design Notes
  
  The new model resolves named actions into concrete runtime bindings once
  from config, then passes those bindings to the UI surfaces that handle
  input or render shortcut hints.
  
  The main concepts are:
  
  - **Context**: a scope where an action is active, such as `global`,
  `chat`, `composer`, `editor`, `pager`, `list`, or `approval`.
  - **Action**: a named operation inside a context, such as
  `global.open_transcript`, `composer.submit`, or `pager.close`.
  - **Binding**: one or more single-key shortcuts assigned to an action,
  written as config strings such as `ctrl-t`, `alt-backspace`, or
  `page-down`. Multi-step sequences such as `ctrl-x ctrl-s`, `g g`, or
  leader-key flows are not part of this PR.
  - **Resolution order**: context-specific config wins first, supported
  global fallbacks come next, and built-in defaults fill in anything
  unset.
  - **Explicit unbinding**: an empty array removes an action binding in
  that scope and does not fall through to a fallback binding.
  - **Conflict validation**: a resolved keymap rejects duplicate active
  bindings inside the same scope so one keypress cannot dispatch two
  actions.
  
  ## What Changed
  
  - Added `TuiKeymap` config support under `[tui.keymap]`, including typed
  contexts/actions, key alias normalization, generated schema coverage,
  and user-facing config errors.
  - Added `RuntimeKeymap` resolution in `codex-rs/tui/src/keymap.rs`,
  including fallback precedence, built-in defaults, explicit unbinding,
  and per-context conflict validation.
  - Rewired existing TUI handlers to consume resolved keymap actions
  instead of directly matching hard-coded keys in each component.
  - Updated key hint rendering and footer/pager/list surfaces so displayed
  shortcuts follow the resolved keymap.
  - Kept onboarding shortcuts fixed in
  `codex-rs/tui/src/onboarding/keys.rs` instead of exposing them through
  `[tui.keymap]`.
  
  ## Validation
  
  The branch includes focused coverage for config parsing, key
  normalization, runtime fallback resolution, explicit unbinding,
  duplicate-key conflict validation, default keymap consistency,
  onboarding startup key behavior, and UI hint snapshots affected by
  resolved key bindings.

  Felipe Coury · 2026-04-28 12:52:25 -03:00
  5e737372ee
• refactor: make auth loading async (#19762)

  ## Summary
  
  Auth loading used to expose synchronous construction helpers in several
  places even though some auth sources now need async work. This PR makes
  the auth-loading surface async and updates the callers to await it.
  
  This is intentionally only plumbing. It does not change how
  AgentIdentity tokens are decoded, how task runtime ids are allocated, or
  how JWT signatures are verified.
  
  ## Stack
  
  1. **This PR:** [refactor: make auth loading
  async](https://github.com/openai/codex/pull/19762)
  2. [refactor: load AgentIdentity runtime
  eagerly](https://github.com/openai/codex/pull/19763)
  3. [feat: verify AgentIdentity JWTs with
  JWKS](https://github.com/openai/codex/pull/19764)
  
  ## Important call sites
  
  | Area | Change |
  | --- | --- |
  | `codex-login` auth loading | `CodexAuth` and `AuthManager`
  construction paths now await auth loading. |
  | app-server startup | Auth manager construction is awaited during
  initialization. |
  | CLI/TUI/exec/MCP/chatgpt callers | Existing auth-loading calls now
  await the same behavior. |
  | cloud requirements storage loader | The loader becomes async so it can
  share the same auth construction path. |
  | auth tests | Tests that load auth now run in async contexts. |
  
  ## Testing
  
  Tests: targeted Rust auth test compilation, formatter, scoped Clippy
  fix, and Bazel lock check.

  efrazer-oai · 2026-04-27 11:00:27 -07:00
  2009f6e894
• fix(tui): reflow scrollback on terminal resize (#18575)

  Fixes multiple scrollback and terminal resize issues: #5538, #5576,
  #8352, #12223, #16165, and #15380.
  
  ## Why
  
  Codex writes finalized transcript output into terminal scrollback after
  wrapping it for the current viewport width. A later terminal resize
  could leave that scrollback shaped for the old width, so wider windows
  kept narrow output and narrower windows could show stale wrapping
  artifacts until enough new output replaced the visible area.
  
  This is also the foundation PR for responsive markdown tables. Table
  rendering needs finalized transcript content to be width-sensitive after
  insertion, not only while content is first streaming. Markdown table
  rendering itself stays in #18576.
  
  ## Stack
  
  - PR1: resize backlog reflow and interrupt cleanup
  - #18576: markdown table support
  
  ## What Changed
  
  - Rebuild source-backed transcript history when the terminal width
  changes. `terminal_resize_reflow` is introduced through the experimental
  feature system, but is enabled by default for this rollout so we can
  validate behavior across real terminals.
  - Preserve assistant and plan stream source so finalized streaming
  output can participate in resize reflow after consolidation.
  - Debounce resize work, but force a final source-backed reflow when a
  resize happened during active or unconsolidated streaming output.
  - Clear stale pending history lines on resize so old-width wrapped
  output is not emitted just before rebuilt scrollback.
  - Bound replay work with `[tui.terminal_resize_reflow].max_rows`:
  omitted uses terminal-specific defaults, `0` keeps all rendered rows,
  and a positive value sets an explicit cap. The cap applies both while
  initially replaying a resumed transcript into scrollback and when
  rebuilding scrollback after terminal resize.
  - Consolidate interrupted assistant streams before cleanup, then clear
  pending stream output and active-tail state consistently.
  - Move resize reflow and thread event buffering helpers out of `app.rs`
  into dedicated TUI modules.
  - Add focused coverage for resize reflow, feature-gated behavior,
  streaming source preservation, interrupted output cleanup,
  unicode-neutral text, terminal-specific row caps, and composer/layout
  stability.
  
  ## Runtime Bounds
  
  Resize reflow keeps only the most recent rendered rows when a row cap is
  active. The default is `auto`, which maps to the detected terminal's
  default scrollback size where Codex can identify it: VS Code `1000`,
  Windows Terminal `9001`, WezTerm `3500`, and Alacritty `10000`.
  Terminals without a dedicated mapping use the conservative fallback of
  `1000` rows. Users can override this with `[tui.terminal_resize_reflow]
  max_rows = N`, or set `max_rows = 0` to disable row limiting.
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui reflow`
  - `cargo test --manifest-path codex-rs/Cargo.toml -p codex-tui
  transcript_reflow`
  - `just fix -p codex-tui`
  - PR CI in progress on the squashed branch

  Felipe Coury · 2026-04-25 22:00:32 -03:00
  5591912f0b
• Support multiple managed environments (#18401)

  ## Summary
  - refactor EnvironmentManager to own keyed environments with
  default/local lookup helpers
  - keep remote exec-server client creation lazy until exec/fs use
  - preserve disabled agent environment access separately from internal
  local environment access
  
  ## Validation
  - not run (per Codex worktree instruction to avoid tests/builds unless
  requested)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• Warn when trusting Git subdirectories (#18602)

  Addresses #18505
  
  ## Summary
  
  When Codex is launched from a subdirectory of a Git repository, the
  onboarding trust prompt says it is trusting the current directory even
  though the persisted trust target is the repository root. That can make
  the scope of the trust decision unclear.
  
  This updates the TUI trust prompt to show a yellow note only when the
  current directory differs from the resolved trust target, explaining
  that trust applies to the repository root and displaying that root. It
  also removes the stale onboarding TODO now that the warning is
  implemented.

  Eric Traut · 2026-04-20 16:43:21 -07:00
  216e7a0a56
• fix: trust-gate project hooks and exec policies (#14718)

  ## Summary
  - trust-gate project `.codex` layers consistently, including repos that
  have `.codex/hooks.json` or `.codex/execpolicy/*.rules` but no
  `.codex/config.toml`
  - keep disabled project layers in the config stack so nested trusted
  project layers still resolve correctly, while preventing hooks and exec
  policies from loading until the project is trusted
  - update app-server/TUI onboarding copy to make the trust boundary
  explicit and add regressions for loader, hooks, exec-policy, and
  onboarding coverage
  
  ## Security
  Before this change, an untrusted repo could auto-load project hooks or
  exec policies from `.codex/` as long as `config.toml` was absent. This
  makes trust the single gate for project-local config, hooks, and exec
  policies.
  
  ## Stack
  - Parent of #15936
  
  ## Test
  - cargo test -p codex-core without_config_toml
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 17:56:58 -07:00
  370bed4bf4
• Refactor config loading to use filesystem abstraction (#18209)

  Initial pass propagating FileSystem through config loading.

  pakrym-oai · 2026-04-17 00:51:21 +00:00
  9effa0509f
• Async config loading (#18022)

  Parts of config will come from executor. Prepare for that by making
  config loading methods async.

  pakrym-oai · 2026-04-15 19:18:38 -07:00
  bd61737e8a
• fix: propagate log db (#17953)

  It restores the TRACE logs in the DB and `/feedback`
  Fix https://github.com/openai/codex/pull/16184 
  
  Result:
  https://openai.sentry.io/issues/6972946529/?project=4510195390611458&query=019d91e9-f931-7451-8852-c5240514a419&referrer=issue-stream

  jif-oai · 2026-04-15 20:25:53 +01:00
  7e7b35b4d2
• Use AbsolutePathBuf in skill loading and codex_home (#17407)

  Helps with FS migration later

  pakrym-oai · 2026-04-13 10:26:51 -07:00
  ac82443d07
• TUI: enforce core boundary (#17399)

  Problem: The TUI still depended on `codex-core` directly in a number of
  places, and we had no enforcement from keeping this problem from getting
  worse.
  
  Solution: Route TUI core access through
  `codex-app-server-client::legacy_core`, add CI enforcement for that
  boundary, and re-export this legacy bridge inside the TUI as
  `crate::legacy_core` so the remaining call sites stay readable. There is
  no functional change in this PR — just changes to import targets.
  
  Over time, we can whittle away at the remaining symbols in this legacy
  namespace with the eventual goal of removing them all. In the meantime,
  this linter rule will prevent us from inadvertently importing new
  symbols from core.

  Eric Traut · 2026-04-10 20:25:31 -07:00
  66e13efd9c
• [codex] Support remote exec cwd in TUI startup (#17142)

  When running with remote executor the cwd is the remote path. Today we
  check for existence of a local directory on startup and attempt to load
  config from it.
  
  For remote executors don't do that.

  pakrym-oai · 2026-04-08 13:09:28 -07:00
  e4d6702b87
• feat: single app-server bootstrap in TUI (#16582)

  Before this, the TUI was starting 2 app-server. One to check the login
  status and one to actually start the session
  
  This PR make only one app-server startup and defer the login check in
  async, outside of the frame rendering path
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-08 13:49:06 +01:00
  2bbab7d8f9
• [codex] reduce module visibility (#16978)

  ## Summary
  - reduce public module visibility across Rust crates, preferring private
  or crate-private modules with explicit crate-root public exports
  - update external call sites and tests to use the intended public crate
  APIs instead of reaching through module trees
  - add the module visibility guideline to AGENTS.md
  
  ## Validation
  - `cargo check --workspace --all-targets --message-format=short` passed
  before the final fix/format pass
  - `just fix` completed successfully
  - `just fmt` completed successfully
  - `git diff --check` passed

  pakrym-oai · 2026-04-07 08:03:35 -07:00
  413c1e1fdf
• Refactor config types into a separate crate (#16962)

  Move config types into a separate crate because their macros expand into
  a lot of new code.

  pakrym-oai · 2026-04-07 00:32:41 +00:00
  1f2411629f
• tui: route device-code auth through app server (#16827)

  Addresses #7646
  Also enables device code auth for remote TUI sessions
  
  Problem: TUI onboarding handled device-code login directly rather than
  using the recently-added app server support for device auth. Also, auth
  screens kept animating while users needed to copy login details.
  
  Solution: Route device-code onboarding through app-server login APIs and
  make the auth screens static while those copy-oriented flows are
  visible.

  Eric Traut · 2026-04-06 15:47:26 -07:00
  e88c2cf4d7
• core: remove cross-crate re-exports from lib.rs (#16512)

  ## Why
  
  `codex-core` was re-exporting APIs owned by sibling `codex-*` crates,
  which made downstream crates depend on `codex-core` as a proxy module
  instead of the actual owner crate.
  
  Removing those forwards makes crate boundaries explicit and lets leaf
  crates drop unnecessary `codex-core` dependencies. In this PR, this
  reduces the dependency on `codex-core` to `codex-login` in the following
  files:
  
  ```
  codex-rs/backend-client/Cargo.toml
  codex-rs/mcp-server/tests/common/Cargo.toml
  ```
  
  ## What
  
  - Remove `codex-rs/core/src/lib.rs` re-exports for symbols owned by
  `codex-login`, `codex-mcp`, `codex-rollout`, `codex-analytics`,
  `codex-protocol`, `codex-shell-command`, `codex-sandboxing`,
  `codex-tools`, and `codex-utils-path`.
  - Delete the `default_client` forwarding shim in `codex-rs/core`.
  - Update in-crate and downstream callsites to import directly from the
  owning `codex-*` crate.
  - Add direct Cargo dependencies where callsites now target the owner
  crate, and remove `codex-core` from `codex-rs/backend-client`.

  Michael Bolin · 2026-04-01 23:06:24 -07:00
  aa2403e2eb
• Rename tui_app_server to tui (#16104)

  This is a follow-up to https://github.com/openai/codex/pull/15922. That
  previous PR deleted the old `tui` directory and left the new
  `tui_app_server` directory in place. This PR renames `tui_app_server` to
  `tui` and fixes up all references.

  Eric Traut · 2026-03-28 11:23:07 -06:00
  61429a6c10
• Remove the legacy TUI split (#15922)

  This is the part 1 of 2 PRs that will delete the `tui` /
  `tui_app_server` split. This part simply deletes the existing `tui`
  directory and marks the `tui_app_server` feature flag as removed. I left
  the `tui_app_server` feature flag in place for now so its presence
  doesn't result in an error. It is simply ignored.
  
  Part 2 will rename the `tui_app_server` directory `tui`. I did this as
  two parts to reduce visible code churn.

  Eric Traut · 2026-03-27 22:56:44 +00:00
  d65deec617
• Use AbsolutePathBuf for cwd state (#15710)

  Migrate `cwd` and related session/config state to `AbsolutePathBuf` so
  downstream consumers consistently see absolute working directories.
  
  Add test-only `.abs()` helpers for `Path`, `PathBuf`, and `TempDir`, and
  update branch-local tests to use them instead of
  `AbsolutePathBuf::try_from(...)`.
  
  For the remaining TUI/app-server snapshot coverage that renders absolute
  cwd values, keep the snapshots unchanged and skip the Windows-only cases
  where the platform-specific absolute path layout differs.

  pakrym-oai · 2026-03-25 16:02:22 +00:00
  504aeb0e09
• Add legal link to TUI /plugin details (#15692)

  - Adds language and "[learn
  more](https://help.openai.com/en/articles/11487775-apps-in-chatgpt)"
  link to plugin details pages.
  -  Message is hidden when plugin is installed
  
  <img width="1970" height="498" alt="image"
  src="https://github.com/user-attachments/assets/f14330f7-661e-4860-8538-6dc9e8bbd90a"
  />

  canvrno-oai · 2026-03-24 17:40:26 -07:00
  38b638d89d
• Move git utilities into a dedicated crate (#15564)

  - create `codex-git-utils` and move the shared git helpers into it with
  file moves preserved for diff readability
  - move the `GitInfo` helpers out of `core` so stacked rollout work can
  depend on the shared crate without carrying its own git info module
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-24 13:26:23 -07:00
  0f957a93cd
• 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
• Renaming Team to Business plan during TUI onboarding (#13313)

  Team is referred to as "Business"

  bwanner-oai · 2026-03-02 23:13:29 -08:00
  6deb72c04b
• Update Codex docs success link (#12805)

  Fix a stale documentation link in the sign-in flow

  Eric Traut · 2026-02-25 12:02:41 -08:00
  f6fdfbeb98
• fix(tui): preserve URL clickability across all TUI views (#12067)

  ## Problem
  
  Long URLs containing `/` and `-` characters are split across multiple
  terminal lines by `textwrap`'s default hyphenation rules. This breaks
  terminal link detection: emulators can no longer identify the URL as
  clickable, and copy-paste yields a truncated fragment. The issue affects
  every view that renders user or agent text — exec output, history cells,
  markdown, the app-link setup screen, and the VT100 scrollback path.
  
  A secondary bug compounds the first: `desired_height()` calculations
  count logical lines rather than viewport rows. When a URL overflows its
  line and wraps visually, the height budget is too small, causing content
  to clip or leave gaps.
  
  Here is how the complete URL is interpreted by the terminal before
  (first line only) and after (complete URL):
  
  | Before | After |
  |---|---|
  | <img width="777" height="1002" alt="Screenshot 2026-02-17 at 7 59 11
  PM"
  src="https://github.com/user-attachments/assets/193a89a0-7e56-49c5-8b76-53499a76e7e3"
  /> | <img width="777" height="1002" alt="Screenshot 2026-02-17 at 7 58
  40 PM"
  src="https://github.com/user-attachments/assets/0b9b4c14-aafb-439f-9ffe-f6bba556f95e"
  /> |
  
  ## Mental model
  
  The TUI now treats URL-like tokens as atomic units that must never be
  split by the wrapping engine. Every call site that previously used
  `word_wrap_*` has been migrated to `adaptive_wrap_*`, which inspects
  each line for URL-like tokens and switches wrapping strategy
  accordingly:
  
  - **Non-URL lines** follow the existing `textwrap` path unchanged (word
  boundaries, optional indentation, hyphenation).
  - **URL-only lines** (with at most decorative markers like `│`, `-`,
  `1.`) are emitted unwrapped so terminal link detection works; ratatui's
  `Wrap { trim: false }` handles the final character wrap at render time.
  - **Mixed lines** (URL + substantive non-URL prose) flow through
  `adaptive_wrap_line` so prose wraps naturally at word boundaries while
  URL tokens remain unsplit.
  
  Height measurement everywhere now delegates to
  `Paragraph::line_count(width)`, which accounts for the visual row cost
  of overflowed lines. This single source of truth replaces ad-hoc line
  counting in individual cells.
  
  For terminal scrollback (the VT100 path that prints history when the TUI
  exits), URL-only lines are emitted unwrapped so the terminal's own link
  detector can find them. Mixed URL+prose lines use adaptive wrapping so
  surrounding text wraps naturally. Continuation rows are pre-cleared to
  avoid stale content artifacts.
  
  ## Non-goals
  
  - Full RFC 3986 URL parsing. The detector is a conservative heuristic
  that covers `scheme://host`, bare domains (`example.com/path`),
  `localhost:port`, and IPv4 hosts. IPv6 (`[::1]:8080`) and exotic schemes
  are intentionally excluded from v1.
  - Changing wrapping behavior for non-URL content.
  - Reflowing or reformatting existing terminal scrollback on resize.
  
  ## Tradeoffs
  
  | Decision | Upside | Downside |
  |----------|--------|----------|
  | Heuristic URL detection vs. full parser | Fast, zero-alloc on the hot
  path; conservative enough to reject file paths like `src/main.rs` |
  False negatives on obscure URL formats (they get split as before) |
  | Adaptive (three-path) wrapping | Non-URL lines are untouched — no
  behavior change, no perf cost; mixed lines wrap prose naturally while
  preserving URLs | Three wrapping strategies to reason about when
  debugging layout |
  | Row-based truncation with line-unit ellipsis | Accurate viewport
  budget; stable "N lines omitted" count across terminal widths |
  `truncate_lines_middle` is more complex (must compute per-line row cost)
  |
  | Unwrapped URL-only lines in scrollback | Terminal emulators detect
  clickable links; copy-paste gets the full URL | TUI and scrollback
  formatting diverge for URL-only lines |
  | Default `desired_height` via `Paragraph::line_count` | DRY — most
  cells inherit correct measurement | Cells with custom layout must
  remember to override |
  
  ## Architecture
  
  ```mermaid
  flowchart TD
      A["adaptive_wrap_*()"] --> B{"line_contains_url_like?"}
      B -- No URL tokens --> C["word_wrap_line<br/>(textwrap default)"]
      B -- Has URL tokens --> D{"mixed URL + prose?"}
      D -- "URL-only<br/>(+ decorative markers)" --> E["emit unwrapped<br/>(terminal char-wraps)"]
      D -- "Mixed<br/>(URL + substantive text)" --> F["adaptive_wrap_line<br/>(AsciiSpace + custom WordSplitter)"]
      C --> G["Paragraph::line_count(w)<br/>(single height truth)"]
      E --> G
      F --> G
  ```
  
  **Changed files:**
  
  | File | Role |
  |------|------|
  | `wrapping.rs` | URL detection heuristics, mixed-line detection,
  `adaptive_wrap_*` functions, custom `WordSplitter` |
  | `exec_cell/render.rs` | Row-aware `truncate_lines_middle`, adaptive
  wrapping for command/output display |
  | `history_cell.rs` | Migrate all cell types to `adaptive_wrap_*`;
  default `desired_height` via `Paragraph::line_count` |
  | `insert_history.rs` | Three-path scrollback wrapping (unwrapped
  URL-only, adaptive mixed, word-wrapped text); continuation row clearing
  |
  | `app_link_view.rs` | Adaptive wrapping for setup URL; `desired_height`
  via `Paragraph::line_count` |
  | `markdown_render.rs` | Adaptive wrapping in `finish_paragraph` |
  | `model_migration.rs` | Viewport-aware wrapping for narrow-pane
  markdown |
  | `pager_overlay.rs` | `Wrap { trim: false }` for transcript and
  streaming chunks |
  | `queued_user_messages.rs` | Migrate to `adaptive_wrap_lines` |
  | `status/card.rs` | Migrate to `adaptive_wrap_lines` |
  
  ## Observability
  
  - **Ellipsis message** in truncated exec output reports omitted count in
  logical lines (stable across resize) rather than viewport rows
  (fluctuates).
  - URL detection is deterministic and stateless — no hidden caching or
  memoization to go stale.
  - Height mismatch bugs surface immediately as visual clipping or gaps;
  the `Paragraph::line_count` path is the same code ratatui uses at render
  time, so measurement and rendering cannot diverge.
  
  ## Tests
  
  26 new unit tests across 7 files, covering:
  
  - **URL integrity**: assert a URL-like token appears on exactly one
  rendered line (not split across two).
  - **Height accuracy**: compare `desired_height()` against
  `Paragraph::line_count()` for URL-containing content.
  - **Row-aware truncation**: verify ellipsis counts logical lines and
  output fits within the row budget.
  - **Scrollback rendering**: VT100 backend tests confirm prefix and URL
  land on the same row; continuation rows are cleared; mixed URL+prose
  lines wrap prose while preserving URL tokens.
  - **Mixed URL+prose detection**: `line_has_mixed_url_and_non_url_tokens`
  correctly distinguishes lines with substantive non-URL text from lines
  with only decorative markers alongside a URL.
  - **Heuristic correctness**: positive matches (`https://...`,
  `example.com/path`, `localhost:3000/api`, `192.168.1.1:8080/health`) and
  negative matches (`src/main.rs`, `foo/bar`, `hello-world`).
  
  ## Risks and open items
  
  1. **URL-like tokens in code output** (e.g. `example.com/api` inside a
  JSON blob) will trigger URL-preserving wrap on that line. This is
  acceptable — the worst case is a slightly wider line, not broken output.
  2. **Very long non-URL tokens on a URL line** can only break at
  character boundaries (the custom splitter emits all char indices for
  non-URL words). On extremely narrow terminals this could overflow, but
  narrow terminals already degrade gracefully.
  3. **No IPv6 support** — `[::1]:8080/path` will be treated as a non-URL
  and may get split. Can be added later without API changes.
  
  Fixes #5457

  Felipe Coury · 2026-02-21 15:31:41 -08:00
  2ba2c57af4
• Promote Windows Sandbox (#11341)

  1. Move Windows Sandbox NUX to right after trust directory screen
  2. Don't offer read-only as an option in Sandbox NUX.
  Elevated/Legacy/Quit
  3. Don't allow new untrusted directories. It's trust or quit
  4. move experimental sandbox features to `[windows]
  sandbox="elevated|unelevatd"`
  5. Copy tweaks = elevated -> default, non-elevated -> non-admin

  iceweasel-oai · 2026-02-11 11:48:33 -08:00
  87279de434
• 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(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
• fix: ignore key release events during onboarding (#10131)

  ## Summary
  - guard onboarding key handling to ignore KeyEventKind::Release
  - handle key events at the onboarding screen boundary to avoid
  double-triggering widgets
  
  ## Related
  - https://github.com/ratatui/ratatui/issues/347
  
  ## Testing
  - cd codex-rs && just fmt
  - cd codex-rs && cargo test -p codex-tui

  Josh McKinney · 2026-01-28 22:13:53 -08:00
  e70592f85a
• Raise welcome animation breakpoint to 37 rows (#9778)

  ### Motivation
  - The large ASCII welcome animation can push onboarding content below
  the fold on default-height terminals, making the CLI appear
  unresponsive; raising the breakpoint prevents that.
  - The existing test measured an arbitrary row count rather than
  asserting the welcome line position relative to the animation frame,
  which made the intent unclear.
  
  ### Description
  - Increase `MIN_ANIMATION_HEIGHT` from `20` to `37` in
  `codex-rs/tui/src/onboarding/welcome.rs` so the animation is skipped
  unless there is enough vertical space.
  - Replace the brittle measurement logic in the welcome render test with
  a `row_containing` helper and assert the welcome row equals the frame
  height plus the spacer line (`frame_lines + 1`).
  - Add a regression test
  `welcome_skips_animation_below_height_breakpoint` that verifies the
  animation is not rendered when the viewport height is one row below the
  breakpoint.
  
  ### Testing
  - Ran formatting with `~/.cargo/bin/just fmt` which completed
  successfully.
  - Ran unit tests for the crate with `cargo test -p codex-tui --lib` and
  they passed (unit test suite succeeded).
  - Ran `cargo test -p codex-tui` which reported a failing integration
  test in this environment because the test cannot locate the `codex`
  binary, so full crate tests are blocked here (environment limitation).
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6973b0a710d4832c9ff36fac26eb1519)

  Matthew Zeng · 2026-01-24 21:50:35 -08:00
  182000999c
• [device-auth] Add device code auth as a standalone option when headless environment is detected. (#9333)
  Matthew Zeng · 2026-01-16 08:35:03 -08:00
  131590066e
• [device-auth] When headless environment is detected, show device login flow instead. (#8756)

  When headless environment is detected, show device login flow instead.

  Matthew Zeng · 2026-01-08 21:48:30 -08:00
  24d6e0114f
• [device-auth] Update login instruction for headless environments. (#8753)

  We've seen reports that people who try to login on a remote/headless
  machine will open the login link on their own machine and got errors.
  Update the instructions to ask those users to use `codex login
  --device-auth` instead.
  
  <img width="1434" height="938" alt="CleanShot 2026-01-05 at 11 35 02@2x"
  src="https://github.com/user-attachments/assets/2b209953-6a42-4eb0-8b55-bb0733f2e373"
  />

  Matthew Zeng · 2026-01-05 13:46:42 -08:00
  c29afc0cf3
• Change "Team" to "Buisness" and add Education (#8221)

  This pull request updates the ChatGPT login description in the
  onboarding authentication widgets to clarify which plans include usage.
  The description now lists "Business" rather than "Team" and adds
  "Education" plans in addition to the previously mentioned plans.
  
  I have read the CLA Document and I hereby sign the CLAs.
  
  ---------
  
  Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

  Ethan Phillips · 2025-12-18 08:35:22 +00:00
  e1deeefa0f
• fix: dont quit on 'q' in onboarding ApiKeyEntry state (#7869)

  ### What
  
  Don't treat `q` as a special quit character on the API key paste page in
  the onboarding flow.
  
  This addresses #7413, where pasting API keys with `q` would cause codex
  to quit on Windows.
  
  ### Test Plan
  
  Tested on Windows and MacOS.

  sayan-oai · 2025-12-11 09:57:59 -08:00
  703bf12b36
• Add Enterprise plan to ChatGPT login description (#6918)

  ## Summary
  - update ChatGPT onboarding login description to mention Enterprise
  plans alongside Plus, Pro, and Team
  
  ## Testing
  - just fmt
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_691e088daf20832c88d8b667adf45128)

  ae · 2025-12-03 23:47:46 -08:00
  871f44f385