106 Commits

• Allow ChatGPT accounts without email (#28991)

  # Summary
  
  Codex required every ChatGPT account to have an email address. A
  service-account personal access token can return valid account metadata
  without one, so PAT login failed while decoding the metadata response.
  
  This change makes email optional in the account metadata type that owns
  it and preserves that absence through authentication, provider account
  state, the app-server API, generated clients, and TUI bootstrap.
  Existing accounts with email addresses keep the same behavior.
  
  ## Behavior-changing call sites
  
  | Call site | Behavior after this change |
  | --- | --- |
  | `login/src/auth/personal_access_token.rs` | PAT metadata accepts a
  missing or null email and retains `None`. |
  | `agent-identity/src/lib.rs` | Agent Identity JWT claims accept an
  omitted email. |
  | `login/src/auth/storage.rs` and `login/src/auth/agent_identity.rs` |
  Stored and managed Agent Identity records carry `Option<String>`.
  Deserialization maps the legacy empty-string sentinel to `None`. |
  | `login/src/auth/manager.rs` | `get_account_email` returns the stored
  option, and managed identity bootstrap no longer converts `None` to an
  empty string. |
  | `model-provider/src/provider.rs` and `protocol/src/account.rs` | A
  ChatGPT provider account requires a plan type but may carry no email. |
  | `app-server-protocol/src/protocol/v2/account.rs` | `account/read`
  keeps the `email` field on the wire and returns `null` when the account
  has no email. Generated TypeScript and JSON schemas describe a required,
  nullable field. |
  | `sdk/python/src/openai_codex/generated/v2_all.py` | The generated
  Python `ChatgptAccount` model accepts `None` for email. |
  | `tui/src/app_server_session.rs` | Email-less ChatGPT accounts
  bootstrap normally, keep external feedback routing, omit account-email
  telemetry, and display the plan in account status. |
  
  ## Design decisions
  
  - Missing email remains `None` at every layer. The code never uses an
  empty string as a substitute.
  - The app-server response includes `"email": null` instead of omitting
  the field. Clients retain a stable response shape.
  - Plan type remains required for provider account state. This change
  relaxes only the email assumption.
  
  ## Testing
  
  Tests: affected test targets compile, scoped Clippy and formatting pass,
  a focused TUI snapshot covers plan-only account status, real
  before/after PAT login smoke covers metadata without email, app-server
  smoke covers `account/read` with `email: null`, and a regression smoke
  covers an existing email-bearing PAT. Unit tests run in CI.
  
  ## Evidence
  
  Visual smoke evidence will be attached here.

  efrazer-oai · 2026-06-22 13:19:40 -07:00
  5a67d898a5
• Expose thread-level multi-agent mode (#28792)

  ## Why
  
  Once multi-agent mode can be selected per turn, clients also need to
  choose the initial selection when creating a thread and observe that
  selection through lifecycle and settings APIs.
  
  The selected value is intentionally distinct from the effective
  model-visible value: no client selection is represented as `null`, even
  though an eligible multi-agent v2 turn derives `explicitRequestOnly` as
  its effective default.
  
  ## What changed
  
  - Add the optional experimental `thread/start.multiAgentMode` parameter
  and pass it through thread creation.
  - Preserve an omitted initial value as an unset selection rather than
  eagerly storing `explicitRequestOnly`.
  - Apply an explicit `thread/start` selection to the first turn through
  the session configuration established at thread creation.
  - Restore the latest persisted effective mode as the selected baseline
  on cold resume when rollout history contains one.
  - Inherit the optional selected mode from a loaded parent when creating
  related runtime threads.
  - Return the current selected `multiAgentMode` from `thread/start`,
  `thread/resume`, `thread/fork`, and thread settings, using `null` when
  no mode is selected.
  - Keep lifecycle reporting independent from model capability and feature
  eligibility; core turn construction remains responsible for calculating
  and persisting the effective mode.
  
  ## Not covered
  
  - Clearing an existing loaded-session selection back to unset through
  `turn/start`; omitted or `null` currently retains the session's
  selection.
  - A TUI control, slash command, or `config.toml` preference.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server-protocol`
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server multi_agent_mode`
  
  The focused app-server coverage verifies explicit `thread/start`
  initialization, first-turn prompting, nullable reporting for an omitted
  selection, and retention of selections that are not currently
  runtime-eligible.
  
  ## Stack
  
  Stacked on #28685. This PR contains only the thread initialization and
  lifecycle/settings API layer.

  Shijie Rao · 2026-06-19 10:50:44 +02:00
  7abfcf220b
• Add per-turn multi-agent mode (#28685)

  ## Why
  
  Multi-agent v2 currently carries an explicit-request-only delegation
  rule in its static usage hint. That provides a safe default, but it
  prevents clients from selecting proactive delegation per turn without
  changing static guidance or rewriting prior model context.
  
  This change makes delegation mode a session selection that can be
  updated through `turn/start`, while deriving the effective model-visible
  mode separately for each turn. Eligible multi-agent v2 turns remain
  explicit-request-only unless proactive mode is both selected and
  enabled.
  
  ## What changed
  
  - Add the experimental `turn/start.multiAgentMode` parameter with
  `explicitRequestOnly` and `proactive` values. Omission retains the
  loaded session's current optional selection.
  - Add the default-off `features.multi_agent_mode` feature gate. Eligible
  multi-agent v2 turns use the selected mode when enabled; an unset
  selection or disabled gate resolves to `explicitRequestOnly`.
  - Treat mode prompting as inapplicable for multi-agent v1 and other
  unsupported session configurations, producing no multi-agent mode
  developer message rather than rejecting the turn.
  - Move the explicit-request-only rule out of the static v2 usage hint
  and into a bounded, tagged developer context fragment.
  - Emit the effective mode in initial context and only when that
  effective mode changes on later turns.
  - Persist the effective mode in `TurnContextItem` as the durable
  baseline for resume and context-update comparisons.
  
  Historical rollout items are not rewritten. Later mode developer
  messages establish the current rule incrementally.
  
  ## Not covered
  
  - Initial selection through `thread/start` and selected-mode reporting
  from thread lifecycle/settings APIs; those are isolated in the stacked
  #28792.
  - A TUI control or slash command for selecting the mode.
  - Persisting a preferred mode to `config.toml`; selection remains
  session/turn scoped.
  - Changes to multi-agent concurrency limits, tool availability, or model
  catalog capability declarations.
  - Rewriting historical rollout prompt items. Cold resume restores the
  latest persisted effective mode when available while leaving historical
  developer messages intact.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-core multi_agent_mode`
  - Focused app-server coverage verifies that `turn/start.multiAgentMode`
  produces proactive developer instructions for an eligible v2 turn.
  
  ## Stack
  
  Followed by #28792, which adds `thread/start` initialization and
  lifecycle/settings observability.

  Shijie Rao · 2026-06-18 22:47:51 -07:00
  fc8c6b7384
• core: load AGENTS.md from foreign environments (#28958)

  ## Why
  
  Make it possible to load AGENTS.md from remote exec-servers whose OS is
  different than app-server.
  
  ## What
  
  - keep `AGENTS.md` discovery and provenance as `PathUri`, with
  root-aware parent and ancestor traversal
  - expose lifecycle instruction sources as legacy app-server path strings
  in events while retaining `PathUri` internally
  - preserve and test mixed POSIX and Windows paths in model context and
  TUI status output
  - cover remote Windows loading end to end by seeding the Wine prefix
  through host filesystem APIs
  - fix bug in `PathUri`'s parent() implementation that would erase
  Windows drive letters

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• [codex] Track plugin install and import telemetry failures (#28731)

  ## Summary
  - Track plugin install failures through the unified
  `codex_plugin_install_failed` event for local installs, remote install
  preflight failures, bundle failures, and remote catalog/backend
  failures.
  - Send classified `error_type` values in plugin install failure
  analytics instead of raw error strings.
  - Stop sending raw external-agent import errors in analytics while
  preserving raw failure details in app-facing import
  notifications/history.
  - Keep raw plugin/migration diagnostics in `tracing::warn!` logs.
  - Keep remote failure plugin names as the existing local placeholder
  (`unknown`) and remove the extra telemetry plugin-name override.
  - Change `ExternalAgentConfigImportParams.source` from a generated enum
  to `string | null`, with legacy `claudeCode` / `claudeCowork` inputs
  normalized to existing analytics values.
  
  ## Testing

  charlesgong-openai · 2026-06-17 13:16:34 -07:00
  3959ab0ffc
• [codex] Restore thread recency with compatible migration history (#28671)

  ## Summary
  
  - Revert #28655, restoring the thread `recencyAt` behavior introduced by
  #27910.
  - Move `threads_recency_at` to migration 0039 so it no longer collides
  with `external_agent_config_imports` at version 0038.
  - Repair databases that already applied the recency migration as version
  38 by moving the matching migration-history row to version 39 before
  SQLx validation. The current version-38 migration can then apply
  normally.
  
  ## Validation
  
  - `just test -p codex-state
  migrations::tests::repairs_recency_migration_that_was_applied_as_version_38`
  - `just test -p codex-state -p codex-rollout -p codex-thread-store -p
  codex-app-server-protocol -p codex-tui`: 3,439 passed; six TUI tests
  could not open the machine's existing read-only incident database at
  `~/.codex/sqlite/state_5.sqlite`.
  - `just fix -p codex-state`
  - `just fmt`
  - Verified that state migration versions are unique.

  Jeremy Rose · 2026-06-17 18:52:18 +00:00
  7dc7096ae1
• Revert thread recencyAt for sidebar ordering (#28655)

  ## Why
  
  Revert #27910 to remove the newly introduced thread `recencyAt`
  persistence and API behavior from `main`.
  
  ## What changed
  
  This reverts commit `fac3158c2a783095768076489815f361fa9b0db4`,
  including the state migration, thread-store propagation, app-server API
  surface, generated schemas, and related tests.
  
  ## Validation
  
  Not run before opening; relying on CI for the initial fast signal.

  pakrym-oai · 2026-06-16 21:39:30 -07:00
  cb15c64760
• Add thread recencyAt for sidebar ordering (#27910)

  ## Summary
  
  Add a server-owned `recencyAt` timestamp and `recency_at` thread-list
  sort key for product recency ordering while preserving the existing
  meaning of `updatedAt` as the latest persisted thread mutation.
  
  This is the server-side alternative to #27697. Rather than narrowing
  `updatedAt`, clients can sort the sidebar by `recency_at` and continue
  treating `updatedAt` as mutation time.
  
  Paired Codex Apps PR:
  [openai/openai#1024599](https://github.com/openai/openai/pull/1024599)
  
  ## Contract
  
  - `recencyAt` initializes when a thread is created.
  - A turn start advances `recencyAt` monotonically.
  - Commentary, agent output, tool results, token/accounting updates, turn
  completion, archive, unarchive, resume, and generic metadata writes do
  not advance it.
  - `updatedAt` retains its existing behavior and continues to advance for
  persisted thread mutations.
  - Current servers populate `recencyAt`; the response field is optional
  in generated TypeScript so clients connected to older servers can fall
  back to `updatedAt`.
  - Filesystem-only fallback uses existing updated/mtime ordering when
  SQLite is unavailable.
  
  ## Persistence and compatibility
  
  Migration 0038 adds second- and millisecond-precision recency columns,
  backfills them from the existing updated timestamp, creates list
  indexes, and includes an insert trigger so older binaries writing to a
  migrated database seed recency without causing later mutations to
  advance it.
  
  Generic metadata upserts preserve existing recency values. Turn-start
  updates use a dedicated monotonic touch, and process-local allocation
  keeps millisecond cursor values unique. State DB list, search, read,
  filtered-list repair, rollout fallback propagation, and app-server
  conversions all carry the new field.
  
  ## API
  
  `Thread` responses include:
  
  ```ts
  recencyAt?: number
  ```
  
  `thread/list` and `thread/search` accept:
  
  ```json
  { "sortKey": "recency_at" }
  ```
  
  Generated TypeScript and JSON schemas are included.
  
  ## Validation
  
  - `just test -p codex-state` — 146 passed
  - `just test -p codex-rollout` — 69 passed
  - `just test -p codex-thread-store` — 81 passed
  - `just test -p codex-app-server-protocol` — 231 passed
  - Focused app-server list ordering, response mapping, archive/unarchive,
  and resume lifecycle tests passed
  - Scoped `just fix` for state, rollout, thread-store,
  app-server-protocol, and app-server
  - `just fmt`
  - `git diff --check`
  - Independent correctness, simplicity, elegance, security, and
  test-quality reviews; actionable ordering, lifecycle, query-projection,
  and timestamp-uniqueness findings were addressed

  Jeremy Rose · 2026-06-16 17:06:22 -07:00
  fac3158c2a
• [codex] expose Bedrock credential source in account/read (#27751)

  ## Why
  
  `account/read` currently reports only `type: "amazonBedrock"`, so
  clients cannot distinguish a Codex-managed Bedrock API key from
  credentials supplied by AWS. The app UI needs that distinction to render
  the appropriate account state without duplicating provider-auth logic.
  
  Credential-source selection belongs to the Bedrock model provider
  because it already owns the precedence between managed Bedrock auth and
  the external AWS credential path. This builds on #27443 and #27689.
  
  ## What changed
  
  - Added `AmazonBedrockCredentialSource` with `codexManaged` and
  `awsManaged` values.
  - Included the selected credential source in
  `ProviderAccount::AmazonBedrock` and the app-server `Account` response.
  - Made `AmazonBedrockModelProvider::account_state()` classify the source
  from its managed-auth state.
  - Regenerated the app-server JSON and TypeScript schemas.
  - Updated app-server account documentation and downstream TUI matches.
  
  `codexManaged` means the provider found a managed Bedrock API key.
  `awsManaged` identifies the provider's external AWS credential path; it
  does not assert that the AWS credential chain has been validated.
  
  ## Testing
  
  - Added model-provider coverage for Codex-managed precedence and
  AWS-managed fallback.
  - Added app-server protocol serialization coverage for both wire values.
  - Added app-server integration coverage for both `account/read`
  responses.
  - `just test -p codex-protocol -p codex-model-provider -p
  codex-app-server-protocol` (497 tests passed).
  
  After rebasing onto #27711, the `codex-app-server` test target compiled
  past the image-generation `PathUri` migration. Local linking was then
  interrupted by disk exhaustion (`No space left on device`).

  Celia Chen · 2026-06-16 07:14:53 +00:00
  12aaeb7bf8
• feat(app-server): expose rate-limit reset credits (#28143)

  ## Why
  
  Codex users can earn personal rate-limit reset credits, but app-server
  clients do not currently have an API for reading or redeeming them. This
  adds the backend and protocol foundation used by the `/usage` TUI flow
  in #28154.
  
  ## What changed
  
  - Extend `account/rateLimits/read` with a nullable
  `rateLimitResetCredits` summary sourced from the existing usage
  response.
  - Add backend-client and app-server support for consuming a reset with a
  caller-generated idempotency key. A UUID is recommended, and clients
  reuse the same key when retrying the same logical reset.
  - Return only the consume `outcome`; clients refetch
  `account/rateLimits/read` for updated window state.
  - Document the response field and each consume outcome, and regenerate
  the JSON and TypeScript schema fixtures.
  - Clarify in `AGENTS.md` that new app-server string enum values use
  camelCase on the wire.
  - Update the existing TUI response fixture for the expanded protocol
  shape.
  - Add coverage for authentication, response mapping, backend failures,
  consume outcomes, and request timeout behavior.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 231 passed.
  - `just test -p codex-backend-client` — 14 passed.
  - Focused `codex-app-server` reset-credit tests — 5 passed.
  - Focused `codex-tui` protocol response fixture test — passed.
  - `just fix -p codex-backend-client -p codex-app-server-protocol -p
  codex-app-server` — passed.
  - `just fmt` — passed.

  jay · 2026-06-15 21:54:01 +00:00
  bef99f861b
• Remove TUI realtime voice support (#27801)

  ## Why
  
  Removes the realtime audio support from TUI.
  
  ## What Changed
  
  - Removed the TUI `/realtime` and realtime `/settings` command paths.
  - Deleted TUI voice capture/playback, WebRTC session handling,
  audio-device selection UI, and recording-meter code.
  - Removed TUI realtime tests and snapshots that covered the deleted
  surfaces.
  - Dropped the TUI-only `cpal` and `codex-realtime-webrtc` dependencies
  and refreshed the Rust/Bazel locks.

  Eric Traut · 2026-06-12 14:20:55 -07:00
  576f603440
• [codex] restore source-specific import copy (#27703)

  ## Summary
  
  - restore source-specific wording across the `/import` picker, lifecycle
  messages, diagnostics, and help text
  - update the matching Unix and Windows snapshots
  - leave import behavior unchanged
  
  ## Why
  
  The import path currently supports one source, so the UI should identify
  that source directly instead of presenting the flow as
  provider-agnostic.
  
  ## Validation
  
  - `just test -p codex-tui external_agent_config_migration` (12 passed)
  - `just fix -p codex-tui`
  - `just fmt`

  stefanstokic-oai · 2026-06-12 10:19:17 -04:00
  743a4147d9
• [1 of 3] Support long raw TUI goal objectives (#27508)

  ## Stack
  
  1. **[1 of 3] Support long raw TUI goal objectives** - this PR
  2. [2 of 3] Support long pasted text in TUI goals - #27509
  3. [3 of 3] Support images in TUI goals - #27510
  
  ## Why
  
  `thread/goal/set` limits persisted objective text to 4000 characters.
  The TUI used to reject raw `/goal` objectives above that limit, even
  though the client can make them usable by writing the long text to a
  file and storing a short objective that points at that file.
  
  This also needs to work for remote app-server sessions: filesystem API
  calls must create files on the app-server host, and the stored path must
  be meaningful to the agent on that host.
  
  ## What Changed
  
  - Adds an app-server-host path helper so TUI code can build paths that
  are resolved on the app-server host rather than the TUI host.
  - Adds TUI app-server session helpers for `fs/createDirectory`,
  `fs/writeFile`, `fs/readFile`, and `fs/remove` that work for embedded
  and remote app-server sessions without changing the app-server protocol.
  - Materializes oversized raw `/goal` objectives into
  `$CODEX_HOME/attachments/<uuid>/goal-objective.md` through the
  app-server filesystem APIs, then stores a short, readable objective that
  directs the agent to that file.
  - Reads managed objective files back for `/goal edit`. Other goal UI
  renders the readable stored objective normally, without
  managed-file-specific presentation logic.
  - Recognizes managed references only when they name the expected
  generated file under the app server's reported `$CODEX_HOME`, and cleans
  up newly materialized files when goal replacement or setting does not
  complete.
  
  ## Verification
  
  - Added/updated TUI tests for raw oversized `/goal` submission, large
  inline-paste expansion, queued oversized goals, app-facing
  materialization before `thread/goal/set`, managed-path validation,
  editing, and cleanup.
  - Added/updated app-server-client remote coverage for initialized remote
  Codex home handling.
  
  ## Manual Testing
  
  - Ran the real TUI against a Unix-socket app server with different local
  and server `$CODEX_HOME` directories. Oversized goals wrote only under
  the server home, and persisted references used the server-canonical path
  rather than the TUI path.
  - Exercised 3,999-, 4,000-, and 4,001-character raw objectives. The
  first two stayed inline without new files; the 4,001-character objective
  became a managed objective file.
  - Submitted a larger 8,275-character objective, verified its full
  contents on the app-server host, and observed the goal continuation open
  the referenced server-side file.
  - Opened `/goal edit` for a managed objective and verified the full text
  was restored through remote `fs/readFile`.
  - Submitted an oversized replacement while a goal was active, verified
  no file was written before confirmation, then canceled and confirmed
  that the existing goal and attachment count were unchanged.

  Eric Traut · 2026-06-11 22:26:31 -07:00
  78bab04116
• feat: add Bedrock API key as a managed auth mode (#27443)

  ## Why
  
  Codex needs to manage Amazon Bedrock API key credentials through the
  existing auth lifecycle instead of introducing a separate auth manager
  or provider-specific credential file. Treating Bedrock API key login as
  a primary auth mode gives it the same persistence, keyring, reload, and
  logout behavior as the existing OpenAI API key and ChatGPT modes.
  
  The credential is valid only for the `amazon-bedrock` model provider.
  OpenAI-compatible providers must reject this auth mode rather than
  treating the Bedrock key as an OpenAI bearer token.
  
  ## What changed
  
  - Added `bedrockApiKey` as an app-server `AuthMode` and
  `CodexAuth::BedrockApiKey` as a primary `AuthManager` mode.
  - Added `BedrockApiKeyAuth`, containing the API key and AWS region, to
  the existing `AuthDotJson` payload stored in `$CODEX_HOME/auth.json` or
  the configured keyring backend.
  - Added `login_with_bedrock_api_key(...)`, parallel to
  `login_with_api_key(...)`, which replaces the current stored login with
  Bedrock credentials.
  - Reused generic auth reload and logout behavior instead of adding a
  Bedrock-specific auth manager or logout path.
  - Updated login restrictions, status reporting, diagnostics, telemetry
  classification, generated app-server schemas, and auth fixtures for the
  new mode.
  - Added explicit errors when Bedrock API key auth is selected with an
  OpenAI-compatible model provider.
  
  This PR establishes managed storage and auth-mode behavior. Routing the
  managed key and region into Amazon Bedrock requests will be in follow-up
  PRs.

  Celia Chen · 2026-06-10 20:42:38 -07:00
  06afd63f4a
• Add session delete commands in CLI and TUI (#27476)

  ## Summary
  
  The app server exposes `thread/delete`, but users cannot invoke it from
  the CLI or TUI. Because deletion is irreversible, the user-facing
  commands need deliberate confirmation and safer handling of name-based
  targets.
  
  - Add `codex delete <SESSION>` with interactive confirmation,
  restricting `--force` to UUID targets.
  - Resolve exact names across active and archived sessions, including
  renamed sessions, and validate prompted UUID targets before
  confirmation.
  - Add a `/delete` command with a confirmation popup that warns the
  current session and its subagent threads will be permanently deleted.
  
  ## Manual testing
  
  - Deleted by UUID with `--force` and verified the rollout, session-index
  entry, and database row were removed.
  - Exercised name-based confirmation for both cancellation and
  affirmative deletion; cancellation preserved the session and
  confirmation removed it.
  - Verified deletion refuses to proceed without `--force`, while
  `--force` rejects names, including duplicate names.
  - Verified duplicate-name confirmation displays the concrete UUID
  selected.
  - Deleted an archived session by name.
  - Verified an already-missing UUID fails before displaying a
  confirmation prompt.
  - Exercised `/delete` in the TUI: the popup defaults to No, cancellation
  preserves the session, and confirmation deletes the session and exits.
  - Verified that `codex delete` works for both archived and non-archived
  sessions.

  Eric Traut · 2026-06-10 18:04:02 -07:00
  9d87b771ce
• [codex] add /import for external agents (#27071)

  ## Why
  
  External-agent import should be discoverable and deliberate without
  blocking startup or claiming the public `codex [PROMPT]` CLI namespace.
  The slash command keeps the flow local to the interactive TUI and reuses
  the existing app-server import API.
  
  ## What changed
  
  - add the user-facing `/import` slash command
  - detect external-agent importable items only when the command is
  invoked
  - run imports through the embedded local app-server
  - show start and completion messages, refresh configuration, and block
  duplicate imports while one is pending
  - reject the flow for unsupported remote and local-daemon sessions
  
  ## Validation
  
  - `just test -p codex-tui external_agent_config_migration` (10 passed)
  - manually exercised an isolated TUI fixture with existing
  external-agent setup and session data using a fresh `CODEX_HOME`
  - verified picker customization, plugin and session detection, import
  completion, repeated invocation, and imported-session resume context
  - the broader `just test -p codex-tui` run passed 2,805 tests, with 2
  unrelated guardian feature-flag failures and 4 skipped tests
  
  ## Draft follow-ups
  
  - review whether completion messaging should remain attached to the
  initiating chat if the user switches chats during an import
  - review shutdown semantics for an in-progress background import
  
  ## Stack
  
  1. [#27064](https://github.com/openai/codex/pull/27064): remove the
  startup migration flow
  2. [#27065](https://github.com/openai/codex/pull/27065): extract the
  picker renderer
  3. [#27070](https://github.com/openai/codex/pull/27070): add the
  external-agent import picker UX
  4. [#27071](https://github.com/openai/codex/pull/27071): expose the flow
  through `/import`
  
  **This PR is stack item 4.** Draft while the lower stack dependencies
  are reviewed.

  stefanstokic-oai · 2026-06-10 15:53:15 -04:00
  b4445f2758
• [codex] remove blocking external agent migration flow (#27064)

  ## Why
  
  External-agent import should be initiated deliberately instead of
  interrupting eligible TUI startups. This cleanup removes the blocking
  startup flow before the replacement import experience is introduced
  later in the stack.
  
  ## What changed
  
  - remove the startup-blocking external-agent migration prompt
  - remove the now-unused external migration feature gate
  - remove the obsolete TUI app-server migration wrappers
  - retain the dormant picker behind a module-scoped dead-code allowance
  until the next stack item wires it back in
  - keep normal TUI startup focused on entering Codex immediately
  
  ## Validation
  
  - `bazel build --config=clippy //codex-rs/tui:tui
  //codex-rs/tui:tui-unit-tests-bin`
  - `just test -p codex-tui external_agent_config_migration` (8 passed)
  - `just test -p codex-tui` (2,786 passed, 12 unrelated local
  environment-sensitive failures, 4 skipped)
  - `just fix -p codex-tui`
  - `just fmt`
  
  ## Stack
  
  1. [#27064](https://github.com/openai/codex/pull/27064): remove the
  startup migration flow
  2. [#27065](https://github.com/openai/codex/pull/27065): extract the
  picker renderer
  3. [#27070](https://github.com/openai/codex/pull/27070): add the
  external-agent import picker UX
  4. [#27071](https://github.com/openai/codex/pull/27071): expose the flow
  through `/import`
  
  **This PR is stack item 1.**

  stefanstokic-oai · 2026-06-10 14:25:04 -04:00
  636cc11398
• fix: Prevent /review crash when entering Esc on steer message (#22879)

  This changes the `/review` escape path so `Esc` no longer behaves like
  the normal queued-follow-up interrupt flow while a review is running.
  Steering is not currently supported in `/review` mode, without this
  change users are able to attempt a steer but it leads to a crash (see
  #22815). If the user has already tried to send additional guidance
  during `/review`, the TUI now keeps the review running and shows a
  warning that steer messages are not supported in that mode, while still
  pointing users to `Ctrl+C` if they actually want to cancel. It also adds
  regression coverage for the review-specific warning behavior. When users
  do cancel with Ctrl+C during /review, the TUI now tolerates the
  active-turn race that can happen during review handoff, and any queued
  steer messages are restored to the composer instead of being discarded.
  
  - Special-case `Esc` during an active `/review` when follow-up steer
  input is pending or has already been deferred.
  - Show a clear warning instead of interrupting the running review.
  - Make the Ctrl+C cancel path during /review resilient to active-turn
  races, while preserving any queued steer text by restoring it to the
  composer.
  - Add review-mode test coverage for the warning path.
  
  ## Testing
  
  1. Start a `/review` with a diff large enough that the review stays
  active for more than a few seconds.
  
  2. While the review is still running, type a follow-up / steer message,
  submit it, and then press `Esc`.
     Before: `Esc` causes the TUI to close abruptly.  
  After: the review keeps running and the transcript shows a warning that
  steer messages are not supported during `/review`, with guidance to use
  `Ctrl+C` if you want to cancel.
  
  3. Press `Ctrl+C` if you actually want to stop the review.  
  Before: (after restarting the test since Pt. 2 crashed) this is the
  intentional cancellation path.
  After: this remains the intentional cancellation path, and any queued
  follow-up steer text is restored to the composer instead of being lost.
     
  ## Note:
  `/review` mode explicitly does not support steering at this time (as
  noted in `turn_processer.rs`, if we want to explore that in the future
  this code will need to be modified). This change keeps unsupported steer
  attempts from crashing the TUI and preserves queued follow-up text if
  the user cancels with Ctrl+C.

  canvrno-oai · 2026-06-09 09:41:58 -07:00
  8a299fb704
• [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
• [codex] Gate terminal visualization instructions in TUI (#26013)

  ## Summary
  - add `Feature::TerminalVisualizationInstructions` as
  `UnderDevelopment`, disabled by default
  - keep terminal visualization instructions inside the TUI package
  - append them to existing developer instructions for TUI start, resume,
  and fork flows only when enabled
  - intentionally do not apply them to `codex exec`
  
  ## Rollout
  Control behavior is unchanged. TUI dogfooders can enable
  `terminal_visualization_instructions`; no default user receives the new
  terminal-specific instructions.
  
  The shared visualization-selection rule is supplied separately through
  the `codex_proxy_model_3` Statsig layer for every target Codex model
  slug in the gated cohort. This TUI feature determines how to render an
  appropriate visualization on the terminal surface; the model-layer
  treatment determines when to use one.
  
  ## Validation
  - `cargo test -p codex-tui
  terminal_visualization_instructions_are_gated_for_all_tui_thread_flows
  --lib`
  - `cargo test -p codex-features --lib`
  - `cargo fmt --all -- --check`
  - `git diff --check`
  - GPT-5.4 and GPT-5.5 real prompt-pipeline smoke tests: both visualized
  the positive mapping case, abstained on the negative route case, and
  passed exact prompt-stack verification on CLI and App
  - refreshed onto current `main` with a clean merge and reran the focused
  validation
  
  The full 53-probe all-model treatment comparison and requested
  production coding evals remain rollout gates before broadening beyond
  the initial employee cohort.
  
  This PR remains open for normal human review.

  vie-oai · 2026-06-05 17:23:45 -07:00
  61a913d9c8
• Speed up TUI startup by reusing plugin discovery (#26469)

  ## Summary
  
  TUI startup loads related plugin data from `hooks/list`, session MCP
  initialization, and plugin skill warmup. These paths repeated filesystem
  discovery and emitted the same plugin warnings, while `hooks/list` and
  account/model bootstrap ran serially.
  
  This change:
  
  - Reuses one immutable plugin load outcome across startup consumers.
  - Keys the cache only on plugin-relevant configuration.
  - Single-flights concurrent plugin loads and prevents invalidated loads
  from repopulating the cache.
  - Runs hook discovery and account/model bootstrap concurrently.
  - Preserves configuration-migration ordering, hook review behavior, and
  accurate startup telemetry.
  
  In 10 alternating release-build launches in the Ruff repository with the
  existing `~/.codex` configuration, median time to the first editable
  composer decreased from 833ms to 504ms. The branch was faster in 9 of 10
  pairs, with a paired median improvement of 312ms.

  Charlie Marsh · 2026-06-05 15:32:43 -04:00
  055c7a7c53
• Make runtime workspace roots absolute in app-server API (#26552)

  Stacked on #26532.
  
  ## Why
  
  #26532 moves cwd normalization to the app-server/core boundary.
  `runtimeWorkspaceRoots` still accepted raw paths in v2 requests and in
  `ConfigOverrides`, which left core responsible for interpreting those
  roots later. This makes runtime workspace roots follow the same
  absolute-path boundary as cwd.
  
  ## What
  
  - Change v2 `runtimeWorkspaceRoots` request fields for `thread/start`,
  `thread/resume`, `thread/fork`, and `turn/start` to `AbsolutePathBuf`.
  - Deduplicate already-absolute runtime roots in app-server handlers and
  pass them through `ConfigOverrides.workspace_roots` as
  `AbsolutePathBuf`.
  - Update TUI and exec client request builders to pass absolute runtime
  roots directly.
  - Update app-server docs, schema fixtures, and focused tests for
  absolute runtime roots.
  
  ## Testing
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server runtime_workspace_roots`
  - `just test -p codex-core
  session_permission_profile_rebinds_runtime_workspace_roots`
  - `just test -p codex-tui app_server_session`
  - `just test -p codex-exec`

  pakrym-oai · 2026-06-05 11:36:53 -07:00
  76c0a5379c
• [codex] Use model-advertised reasoning effort order (#26446)

  ## Summary
  - preserve the model catalog order for app-server
  `supportedReasoningEfforts` and document that client contract
  - render TUI reasoning choices in the advertised order
  - step reasoning shortcuts by adjacent list position instead of deriving
  order from known effort names
  - anchor unsupported configured values to the advertised default, or the
  first option when needed
  - remove canonical effort ordering helpers and the unused upgrade effort
  mapping
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.
  
  Stacked on #26444.

  Ahmed Ibrahim · 2026-06-04 14:01:14 -07:00
  f6e529656f
• [codex] Support model-defined reasoning efforts (#26444)

  ## Summary
  - accept non-empty model-defined reasoning effort values while
  preserving built-in effort behavior
  - propagate the non-Copy effort type through core, app-server, TUI,
  telemetry, and persistence call sites
  - preserve string wire encoding and expose an open-string schema for
  clients
  - update model selection and shortcut behavior for model-advertised
  effort values
  
  ## Root cause
  `ReasoningEffort` gained a string-backed custom variant, so it could no
  longer implement `Copy` or rely on derived closed-enum serialization.
  Existing consumers still moved effort values from shared references and
  assumed a fixed built-in value set.
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.

  Ahmed Ibrahim · 2026-06-04 13:36:24 -07:00
  8ac304c299
• feat: show enterprise monthly credit limits in status (#24812)

  ## Summary
  
  Enterprise users can have an effective monthly credit limit, but Codex
  `/status` currently drops that metadata from the account-usage response.
  
  This change adds the optional `spend_control.individual_limit`
  projection to the existing rate-limit snapshot flow. The backend client
  reads the monthly limit, app-server exposes it as `individualLimit`, and
  the TUI renders a `Monthly credit limit` row through the existing
  progress-bar renderer.
  
  When the backend does not return an effective monthly limit, existing
  rate-limit behavior is unchanged.
  
  ## Existing backend state
  
  The account-usage backend already returns the effective monthly limit
  and current usage together:
  
  ```json
  {
    "spend_control": {
      "reached": false,
      "individual_limit": {
        "limit": "25000",
        "used": "8000",
        "remaining": "17000",
        "used_percent": 32,
        "remaining_percent": 68,
        "reset_after_seconds": 86400,
        "reset_at": 1778137680
      }
    }
  }
  ```
  
  Before this change, Codex projected rolling `primary` and `secondary`
  windows plus `credits`. It ignored `spend_control.individual_limit`, so
  app-server clients and `/status` could not render the monthly cap.
  
  The updated flow is:
  
  ```text
  account usage backend
    -> backend-client reads spend_control.individual_limit
    -> existing rate-limit snapshot carries optional individual_limit
    -> app-server exposes optional individualLimit
    -> TUI renders Monthly credit limit
  ```
  
  ## App-server contract
  
  `account/rateLimits/read` and sparse `account/rateLimits/updated`
  notifications now include an additive nullable
  `rateLimits.individualLimit` field:
  
  ```json
  {
    "individualLimit": {
      "limit": "25000",
      "used": "8000",
      "remainingPercent": 68,
      "resetsAt": 1778137680
    }
  }
  ```
  
  In an `account/rateLimits/read` response, `null` means no monthly limit
  is available. `account/rateLimits/updated` remains a sparse rolling
  notification: clients merge available values into their most recent
  `account/rateLimits/read` snapshot or refetch. Nullable account metadata
  in a rolling notification does not clear a previously observed value.
  
  ## Design decisions
  
  - Extend the existing rate-limit snapshot instead of introducing a
  separate request or wire-level update protocol.
  - Keep the Codex projection narrow: `/status` needs the effective limit,
  current usage, remaining percentage, and reset timestamp.
  - Render the monthly row through the existing progress-bar renderer,
  with one optional detail line for `8,000 of 25,000 credits used`.
  - Keep the backend response optional so existing accounts and older
  usage states preserve their current behavior.
  - Preserve cached monthly metadata when sparse rolling notifications
  omit it. Live account-usage reads remain authoritative and can clear a
  removed limit.
  
  ## Visual evidence
  
  ```text
   Monthly credit limit:   [██████████████░░░░░░] 68% left (resets 07:08 on 7 May)
                           8,000 of 25,000 credits used
  ```
  
  Snapshot:
  `codex-rs/tui/src/status/snapshots/codex_tui__status__tests__status_snapshot_includes_enterprise_monthly_credit_limit.snap`
  
  ## Testing
  
  Tests: generated app-server schema verification, protocol tests,
  backend-client tests, app-server integration coverage, TUI snapshot
  coverage, formatting, and workspace lint cleanup.

  efrazer-oai · 2026-06-01 21:25:42 -07:00
  c8e5db16c9
• app-server: remove experimental persist_extended_history bool flag (#25712)

  ## Summary
  
  Remove the dead experimental `persistExtendedHistory` app-server flag
  and collapse rollout persistence to the single policy app-server already
  used.
  
  ## What Changed
  
  - Removed `persistExtendedHistory` from v2 thread start/resume/fork
  params and deleted its deprecation notice path.
  - Removed the persistence-mode enums and plumbing through core, rollout,
  and thread-store.
  - Made rollout filtering mode-free, keeping the existing limited
  persisted-history behavior.
  
  ## Test Plan
  
  - `just write-app-server-schema`
  - `cargo nextest run --no-fail-fast -p codex-app-server-protocol
  schema_fixtures`
  - `cargo nextest run --no-fail-fast -p codex-app-server
  thread_shell_command_history_responses_exclude_persisted_command_executions`
  - `cargo nextest run --no-fail-fast -p codex-rollout -p
  codex-thread-store`
  - final `rg` for removed flag/type names

  Owen Lin · 2026-06-01 23:33:42 +00:00
  11e0f3d3ae
• store and expose parent_thread_id on Threads (#25113)

  ## Why
  
  This PR
  https://github.com/openai/codex/pull/24161#discussion_r3325692763
  revealed a subagent data modeling issue, where we overloaded
  `forked_from_id` to also mean `parent_thread_id`. That's incorrect since
  guardian and review subagents can be a subagent and NOT fork the main
  thread's history.
  
  The solution here is to explicitly store a new `parent_thread_id` on
  `SessionMeta`, alongside `forked_from_id` which already exists. While
  we're at it, also expose it in the app-server protocol on the `Thread`
  object.
  
  A thread->subagent relationship and a fork of thread history are
  orthogonal concepts.
  
  ## What Changed
  
  - Added top-level `parent_thread_id` persistence on `SessionMeta` and
  runtime/session plumbing through `SessionConfiguredEvent`,
  `CodexSpawnArgs`, `SessionConfiguration`, `ThreadConfigSnapshot`,
  `TurnContext`, and `ModelClient`.
  - Made turn metadata, request headers, analytics, and subagent-start
  events read the separate runtime/top-level parent field instead of
  deriving general parent lineage from `SessionSource` or
  `forked_from_thread_id`.
  - Passed parent lineage separately at delegated subagent, review,
  guardian, agent-job, and multi-agent spawn construction sites;
  copied-history fork lineage remains derived only from `InitialHistory`.
  - Persisted and exposed parent lineage through rollout/thread-store
  projections and app-server v2 `Thread.parentThreadId`.
  - Updated app-server README text and regenerated app-server schema
  fixtures for the additive `parentThreadId` response field.

  Owen Lin · 2026-06-01 04:33:20 +00:00
  cf0911076f
• Add thread archive CLI commands (#25021)

  ## Problem
  
  Saved threads can already be archived through app-server RPCs, but the
  command line did not expose direct archive or unarchive commands.
  
  ## Solution
  
  Add `codex archive <thread>` and `codex unarchive <thread>`, resolving
  UUIDs or exact thread names before calling the existing `thread/archive`
  and `thread/unarchive` RPCs. The commands support scoped remote flags so
  callers can target remote app-server endpoints when archiving or
  unarchiving threads.
  
  This also fixes a long-standing bug in `codex resume <thread id>` and
  `codex fork <thread id>` that I found when testing the new commands.
  These operations shouldn't be allowed on archived sessions. They now
  fail with an error that tells the user to run `codex unarchive <thread
  id>` first.
  
  ## Verification
  
  Added app-server coverage for rejecting archived thread resume by id and
  checking that the error includes the matching `codex unarchive <thread
  id>` command.

  Eric Traut · 2026-05-29 23:37:26 -07:00
  3e7baa00e4
• Add /archive slash command (#25027)

  ## Why
  
  TUI users can archive saved sessions from other surfaces, but there is
  no in-session command for archiving the active session. Since archiving
  the active session also exits the TUI, the command should ask for
  explicit confirmation instead of firing immediately.
  
  I'm also working on [a companion
  PR](https://github.com/openai/codex/pull/25021) that adds `codex
  archive` and `codex unarchive` top-level CLI commands.
  
  ## What changed
  
  - Adds a new `/archive` slash command described as `archive this session
  and exit`.
  - Shows a confirmation dialog with `No, don't archive` selected first
  and `Yes, archive and exit` as the explicit action.
  - On confirmation, calls the existing `thread/archive` app-server RPC
  for the active main session and exits after success.
  - Keeps `/archive` disabled while a task is running and unavailable in
  side conversations.
  
  ## Verification
  
  Added focused TUI coverage for the `/archive` confirmation flow,
  disabled-while-task-running behavior, and the `/ar` slash-command popup
  snapshot.

  Eric Traut · 2026-05-29 11:07:19 -07:00
  36cd36626d
• [codex] Add user input client ids (#24653)

  ## Summary
  
  Adds an optional `clientId` field to app-server v2 `UserInput` and
  carries it through the core `UserInput` model so clients can correlate
  echoed user input items without relying on payload equality.
  
  ## Details
  
  - Adds `client_id: Option<String>` to core `UserInput` variants.
  - Exposes the v2 app-server field as `clientId` on the wire and in
  generated TypeScript.
  - Preserves the id when converting between app-server v2 and core
  protocol types.
  - Regenerates app-server schema fixtures.
  
  ## Validation
  
  - `just fmt`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-protocol`
  - `git diff --check`

  Alexi Christakis · 2026-05-28 14:54:39 -07:00
  e92c952b2e
• feat(app-server): include turns page on thread resume (#23534)

  ## Summary
  
  The client currently calls `thread/resume` to establish live updates and
  immediately follows it with `thread/turns/list` to hydrate recent turns.
  This lets `thread/resume` return that page directly, eliminating a round
  trip and the ordering/deduplication gap between the two calls.
  
  Experimental clients opt in with `initialTurnsPage: { limit,
  sortDirection, itemsView }`. The response returns `initialTurnsPage` as
  a `TurnsPage`, including cursors for paging further back in history.
  Keeping the controls in a nested opt-in object provides the useful
  `thread/turns/list` knobs without spreading page-specific parameters
  across `thread/resume`.
  
  ## Verification
  
  - `just fmt`
  - `just write-app-server-schema --experimental`
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server
  thread_resume_initial_turns_page_matches_requested_turns_list_page
  --tests`
  - `cargo test -p codex-app-server
  thread_resume_rejoins_running_thread_even_with_override_mismatch
  --tests`
  - `just fix -p codex-app-server-protocol -p codex-app-server`

  Brent Traut · 2026-05-28 09:18:13 -07:00
  2a1158b8e2
• Add experimental turn additional context (#24154)

  ## Summary
  
  Adds experimental `additionalContext` support to `turn/start` and
  `turn/steer` so clients can provide ephemeral external context, such as
  browser or automation state, without turning that plumbing into a
  visible user prompt or triggering user-prompt lifecycle behavior.
  
  ## API Shape
  
  The parameter shape is:
  
  ```ts
  additionalContext?: Record<string, {
    value: string
    kind: "untrusted" | "application"
  }> | null
  ```
  
  Example:
  
  ```json
  {
    "additionalContext": {
      "browser_info": {
        "value": "Active tab is CI failures.",
        "kind": "untrusted"
      },
      "automation_info": {
        "value": "CI rerun is in progress.",
        "kind": "application"
      }
    }
  }
  ```
  
  The keys are opaque and caller-defined.
  
  ## Context Injection
  
  When provided, accepted entries are inserted into model context as
  hidden contextual message items, not as visible thread user-message
  items.
  
  `kind: "untrusted"` entries are inserted with role `user`:
  
  ```text
  <external_${key}>${value}</external_${key}>
  ```
  
  `kind: "application"` entries are inserted with role `developer`:
  
  ```text
  <${key}>${value}</${key}>
  ```
  
  Values are not escaped. Each value is truncated to 1k approximate tokens
  before wrapping.
  
  For `turn/start`, accepted additional context is inserted before normal
  user input. For `turn/steer`, additional context is merged only when the
  steer includes non-empty user input; context-only steers still reject as
  empty input.
  
  ## Dedupe Strategy
  
  `AdditionalContextStore` lives on session state and stores the latest
  complete additional-context map.
  
  Each `turn/start` or non-empty `turn/steer` treats its
  `additionalContext` as the current complete set of values. Entries are
  injected only when the key is new or the exact entry for that key
  changed, including `value` or `kind`. After merging, the store is
  replaced with the provided map, so omitted keys are removed from the
  retained set and can be injected again later if reintroduced.
  
  Omitting `additionalContext`, passing `null`, or passing an empty object
  resets the store to empty and injects nothing.
  
  ## What Changed
  
  - Threads experimental v2 `additionalContext` through app-server into
  core turn start and steer handling.
  - Adds separate contextual fragment types for untrusted user-role
  context and application developer-role context.
  - Uses pending response input items so additional context can be
  combined with normal user input without treating it as prompt text.
  - Adds integration coverage for start/steer flow, role routing,
  dedupe/reset behavior, deletion/re-add behavior, hook-blocked input
  behavior, empty context-only steer rejection, external-fragment marker
  matching, and truncation.

  pakrym-oai · 2026-05-26 13:02:34 -07:00
  768848ab6f
• Respect hook trust bypass during TUI startup (#24317)

  Fixes #24093.
  
  ## Why
  
  `--dangerously-bypass-hook-trust` is a supported CLI flag intended for
  headless or automated runs where enabled hooks should be allowed to run
  without requiring persisted trust. In the TUI, startup hook review still
  opened whenever hooks looked untrusted, so a launch using the bypass
  could block on the interactive "Hooks need review" prompt.
  
  The tricky case is persistent app-server resume: a resume may attach to
  an already-running thread, where resume config overrides are ignored. In
  that path, hiding the startup review would be wrong because the existing
  hook engine may still filter untrusted hooks.
  
  ## What Changed
  
  - Startup hook review now skips the prompt only when hook trust bypass
  is actually safe for that launch.
  - The TUI forwards `bypass_hook_trust` through the app-server request
  config for fresh thread start/resume/fork paths, and the app-server
  applies it as a runtime-only `ConfigOverrides` value rather than
  treating it like a `config.toml` setting.
  - Persistent app-server resumes keep the startup review prompt so users
  still have a chance to trust hooks when the running thread cannot
  receive the bypass override.
  
  ## Verification
  
  - Added focused coverage for startup hook review with and without
  `bypass_hook_trust`.
  - Extended existing TUI/app-server config override tests to cover
  forwarding and applying `bypass_hook_trust`.

  Eric Traut · 2026-05-25 09:44:21 -07:00
  5fb5e47767
• Show remote connection details in /status (#24420)

  ## Summary
  
  Fixes #24411.
  
  `/status` currently has no way to show when the TUI is talking to Codex
  through a remote transport. That makes embedded local sessions, local
  daemon sessions, and true remote sessions look the same, and it hides
  the remote server version when debugging connection-specific behavior.
  
  This PR adds a single `Remote` row for non-embedded connections only.
  The row shows the sanitized connection address and a dimmed version
  parenthetical, preserving the existing status output for embedded local
  sessions.
  
  <img width="791" height="144" alt="image"
  src="https://github.com/user-attachments/assets/529d7940-1c45-4586-8b06-f20a1f04b771"
  />
  
  
  ## Verification
  
  - Manually validated when connecting remotely (either implicitly to
  local daemon or explicitly)

  Eric Traut · 2026-05-25 09:42:42 -07:00
  913270a689
• config: remove legacy profile write paths (#24055)

  ## Why
  
  [#23883](https://github.com/openai/codex/pull/23883) moved the
  user-facing `--profile` flag onto profile v2 and
  [#23886](https://github.com/openai/codex/pull/23886) removed CLI
  forwarding for the legacy profile-v1 path. Core and TUI config
  persistence still carried `active_profile` and
  `ConfigEditsBuilder::with_profile`, which let later writes continue
  targeting legacy `[profiles.<name>]` tables after profile selection
  moved to profile-v2 config files.
  
  ## What
  
  - Remove legacy profile routing from
  [`ConfigEditsBuilder`](https://github.com/openai/codex/blob/4b38e9c22e762261d7f7eef49d8a21792e241a06/codex-rs/core/src/config/edit.rs#L1064-L1294),
  so core config edits no longer carry `with_profile` or infer
  `[profiles.*]` write targets from a `profile` key.
  - Drop `active_profile` plumbing from runtime `Config`, TUI
  startup/state, app-server config override forwarding, and Windows
  sandbox setup persistence.
  - Make app-server-backed TUI config edits use unscoped model,
  service-tier, feature, Auto-review, plan-mode, and Windows sandbox paths
  through
  [`tui/src/config_update.rs`](https://github.com/openai/codex/blob/4b38e9c22e762261d7f7eef49d8a21792e241a06/codex-rs/tui/src/config_update.rs#L43-L112).
  - Update config edit coverage so legacy `profile` state stays untouched
  by direct model writes, and remove tests whose only contract was the
  deleted profile-scoped persistence path.
  
  ## Testing
  
  - Not run locally.

  jif-oai · 2026-05-22 12:50:42 +02:00
  2c6605ab35
• Honor client-resolved service tier defaults (#23537)

  ## Why
  
  Model catalog responses can now advertise a nullable
  `default_service_tier` for each model. Codex needs to preserve three
  distinct states all the way from config/app-server inputs to inference:
  
  - no explicit service tier, so the client may apply the current model
  catalog default when FastMode is enabled
  - explicit `default`, meaning the user intentionally wants standard
  routing
  - explicit catalog tier ids such as `priority`, `flex`, or future tiers
  
  Keeping those states distinct prevents the UI from showing one tier
  while core sends another, especially after model switches or app-server
  `thread/start` / `turn/start` updates.
  
  ## What Changed
  
  - Plumbed `default_service_tier` through model catalog protocol types,
  app-server model responses, generated schemas, model cache fixtures, and
  provider/model-manager conversions.
  - Added the request-only `default` service tier sentinel and normalized
  legacy config spelling so `fast` in `config.toml` still materializes as
  the runtime/request id `priority`.
  - Moved catalog default resolution to the TUI/client side, including
  recomputing the effective service tier when model/FastMode-dependent
  surfaces change.
  - Updated app-server thread lifecycle config construction so
  `serviceTier: null` preserves explicit standard-routing intent by
  mapping to `default` instead of internal `None`.
  - Kept core responsible for validating explicit tiers against the
  current model and stripping `default` before `/v1/responses`, without
  applying catalog defaults itself.
  
  ## Validation
  
  - `CARGO_INCREMENTAL=0 cargo build -p codex-cli`
  - `CARGO_INCREMENTAL=0 cargo test -p codex-app-server model_list`
  - `cargo test -p codex-tui service_tier`
  - `cargo test -p codex-protocol service_tier_for_request`
  - `cargo test -p codex-core get_service_tier`
  - `RUST_MIN_STACK=8388608 CARGO_INCREMENTAL=0 cargo test -p codex-core
  service_tier`

  Shijie Rao · 2026-05-20 15:57:50 -07:00
  370b13afc9
• Sync TUI thread settings through app server (#23507)

  Builds on #23502.
  
  ## Why
  
  #23502 adds the app-server `thread/settings/update` API and matching
  `thread/settings/updated` notification. The TUI already lets users
  change thread-scoped settings such as model, reasoning effort, service
  tier, approvals, permissions, personality, and collaboration mode, but
  those updates need to flow through the app server so embedded and
  connected clients observe the same thread state.
  
  This is a rework (simplification) of PR
  https://github.com/openai/codex/pull/22510. It has the same
  functionality, but the underlying `thread/settings/update` api is now
  simpler in that it no longer returns the effective settings as a
  response. Now, clients receive the effective settings only through the
  `thread/settings/updated` notification.
  
  ## What Changed
  
  This updates the TUI to send `thread/settings/update` whenever those
  thread-scoped settings change and to treat the RPC response as the
  authoritative acknowledgement. It also routes `thread/settings/updated`
  notifications back into cached session state and the visible chat widget
  so active and inactive threads stay in sync after app-server-originated
  changes.
  
  The implementation is kept to the TUI layer: settings conversion and
  merge logic live under `codex-rs/tui/src/app/thread_settings.rs`, with
  dispatch/routing hooks in the existing app and chat widget paths.
  
  ## Verification
  
  I manually tested using `codex app-server --listen unix://` and then
  launching two copies of the TUI that use the same local app server. I
  then resumed the same thread on both and verified that changes like plan
  mode, fast mode, model, reasoning effort, etc. are reflected "live" in
  the second client when modified in the first and vice versa.

  Eric Traut · 2026-05-20 11:05:14 -07:00
  edc48e4612
• [2 of 2] Start fresh TUI thread in background (#23176)

  ## Why
  
  After the terminal-probe work in #23175, fresh-session startup still
  waits for `thread/start` before the chat input can become usable. The
  chat widget already has the machinery to hold early submissions until a
  session is configured, so fresh `thread/start` does not need to stay on
  the input-ready hot path.
  
  Refs #16335.
  
  ## What
  
  This PR starts fresh app-server threads in a background task, reports
  completion through a startup app event, and attaches the primary session
  once `thread/start` returns. Resume and fork startup paths remain
  synchronous.
  
  ## Benchmark
  
  In the local pty startup benchmark, this PR's pre-optimization base
  branch, #23175, measured about 152ms median from launch to accepted chat
  input. The stacked result measured about 66ms median, for an approximate
  additional savings of 85-95ms. For broader context, the original `main`
  baseline before either startup optimization was about 250.5ms median. We
  also measured Codex 0.117.0 on the same machine at about 64.6ms median,
  so the stacked branch is back in the old-startup-time range.
  
  ## Stack
  
  1. [#23175: [1 of 2] Optimize TUI startup terminal
  probes](https://github.com/openai/codex/pull/23175) — base PR
  2. [#23176: [2 of 2] Start fresh TUI thread in
  background](https://github.com/openai/codex/pull/23176) — this PR
  
  ## Verification
  
  - `cargo test -p codex-tui`

  Eric Traut · 2026-05-20 10:00:33 -07:00
  c0f7e1b99f
• Fix: TUI starting in wrong CWD (#23538)

  This fixes a regression wher codex could start in the wrong directory
  when a live local app-server socket was present. The issue was that
  implicit local socket reuse was being treated like an explicit remote
  workspace session, which dropped the invoking cwd unless --cd was
  passed.
  
  The change separates local socket transport from true remote workspace
  semantics.
  - Plain local startup keeps local cwd, trust, resume, picker, and
  config-refresh behavior.
  - Explicit --remote keeps the existing remote cwd behavior.
  - Added coverage for launch target selection and local-session
  filtering/cwd behavior.
  
  Steps to test:
  - Start a local app-server from a different directory than the repo you
  want to use.
    - Launch codex from a project/worktree without --cd.
  - Confirm the session starts in the invoking directory, not the
  app-server process directory.
  - Confirm explicit codex --remote ... still preserves existing remote
  behavior.

  canvrno-oai · 2026-05-19 15:48:40 -07:00
  27c4c67b15
• Harden CLI rate limit window labels (#22929)

  ## Context
  
  The CLI rate-limit surfaces previously described usage windows as fixed
  5-hour and weekly limits. We want the CLI to display whatever supported
  rate-limit period the server returns instead of assuming a 5-hour/1-week
  pair. This supports generalized Codex rate-limit periods.
  
  ## Summary
  
  - Formats CLI rate-limit warning/status labels only for the supported
  returned window durations: approximate 5h, daily, weekly, monthly, and
  annual.
  - Uses generic fallback copy when a primary or secondary window has no
  duration, so missing secondary protection data does not produce stale
  weekly copy.
  - Uses generic fallback copy for unsupported window durations instead of
  adding arbitrary hourly, multi-day, multi-week, or multi-year labels.
  - Updates status line and terminal title setup descriptions/previews to
  talk about primary/secondary usage limits rather than fixed 5h/weekly
  limits.
  - Adds rendered insta snapshot coverage for the updated rate-limit
  status surfaces and `/status` fallback labels.
  
  ## Tests
  Tested locally:
  - one primary window
  - one secondary window
  - primary and secondary window

  Arun Eswara · 2026-05-19 11:22:00 -07:00
  d269aa2af9
• app-server: use profile ids in v2 permission params (#23360)

  ## Why
  
  The v2 app-server permission profile fields are experimental, but the
  previous migration kept a legacy object payload for profile selection.
  That made clients aware of server-owned `activePermissionProfile`
  metadata such as `extends`, and it kept a
  `legacy_additional_writable_roots` path even though
  `runtimeWorkspaceRoots` now owns runtime workspace-root selection.
  
  This PR makes the client contract match the intended model: clients
  select a permission profile by id, and the server resolves and reports
  active profile provenance in response payloads.
  
  Follow-up to #22611.
  
  ## What Changed
  
  - Changed `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start` permission profile selection to plain profile id strings.
  - Changed `command/exec.permissionProfile` to a plain profile id string
  for the same client/server ownership split.
  - Removed `PermissionProfileSelectionParams` and the legacy `{ type:
  "profile", modifications: [...] }` compatibility deserializer.
  - Updated app-server, TUI, and `codex exec` call sites to send only ids,
  while keeping `activePermissionProfile` as server response metadata.
  - Updated app-server docs and schema fixtures for the revised
  `command/exec.permissionProfile` shape.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-app-server`
  - `cargo test -p codex-exec`
  - `RUST_MIN_STACK=8388608 cargo test -p codex-tui`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/23360).
  * #23368
  * __->__ #23360

  Michael Bolin · 2026-05-18 17:28:50 -07:00
  3fd79b7986
• app-server-protocol: remove PermissionProfile from API (#22924)

  ## Why
  
  The app server API should expose permission profile identity, not the
  lower-level runtime permission model. `PermissionProfile` is the
  compiled sandbox/network representation that the server uses internally;
  exposing it through app-server-protocol forces clients to understand
  details that should remain implementation-level.
  
  The API boundary should prefer `ActivePermissionProfile`: a stable
  profile id, plus future parent-profile metadata, that clients can pass
  back when they want to select the same active permissions. This also
  avoids schema generation collisions between the app-server v2 API type
  space and the core protocol model.
  
  Incidentally, while PR makes a number of changes to `command/exec`, note
  that we are hoping to deprecate this API in favor of `process/spawn`, so
  we don't need to be too finicky about these changes.
  
  ## What Changed
  
  - Removed `PermissionProfile` from the app-server-protocol API surface,
  including generated schema and TypeScript exports.
  - Changed `CommandExecParams.permissionProfile` to
  `ActivePermissionProfile`.
  - Resolve command exec profile ids through `ConfigManager` for the
  command cwd, matching turn override selection semantics.
  - Updated downstream TUI tests/helpers to use core permission types
  directly instead of app-server-protocol `PermissionProfile` shims.

  Michael Bolin · 2026-05-15 17:10:15 -07:00
  9025550709
• app-server: stop returning thread permission profiles (#22792)

  ## Why
  
  The app-server thread lifecycle API should no longer expose the full
  `PermissionProfile` value. After the permissions-profile migration,
  clients should round-trip only the active profile identity through
  `activePermissionProfile` and `permissions` when that identity is known.
  
  The full profile is server-side config. Treating a response-derived
  legacy sandbox projection as a new local profile can lose named-profile
  restrictions and accidentally widen permissions on the next turn. The
  legacy `sandbox` response field remains only as the
  compatibility/display fallback.
  
  ## What Changed
  
  - Removed `permissionProfile` from `ThreadStartResponse`,
  `ThreadResumeResponse`, and `ThreadForkResponse`.
  - Stopped populating that field in app-server thread start/resume/fork
  responses.
  - Updated embedded exec/TUI response mapping to derive display
  permission state from local config or the legacy sandbox fallback
  instead of a response profile value.
  - Added a TUI turn override shape that distinguishes preserving server
  permissions, selecting an active profile id, and sending a legacy
  sandbox for an explicit local override.
  - Preserved remote app-server permissions across turns by sending
  `permissions` only when an `activePermissionProfile` id is known, and
  otherwise sending no sandbox override unless the user selected a local
  override.
  - Kept embedded `thread/resume` hydration server-authored when
  `activePermissionProfile` is absent, which matches the live-thread
  attach path where the server ignores requested overrides.
  - Updated the app-server README to remove the obsolete lifecycle
  response `permissionProfile` reference. The remaining
  `permissionProfile` README references are request-side permission
  overrides.
  - Regenerated app-server JSON schema and TypeScript fixtures.
  - Kept the generated typed response enum exempt from
  `large_enum_variant`, matching the existing payload enum exemption after
  the lifecycle response variants shrank.
  
  ## How To Review
  
  Start with `codex-rs/app-server-protocol/src/protocol/v2/thread.rs` to
  confirm the response shape, then check the response construction in
  `codex-rs/app-server/src/request_processors`. The generated schema and
  TypeScript fixture changes are mechanical follow-through from the
  protocol removal.
  
  The TUI behavior is the delicate part: review
  `codex-rs/tui/src/app_server_session.rs` for response hydration and
  turn-start override projection, then
  `codex-rs/tui/src/app/thread_routing.rs` for the decision about whether
  the next turn should preserve the server snapshot, send an active
  profile id, or send a legacy sandbox for an explicit local override.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol
  thread_lifecycle_responses_default_missing_optional_fields`
  - `cargo test -p codex-exec
  session_configured_from_thread_response_uses_permission_profile_from_config`
  - `cargo test -p codex-tui --lib thread_response`
  - `cargo test -p codex-tui turn_permissions_`
  - `cargo test -p codex-tui
  resume_response_restores_turns_from_thread_items`
  - `cargo test -p codex-analytics
  track_response_only_enqueues_analytics_relevant_responses`
  - `just fix -p codex-analytics`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22792).
  * #22795
  * __->__ #22792

  Michael Bolin · 2026-05-15 12:45:48 -07:00
  83bbb4f326
• app-server: use permission ids and runtime workspace roots (#22611)

  ## Why
  
  This PR builds on [#22610](https://github.com/openai/codex/pull/22610)
  and is the app-server side of the migration from mutable per-turn
  `SandboxPolicy` replacement toward selecting immutable permission
  profiles by id plus mutable runtime workspace roots.
  
  Once permission profiles can carry their own immutable
  `workspace_roots`, app-server no longer needs to mutate the selected
  `PermissionProfile` just to represent thread-specific filesystem
  context. The mutable part now lives on the thread as explicit
  `runtimeWorkspaceRoots`, while `:workspace_roots` remains symbolic until
  the sandbox is realized for a turn.
  
  ## What Changed
  
  - Replaced the v2 permission-selection wrapper surface with plain
  profile ids for `thread/start`, `thread/resume`, `thread/fork`, and
  `turn/start`.
  - Removed the API surface for profile modifications
  (`PermissionProfileSelectionParams`,
  `PermissionProfileModificationParams`,
  `ActivePermissionProfileModification`).
  - Added experimental `runtimeWorkspaceRoots` fields to the thread
  lifecycle and turn-start APIs.
  - Threaded runtime workspace roots through core session/thread
  snapshots, turn overrides, app-server request handling, and command
  execution permission resolution.
  - Kept session permission state symbolic so later runtime root updates
  and cwd-only implicit-root retargeting rebind `:workspace_roots`
  correctly.
  - Updated the embedded clients just enough to send and restore the new
  thread state.
  - Refreshed the generated schema/TypeScript artifacts and the app-server
  README to match the new contract.
  
  ## Verification
  
  Targeted coverage for this layer lives in:
  
  - `codex-rs/app-server-protocol/src/protocol/v2/tests.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_start.rs`
  - `codex-rs/app-server/tests/suite/v2/thread_resume.rs`
  - `codex-rs/app-server/tests/suite/v2/turn_start.rs`
  - `codex-rs/core/src/session/tests.rs`
  
  The key regression checks exercise that:
  
  - `runtimeWorkspaceRoots` resolve against the effective cwd on thread
  start.
  - Profile-declared workspace roots are excluded from the runtime
  workspace roots returned by app-server.
  - A turn-level runtime workspace-root update persists onto the thread
  and is returned by `thread/resume`.
  - A named permission profile selected on one turn remains symbolic so a
  later runtime-root-only turn update changes the actual sandbox writes.
  - A cwd-only turn update retargets the implicit runtime cwd root while
  preserving additional runtime roots.
  - The protocol fixtures and generated client artifacts stay in sync with
  the string-based permission selection contract.
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22611).
  * #22612
  * __->__ #22611

  Michael Bolin · 2026-05-14 23:00:05 -07:00
  8a5306ff88
• permissions: support workspace roots in profiles (#22610)

  ## Why
  
  This is the configuration/model half of the alternative permissions
  migration we discussed as a comparison point for
  [#22401](https://github.com/openai/codex/pull/22401) and
  [#22402](https://github.com/openai/codex/pull/22402).
  
  The old `workspace-write` model mixes three concerns that we want to
  keep separate:
  - reusable profile rules that should stay immutable once selected
  - user/runtime workspace roots from `cwd`, `--add-dir`, and legacy
  workspace-write config
  - internal Codex writable roots such as memories, which should not be
  shown as user workspace roots
  
  This PR gives permission profiles first-class `workspace_roots` so users
  can opt multiple repositories into the same `:workspace_roots` rules
  without using broad absolute-path write grants. It also starts
  separating the raw selected profile from the effective runtime profile
  by making `Permissions` expose explicit accessors instead of public
  mutable fields.
  
  A representative `config.toml` looks like this:
  
  ```toml
  default_permissions = "dev"
  
  [permissions.dev.workspace_roots]
  "~/code/openai" = true
  "~/code/developers-website" = true
  
  [permissions.dev.filesystem.":workspace_roots"]
  "." = "write"
  ".codex" = "read"
  ".git" = "read"
  ".vscode" = "read"
  ```
  
  If Codex starts in `~/code/codex` with that profile selected, the
  effective workspace-root set becomes:
  - `~/code/codex` from the runtime `cwd`
  - `~/code/openai` from the profile
  - `~/code/developers-website` from the profile
  
  The `:workspace_roots` rules are materialized across each root, so
  `.git`, `.codex`, and `.vscode` stay scoped the same way everywhere.
  Runtime additions such as `--add-dir` can still layer on later stack
  entries without mutating the selected profile.
  
  ## Stack Shape
  
  This PR intentionally stops before the profile-identity cleanup in
  [#22683](https://github.com/openai/codex/pull/22683) so the base review
  stays focused on config loading, workspace-root materialization, and
  compatibility with legacy `workspace-write`.
  
  The representation in this PR is therefore transitional: `Permissions`
  carries enough state to distinguish the raw constrained profile from the
  effective runtime profile, and there are still call sites that must keep
  the active profile identity and constrained profile value in sync. The
  follow-up PR replaces that with a single resolved profile state
  (`ResolvedPermissionProfile` / `PermissionProfileState`) that keeps the
  profile id, immutable `PermissionProfile`, and profile-declared
  workspace roots together. That follow-up removes APIs such as
  `set_constrained_permission_profile_with_active_profile()` where
  separate arguments could drift out of sync.
  
  Downstream PRs then build on this base to switch app-server turn updates
  to profile ids plus runtime workspace roots and to finish the
  user-visible summary behavior. Reviewers should judge this PR as the
  workspace-roots foundation, not as the final in-memory shape of selected
  permission profiles.
  
  ## Review Guide
  
  Suggested review order:
  
  1. Start with `codex-rs/core/src/config/mod.rs`.
  This is the main shape change in the base slice. `Permissions` now
  stores a private raw `Constrained<PermissionProfile>` plus runtime
  `workspace_roots`. Callers use `permission_profile()` when they need the
  raw constrained value and `effective_permission_profile()` when they
  need a materialized runtime profile. As noted above,
  [#22683](https://github.com/openai/codex/pull/22683) replaces this
  transitional shape with a resolved profile state that keeps identity and
  profile data together.
  
  2. Review `codex-rs/config/src/permissions_toml.rs` and
  `codex-rs/core/src/config/permissions.rs`.
  These add `[permissions.<id>.workspace_roots]`, resolve enabled entries
  relative to the policy cwd, and keep `:workspace_roots` deny-read glob
  patterns symbolic until the actual roots are known.
  
  3. Review `codex-rs/protocol/src/permissions.rs` and
  `codex-rs/protocol/src/models.rs`.
  These add the policy/profile materialization helpers that expand exact
  `:workspace_roots` entries and scoped deny-read globs over every
  workspace root. This is also where `ActivePermissionProfileModification`
  is removed from the core model.
  
  4. Review the legacy bridge in
  `Config::load_from_base_config_with_overrides` and
  `Config::set_legacy_sandbox_policy`.
  This is where legacy `workspace-write` roots become runtime workspace
  roots, while Codex internal writable roots stay internal and do not
  appear as user-facing workspace roots.
  
  5. Then skim downstream call sites.
  The interesting pattern is raw-vs-effective access: state/proxy/bwrap
  paths keep the raw constrained profile, while execution, summaries, and
  user-visible status use the effective profile and workspace-root list.
  
  ## What Changed
  
  - added `[permissions.<id>.workspace_roots]` to the config model and
  schema
  - added runtime `workspace_roots` state to `Config`/`Permissions` and
  `ConfigOverrides`
  - made `Permissions` profile fields private and replaced direct mutation
  with accessors/setters
  - added `PermissionProfile` and `FileSystemSandboxPolicy` helpers for
  materializing `:workspace_roots` exact paths and deny-read globs across
  all roots
  - moved legacy additional writable roots into runtime workspace-root
  state instead of active profile modifications
  - removed `ActivePermissionProfileModification` and its app-server
  protocol/schema export
  - updated sandbox/status summary paths so internal writable roots are
  not reported as user workspace roots
  
  ## Verification Strategy
  
  The targeted tests cover the behavior at the layers where regressions
  are most likely:
  - `codex-rs/core/src/config/config_tests.rs` verifies config loading,
  legacy workspace-root seeding, effective profile materialization, and
  memory-root handling.
  - `codex-rs/core/src/config/permissions_tests.rs` verifies profile
  `workspace_roots` parsing and `:workspace_roots` scoped/glob
  compilation.
  - `codex-rs/protocol/src/permissions.rs` unit tests verify exact and
  glob materialization over multiple workspace roots.
  - `codex-rs/tui/src/status/tests.rs` and
  `codex-rs/utils/sandbox-summary/src/sandbox_summary.rs` verify the
  user-facing summaries show effective workspace roots and hide internal
  writes.
  
  I also ran `cargo check --tests` locally after the latest stack refresh
  to catch cross-crate API breakage from the private-field/accessor
  changes.
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22610).
  * #22612
  * #22611
  * #22683
  * __->__ #22610

  Michael Bolin · 2026-05-14 18:25:23 -07:00
  c25d905f61
• permissions: canonicalize workspace_roots and danger-full-access names (#22624)

  ## Why
  
  This is a small precursor to the larger permissions-migration work. Both
  the comparison stack in
  [#22401](https://github.com/openai/codex/pull/22401) /
  [#22402](https://github.com/openai/codex/pull/22402) and the alternate
  stack in [#22610](https://github.com/openai/codex/pull/22610) /
  [#22611](https://github.com/openai/codex/pull/22611) /
  [#22612](https://github.com/openai/codex/pull/22612) are easier to
  review if the terminology is already settled underneath them.
  
  Because `:project_roots` and `:danger-no-sandbox` have not shipped as
  stable user-facing surface area, carrying them forward as aliases would
  just add more migration logic to the later stacks. This PR removes that
  ambiguity now so the follow-on work can rely on one spelling for each
  built-in concept.
  
  ## What Changed
  
  - renamed the config-facing special filesystem key from `:project_roots`
  to `:workspace_roots`
  - dropped unpublished `:project_roots` parsing support in
  `core/src/config/permissions.rs`, so new config only recognizes
  `:workspace_roots`
  - renamed the built-in full-access permission profile id from
  `:danger-no-sandbox` to `:danger-full-access`
  - dropped unpublished `:danger-no-sandbox` support entirely, including
  the old active-profile canonicalization path, and added explicit
  rejection coverage for the legacy id
  - introduced shared built-in permission-profile id constants in
  `codex-rs/protocol/src/models.rs`
  - updated `core`, `app-server`, and `tui` call sites that special-case
  built-in profiles to use the shared constants and canonical ids
  - updated tests and the Linux sandbox README to use `:workspace_roots` /
  `:danger-full-access`
  
  ## Verification
  
  I focused verification on the three places this rename can regress:
  config parsing, active-profile identity surfaced back out of `core`, and
  user/server call sites that special-case built-in profiles.
  
  Targeted checks:
  
  -
  `config::tests::default_permissions_can_select_builtin_profile_without_permissions_table`
  -
  `config::tests::default_permissions_read_only_applies_additional_writable_roots_as_modifications`
  -
  `config::tests::default_permissions_can_select_builtin_full_access_profile`
  - `config::tests::legacy_danger_no_sandbox_is_rejected`
  - `workspace_root` filtered `codex-core` tests
  -
  `request_processors::thread_processor::thread_processor_tests::thread_processor_behavior_tests::requested_permissions_trust_project_uses_permission_profile_intent`
  -
  `suite::v2::turn_start::turn_start_rejects_invalid_permission_selection_before_starting_turn`
  - `status::tests::status_snapshot_shows_auto_review_permissions`
  -
  `status::tests::status_permissions_full_disk_managed_with_network_is_danger_full_access`
  -
  `app_server_session::tests::embedded_turn_permissions_use_active_profile_selection`

  Michael Bolin · 2026-05-14 08:45:54 -07:00
  01d93fd9fc
• fix(tui): handle hidden app git directives (#21946)
  Felipe Coury · 2026-05-11 21:08:40 -03:00
  e16b4e46d4
• Fix side conversation config inheritance (#22106)

  Addresses #22101
  
  ## Why
  
  Side conversations are ephemeral forks of the active thread, but `/side`
  was building its fork config from the app-level config after refreshing
  it from disk. If the parent thread had runtime settings that differed
  from the current persisted defaults, such as a changed model, reasoning
  effort, permissions, reviewer, or fast-mode selection, the side
  conversation could start with different behavior than its parent.
  
  ## What changed
  
  - Build side fork config from the active parent `ChatWidget` config,
  then overlay the parent thread's effective model, reasoning effort,
  service tier, and fast-mode opt-out state.
  - Forward model reasoning summary, verbosity, personality, web search
  mode, and service-tier overrides through TUI app-server
  start/resume/fork lifecycle params.
  - Add focused tests for parent runtime inheritance, side developer
  guardrail preservation, and lifecycle param forwarding.

  Eric Traut · 2026-05-11 09:47:51 -07:00
  c03eb20d8d
• [codex-tui] pass thread source for tui threads (#21401)

  ## Summary
  - mark TUI-created thread starts and forks with explicit `thread_source
  = user`
  - add focused coverage for embedded and remote lifecycle request
  builders
  
  ## Why
  Thread analytics now consume an explicit thread-level source
  classification instead of inferring it from `session_source`. The TUI
  still omitted that field, so TUI-created interactive threads would
  continue to land as `null` even after the new analytics plumbing
  shipped.
  
  ## Validation
  - `cargo test -p codex-tui app_server_session --lib`

  rhan-oai · 2026-05-06 13:18:41 -07:00
  21295f47e2
• Move message history out of core (#21278)

  ## Why
  
  Message history was implemented inside `codex-core` and surfaced through
  core protocol ops and `SessionConfiguredEvent` fields even though the
  current consumer is TUI-local prompt recall. That made core own UI
  history persistence and exposed `history_log_id` / `history_entry_count`
  through surfaces that app-server and other clients do not need.
  
  This change moves message history persistence out of core and keeps the
  recall plumbing local to the TUI.
  
  ## What changed
  
  - Added a new `codex-message-history` crate for appending, looking up,
  trimming, and reading metadata from `history.jsonl`.
  - Removed core protocol history ops/events: `AddToHistory`,
  `GetHistoryEntryRequest`, and `GetHistoryEntryResponse`.
  - Removed `history_log_id` and `history_entry_count` from
  `SessionConfiguredEvent` and updated exec/MCP/test fixtures accordingly.
  - Updated the TUI to dispatch local app events for message-history
  append/lookup and keep its persistent-history metadata in TUI session
  state.
  
  ## Validation
  
  - `cargo test -p codex-message-history -p codex-protocol`
  - `cargo test -p codex-exec event_processor_with_json_output`
  - `cargo test -p codex-mcp-server outgoing_message`
  - `cargo test -p codex-tui`
  - `just fix -p codex-message-history -p codex-protocol -p codex-core -p
  codex-tui -p codex-exec -p codex-mcp-server`

  pakrym-oai · 2026-05-06 08:35:42 -07:00
  2004173cd7