1827 Commits

• fix(tui): preserve modified enter in plan questions (#23536)

  ## Why
  
  Plan mode questionnaires reuse the shared composer for free-form
  answers, but the surrounding `request_user_input` overlay still treated
  every `KeyCode::Enter` as “advance to the next question.” That made
  `Shift+Enter` insert a newline in the composer and then immediately
  advance the questionnaire anyway.
  
  Fixes #23448.
  
  ## What Changed
  
  - pass the live `RuntimeKeymap` into `RequestUserInputOverlay` so its
  embedded composer honors existing `/keymap` composer/editor remaps
  - advance free-form questions only on the configured composer submit
  binding, instead of any Enter-shaped key event
  - add regressions for `Shift+Enter` newline behavior and configured
  composer submit bindings inside the questionnaire UI
  
  ## How to Test
  
  1. Start Codex in Plan mode and trigger a `request_user_input`
  questionnaire with a free-form answer field.
  2. Focus the free-form field, type a line, then press `Shift+Enter`.
  3. Confirm the answer gains a newline and the questionnaire stays on the
  same question.
  4. Press the configured submit binding, or plain `Enter` with the
  default keymap, and confirm the questionnaire advances as before.
  
  Targeted tests:
  - `cargo test -p codex-tui
  bottom_pane::request_user_input::tests::freeform_ -- --nocapture`
  
  ## Notes
  
  - `cargo test -p codex-tui` still reaches an unrelated existing stack
  overflow in
  `app::tests::discard_side_thread_removes_agent_navigation_entry` on this
  checkout.
  - `just argument-comment-lint` is locally blocked by Bazel analysis
  failing in external `compiler-rt` before the lint runs.

  Felipe Coury · 2026-05-19 18:01:38 -03:00
  40be41763c
• Make local environment optional in EnvironmentManager (#23369)

  ## Summary
  - make `EnvironmentManager` local environment/runtime paths optional
  - simplify constructor surface around snapshot materialization
  - rename local env accessors to `require_local_environment` /
  `try_local_environment`
  
  ## Validation
  - devbox Bazel build for touched crate surfaces
  - `//codex-rs/exec-server:exec-server-unit-tests`
  - `//codex-rs/app-server-client:app-server-client-unit-tests`
  - filtered touched `//codex-rs/core:core-unit-tests` cases

  starr-openai · 2026-05-19 12:55:34 -07:00
  5c43a64e2b
• Add SubagentStart hook (#22782)

  # What
  
  `SubagentStart` runs once when Codex creates a thread-spawned subagent,
  before that child sends its first model request. Thread-spawned
  subagents use `SubagentStart` instead of the normal root-agent
  `SessionStart` hook.
  
  Configured handlers match on the subagent `agent_type`, using the same
  value passed to `spawn_agent`. When no agent type is specified, Codex
  uses the default agent type.
  
  Hook input includes the normal session-start fields plus:
  
  - `agent_id`: the child thread id.
  - `agent_type`: the resolved subagent type.
  
  `SubagentStart` may return `hookSpecificOutput.additionalContext`. That
  context is added to the child conversation before the first model
  request.
  
  # Lifecycle Scope
  
  Only thread-spawned subagents run `SubagentStart`.
  
  Internal/system subagents such as Review, Compact, MemoryConsolidation,
  and Other do not run normal `SessionStart` hooks and do not run
  `SubagentStart`. This avoids exposing synthetic matcher labels for
  internal implementation paths.
  
  Also the `SessionStart` hook no longer fires for subagents, this matches
  behavior with other coding agents' implementation
  
  # Stack
  
  1. This PR: add `SubagentStart`.
  2. #22873: add `SubagentStop`.
  3. #22882: add subagent identity to normal hook inputs.

  Abhinav · 2026-05-19 12:45:08 -07:00
  d661ab70ed
• 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
• Make deny canonical for filesystem permission entries (#23493)

  ## Why
  Filesystem permission profiles used `none` for deny-read entries, which
  is less direct than the action the entry actually represents. This
  change makes `deny` the canonical filesystem permission spelling while
  preserving compatibility for older configs that still send `none`.
  
  ## What changed
  - rename `FileSystemAccessMode::None` to `Deny`
  - serialize and generate schemas with `deny` as the canonical value
  - retain `none` only as a legacy input alias for temporary config
  compatibility
  - update filesystem glob diagnostics and regression coverage to use the
  canonical spelling
  - refresh config and app-server schema fixtures to match the new wire
  shape
  
  ## Validation
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core config_toml_deserializes_permission_profiles
  --lib`
  - `cargo test -p codex-core
  read_write_glob_patterns_still_reject_non_subpath_globs --lib`
  
  Earlier in the session, a broad `cargo test -p codex-core` run reached
  unrelated pre-existing failures in timing/snapshot/git-info tests under
  this environment; the targeted surfaces touched by this PR passed
  cleanly.

  viyatb-oai · 2026-05-19 11:03:47 -07:00
  3c76081876
• [2 of 4] tui: route app and skill enablement through app server (#22914)

  ## Why
  App and skill toggles are user config mutations too. When the TUI is
  attached to a remote app server, writing those toggles into the local
  `config.toml` makes the UI report success without updating the server
  that actually owns the session.
  
  This is **[2 of 4]** in a stacked series that moves TUI-owned config
  mutations onto app-server APIs.
  
  ## What changed
  - Routed app enable/disable persistence through app-server config batch
  writes.
  - Routed skill enable/disable persistence through `skills/config/write`.
  - Avoided refreshing local config from disk after these writes when the
  TUI is connected to a remote app server.
  
  ## Config keys affected
  - `apps.<app_id>.enabled`
  - `apps.<app_id>.disabled_reason`
  - `[[skills.config]]` entries keyed by `path`, with `enabled = false`
  used for persisted disables
  
  ## Suggested manual validation
  - Connect the TUI to a remote app server, disable an app, reconnect, and
  confirm the app remains disabled from remote config rather than local
  disk state.
  - Re-enable the same app and confirm both `apps.<app_id>.enabled` and
  `apps.<app_id>.disabled_reason` are cleared remotely.
  - Disable a skill in the manage-skills UI and confirm a remote
  `[[skills.config]]` disable entry appears.
  - Re-enable that skill and confirm the disable entry is removed and the
  effective enabled state updates without relying on local config reloads.
  
  ## Stack
  1. [#22913](https://github.com/openai/codex/pull/22913) `[1 of 4]`
  primary settings writes
  2. [#22914](https://github.com/openai/codex/pull/22914) `[2 of 4]` app
  and skill enablement
  3. [#22915](https://github.com/openai/codex/pull/22915) `[3 of 4]`
  feature and memory toggles
  4. [#22916](https://github.com/openai/codex/pull/22916) `[4 of 4]`
  startup and onboarding bookkeeping

  Eric Traut · 2026-05-19 10:21:07 -07:00
  ae10708ae0
• 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
• fix(tui): warn on unsupported iTerm2 pet versions (#23371)

  ## Why
  
  Older iTerm2 builds can be detected as supporting the image transport
  that terminal pets use, but in practice they fail to render the pet flow
  correctly. Instead of silently attempting image rendering, Codex should
  tell the user that their iTerm2 version is too old and that upgrading is
  the fix.
  
  ## What Changed
  
  - gate iTerm2 pet auto-detection on version `3.6.0` or newer
  - show a dedicated upgrade message for older or unknown iTerm2 versions
  instead of the generic unsupported-terminal warning
  - keep the existing generic unsupported-terminal path for non-iTerm
  terminals
  - add regression coverage for iTerm2 version parsing and the old-iTerm
  warning path
  
  ## How to Test
  
  1. Start Codex in iTerm2 3.6 or newer.
  2. Run `/pets`.
  3. Confirm the pets picker opens instead of showing a warning.
  4. Start Codex in an older iTerm2 build, or exercise the equivalent test
  path.
  5. Run `/pets`.
  6. Confirm Codex warns that pets require iTerm2 3.6 or newer and tells
  the user to upgrade.
  7. Also verify that a non-iTerm unsupported terminal still shows the
  generic unsupported-terminal message.
  
  Targeted tests:
  - `cargo test -p codex-terminal-detection`
  - `cargo test -p codex-tui pets::`
  - `cargo test -p codex-tui slash_pets_on_unsupported_terminal`
  - `cargo test -p codex-tui slash_pets_on_old_iterm2`

  Felipe Coury · 2026-05-18 20:24:09 -03:00
  a66712c95d
• feat(tui): handle paste in session picker (#23338)

  ## Why
  
  The session picker already supports typed search, but it ignored
  bracketed paste events entirely. On macOS terminals this makes pasted
  text look like a no-op on the resume screen, which is especially
  noticeable when a user wants to paste part of a thread name, branch, or
  path into the search field.
  
  ## What Changed
  
  - route `TuiEvent::Paste(String)` into the session picker instead of
  dropping it
  - normalize pasted search text into a single-line query by collapsing
  whitespace
  - ignore whitespace-only pastes
  - reuse the existing `set_query(...)` path so pasted searches keep the
  same filtering and pagination behavior as typed input
  - add focused tests for append behavior, whitespace normalization,
  whitespace-only paste, and the existing search-loading path
  
  This PR is stacked on top of #23234 and contains only the net change
  relative to `etraut/clarify-resume-hints`.
  
  ## How to Test
  
  1. Start Codex in a terminal that emits bracketed paste, for example
  iTerm2 on macOS.
  2. Open the resume picker so the search UI is visible.
  3. Copy a term that should match one of the visible sessions, then paste
  it into the picker.
  4. Confirm the query updates immediately and the list filters as if the
  text had been typed.
  5. Also verify that pasting text with newlines or tabs still produces a
  usable single-line search query.
  6. Also verify that normal typed search still works and that `Esc` still
  clears the query / exits as before.
  
  Targeted tests:
  - `cargo test -p codex-tui`
  
  ---------
  
  Co-authored-by: Eric Traut <etraut@openai.com>

  Felipe Coury · 2026-05-18 19:04:41 +00:00
  8e52578e66
• TUI: replay in-progress MCP calls as started (#23236)

  Fixes #22300.
  
  ## Summary
  MCP tool calls can appear in thread history while still in progress.
  During replay, `handle_thread_item` routed every
  `ThreadItem::McpToolCall` to the completion handler, so an in-progress
  item with no result or error was rendered as `MCP tool call completed
  without a result`.
  
  This updates replay handling to mirror command executions: `InProgress`
  MCP calls go through `on_mcp_tool_call_started`, while completed and
  failed calls continue through the completion path.
  
  ## Validation
  - `cargo test -p codex-tui
  replayed_in_progress_mcp_tool_call_stays_active`

  Eric Traut · 2026-05-18 11:34:31 -07:00
  ae03d073b3
• TUI: route elicitation responses to request thread (#23241)

  ## Why
  
  Fixes #21894.
  
  When the TUI handles an MCP elicitation, the request payload already
  includes the thread that generated the elicitation.
  `ChatWidget::handle_elicitation_request_now` was ignoring that value and
  using the currently visible chat thread instead. In a multi-session TUI,
  that can send `resolve_elicitation` to an older visible thread rather
  than the session that owns the pending elicitation, producing
  `elicitation request not found` and leaving the prompt unresolved.
  
  ## What changed
  
  - Parse `McpServerElicitationRequestParams.thread_id` in the ChatWidget
  elicitation handler and use it for app-link, form, fallback approval,
  and auto-decline resolution paths.
  - Keep the existing visible-thread fallback only for malformed request
  payloads with an invalid thread id.
  - Update the invalid URL elicitation regression test so the visible
  thread and request thread intentionally differ.

  Eric Traut · 2026-05-18 11:33:13 -07:00
  53a1f4c29e
• Clarify resume hints for renamed threads (#23234)

  Addresses #23181
  
  ## Why
  Renamed threads can share names, so hints that suggest resuming directly
  by name are ambiguous. Issue #23181 asks for the picker hint to include
  the thread name and thread ID in parens so users can disambiguate
  safely.
  
  ## What
  - Adds a shared resume hint formatter for named threads: run `codex
  resume`, then select `<name> (<thread-id>)`.
  - Uses that hint for /rename confirmations, TUI session summaries, and
  CLI/TUI exit messages.
  - Keeps direct `codex resume <thread-id>` guidance for unnamed threads.
  
  ## Verification
  Manually verified that message after `/rename` and after `/exit` include
  session ID in parens.
  
  ---------
  
  Co-authored-by: Felipe Coury <felipe.coury@openai.com>

  Eric Traut · 2026-05-18 11:32:02 -07:00
  4ac3ea20a2
• goal: pause continuation loops on usage limits and blockers (#23094)

  Addresses #22833, #22245, #23067
  
  ## Why
  `/goal` can keep synthesizing turns even when the next turn cannot make
  meaningful progress. Hard usage exhaustion can replay failing turns, and
  repeated permission or external-resource blockers can keep burning
  tokens while waiting for user or system intervention.
  
  ## What changed
  - Add resumable `blocked` and `usageLimited` goal states. As with
  `paused`, goal continuation stops with these states.
  - Move to `usageLimited` after usage-limit failures.
  - Allow the built-in `update_goal` tool to set `blocked` only under
  explicit repeated-impasse guidance. Updated goal continuation prompt to
  specify that agent should use `blocked` only when it has made at least
  three attempts to get past an impasse.
  
  Most of the files touched by this PR are because of the small app server
  protocol update.
  
  ## Validation
  
  I manually reproduced a number of situations where an agent can run into
  a true impasse and verified that it properly enters `blocked` state. I
  then resumed and verified that it once again entered `blocked` state
  several turns later if the impasse still exists.
  
  I also manually reproduced the usage-limit condition by creating a
  simulated responses API endpoint that returns 429 errors with the
  appropriate error message. Verified that the goal runtime properly moves
  the goal into `usageLimited` state and TUI UI updates appropriately.
  Verified that `/goal resume` resumes (and immediately goes back into
  `ussageLImited` state if appropriate).
  
  
  ## Follow-up PRs
  
  Small changes will be needed to the GUI clients to properly handle the
  two new states.

  Eric Traut · 2026-05-18 11:28:53 -07:00
  0d344aca9b
• fix(tui): show shutdown feedback on exit (#23323)

  ## Why
  
  Ctrl+C can take a noticeable amount of time to finish when the TUI is
  waiting for the app-server thread shutdown path to complete. Before this
  change, the UI could look like it had not accepted the shutdown request
  because the composer and cursor remained in their normal interactive
  state during that wait.
  
  This PR makes the accepted shutdown visible immediately. It does not add
  an artificial sleep or change the shutdown timeout; it only draws one
  final feedback frame before continuing through the existing shutdown
  flow.
  
  ## What Changed
  
  - On `ExitMode::ShutdownFirst`, the TUI now renders shutdown feedback
  before awaiting the existing thread shutdown future.
  - The bottom pane disables composer input, which hides the cursor
  through the existing disabled-input cursor path.
  - The composer shows `Shutting down...` as the disabled input hint and
  suppresses footer content so the shutdown acknowledgement is not
  competing with shortcut/status text.
  - The logout path uses the same feedback path before shutting down.
  
  ## How to Test
  
  1. Start Codex from this branch.
  2. Press `Ctrl+C` to request shutdown.
  3. If shutdown takes long enough to observe, confirm the composer
  changes to `› Shutting down...`, the cursor disappears, and no footer
  hint is rendered below it.
  4. Regression check: repeat with text already typed in the composer and
  confirm the visible row still switches to `Shutting down...` while the
  draft remains preserved internally until the process exits.
  
  Targeted tests:
  
  - `cargo test -p codex-tui
  shutdown_in_progress_disables_input_and_uses_hint_without_footer`
  - `cargo test -p codex-tui bottom_pane::footer::tests::`
  
  ## Local Validation Note
  
  `cargo test -p codex-tui` still aborts in
  `app::tests::discard_side_thread_removes_agent_navigation_entry` with a
  stack overflow. That same test also failed when run alone locally, and
  the failure appears unrelated to this shutdown feedback path.

  Felipe Coury · 2026-05-18 14:41:14 -03:00
  bb43044cba
• [1 of 2] Optimize TUI startup terminal probes (#23175)

  ## Why
  
  Codex TUI startup still feels slower than 0.117.0 after the app-server
  move in 0.118.0. A visible chunk of launch-to-input latency comes from
  serial terminal startup probes: cursor position, keyboard enhancement
  support, and default foreground/background color queries can each wait
  on terminal responses before the first usable frame.
  
  Refs #16335.
  
  ## What
  
  This PR batches the terminal startup probes into one bounded probe. It
  also reuses the probed cursor position and default colors during TUI
  setup, fast-paths the primary-device-attributes fallback as keyboard
  enhancement unsupported, and keeps lightweight startup timing logs for
  future tuning.
  
  The startup telemetry is intentionally left in production: it records
  phase timings for terminal probes and initial-frame scheduling so future
  startup regressions can be diagnosed from normal logs rather than
  re-adding one-off debug instrumentation.
  
  ## Benchmark
  
  In the local pty startup benchmark, the pre-optimization `main` baseline
  was about 250.5ms median from launch to accepted chat input. This
  probe-only branch measured about 152ms median, for an approximate
  savings of 95-100ms.
  
  ## Stack
  
  1. [#23175: [1 of 2] Optimize TUI startup terminal
  probes](https://github.com/openai/codex/pull/23175) — this PR
  2. [#23176: [2 of 2] Start fresh TUI thread in
  background](https://github.com/openai/codex/pull/23176) — layered on
  this PR
  
  ## Verification
  
  - `cargo test -p codex-tui`

  Eric Traut · 2026-05-18 09:04:02 -07:00
  adca1b643f
• Hide ChatGPT usage link for non-OpenAI status (#23127)

  Addresses #22778
  
  ## Summary
  
  Provider deployments such as Bedrock manage rate limits and billing
  outside ChatGPT, so the `/status` link to the ChatGPT usage page is
  irrelevant and confusing for those users. Custom providers that are
  explicitly configured to use OpenAI/ChatGPT auth still point at
  OpenAI-backed usage, so they should keep the link.
  
  ## Changes
  
  - Render the ChatGPT usage note only when the configured provider uses
  OpenAI auth.
  - Keep the note hidden when `/status` displays a provider such as
  Bedrock that manages limits elsewhere.
  - Add regression coverage for both Bedrock and a custom OpenAI-auth
  proxy provider.
  
  ## Manual Repro
  
  1. Configure Codex with a non-OpenAI-auth provider, for example
  `model_provider = "amazon-bedrock"`.
  2. Start the TUI and run `/status`.
  3. Confirm the status card shows the custom provider, for example `Model
  provider: Amazon Bedrock`, and does not show
  `https://chatgpt.com/codex/settings/usage`.
  4. Configure a custom provider that proxies to OpenAI and has
  OpenAI/ChatGPT auth enabled.
  5. Run `/status` again and confirm the ChatGPT usage link appears for
  that OpenAI-auth provider.

  Eric Traut · 2026-05-18 09:02:38 -07:00
  e734cb5713
• Fix TUI stream cleanup after turn errors (#23128)

  ## Summary
  
  Fixes #22726.
  
  After a Responses stream disconnect, the live TUI could keep accepting
  prompts while leaving partially streamed assistant output in its
  transient streaming-cell form. That made fenced diffs or SVG/XML-like
  content appear as raw transcript text until the user closed the TUI and
  resumed the same session, which rebuilt the transcript from saved
  history.
  
  This change finalizes the active answer stream before generic
  failed-turn cleanup clears the stream controller, so the live transcript
  takes the same source-backed markdown consolidation path as a successful
  turn.
  
  ## Reviewer repro
  
  1. Start a local Codex TUI session.
  2. Trigger an assistant turn that streams markdown content, especially a
  fenced diff or SVG/XML-like block.
  3. Force or encounter a non-retry stream disconnect before the turn
  completes.
  4. Continue using the same still-open TUI session.
  5. Before this fix, the live history can stay raw/plain even though
  `codex resume` renders the same session normally.
  6. After this fix, the failed-turn path consolidates the partial stream
  before rendering the error, so the live TUI keeps normal transcript
  rendering.

  Eric Traut · 2026-05-18 09:00:57 -07:00
  deb159d9ff
• tui: keep cleared Fast tier from reappearing after side-thread resume (#23121)

  ## Why
  
  After turning Fast mode off in the TUI, returning from a side thread
  could make `Fast` appear again in the main chat widget. The opt-out
  itself was still persisted; the display was being rebuilt from stale
  cached `ThreadSessionState` data, which made it look like Fast had been
  re-enabled.
  
  Fixes #23104.
  
  ## What changed
  
  - Keep the active thread's cached `service_tier` in sync whenever the
  user persists a service-tier selection.
  - Update both the primary-thread snapshot and the thread event store so
  restored TUI state reflects the current tier.
  - Add a focused regression test for clearing a cached Fast tier.
  
  ## Manual repro
  
  1. Start a TUI session where `Fast` is enabled by default.
  2. Run `/fast` and turn Fast mode off. Confirm `Fast` disappears from
  the chat widget display.
  3. Re-enter thread navigation via either path:
     - Run `/side test`, then return to the main thread.
     - Run `/agent`, enter a child thread, then return to the main thread.
  4. Before this fix, `Fast` reappears in the main chat widget display
  even though the opt-out was already persisted.
  5. After this fix, `Fast` stays cleared.
  
  ## Verification
  
  - `cargo test -p codex-tui
  app::thread_session_state::tests::service_tier_sync_updates_active_cached_session
  -- --exact`

  Eric Traut · 2026-05-18 08:52:18 -07:00
  fce10e009d
• [1 of 4] tui: route primary settings writes through app server (#22913)

  ## Why
  The TUI can run against a remote app server, but several high-traffic
  settings still persisted by editing the local config file. That sends
  remote sessions' preference writes to the wrong machine and lets local
  disk state drift from the app-server-owned config.
  
  This is **[1 of 4]** in a stacked series that moves TUI-owned config
  mutations onto app-server APIs.
  
  ## What changed
  - Added a small TUI helper for typed app-server config writes.
  - Routed primary interactive preference writes through
  `config/batchWrite`.
  - Preserved existing profile scoping for settings that already support
  `profiles.<profile>.*` overrides.
  
  ## Config keys affected
  - `model`
  - `model_reasoning_effort`
  - `personality`
  - `service_tier`
  - `plan_mode_reasoning_effort`
  - `approvals_reviewer`
  - `notice.fast_default_opt_out`
  - Profile-scoped equivalents under `profiles.<profile>.*`
  
  ## Suggested manual validation
  - Connect the TUI to a remote app server, change `model` and
  `model_reasoning_effort`, reconnect, and confirm the remote config
  retained both values while the local `config.toml` did not change.
  - Change `personality`, `plan_mode_reasoning_effort`, and the explicit
  auto-review selection, then reconnect and confirm those choices persist
  through the app server.
  - Clear the service tier back to default and confirm `service_tier` is
  cleared while `notice.fast_default_opt_out = true` is persisted
  remotely.
  - Repeat one setting change with an active profile and confirm the write
  lands under `profiles.<profile>.*`.
  
  ## Stack
  1. [#22913](https://github.com/openai/codex/pull/22913) `[1 of 4]`
  primary settings writes
  2. [#22914](https://github.com/openai/codex/pull/22914) `[2 of 4]` app
  and skill enablement
  3. [#22915](https://github.com/openai/codex/pull/22915) `[3 of 4]`
  feature and memory toggles
  4. [#22916](https://github.com/openai/codex/pull/22916) `[4 of 4]`
  startup and onboarding bookkeeping

  Eric Traut · 2026-05-16 14:27:02 -07:00
  0445b290fe
• core: set permission profiles from snapshots (#22920)

  ## Why
  
  #22891 moved the TUI turn-command path to pass `ActivePermissionProfile`
  instead of the full `PermissionProfile`, but the remaining
  config/session bridge still accepted the concrete `PermissionProfile`
  and active profile id as separate arguments. That shape made it too easy
  for future callers to update the concrete profile and active profile id
  out of sync.
  
  This PR makes the trusted session snapshot path pass one coherent value
  into `Permissions`, while keeping `requirements.toml` enforcement owned
  by the existing constrained permission state.
  
  ## What Changed
  
  - Added `PermissionProfileSnapshot` as the public snapshot value for
  trusted session/config synchronization.
  - Changed `Permissions::set_permission_profile_from_session_snapshot()`
  and `replace_permission_profile_from_session_snapshot()` to take a
  `PermissionProfileSnapshot`.
  - Updated the replacement path to derive its constrained
  `PermissionProfile` from the snapshot, so callers cannot pass a separate
  profile that disagrees with the snapshot.
  - Removed the internal tuple-style
  `PermissionProfileState::set_active_permission_profile()` mutation path.
  - Updated core session projection and TUI call sites to construct
  explicit legacy or active snapshots.
  - Documented the snapshot constructors so legacy use and id/profile
  mismatch hazards are called out at the API boundary.
  - Added a focused config test that verifies snapshot updates still
  respect existing permission constraints.
  
  ## How To Review
  
  1. Start with `codex-rs/core/src/config/resolved_permission_profile.rs`;
  `PermissionProfileSnapshot` is the public wrapper, while
  `ResolvedPermissionProfile` stays internal.
  2. Check `codex-rs/core/src/config/mod.rs` to confirm both
  session-snapshot setters validate through `PermissionProfileState` and
  no longer accept loose profile/id pairs.
  3. Skim `codex-rs/core/src/session/session.rs` for the session
  projection path; it now builds the snapshot before installing it.
  4. Skim the TUI changes as call-site migration from loose argument pairs
  to explicit snapshot construction.
  
  ## Verification
  
  - `cargo test -p codex-core
  permission_snapshot_setter_preserves_permission_constraints`
  - `cargo test -p codex-tui status_permissions_`
  - `cargo test -p codex-tui
  session_configured_preserves_profile_workspace_roots`
  - `just fix -p codex-core -p codex-tui`

  Michael Bolin · 2026-05-16 07:26:18 -07:00
  108234b5eb
• 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
• tui: pass active permission profiles through app commands (#22891)

  ## Why
  
  This continues the permissions migration by keeping the TUI command
  boundary aligned with the app-server protocol direction from #22795:
  callers should select a permission profile by id instead of passing a
  concrete `PermissionProfile` value around as the turn configuration.
  
  `AppCommand` is internal to the TUI, but it is the path that eventually
  becomes `thread/turn/start`, so carrying concrete profile details there
  made it too easy for UI code to keep relying on the old whole-profile
  replacement model.
  
  ## What changed
  
  - `AppCommand::UserTurn` and `AppCommand::OverrideTurnContext` now carry
  `Option<ActivePermissionProfile>` instead of `PermissionProfile`.
  - Composer submissions copy the active permission profile id from the
  current session snapshot; legacy snapshots intentionally submit no
  active profile id.
  - Permission preset UI events now carry only the active built-in profile
  id. The app derives the concrete built-in `PermissionProfile` internally
  only when updating its local config/status snapshot.
  - Permission presets expose their built-in active profile id, and preset
  selection preserves that id in both the immediate turn override and the
  local TUI config snapshot.
  - Turn routing sends `TurnPermissionsOverride::ActiveProfile` when an
  active id is present, and only falls back to the legacy sandbox
  projection for the remaining runtime override path.
  
  ## How to review
  
  Start with `codex-rs/tui/src/app_command.rs` to verify the command shape
  no longer exposes `PermissionProfile`.
  
  Then read `codex-rs/tui/src/app/thread_routing.rs` to verify the
  app-server turn-start conversion: active ids go through as ids, while
  the legacy sandbox fallback is still constrained to the existing runtime
  override case.
  
  Finally, check `codex-rs/tui/src/chatwidget/permission_popups.rs`,
  `codex-rs/tui/src/app/event_dispatch.rs`,
  `codex-rs/tui/src/app/config_persistence.rs`, and
  `codex-rs/utils/approval-presets/src/lib.rs` to see how preset
  selections stay id-only across TUI events while the local display/config
  mirror still gets a concrete built-in profile.
  
  ## Verification
  
  Latest local verification after the id-only `AppEvent` cleanup:
  
  - `cargo check -p codex-tui --tests`
  - `cargo test -p codex-tui
  permissions_selection_sends_approvals_reviewer_in_override_turn_context`
  - `cargo test -p codex-tui update_feature_flags_enabling_guardian`
  - `cargo test -p codex-utils-approval-presets`
  - `just fmt`
  - `just fix -p codex-tui -p codex-utils-approval-presets`
  
  Earlier in the same PR, before the final event-shape cleanup:
  
  - `cargo test -p codex-tui turn_permissions_`
  - `cargo test -p codex-tui submission_`
  - `cargo test -p codex-tui
  session_configured_syncs_widget_config_permissions_and_cwd`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-tui`

  Michael Bolin · 2026-05-15 22:42:35 +00:00
  bbb5c2811d
• Preserve image detail in app-server inputs (#20693)

  ## Summary
  
  - Add optional image detail to user image inputs across core, app-server
  v2, thread history/event mapping, and the generated app-server
  schemas/types.
  - Preserve requested detail when serializing Responses image inputs:
  omitted detail stays on the existing `high` default, while explicit
  `original` keeps local images on the original-resolution path.
  - Support `high`/`original` consistently for tool image outputs,
  including MCP `codex/imageDetail`, code-mode image helpers, and
  `view_image`.

  Curtis 'Fjord' Hawthorne · 2026-05-15 15:04:04 -07:00
  8543e39885
• 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
• tui: split remaining composer draft and footer state (#22656)

  ## Why
  
  [#22581](https://github.com/openai/codex/pull/22581) started separating
  the chat composer’s responsibilities, but `ChatComposer` still owned the
  remaining editable draft state alongside footer/status presentation
  state. This follow-up makes those ownership lines explicit so future
  composer changes have a smaller blast radius and `BottomPane` does not
  need to keep exposing scattered draft getters.
  
  This is just a refactor. No functional or behavioral changes are
  intended.
  
  ## What changed
  
  - Move the remaining editable composer state into
  `bottom_pane/chat_composer/draft_state.rs`.
  - Move footer and status-row presentation state into
  `bottom_pane/chat_composer/footer_state.rs`.
  - Add an internal `ComposerDraftSnapshot` for restore flows, replacing
  several ad hoc `BottomPane` pass-through reads.
  - Rewire the related history-search and thread-input restore paths to
  use the extracted state.
  
  ## Verification
  
  - `RUST_MIN_STACK=8388608 cargo test -p codex-tui`
  - `cargo insta pending-snapshots`

  Eric Traut · 2026-05-15 09:12:52 -07:00
  7fa0007ea8
• tui/exec: show effective workspace roots in summaries (#22612)

  ## Why
  
  This PR builds on [#22611](https://github.com/openai/codex/pull/22611).
  
  After `runtimeWorkspaceRoots` moved onto thread state, the user-facing
  summaries were still inconsistent about which roots they showed. In
  particular, `/status` and the exec startup summary could under-report
  extra workspace roots from `--add-dir` or from profile-defined
  `workspace_roots`, which made the new model look incorrect even when the
  permissions themselves were right.
  
  ## What Changed
  
  - switched the TUI status surfaces to summarize against
  `Config::effective_workspace_roots()`
  - updated the exec human-output summary to render from the effective
  permission profile instead of the raw constrained profile
  - added focused regressions for both the TUI and exec code paths so
  extra workspace roots stay visible in user-facing summaries
  
  ## Verification
  
  Targeted coverage for this follow-up lives in:
  - `codex-rs/tui/src/status/tests.rs`
  - `codex-rs/exec/src/event_processor_with_human_output_tests.rs`
  
  The added regressions verify that:
  - status output includes profile-defined workspace roots in the
  effective permissions summary
  - exec startup output includes runtime workspace roots instead of
  collapsing back to `cwd` only

  Michael Bolin · 2026-05-14 23:10:45 -07:00
  8adb6032cc
• 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
• TUI: split history cells into focused modules (#22704)

  ## Why
  
  `codex-rs/tui/src/history_cell.rs` had become the dumping ground for
  transcript rendering: the shared trait, common helpers, and the concrete
  cells for messages, plans, MCP/search, notices, patches, approvals,
  session chrome, and separators all lived together. That made small
  transcript changes require reopening a very large file and made
  ownership less obvious.
  
  ## What changed
  
  - Replaced the monolithic `history_cell.rs` with a `history_cell/`
  module tree organized by concern.
  - Kept the existing `crate::history_cell::*` surface stable through
  re-exports in `history_cell/mod.rs`.
  - Moved the existing render coverage into `history_cell/tests.rs`.
  
  ## Reviewer notes
  
  - This PR is intentionally mechanical in mature — existing code and
  tests moving into files that match their concern.
  - The snapshot files under `codex-rs/tui/src/history_cell/snapshots/`
  moved with the extracted test module. `insta` resolves these unnamed
  snapshots relative to the source file that declares them, so this is
  path churn only; snapshot contents were not updated.
  - The small non-mechanical seam edits are limited to split fallout:
  sibling-module visibility for shared cell containers, moving
  approval-specific exec-snippet helpers beside approvals, fixing the
  separator module path, and keeping a couple of existing test helpers
  reachable after extraction.

  Eric Traut · 2026-05-14 21:19:06 -07:00
  e6a7368810
• Prevent Esc from dismissing or rewinding /side (#22710)

  Addresses #22599
  
  ## Why
  `/side` currently lets `Esc` return to the parent thread. Multiple users
  reported that this collides with queued-steer UI that also advertises
  `Esc`, so a timing-sensitive keypress can dismiss an ephemeral side chat
  instead of sending the queued prompt.
  
  After removing that dismissal shortcut, the same `Esc` path could fall
  through to main-thread backtrack/edit-previous handling, which is not
  valid for ephemeral side conversations. This keeps `/side` out of both
  global `Esc` behaviors.
  
  ## What changed
  - Remove `Esc` from the `/side` return shortcut matcher while keeping
  the existing `Ctrl+C` and `Ctrl+D` behavior.
  - Update side-conversation hints and blocked-command copy to advertise
  `Ctrl+C` as the return shortcut.
  - Rename the reserved `Esc` keymap label to describe backtracking only.
  - Block backtrack/edit-previous handling while a side conversation is
  active and report `Editing previous prompts is unavailable in side
  conversations.` when that path would have fired.
  - Keep composer-owned `Esc` behavior, such as Vim insert-mode escape,
  routed locally.
  - Refresh focused shortcut assertions and TUI snapshots for the updated
  footer and new side-conversation error message.
  
  ## Verification
  Manually tested `/side` use cases and `Esc`, `Ctrl+C`, `Ctrl+D`.

  Eric Traut · 2026-05-14 20:51:08 -07:00
  d1235a0a78
• tui: recover local state db startup failures (#22734)

  ## Why
  
  #22580 made app-server startup fail when the local SQLite state database
  cannot be initialized. Embedded/local TUI startup still continued on the
  permissive path, which left the CLI inconsistent and could hide a real
  startup problem behind unrelated UI. This brings local TUI startup onto
  the same fail-closed behavior while keeping recovery humane for the two
  failure modes we are seeing in practice: damaged database files and
  startup stalls caused by another process holding the database write
  lock.
  
  ## What changed
  
  - Embedded TUI startup now uses `state_db::try_init(...)` and returns a
  typed `LocalStateDbStartupError` that preserves the affected database
  path plus the underlying failure detail.
  - CLI startup handles that failure before entering the interactive TUI:
  - lock-contention failures tell users to quit other Codex processes and
  try again
  - failures consistent with a broken local database offer a safe repair
  that backs up Codex-owned SQLite files, rebuilds local database files,
  and retries startup once
  - declined or unsuccessful repairs print concise guidance plus technical
  details
  - Shared startup error plumbing lives in `tui/src/startup_error.rs`,
  while CLI recovery policy and focused recovery tests live in
  `cli/src/state_db_recovery.rs`.
  
  ## Verification
  
  - `cargo test -p codex-tui
  embedded_state_db_failure_is_typed_for_cli_recovery`
  - `cargo test -p codex-cli state_db_recovery`
  - Manually held an exclusive SQLite lock on `state_5.sqlite` and
  confirmed the CLI shows lock-specific guidance without offering repair.
  - Manually exercised the repair path with a deliberately invalid
  `sqlite_home` and confirmed it backs up the blocking path and resumes
  startup.

  Eric Traut · 2026-05-14 18:51:36 -07:00
  3a23e87e20
• permissions: resolve profile identity with constraints (#22683)

  ## Why
  
  This PR is the invariant-cleanup layer that follows the workspace-roots
  base merged in [#22610](https://github.com/openai/codex/pull/22610).
  
  #22610 adds `[permissions.<id>.workspace_roots]` and keeps runtime
  workspace roots separate from the raw permission profile, but its
  in-memory representation is intentionally transitional: `Permissions`
  still carries the selected profile identity next to a constrained
  `PermissionProfile`. That makes APIs such as
  `set_constrained_permission_profile_with_active_profile()` fragile
  because the id and value only mean the right thing when every caller
  keeps them in sync.
  
  This PR introduces a single resolved profile state so profile identity,
  `extends`, the profile value, and profile-declared workspace roots
  travel together. The next PR,
  [#22611](https://github.com/openai/codex/pull/22611), builds on this by
  changing the app-server turn API to select permission profiles by id
  plus runtime workspace roots.
  
  ## Stack Context
  
  - #22610, now merged: adds profile-declared `workspace_roots`, runtime
  workspace roots, and `:workspace_roots` materialization.
  - This PR: replaces the parallel active-profile/profile-value fields
  with `PermissionProfileState`.
  - #22611: switches app-server turn updates toward profile ids plus
  runtime workspace roots.
  - #22612: updates TUI/exec summaries to show the effective workspace
  roots.
  
  Keeping this separate from #22611 is deliberate: reviewers can validate
  the internal state invariant before reviewing the app-server protocol
  migration.
  
  ## What Changed
  
  - Added `ResolvedPermissionProfile::{Legacy, BuiltIn, Named}` and
  `PermissionProfileState`.
  - Typed built-in profile ids with `BuiltInPermissionProfileId`.
  - Moved selected profile identity and profile-declared workspace roots
  into the resolved state.
  - Replaced `Permissions` parallel profile fields with one
  `permission_profile_state`.
  - Removed `set_constrained_permission_profile_with_active_profile()`
  from session sync paths.
  - Kept trusted session replay/`SessionConfigured` compatibility through
  explicit session snapshot helpers.
  - Updated session configuration, MCP initialization, app-server, exec,
  TUI, and guardian call sites to consume `&PermissionProfile` directly.
  
  ## Review Guide
  
  Start with `codex-rs/core/src/config/resolved_permission_profile.rs`; it
  is the new invariant boundary. Then review
  `codex-rs/core/src/config/mod.rs` to see how config loading records
  active profile identity and profile workspace roots. The remaining
  call-site changes are mostly mechanical fallout from
  `Permissions::permission_profile()` returning `&PermissionProfile`
  instead of `&Constrained<PermissionProfile>`.
  
  ## Verification
  
  The existing config/session coverage now constructs and asserts through
  `PermissionProfileState`. The workspace-root config test also asserts
  that profile-declared roots are preserved in the resolved state, which
  is the behavior #22611 relies on when runtime roots become mutable
  through the app-server API.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/22683).
  * #22612
  * #22611
  * __->__ #22683

  Michael Bolin · 2026-05-14 18:47:44 -07:00
  3c6d727810
• 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
• Fix /review mode MCP startup render issue (#21624)

  This change fixes the case where the UI can sit on _"Starting MCP
  servers"_ even though the review work is already running or has already
  completed.
  
  - MCP startup status header is visible when a `/review` turn starts with
  enabled MCP server startups
  - Restore the underlying _Working..._ status after MCP startup completes
  or fails
  - Add regression coverage for overlapping startup/turn flows and status
  restoration
  
  _De-scoped from a broader thread-scoped MCP status change that would
  have made it easier to route MCP startup statuses to the appropriate
  thread (parent vs. review). These changes address the UI regression
  without requiring more significant changes across app-server & core._
  
  Fixes #18792.

  canvrno-oai · 2026-05-14 17:25:32 -07:00
  66af217865
• Trim TUI legacy core helper usage (#22695)

  ## Why
  
  The TUI still had a few low-risk dependencies flowing through the
  transitional `legacy_core` namespace after the app-server migration.
  These helpers either already have clearer non-core owners or are
  presentation logic that does not belong in `codex-core`, so moving them
  out reduces the compatibility surface without changing product behavior.
  
  ## What changed
  
  This is a low-risk change, almost completely mechanical in nature.
  
  - Route TUI Codex-home lookup through `codex-utils-home-dir`, use
  `Config::log_dir` directly, and call
  `codex-sandboxing::system_bwrap_warning` without going through
  `legacy_core`.
  - Move shared `codex resume` hint formatting from `codex-core` into
  `codex-utils-cli`.
  - Update CLI and TUI call sites to use the shared CLI utility, and keep
  the resume-command behavior covered by tests in its new home.
  
  ## Verification
  
  - `cargo test -p codex-utils-cli`
  - `cargo test -p codex-utils-cli resume_command`

  Eric Traut · 2026-05-14 16:54:59 -07:00
  3dc278b68e
• [codex] Support multiple forced ChatGPT workspaces (#18161)

  ## Summary
  
  This change lets `forced_chatgpt_workspace_id` accept multiple workspace
  IDs instead of a single value.
  
  It keeps the existing config key name, adds backward-compatible parsing
  for a single string in `config.toml`, and normalizes the setting into an
  allowed workspace list across login enforcement, app-server config
  surfaces, and local ChatGPT auth helpers.
  
  ## Why
  
  Workspace-restricted deployments may need to allow more than one ChatGPT
  workspace without dropping the guardrail entirely.
  
  ## Server-side impact
  
  Codex's local server and app-server protocol needed changes because they
  previously assumed a single workspace ID. The local login flow now
  matches the auth backend interface by sending the allowed workspace list
  as a single comma-separated `allowed_workspace_id` query parameter.
  
  ## Validation
  
  This was tested with:
  
  - A single workspace config
  - With multi-workspace configs
  - With multiple workspaces in the config
  - The user only being a part of a subset of them
  
  All were successful.
  
  Automated coverage:
  
  - `cargo test -p codex-login`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-tui local_chatgpt_auth`
  - `cargo test --locked -p codex-app-server
  login_account_chatgpt_includes_forced_workspace_allowlist_query_param`

  rreichel3-oai · 2026-05-14 17:11:36 -04:00
  02a7205250
• fix(tui): render network approval history by target (#22229)

  ## Why
  
  Network approval prompts are rendered without a command string on the
  app-server path. After the user approves one of those prompts, the TUI
  history cell previously fell back to command-oriented copy and produced
  malformed lines such as:
  
  ```text
  You approved codex to run  every time this session
  ```
  
  That hid the network target the user actually approved and left a
  visibly broken transcript entry.
  
  ## What changed
  
  - Preserve the approval subject as either a command or a network target
  when recording TUI approval decisions.
  - Render target-aware history copy for network approval outcomes:
    - approve once
    - approve for the current session
    - cancel
  - Include the approval protocol and preserve the managed-proxy
  `network-access` target when present, including non-default ports such
  as `https://example.com:8443`.
  - Fall back to formatting the network approval context as
  `protocol://host` when no generated target command is available.
  - Keep ordinary command approval history, Guardian approval history, and
  persisted network-rule history behavior unchanged.
  - Add focused regression coverage and snapshots for the three
  network-history cases.
  
  ## How to Test
  
  1. Start Codex in a flow that triggers a network approval prompt.
  2. Approve network access only for the current conversation.
  3. Confirm the transcript records the approved network target, for
  example:
  - `You approved codex network access to https://example.com:8443 every
  time this session`
  4. Trigger the prompt again and verify the one-time approval and cancel
  paths also record target-specific history text instead of an empty
  command gap.
  
  Targeted automated coverage:
  - `cargo test -p codex-tui network_exec_approval_history`
  
  ## Additional verification
  
  - `cargo insta pending-snapshots`
  - `git diff --check`
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  
  ## Known unrelated local test noise
  
  A full `cargo test -p codex-tui` run still hits a pre-existing stack
  overflow outside this change:
  - `tests::fork_last_filters_latest_session_by_cwd_unless_show_all`
  aborts with a stack overflow

  Felipe Coury · 2026-05-14 14:33:54 -03:00
  5a02962519
• tui: split composer attachment and popup state (#22581)

  ## Why
  
  `ChatComposer` currently owns text editing alongside attachment
  bookkeeping and popup lifecycle state, while `BottomPane` still triggers
  a couple of popup resyncs after composer methods that already do that
  work internally. That blurs the ownership boundary and makes the
  composer harder to simplify safely.
  
  This PR is part 1 of a two-part cleanup. It peels off the composer state
  that can move cleanly on its own, so the follow-up can tackle the
  heavier draft/editing boundary without mixing every concern into one
  diff.
  
  ## What changed
  
  - Move local and remote image bookkeeping, placeholder relabeling, and
  remote-image keyboard selection into `AttachmentState`.
  - Move active-popup and popup-dismissal/query bookkeeping into
  `PopupState`.
  - Update composer and history-search paths to use those state owners
  directly.
  - Remove redundant `BottomPane` popup synchronization after paste
  handling and `insert_str`.
  
  ## Part 2
  
  The follow-up PR will finish the cleanup around the remaining composer
  boundary: split out the draft/editing-oriented state and footer/status
  presentation concerns that still live in `ChatComposer`, then revisit
  the leftover `BottomPane` pass-throughs once those ownership lines are
  explicit. The goal is for `ChatComposer` to coordinate a few focused
  collaborators instead of continuing to be the landing zone for every
  input-path concern.
  
  ## Verification
  
  Did manual smoke tests.

  Eric Traut · 2026-05-14 09:04:27 -07:00
  a5040d0b39
• 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
• feat: add layered --profile-v2 config files (#17141)

  ## Why
  
  `--profile-v2 <name>` gives launchers and runtime entry points a named
  profile config without making each profile duplicate the base user
  config. The base `$CODEX_HOME/config.toml` still loads first, then
  `$CODEX_HOME/<name>.config.toml` layers above it and becomes the active
  writable user config for that session.
  
  That keeps shared defaults, plugin/MCP setup, and managed/user
  constraints in one place while letting a named profile override only the
  pieces that need to differ.
  
  ## What Changed
  
  - Added the shared `--profile-v2 <name>` runtime option with validated
  plain names, now represented by `ProfileV2Name`.
  - Extended config layer state so the base user config and selected
  profile config are both `User` layers; APIs expose the active user layer
  and merged effective user config.
  - Threaded profile selection through runtime entry points: `codex`,
  `codex exec`, `codex review`, `codex resume`, `codex fork`, and `codex
  debug prompt-input`.
  - Made user-facing config writes go to the selected profile file when
  active, including TUI/settings persistence, app-server config writes,
  and MCP/app tool approval persistence.
  - Made plugin, marketplace, MCP, hooks, and config reload paths read
  from the merged user config so base and profile layers both participate.
  - Updated app-server config layer schemas to mark profile-backed user
  layers.
  
  ## Limits
  
  `--profile-v2` is still rejected for config-management subcommands such
  as feature, MCP, and marketplace edits. Those paths remain tied to the
  base `config.toml` until they have explicit profile-selection semantics.
  
  Some adjacent background writes may still update base or global state
  rather than the selected profile:
  
  - marketplace auto-upgrade metadata
  - automatic MCP dependency installs from skills
  - remote plugin sync or uninstall config edits
  - personality migration marker/default writes
  
  ## Verification
  
  Added targeted coverage for profile name validation, layer
  ordering/merging, selected-profile writes, app-server config writes,
  session hot reload, plugin config merging, hooks/config fixture updates,
  and MCP/app approval persistence.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-14 15:16:15 +02:00
  deedf3b2c4
• Defer startup NUX impressions until startup succeeds (#22587)

  ## Why
  
  This is a follow-up to #22573. This problem was surfaced in a code
  review comment that I missed before merging the previous PR.
  
  Fresh-session startup could prepare a model-availability NUX before
  `app_server.start_thread(&config)` completed. If thread startup then
  failed, the TUI never rendered the tooltip, but
  `prepare_startup_tooltip_override(...)` had already persisted one of the
  limited impressions.
  
  ## What Changed
  
  - Move startup tooltip preparation inside the fresh-thread startup
  branch, after `start_thread(...)` succeeds.
  - Keep resume/fork paths unchanged.
  - Remove the now-redundant
  `should_prepare_startup_tooltip_override(...)` helper and its gate test.

  Eric Traut · 2026-05-13 21:03:19 -07:00
  6a225e4005
• Simplify TUI startup test coverage (#22573)

  ## Why
  
  The TUI startup test surface had drifted into expensive, brittle
  coverage:
  
  - `tui/tests/suite/no_panic_on_startup.rs` was already ignored as flaky
  while still spawning a PTY to exercise malformed exec-policy rules.
  - `tui/tests/suite/model_availability_nux.rs` used a seeded session,
  cursor-query spoofing, and repeated interrupts to verify a narrow
  resume-path invariant.
  - `app/tests.rs` had started accumulating unrelated startup and summary
  coverage in one flat module even after the surrounding app code was
  split into feature modules.
  
  This keeps those behaviors covered while making the tests cheaper to
  understand and less likely to rot. It also preserves the malformed-rules
  regression from #8803 without requiring a terminal orchestration test.
  
  ## What changed
  
  - Replaced the malformed `rules` startup PTY case with a direct
  exec-policy loader regression:
  
  [`rules_path_file_returns_read_dir_error`](https://github.com/openai/codex/blob/21b6b5622f18b8cac0ea41fd083b3106778d9ffc/codex-rs/core/src/exec_policy_tests.rs#L264-L284)
  - Made the existing fresh-session-only startup tooltip behavior explicit
  with
  
  [`should_prepare_startup_tooltip_override`](https://github.com/openai/codex/blob/21b6b5622f18b8cac0ea41fd083b3106778d9ffc/codex-rs/tui/src/app/thread_routing.rs#L1272-L1279),
  then added focused coverage for the resume/fork gate and the persisted
  NUX counter.
  - Split startup and session-summary coverage out of
  `tui/src/app/tests.rs` into dedicated modules so the test layout better
  mirrors the current app architecture.
  - Converted one single-message goal validation snapshot into semantic
  assertions where layout was not the behavior under test.
  - Removed the two PTY-heavy suite files that the narrower tests now
  supersede.
  
  ## Verification
  
  - `cargo test -p codex-core rules_path_file_returns_read_dir_error`
  - `cargo test -p codex-tui startup_`
  - `cargo test -p codex-tui session_summary_`
  - `cargo test -p codex-tui
  goal_slash_command_rejects_oversized_objective`

  Eric Traut · 2026-05-13 18:16:54 -07:00
  35451ba79c
• Refactor chatwidget orchestration into modules (phase 5) (#22537)

  ## Why
  
  `chatwidget.rs` is still carrying too many unrelated responsibilities in
  one file. #22269 started a five-phase cleanup to move coherent behavior
  domains into focused modules while keeping `chatwidget.rs` as the
  composition layer. #22407 completed phase 2 by extracting input and
  submission flow, #22433 completed phase 3 by extracting protocol,
  replay, streaming, and tool lifecycle handling, and #22518 completed
  phase 4 by extracting settings, popups, and status surfaces.
  
  This PR is phase 5. It cleans up the remaining constructor and
  orchestration code now that the larger behavior domains have moved out,
  leaving `chatwidget.rs` much closer to the composition layer the cleanup
  was aiming for. This is once again a mechanical movement of existing
  functions. No functional changes.
  
  ## What Changed
  
  - Added focused modules for widget construction and initial wiring,
  session configuration flow, key/composer interaction routing, review
  popup orchestration, desktop notification coalescing, and render
  composition.
  - Moved the remaining constructor, session setup, interaction,
  notification, review picker, and rendering helpers out of
  `codex-rs/tui/src/chatwidget.rs`.
  - Preserved the existing startup/session behavior, keyboard handling,
  review picker flow, notification priority behavior, and render
  composition while shrinking the central widget module substantially.
  - Left `codex-rs/tui/src/chatwidget.rs` as the registration and
  composition surface for the extracted behavior modules.
  
  ## Cleanup Phases
  
  The five-phase cleanup plan from #22269 is:
  
  1. Phase 1: mechanical helper and state moves. Completed in #22269.
  2. Phase 2: extract input and submission flow, including queued user
  messages, shell prompt submission, pending steer restoration, and thread
  input snapshot/restore behavior. Completed in #22407.
  3. Phase 3: extract protocol, replay, streaming, and tool lifecycle
  handling, while preserving active-cell grouping, transcript
  invalidation, interrupt deferral, and final-message separator behavior.
  Completed in #22433.
  4. Phase 4: extract settings, popups, and status surfaces, including
  model/reasoning/collaboration/personality popups, permission prompts,
  rate-limit UI, and connectors helpers. Completed in #22518.
  5. Phase 5: clean up the remaining constructor and orchestration code
  once the larger behavior domains have moved out, leaving `chatwidget.rs`
  as the composition layer. This PR.
  
  ## Verification
  
  - `cargo check -p codex-tui`
  - `cargo test -p codex-tui chatwidget::tests::popups_and_settings`
  - `cargo test -p codex-tui chatwidget::tests::plan_mode`
  - `cargo test -p codex-tui chatwidget::tests::review_mode`
  - `cargo test -p codex-tui chatwidget::tests::status_and_layout`
  
  `cargo test -p codex-tui` also compiles and begins running, but aborts
  in the unchanged app-side test
  `app::tests::discard_side_thread_keeps_local_state_when_server_close_fails`
  with the same reproducible stack overflow noted in phase 4.

  Eric Traut · 2026-05-13 15:40:53 -07:00
  3c3e18c222
• Remove resurrected /collab slash command (#22535)

  ## Summary
  `/collab` was intentionally removed in
  [#12012](https://github.com/openai/codex/pull/12012), but the
  TUI/app-server migration accidentally brought that slash-command path
  back. This restores the earlier product decision so the TUI no longer
  advertises or dispatches `/collab`. This command was redundant because
  it did the same thing as `/plan` but in a less-intuitive way.
  
  ## What Changed
  - Remove `SlashCommand::Collab` from the TUI slash-command surface.
  - Delete the picker and app-event plumbing that only existed to service
  `/collab`.
  - Remove obsolete TUI test coverage for the deleted picker flow.

  Eric Traut · 2026-05-13 15:40:37 -07:00
  efdcbba053
• feat(cli): add codex doctor diagnostics (#22336)

  ## Why
  
  Users and support need a single command that captures the local Codex
  runtime, configuration, auth, terminal, network, and state shape without
  asking the user to know which diagnostic depth to choose first. `codex
  doctor` now runs the useful checks by default and makes the detailed
  human output the default because the command is usually run when someone
  already needs context.
  
  The command also targets concrete support failure modes we have seen
  while iterating on the design:
  
  - update-target mismatches like #21956, where the installed package
  manager target can differ from the running executable
  - terminal and multiplexer issues that depend on `TERM`, tmux/zellij
  state, color handling, and TTY metadata
  - provider-specific HTTP/WebSocket connectivity, including ChatGPT
  WebSocket handshakes and API-key/provider endpoint reachability
  - local state/log SQLite integrity problems and large rollout
  directories
  - feedback reports that need an attached, redacted diagnostic snapshot
  without asking the user to run a second command
  
  ## What Changed
  
  - Adds `codex doctor` as a grouped CLI diagnostic report with default
  detailed output and `--summary` for the compact view.
  - Adds stable report sections for Environment, Configuration, Updates,
  Connectivity, and Background Server, plus a top Notes block that
  promotes anomalies such as available updates, large rollout directories,
  optional MCP issues, and mixed auth signals.
  - Adds runtime provenance, install consistency, bundled/system search
  readiness, terminal/multiplexer metadata, `config.toml` parse status,
  auth mode details, sandbox details, feature flag summaries, update
  cache/latest-version state, app-server daemon state, SQLite integrity
  checks, rollout statistics, and provider-aware network diagnostics.
  - Adds ChatGPT WebSocket diagnostics that report the negotiated HTTP
  upgrade as `HTTP 101 Switching Protocols` and include timeout, DNS,
  auth, and provider context in detailed output.
  - Makes reachability provider-aware: API-key OpenAI setups check the API
  endpoint, ChatGPT auth checks the ChatGPT path, and custom/AWS/local
  providers check configured HTTP endpoints when available.
  - Adds structured, redacted JSON output where `checks` is keyed by check
  id and `details` is a key/value object for support tooling.
  - Integrates doctor with feedback uploads by attaching a best-effort
  `codex-doctor-report.json` report and adding derived Sentry tags for
  overall status and failing/warning checks.
  - Updates the TUI feedback consent copy so users can see that the doctor
  report is included when logs/diagnostics are uploaded.
  - Updates the CLI bug issue template to ask reporters for `codex doctor
  --json` and render pasted reports as JSON.
  
  ## Example Output
  
  The examples below are sanitized from local smoke runs with `--no-color`
  so the structure is reviewable in plain text.
  
  ### `codex doctor`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
        version                  0.0.0
        install method           other
        commit                   unknown
        executable               ~/code/codex.fcoury-doct…x-rs/target/debug/codex
    ✓ install      consistent
        context                  other
        managed by               npm: no · bun: no · package root —
        PATH entries (2)         ~/.local/share/mise/installs/node/24/bin/codex
                                 ~/.local/share/mise/shims/codex
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
        terminal                 Ghostty
        TERM_PROGRAM             ghostty
        terminal version         1.3.2-main-+b0f827665
        TERM                     xterm-256color
        multiplexer              tmux 3.6a
        tmux extended-keys       on
        tmux allow-passthrough   on
        tmux set-clipboard       on
    ✓ state        databases healthy
        CODEX_HOME               ~/.codex (dir)
        state DB                 ~/.codex/state_5.sqlite (file) · integrity ok
        log DB                   ~/.codex/logs_2.sqlite (file) · integrity ok
        active rollouts          1,526 files · 2.53 GB (avg 1.70 MB)
        archived rollouts        8 files · 3.84 MB (avg 491.11 KB)
  
  Configuration
    ✓ config       loaded
        model                    gpt-5.5 · openai
        cwd                      ~/code/codex.fcoury-doctor/codex-rs
        config.toml              ~/.codex/config.toml
        config.toml parse        ok
        MCP servers              1
        feature flags            36 enabled · 7 overridden (full list with --all)
        overrides                code_mode, code_mode_only, memories, chronicle, goals, remote_control, prevent_idle_sleep
    ✓ auth         auth is configured
        auth storage mode        File
        auth file                ~/.codex/auth.json
        auth env vars present    OPENAI_API_KEY
        stored auth mode         chatgpt
        stored API key           false
        stored ChatGPT tokens    true
        stored agent identity    false
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
        configured servers       1
        disabled servers         0
        streamable_http servers  1
        optional reachability    openaiDeveloperDocs: https://developers.openai.com/mcp (HEAD connect failed; GET connect failed)
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
        approval policy          OnRequest
        filesystem sandbox       restricted
        network sandbox          restricted
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
        model provider           openai
        provider name            OpenAI
        wire API                 responses
        supports websockets      true
        connect timeout          15000 ms
        auth mode                chatgpt
        endpoint                 wss://chatgpt.com/backend-api/<redacted>
        DNS                      2 IPv4, 2 IPv6, first IPv6
        handshake result         HTTP 101 Switching Protocols
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
        reachability mode        API key auth
        openai API               https://api.openai.com/v1 connect failed (required)
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  --summary compact output           --all expand truncated lists
  --json redacted report
  ```
  
  ### `codex doctor --summary`
  
  ```text
  Codex Doctor v0.0.0 · macos-aarch64
  
  Notes
     ↑ updates      0.130.0 available (current 0.0.0, dismissed 0.128.0)
     ⚠ rollouts     1,526 active files · 2.53 GB on disk
     ⚠ mcp          MCP configuration has optional issues
     ⚠ auth         mixed auth signals: ChatGPT login plus API key env var; HTTP reachability uses API-key mode
  ─────────────────────────────────────────────────────────────
  
  Environment
    ✓ runtime      local debug build
    ✓ install      consistent
    ✓ search       ripgrep 15.1.0 (system, `rg`)
    ✓ terminal     Ghostty 1.3.2-main-+b0f827665 · tmux 3.6a · TERM=xterm-256color
    ✓ state        databases healthy
  
  Configuration
    ✓ config       loaded
    ✓ auth         auth is configured
    ⚠ mcp          MCP configuration has optional issues — Set the missing MCP env vars or disable the affected server.
    ✓ sandbox      restricted fs + restricted network · approval OnRequest
  
  Updates
    ✓ updates      update configuration is locally consistent
  
  Connectivity
    ✓ network      network-related environment looks readable
    ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
    ✗ reachability one or more required provider endpoints are unreachable over HTTP — Check proxy, VPN, firewall, DNS, and custom CA configuration.
  
  Background Server
    ○ app-server   not running (ephemeral mode)
  
  ─────────────────────────────────────────────────────────────
  11 ok · 1 idle · 4 notes · 1 warn · 1 fail failed
  
  Run codex doctor without --summary for detailed diagnostics.
  --all expand truncated lists       --json redacted report
  ```
  
  ### `codex doctor --json` shape
  
  ```json
  {
    "schema_version": 1,
    "overall_status": "fail",
    "checks": {
      "runtime.provenance": {
        "id": "runtime.provenance",
        "category": "Environment",
        "status": "ok",
        "summary": "local debug build",
        "details": {
          "version": "0.0.0",
          "install method": "other",
          "commit": "unknown"
        }
      },
      "sandbox.helpers": {
        "id": "sandbox.helpers",
        "category": "Configuration",
        "status": "ok",
        "summary": "restricted fs + restricted network · approval OnRequest",
        "details": {
          "approval policy": "OnRequest",
          "filesystem sandbox": "restricted",
          "network sandbox": "restricted"
        }
      }
    }
  }
  ```
  
  ### `/feedback` new sentry attachment
  
  <img width="938" height="798" alt="CleanShot 2026-05-13 at 15 36 14"
  src="https://github.com/user-attachments/assets/715e62e0-d7b4-4fea-a35a-fd5d5d33c4c0"
  />
  
  ### New section in CLI issue template
  
  <img width="1164" height="435" alt="CleanShot 2026-05-13 at 15 47 24"
  src="https://github.com/user-attachments/assets/9081dc25-a28c-4afa-8ba1-e299c2b4031d"
  />
  
  ## How to Test
  
  1. Run `cargo run --bin codex -- doctor --no-color`.
  2. Confirm the detailed report is the default and includes promoted
  Notes, grouped sections, terminal details, state DB integrity, rollout
  stats, provider reachability, WebSocket diagnostics, and app-server
  status.
  3. Run `cargo run --bin codex -- doctor --summary --no-color`.
  4. Confirm the compact view keeps the same sections and summary counts
  but omits detailed key/value rows.
  5. Run `cargo run --bin codex -- doctor --json`.
  6. Confirm the output is redacted JSON, `checks` is an object keyed by
  check id, and each check's `details` is a key/value object.
  7. Preview the CLI bug issue template and confirm the `Codex doctor
  report` field appears after the terminal field, asks for `codex doctor
  --json`, and renders pasted output as JSON.
  8. Start a feedback flow that includes logs.
  9. Confirm the upload consent copy lists `codex-doctor-report.json`
  alongside the log attachments.
  
  Targeted tests:
  
  - `cargo test -p codex-cli doctor`
  - `cargo test -p codex-app-server
  doctor_report_tags_summarize_status_counts`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-tui feedback_view`
  - `just argument-comment-lint`
  - `git diff --check`

  Felipe Coury · 2026-05-13 21:23:19 +00:00
  9798eb377a
• [codex] Fix TUI wrapping for external borrowed slices (#21235)

  Fixes #20587, reported by @noeljackson.
  
  This prevents the TUI wrapping code from panicking when `textwrap`
  returns a borrowed slice that does not point into the original source
  text. The fix follows the direction proposed by @misrtjakub in the issue
  comment: validate the borrowed slice pointer range first, and fall back
  to the existing owned-line mapper when the slice is external.
  
  - Guards borrowed wrapped slices before converting pointer offsets into
  byte ranges.
  - Reuses the existing owned-line range recovery path for external
  borrowed slices.
  - Adds coverage for rejecting borrowed slices outside the source text.
  
  End-user testing steps:
  - Start Codex in TUI mode under a PTY wrapper that can inject stdin
  after startup.
  - Inject `\x1b[200~test message\x1b[201~\r` after the TUI is ready.
  - Confirm Codex does not panic and the pasted text is handled normally.
  
  Local validation:
  - `cargo test -p codex-tui wrapping::tests::`
  - `cargo test -p codex-tui -- --skip
  status::tests::status_permissions_full_disk_managed_with_network_is_danger_full_access
  --skip
  status::tests::status_permissions_full_disk_managed_without_network_is_external_sandbox`

  canvrno-oai · 2026-05-13 14:19:05 -07:00
  5d7e6a2503
• Use plugin/list to get list of plugins for mentions (#22375)

  This switches TUI plugin mentions to use app-server `plugin/list` for
  plugin inventory and metadata instead of `PluginManager`, while keeping
  the same mention-eligibility filters as before.
  
  Same filters as before:
  - Only plugins in the current config / cwd scope.
  - Only installed and enabled plugins.
  - Only plugins that actually expose a capability, meaning at least one
  skill, MCP server, or app connector.
  - Uses `plugin/list` for the mention names/descriptions

  canvrno-oai · 2026-05-13 14:11:10 -07:00
  16592f593d
• Refactor chatwidget settings surfaces into modules (phase 4) (#22518)

  ## Why
  
  `chatwidget.rs` is still carrying too many unrelated responsibilities in
  one file. #22269 started a five-phase cleanup to move coherent behavior
  domains into focused modules while keeping `chatwidget.rs` as the
  composition layer. #22407 completed phase 2 by extracting input and
  submission flow, and #22433 completed phase 3 by extracting protocol,
  replay, streaming, and tool lifecycle handling.
  
  This PR is phase 4. It keeps moving high-churn UI coordination out of
  the central widget by extracting settings, popups, and status surfaces
  without changing the visible behavior those flows already provide. This
  is once again a mechanical movement of existing functions. No functional
  changes.
  
  ## What Changed
  
  - Added focused modules for runtime settings/model coordination,
  model/reasoning/collaboration popups,
  settings/personality/theme/audio/experimental popups, permission
  prompts, status setup/output controls, and Windows sandbox prompt flows.
  - Moved the remaining rate-limit nudge/status helpers and connectors
  popup/loading/update helpers into their existing focused modules.
  - Preserved the existing picker flows, approval behavior, status/title
  setup previews, rate-limit notices, and connectors/app list behavior
  while shrinking `chatwidget.rs` back toward orchestration.
  - Left `codex-rs/tui/src/chatwidget.rs` as the registration and
  composition surface for these extracted behaviors.
  
  ## Cleanup Phases
  
  The five-phase cleanup plan from #22269 is:
  
  1. Phase 1: mechanical helper and state moves. Completed in #22269.
  2. Phase 2: extract input and submission flow, including queued user
  messages, shell prompt submission, pending steer restoration, and thread
  input snapshot/restore behavior. Completed in #22407.
  3. Phase 3: extract protocol, replay, streaming, and tool lifecycle
  handling, while preserving active-cell grouping, transcript
  invalidation, interrupt deferral, and final-message separator behavior.
  Completed in #22433.
  4. Phase 4: extract settings, popups, and status surfaces, including
  model/reasoning/collaboration/personality popups, permission prompts,
  rate-limit UI, and connectors helpers. This PR.
  5. Phase 5: clean up the remaining constructor and orchestration code
  once the larger behavior domains have moved out, leaving `chatwidget.rs`
  as the composition layer.
  
  ## Verification
  
  - `cargo check -p codex-tui`
  - `cargo test -p codex-tui chatwidget::tests::permissions`
  - `cargo test -p codex-tui chatwidget::tests::status_surface_previews`
  - `cargo test -p codex-tui chatwidget::tests::popups_and_settings`
  - `cargo test -p codex-tui chatwidget::tests::status_and_layout`
  
  `cargo test -p codex-tui` also compiles and begins running, but aborts
  in the unchanged app-side test
  `app::tests::discard_side_thread_keeps_local_state_when_server_close_fails`
  with a reproducible stack overflow.

  Eric Traut · 2026-05-13 11:26:37 -07:00
  1ae811ddb2
• 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
• Refactor chatwidget protocol flows into modules (phase 3) (#22433)

  ## Why
  
  `chatwidget.rs` is still carrying too many unrelated responsibilities in
  one file. #22269 started a five-phase cleanup to move coherent behavior
  domains into focused modules while keeping `chatwidget.rs` as the
  composition layer. #22407 completed phase 2 by extracting input and
  submission flow.
  
  This PR is phase 3. It keeps moving high-churn event handling out of the
  central widget by extracting protocol, replay, streaming, and tool
  lifecycle handling without changing the visible behavior those flows
  already provide. This is once again just a mechanical movement of
  existing functions. No functional changes.
  
  ## What Changed
  
  - Added focused modules for protocol request dispatch, replay rendering,
  assistant/plan/reasoning streaming, turn runtime bookkeeping, hook
  lifecycle handling, command lifecycle handling, tool lifecycle
  rendering, and interactive tool request prompts.
  - Kept active-cell grouping, transcript invalidation, interrupt
  deferral, and final-message separator behavior in the same flows, just
  moved into smaller files.
  - Added module header comments to the new files so the ownership
  boundaries are explicit.
  - Left `codex-rs/tui/src/chatwidget.rs` as the registration and
  orchestration surface for these extracted behaviors.
  
  ## Cleanup Phases
  
  The five-phase cleanup plan from #22269 is:
  
  1. Phase 1: mechanical helper and state moves. Completed in #22269.
  2. Phase 2: extract input and submission flow, including queued user
  messages, shell prompt submission, pending steer restoration, and thread
  input snapshot/restore behavior. Completed in #22407.
  3. Phase 3: extract protocol, replay, streaming, and tool lifecycle
  handling, while preserving active-cell grouping, transcript
  invalidation, interrupt deferral, and final-message separator behavior.
  This PR.
  4. Phase 4: extract settings, popups, and status surfaces, including
  model/reasoning/collaboration/personality popups, permission prompts,
  rate-limit UI, and connectors helpers.
  5. Phase 5: clean up the remaining constructor and orchestration code
  once the larger behavior domains have moved out, leaving `chatwidget.rs`
  as the composition layer.

  Eric Traut · 2026-05-13 08:52:56 -07:00
  8fe0ecb045
• feat(tui): standardize picker navigation keys (#22347)

  ## Why
  
  Picker-style UI in the TUI has accumulated a mix of hardcoded navigation
  keys. Some lists supported page movement, some did not; some accepted
  Vim-like keys, while others only accepted arrows; and tabbed or
  horizontally adjustable pickers had no shared keymap action for
  left/right movement.
  
  This PR makes picker/list navigation consistent and configurable so
  users can rely on the same defaults across the TUI.
  
  ## What Changed
  
  - Adds shared list keymap actions for:
    - vertical movement: `move_up`, `move_down`
    - horizontal movement: `move_left`, `move_right`
    - paging and jumps: `page_up`, `page_down`, `jump_top`, `jump_bottom`
  - Adds defaults:
  - Up/down: arrows, `Ctrl+P/N`, `Ctrl+K/J`, and plain `k/j` where text
  input is not active
    - Page up/down: `PageUp/PageDown` and `Ctrl+B/F`
    - First/last: `Home/End`
    - Left/right: `Left/Right` and `Ctrl+H/L`
  - Wires the shared list keymap through picker and list surfaces
  including session resume, multi-select, tabbed selection lists,
  settings-style lists, app-link selection, MCP elicitation,
  request-user-input, and the OSS selection wizard.
  - Keeps search behavior intact by reserving printable characters for
  query text in searchable pickers.
  - Updates keymap setup actions, config schema, snapshots, and focused
  coverage for the new list actions.
  
  ## How to Test
  
  1. Start Codex from this branch and open the session picker, for example
  with an existing session history.
  2. In the session list, verify that `Ctrl+J/K` moves the selection
  down/up.
  3. Verify that `Ctrl+F/B` pages down/up and `Home/End` jumps to the
  first/last visible session.
  4. Type printable search text such as `j` or `k` and confirm it updates
  the query instead of navigating.
  5. Focus a picker control that changes values horizontally, such as a
  session picker toolbar control, and verify `Ctrl+H/L` changes the
  focused value like left/right arrows.
  
  Targeted tests run:
  
  - `cargo test -p codex-tui keymap::tests::`
  - `cargo test -p codex-tui keymap_setup::tests::`
  - `cargo test -p codex-tui horizontal_list_keys`
  - `cargo test -p codex-tui page_and_jump_navigation_use_list_keymap`
  - `cargo test -p codex-tui ctrl_h_l_move_provider_selection`
  - `cargo test -p codex-tui scroll_state::tests`
  - `cargo test -p codex-tui
  switching_tabs_changes_visible_items_and_clears_search`
  - `cargo test -p codex-tui toggle_sort_key_reloads_with_new_sort`
  
  Also ran `just write-config-schema`, `just fmt`, `just fix -p
  codex-tui`, `just argument-comment-lint`, and `git diff --check`.
  
  Note: `cargo test -p codex-tui` was attempted and still aborts in the
  pre-existing
  `tests::fork_last_filters_latest_session_by_cwd_unless_show_all` stack
  overflow, which is unrelated to this branch.

  Felipe Coury · 2026-05-13 15:33:27 +00:00
  3d517fbd00