229 Commits

• TUI Plugin Sharing 5 - polish remote plugin catalog rows (#26705)

  This is the final plugin sharing PR in the 5-PR stack. It applies the
  remaining TUI polish for remote plugin catalog rows and tabs:
  admin-disabled plugins now read as blocked/view-only instead of looking
  toggleable, admin-installed/default-installed plugins count and sort
  like installed plugins, plugin search matches richer metadata, and an
  empty successful `Shared with me` section stays hidden.
  
  - Admin-disabled rows use a blocked marker, show `Disabled`, and keep
  Enter-only detail behavior without a toggle hint.
  - Admin-installed/default-installed plugins show as installed in counts,
  ordering, tabs, and detail copy.
  - Plugin search now matches descriptions and keywords in addition to
  existing row metadata.
  - Successful-empty `Shared with me` tabs are hidden, while loading,
  error, workspace-empty, and real shared-plugin states remain visible.
  - Updates coverage in
  `plugins_popup_snapshot_shows_all_marketplaces_and_sorts_installed_then_name`,
  `plugins_popup_admin_disabled_installed_plugin_has_no_toggle_hint`,
  `plugins_popup_search_matches_plugin_descriptions`, and
  `plugins_popup_remote_section_fallback_states_snapshot`.
  - Updates snapshots `plugins_popup_curated_marketplace` and
  `plugins_popup_empty_shared_section_hidden`.
  
  
  <img width="2034" height="106" alt="image"
  src="https://github.com/user-attachments/assets/3f9a57e1-edd8-4e6c-b0b0-9f632a3c9529"
  />
  <img width="2038" height="380" alt="image"
  src="https://github.com/user-attachments/assets/45a47491-3381-4846-a13d-496bc0051d42"
  />

  canvrno-oai · 2026-06-24 18:48:11 -07:00
  a0d5fd772e
• Pause active goals before TUI interrupts (#28813)

  Fixes #28104.
  
  ## Summary
  Active `/goal` turns should leave the persisted goal paused whenever the
  TUI interrupts the running turn. The bug in #28104 showed this most
  visibly through `Esc`: some interrupt paths aborted the turn without
  updating the goal status, so the goal could remain active and continue
  automatically.
  
  This change makes `ChatWidget` pause an active goal before the TUI sends
  an interrupt from the status-row path, the pending-steer path, `Ctrl+C`,
  or a request-user-input overlay. The modal overlay now reports whether a
  key will interrupt the turn, which keeps modal `Esc` and `Ctrl+C`
  behavior aligned with the normal interrupt paths.
  
  ## Manual Testing
  Built the local CLI with `just codex --help`, then launched the local
  TUI with goals enabled. Started an active `/goal` turn and interrupted
  it with `Esc`, then resumed and repeated with `Ctrl+C`; both paths
  showed `Goal paused`, the interrupted-conversation message, and the
  `Goal paused (/goal resume)` footer. I also stopped the background
  terminal and exited the TUI cleanly after the run.
  
  I did not find a reliable standalone manual path to force the
  request-user-input overlay case, so that path is covered by the focused
  automated test.

  Eric Traut · 2026-06-18 08:48:03 -07:00
  07298a948c
• Scope command approvals by execution environment (#28738)

  ## Why
  
  Command approval cache keys included the command and working directory,
  but not the execution environment. An approval for `/workspace` locally
  could therefore be reused for the same command and path on an executor.
  
  ## What changed
  
  - Include the selected environment ID in shell and unified-exec approval
  cache keys.
  - Carry that ID through the normal command approval request so clients
  can show which environment is being approved.
  - Expose the environment through app-server as a required nullable
  `environmentId` and show it in the inline TUI approval prompt.
  - Keep older recorded approval events compatible when the environment is
  absent.
  
  For example, `echo ok` in local `/workspace` and `echo ok` in executor
  `/workspace` now produce different approval keys and separate prompts.
  
  ## Scope
  
  This PR does not change network approvals, Guardian review actions, MCP
  elicitation, full-screen TUI rendering, or environment-ID validation.
  Remote `shell_command` execution itself remains in #28722; this PR only
  makes its approval key environment-aware.

  jif · 2026-06-17 19:52:43 +02:00
  1391d786bc
• feat(tui): add rate-limit reset redemption to /usage (#28154)

  ## Why
  
  Codex users can earn personal rate-limit reset credits, but the CLI does
  not currently provide a way to view or redeem them. The `/usage` command
  restored in #27925 is intended to be the entry point for usage-related
  actions, so reset redemption belongs there rather than in a separate
  dashed slash command.
  
  Depends on #28143 for the app-server and backend-client reset-credit
  APIs.
  
  ## What changed
  
  - Turn bare `/usage` into a menu with entries for token activity and
  earned rate-limit resets while preserving `/usage daily`, `/usage
  weekly`, and `/usage cumulative`.
  - Add loading, empty, confirmation, success, retry, and error states
  with a caller-generated UUID idempotency key reused across retries of
  the same logical reset.
  - Show an availability hint only for backend-classified rate-limit
  errors with credits available.
  - Hide the reset entry for workspace accounts.
  
  ## Validation
  
  - `just test -p codex-tui chatwidget::tests::usage` — 19 passed.
  - `just fix -p codex-tui` — passed.
  - `just fmt` — passed.
  - `cargo insta pending-snapshots` from `codex-rs/tui` — no pending
  snapshots.
  
  ## Examples
  <img width="1168" height="304" alt="image"
  src="https://github.com/user-attachments/assets/caa4c1e3-e996-494d-ae17-50b521f5dce8"
  />
  <img width="908" height="260" alt="image"
  src="https://github.com/user-attachments/assets/e38a726b-77cc-4bd0-9ea8-9f3ad21c5768"
  />
  
  
  ### Reset flow
  <img width="1509" height="312" alt="image"
  src="https://github.com/user-attachments/assets/d987013c-78a5-48a2-ad8d-c61ad267a327"
  />
  <img width="585" height="190" alt="image"
  src="https://github.com/user-attachments/assets/de32be19-79b9-4a3e-8574-6f1c208c98ae"
  />
  <img width="600" height="210" alt="image"
  src="https://github.com/user-attachments/assets/88a165cf-796d-4fdc-a7bc-ea89917573da"
  />
  
  <img width="512" height="193" alt="image"
  src="https://github.com/user-attachments/assets/d2353998-5aa8-442e-a5f8-3a8a5b832753"
  />

  jay · 2026-06-16 17:59:40 +00:00
  f8f5a6e78f
• Add request user input auto-resolution timer (#28235)

  ## Summary
  - Add TUI auto-resolution handling for `request_user_input` prompts when
  `autoResolutionMs` is present.
  - Use a 60s hidden grace period followed by a 60s visible countdown,
  then submit an empty answer response if the user does not interact.
  - Snooze auto-resolution on key or paste interaction and add
  snapshot/test coverage for the countdown UI.
  
  ## Notes
  - The TUI currently treats `autoResolutionMs` as an enable signal and
  intentionally does not use the provided duration value for the countdown
  policy.
  
  ### Auto resolution
  
  
  https://github.com/user-attachments/assets/5323152f-2ece-4aba-b75d-c32aa776f544
  
  
  ### Snooze after interaction
  
  
  https://github.com/user-attachments/assets/100d54c4-3a41-4c6c-9c07-cd28075a0d62

  Shijie Rao · 2026-06-15 11:49:19 -07:00
  1b81365926
• feat(tui): reland token activity command (#27925)

  ## Why
  
  [#25345](https://github.com/openai/codex/pull/25345) was approved,
  green, and squash-merged into its stacked base branch,
  `fcoury/tokenmaxxing-api`. Four minutes later, that base branch was
  force-pushed back to an API-only rebased head while preparing
  [#25344](https://github.com/openai/codex/pull/25344) for `main`. As a
  result, the squash commit from #25345 was orphaned and the TUI command
  never reached `main` or a release.
  
  This PR relands the orphaned TUI change from
  [`411410b8`](https://github.com/openai/codex/commit/411410b85c2d8eb050d441f17396c5c4048d866f)
  on current `main`.
  
  ## What changed
  
  - Add `/usage`, `/usage daily`, `/usage weekly`, and `/usage cumulative`
  for account token activity.
  - Fetch account usage asynchronously through the existing
  `account/usage/read` app-server RPC.
  - Render daily, weekly, and cumulative activity with theme-aware
  terminal palettes and bounded transient cards.
  - Preserve transcript ordering while assistant streams, history
  consolidations, active cells, and hooks complete.
  - Hide `/usage` from completion when backend auth is unavailable while
  keeping typed-command guidance.
  - Carry current-main behavior forward for cwd-aware Markdown parsing,
  Windows Terminal color detection, and personal access token auth.
  - Clear pending usage cards on thread rollback and delay completed cards
  until live hook output is committed.
  - Add focused regression and snapshot coverage for loading, auth errors,
  invalid views, rollback, hook ordering, layout, and charts.
  
  ## Prior review
  
  The original implementation was approved by Eric Traut in #25345 after
  testing multiple themes and light/dark terminals. This PR preserves that
  reviewed implementation while adapting it to current `main` and adding
  regression coverage for newer rollback and hook lifecycle behavior.
  
  ## Validation
  
  - `just test -p codex-tui token_activity palette renderable
  usage_command` — 37 passed.
  - Focused rollback, hook-ordering, and error snapshot tests — 4 passed.
  - `just fix -p codex-tui` — passed.
  - `UV_CACHE_DIR=/private/tmp/codex-uv-cache just fmt` — passed.
  - `cargo insta pending-snapshots` — no pending snapshots.
  - `just test -p codex-tui` — 2,870 passed; two unrelated guardian
  feature-flag tests failed because their expected `OverrideTurnContext`
  event was absent:
  -
  `update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`
  -
  `update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
  - `just argument-comment-lint` could not complete because the local
  Bazel LLVM `compiler-rt` repository is missing `include/sanitizer/*.h`.
  The touched Rust diff was manually inspected and no missing
  opaque-literal argument comments were found.

  Felipe Coury · 2026-06-12 17:33:43 -07:00
  c884536d84
• [3 of 3] Support images in TUI goals (#27510)

  ## Stack
  
  1. [1 of 3] Support long raw TUI goal objectives - #27508
  2. [2 of 3] Support long pasted text in TUI goals - #27509
  3. **[3 of 3] Support images in TUI goals** - this PR
  
  ## Why
  
  The first two PRs make goal definitions resilient to long text, but
  `/goal` still dropped image inputs from the composer. That meant a user
  could attach images while defining a goal and the resulting goal
  continuation would not have any useful reference to those images.
  
  Goal state still persists only objective text, so image inputs need to
  become paths or URLs that the agent can read later.
  
  ## What Changed
  
  - Extends TUI `GoalDraft` with local image attachments and remote image
  URLs.
  - Copies local goal images through the app-server filesystem layer into
  the managed goal attachment directory, then rewrites active image
  placeholders to file references.
  - Appends unplaced local images and remote image URLs to the objective
  as referenced image files or URLs.
  - Preserves goal image metadata through live `/goal` submission and
  queued `/goal` dispatch.
  
  ## Verification
  
  - Added goal materialization coverage for local image files and remote
  image URLs.
  - Added/updated TUI slash-command coverage showing `/goal` drafts
  include attached images instead of dropping them.
  
  ## Manual Testing
  
  - Attached an image by bracketed-pasting its local path into a live
  `/goal` composer. The `[Image #1]` placeholder became a server-host
  `image-1.png` reference, copied bytes matched exactly, and no attachment
  was written under the TUI's local home.
  - Deleted an image placeholder before submitting a small goal and
  verified no image was copied.
  - Attached PNG and JPEG files to the same goal. Placeholder order was
  preserved as `image-1.png` and `image-2.jpg`, and both remote copies
  matched their source bytes.
  - Tried extensionless, malformed-extension, and
  extension/content-mismatched paths; the composer rejected them as image
  attachments before goal dispatch rather than creating misleading managed
  image files.
  - Combined a local image, a large pasted block, and enough raw text to
  exceed 4,000 characters. The remote attachment directory contained the
  image, paste sidecar, and `goal-objective.md`; all embedded references
  used server-host paths and both payloads matched their sources.
  - Submitted an image replacement while a goal was active, verified no
  image was copied before confirmation, then canceled and confirmed the
  attachment count was unchanged.

  Eric Traut · 2026-06-12 17:14:27 -07:00
  9e07892253
• [2 of 3] Support long pasted text in TUI goals (#27509)

  ## Stack
  
  1. [1 of 3] Support long raw TUI goal objectives - #27508
  2. **[2 of 3] Support long pasted text in TUI goals** - this PR
  3. [3 of 3] Support images in TUI goals - #27510
  
  ## Why
  
  Large text pasted into the TUI composer is represented as a paste
  placeholder plus pending paste metadata. For `/goal`, preserving only
  the visible placeholder is not enough: the agent would see a short
  placeholder string instead of the actual pasted text, and the long-text
  support from the first PR would never see the payload.
  
  The TUI also needs to avoid writing stale sidecar files when a user
  pastes a large block and then deletes its placeholder before submitting
  the goal.
  
  ## What Changed
  
  - Introduces a TUI `GoalDraft` for goal submissions so `/goal`, `/goal
  edit`, and queued goal commands can carry objective text plus text
  elements and pending paste payloads.
  - Materializes active pasted-text placeholders to `pasted-text-N.txt`
  files through the app-server filesystem path introduced in #27508.
  - Rewrites active paste placeholders in the persisted objective to file
  references, while leaving literal placeholder-looking text alone.
  - Filters out deleted paste placeholders so otherwise-small goals do not
  require `$CODEX_HOME` or remote filesystem writes.
  - Preserves pending paste metadata when a `/goal` command is queued
  before a thread exists.
  
  ## Verification
  
  - Added goal materialization tests for active paste placeholders,
  deleted paste placeholders, and whitespace-only paste payloads.
  - Added/updated TUI slash-command tests for large pasted text, queued
  `/goal` commands before thread start, and queued oversized goal
  behavior.
  
  ## Manual Testing
  
  - Used real terminal bracketed-paste sequences through a remote TUI
  session. A 1,228-byte multiline paste became `pasted-text-1.txt`; its
  first/last lines and byte count matched exactly, and the persisted
  objective referenced the server-host path.
  - Pasted a large block, deleted its placeholder, and submitted a small
  replacement objective. No new directory or sidecar file was created.
  - Added two same-length large pastes to one goal. The composer
  disambiguated their visible placeholders, and materialization preserved
  order and contents in `pasted-text-1.txt` and `pasted-text-2.txt`.
  - Submitted a whitespace-only large paste and verified the goal was
  rejected as empty without writing a file.
  - Submitted a pasted-text replacement while another goal was active,
  verified no file was written before confirmation, then canceled and
  confirmed the original goal remained unchanged.
  - Combined a large paste with enough raw text to exceed 4,000 characters
  after placeholder rewriting. The paste sidecar and `goal-objective.md`
  were created in the same remote attachment directory, and `/goal edit`
  restored the rewritten objective with its sidecar reference.

  Eric Traut · 2026-06-12 15:34:04 -07:00
  c0f1ec5afd
• Remove TUI realtime voice support (#27801)

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

  Eric Traut · 2026-06-12 14:20:55 -07:00
  576f603440
• [1 of 3] Support long raw TUI goal objectives (#27508)

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

  Eric Traut · 2026-06-11 22:26:31 -07:00
  78bab04116
• fix(tui): restore cancelled prompt cursor at end (#26457)

  ## Why
  
  Pressing `Esc` on a turn that produced no visible output restores the
  submitted prompt so the user can keep editing it. That restore path
  preserved the prompt content, images, and mention bindings, but left the
  composer cursor at the start of the restored text. The next edit
  therefore inserted at the beginning instead of continuing from the end
  of the prompt.
  
  ## What Changed
  
  - Move the cursor to the end after
  `BottomPane::set_composer_text_with_mention_bindings` rehydrates a
  restored draft.
  - Add test-only cursor accessors so restore tests can assert the
  composer state directly.
  - Extend the queued restore regression to assert the restored composer
  cursor is positioned at `text.len()`.
  
  ## How to Test
  
  Manual reviewer flow:
  
  1. Start Codex in the TUI.
  2. Submit a prompt that will take long enough to interrupt.
  3. Press `Esc` before any visible assistant output appears.
  4. Confirm the prompt is restored into the composer and the cursor is at
  the end, so typing appends to the prompt.
  5. Repeat with a prompt that includes an attached image or resolved
  mention and confirm the restored content remains intact.
  
  Targeted tests:
  
  - `just test -p codex-tui
  chatwidget::tests::composer_submission::queued_restore_with_remote_images_keeps_local_placeholder_mapping`
  
  Lint note:
  
  - `just argument-comment-lint` is blocked locally by the existing Bazel
  `compiler-rt` empty glob failure before analyzing touched code. The
  touched Rust diff was manually inspected and adds no new opaque
  positional literal callsites.

  Felipe Coury · 2026-06-05 15:10:13 -03:00
  679a944dbc
• feat(tui): restore output-free cancelled prompts (#25316)

  ## TL;DR
  
  When you press Esc or Ctrl+C after sending a prompt but before any
  output was rendering, it restores the last composer and the message.
  
  ## Summary
  
  Cancelling a prompt immediately after submission should behave like
  returning to edit that prompt, not like discarding the user's draft.
  Today, pressing `Esc` or `Ctrl+C` before Codex responds leaves the
  submitted prompt in the transcript and returns an empty composer,
  forcing the user to recall or retype it.
  
  When an interrupted turn has not produced substantive visible output,
  restore its submitted prompt directly into the composer and roll back
  that latest turn. This also covers the first prompt in a fresh thread,
  before the TUI has retained a local user-history cell. The restored
  draft keeps its text, image attachments, and active collaboration mode
  so it can be edited and resubmitted in place.
  
  Restoration is intentionally suppressed once the turn has produced
  user-visible activity such as assistant output, tool work, hooks, or
  patches. A transient thinking status does not make the prompt
  ineligible. Rollback also rebuilds terminal scrollback from the retained
  transcript cells so repeated cancellations and terminal resizes do not
  duplicate history.
  
  ## How to Test
  
  1. Start the TUI with `cargo run -p codex-cli --bin codex`.
  2. In a fresh thread, submit the first prompt and press `Esc` before
  Codex emits substantive output. Confirm that the prompt returns to the
  composer for editing and its submitted transcript row is removed.
  3. Repeat with `Ctrl+C`, then repeat after at least one completed turn.
  Confirm the same behavior.
  4. Submit a prompt, wait for assistant output or tool activity, then
  cancel. Confirm that the transcript remains intact and the prompt is not
  restored into the composer.
  5. Cancel several output-free prompts and resize the terminal between
  attempts. Confirm that the startup banner, tip, and transcript history
  do not duplicate in scrollback.
  
  Targeted tests:
  - `just test -p codex-tui cancelled_turn_edit_restores_prompt`
  - `just test -p codex-tui
  output_free_interrupted_turn_requests_prompt_restore`
  - `just test -p codex-tui
  visible_output_prevents_cancelled_turn_prompt_restore`
  - `just test -p codex-tui
  thinking_status_keeps_cancelled_turn_prompt_restore_eligible`
  - `just test -p codex-tui
  patch_activity_prevents_cancelled_turn_prompt_restore`
  
  The full `just test -p codex-tui` run completed with `2746` passing
  tests and two unrelated existing guardian feature-flag failures. `just
  argument-comment-lint` remains blocked locally by the existing Bazel
  LLVM `compiler-rt` sanitizer-header glob failure; the touched Rust diff
  was manually audited for positional literal comments.

  Felipe Coury · 2026-06-01 11:49:14 -03:00
  c0ea566bb5
• Seed prompt history from resumed messages (#24298)

  ## Why
  
  When the TUI resumes a thread, transcript replay renders prior user
  messages but did not seed the composer history. That leaves the resumed
  session with empty in-memory prompt history, so pressing Up can fall
  through to persisted global history and surface a prompt from another
  thread.
  
  The expected behavior is that prompts from the resumed thread are
  recalled first, with global history only as a fallback.
  
  ## What changed
  
  - Record replayed user messages into the composer history during resume
  replay.
  - Preserve the existing persisted history format and avoid any startup
  history scan.
  - Add focused TUI coverage showing replayed prompts are recalled before
  persisted global history.
  
  ## Validation
  
  - Added `replayed_user_messages_seed_composer_history` in
  `codex-rs/tui/src/chatwidget/tests/history_replay.rs`.
  - `just test -p codex-tui replayed_user_messages_seed_composer_history`
  passed.

  Eric Traut · 2026-05-28 22:08:05 -07:00
  56958f2512
• TUI: Unified mentions tweaks + polish mentions rendering (#23363)

  This change keeps unified @mentions behind the mentions_v2 gate, moves
  the flag to under-development, and polishes mention rendering/history
  behavior.
  
  It also adds a few small improvements to the mentions feature around
  mention rendering and history round-tripping for plugin/tool mentions in
  message edit scenarios. Plugin selections now insert `@` mentions with
  better casing, and saved history preserves the visible sigil so recalled
  messages look the same as what the user typed.
  
  - Preserves `@` sigils when encoding/decoding mention history for
  tool/plugin paths.
  - Improves plugin mention insertion so display names/casing are
  reflected more cleanly in the composer.
  - Update composer to render user-entered plugin mentions in the same
  color as the mentions menu. ALso applies to recalled/edited messages.
  - Left/right arrows no longer switch unified-mention search modes after
  an @mention has already been accepted (Ex: arrowing left through a
  composed message that contains @mentions).
  - Keeps bound mentions stable around punctuation, so accepted `@`
  mentions do not reopen the popup and punctuated `$` mentions still
  persist to cross-session history.
  
  **Steps to test**
  - Ensure mentions_v2 is enabled through configuration or `--enable
  mentions_v2`
  - Type `@` in the TUI composer and verify filesystem/plugin/skill
  results are displayed in the unified mentions menu.
  - Select a plugin mention from the `@` popup and confirm the inserted
  text is an `@...` mention with casing, then recall/edit the message and
  confirm it still renders as `@...`.
  - Mention a skill and verify that skills still insert as `$skill`
  mentions rather than `@` mentions.
  - Verify punctuated mentions such as `@plugin.` and `($skill)` keep
  their bound mention behavior across editing and history recall.

  canvrno-oai · 2026-05-28 10:30:15 -07:00
  6c1215dac6
• feat(tui): make turn interruption keybind configurable (#24766)

  ## Why
  
  Interrupting an active turn is currently fixed to `Esc`, which is easy
  to hit accidentally and cannot be customized through `/keymap`. This
  gives users a less accidental binding while preserving the existing
  default.
  
  ## What Changed
  
  - Adds `tui.keymap.chat.interrupt_turn` to `/keymap`, defaulting to
  `esc` and supporting remapping or unbinding.
  - Uses the configured interrupt binding for running-turn status, queued
  steer interruption, and `request_user_input`, including the visible
  hints.
  - Preserves local `Esc` behavior for popups, Vim insert mode, and
  `/agent` editing while validating conflicts with fixed/backtrack and
  request-input navigation bindings.
  - Adds behavior and snapshot coverage for remapped interruption paths.
  
  ## How to Test
  
  1. Run Codex and open `/keymap`, then set **Interrupt Turn** to `f12`.
  2. Start a turn and confirm `Esc` no longer interrupts it while `f12`
  does; the running hint should display `f12 to interrupt`.
  3. Queue a steer while a turn is running and confirm the preview
  displays `f12`; pressing it should interrupt and submit the steer
  immediately.
  4. Trigger a `request_user_input` prompt and confirm its footer uses
  `f12`; with notes open, `Esc` should still clear notes while `f12`
  interrupts the turn.
  5. Clear the Interrupt Turn binding and confirm the key-specific
  interrupt hint is removed while `Ctrl+C` remains available.
  
  Targeted validation:
  
  - `just write-config-schema`
  - `just fix -p codex-config`
  - `just fix -p codex-tui`
  - `just fmt`
  - `just argument-comment-lint-from-source -p codex-config -p codex-tui`
  - `just test -p codex-config`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  - `just test -p codex-tui keymap_setup::tests`
  - `just test -p codex-tui` (fails in two pre-existing guardian
  feature-flag tests unrelated to this diff; the intentional picker
  snapshot updates were reviewed and accepted)

  Felipe Coury · 2026-05-27 18:59:17 +00:00
  2d1ad374a7
• [2 of 2] Start fresh TUI thread in background (#23176)

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

  Eric Traut · 2026-05-20 10:00:33 -07:00
  c0f7e1b99f
• fix(tui): 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
• 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
• 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: 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
• 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
• feat(tui): add ambient terminal pets (#21206)

  ## Why
  
  The Codex App has animated pets, but the TUI had no equivalent ambient
  companion surface. This brings that experience into terminal Codex while
  keeping the main chat flow usable: the pet should feel present, but it
  cannot cover transcript text, composer input, approvals, or picker
  content.
  
  The feature also needs to be terminal-aware. Different terminals support
  different image protocols, tmux can interfere with image rendering, and
  some users will want pets disabled entirely or anchored differently
  depending on their layout.
  
  <table>
  <tr><td>
  <img width="4110" height="2584" alt="CleanShot 2026-05-05 at 12 41
  45@2x"
  src="https://github.com/user-attachments/assets/68a1fcbc-2104-48d6-b834-69c6aaa95cdf"
  />
  <p align="center">macOS - Ghostty, iTerm2 and WezTerm with Custom
  Pet</p>
  </td></tr>
  <tr><td>
  ![Uploading CleanShot 2026-05-10 at 20.28.30.png…]()
  <p align="center">Windows Terminal</p>
  </td></tr>
  <tr><td>
  <img width="3902" height="2752" alt="CleanShot 2026-05-05 at 12 39
  02@2x"
  src="https://github.com/user-attachments/assets/300e2931-6b00-467e-91cb-ab8e28470500"
  />
  <p align="center">Linux - WezTerm and Ghostty</p>
  </td></tr>
  </table>
  
  ## What Changed
  
  - Add a TUI ambient pet renderer in `codex-rs/tui/src/pets/`.
  - Port the app-style pet animation states so the sprite changes with
  task status, waiting-for-input states, review/ready states, and
  failures.
  - Add `/pets` selection UI with a preview pane, loading state, built-in
  pet choices, and a first-row `Disable terminal pets` option.
  - Download built-in pet spritesheets on demand from the same public CDN
  path already used by Android, under
  `https://persistent.oaistatic.com/codex/pets/v1/...`, and cache them
  locally under `~/.codex/cache/tui-pets/`.
  - Keep custom pets local.
  - Add config support for pet selection, disabling pets, and choosing
  whether the pet follows the composer bottom or anchors to the terminal
  bottom.
  - Reserve layout space around the pet so transcript wrapping, live
  responses, and composer input do not render underneath the sprite.
  - Gate image rendering by terminal capability, disable image pets under
  tmux, and support both Kitty Graphics and SIXEL terminals.
  - Add redraw cleanup for terminal image artifacts, including sixel cell
  clearing.
  
  ## Current Scope
  
  - This is an initial TUI version of ambient pets, not full App parity.
  - It focuses on ambient sprite rendering, `/pets` selection, custom
  pets, terminal capability gating, and on-demand CDN-backed built-in
  assets.
  - The ambient text overlay is currently disabled, so the TUI renders the
  pet sprite without extra status text beside it.
  
  ## How to Test
  
  1. Start Codex TUI in a terminal with image support.
  2. Run `/pets`.
  3. Confirm the picker shows built-in pets plus custom pets, and the
  first item is `Disable terminal pets`.
  4. On a fresh `~/.codex/cache/tui-pets/`, move onto a built-in pet and
  confirm the first preview downloads the spritesheet from the shared
  Codex pets CDN and renders successfully.
  5. Move through the pet list and confirm subsequent built-in previews
  use the local cache.
  6. Select a pet, then send and receive messages. Confirm transcript and
  composer text wrap before the pet instead of rendering underneath the
  sprite.
  7. Change the pet anchor setting and confirm the pet can either follow
  the composer bottom or sit at the terminal bottom.
  8. Return to `/pets`, choose `Disable terminal pets`, and confirm the
  sprite disappears cleanly.
  
  Targeted tests:
  - `cargo test -p codex-tui ambient_pet_`
  - `cargo test -p codex-tui
  resize_reflow_wraps_transcript_early_when_pet_is_enabled`
  - `cargo insta pending-snapshots`

  Felipe Coury · 2026-05-12 10:43:17 -03:00
  95b332c820
• Unified mentions in TUI (#19068)

  This PR replaces the TUI’s file-only `@mention` popup with a unified
  mentions experience. Typing `@...` now searches across filesystem
  matches, installed plugins, and skills in one popup, with result types
  clearly labeled and selectable from the same flow.
  
  - Adds a unified `@mentions` popup that returns:
    - plugins
    - skills
    - files
    - directories
  
  - Adds search modes so users can narrow the popup without changing their
  query:
    - All Results _(default/same as Codex App)_
    - Filesystem Only
    - Plugins _(...and skills)_
  
  - Preserves existing insertion behavior:
    - selected file paths are inserted into the prompt
    - paths with spaces are quoted
    - image file selections still attach as images when possible
    - selecting a plugin or skill inserts the corresponding `$name`
  - the composer records the canonical mention binding, such as
  `plugin://...` or the skill path
  
  - Expanded `@mentions` rendering:
    - type tags for Plugin, Skill, File, and Dir
    - distinct plugin/filesystem colors
    - stable fixed-height layout (8 rows)
    - truncation behavior for narrow terminals
  
  Note:
  - The unified mentions popup does not display app connectors under
  `@mention` results for Codex App parity. Connector mentions remain
  available through the existing `$mention` path.
  
  
  https://github.com/user-attachments/assets/f93781ed-57d3-4cb5-9972-675bc5f3ef3f

  canvrno-oai · 2026-05-11 11:34:52 -07:00
  eaf05c9002
• Improve hooks trust flow in TUI (#21755)

  # Why
  Hooks that need trust review were easy to miss, and the existing TUI
  flow made users discover `/hooks` manually before they could decide
  whether to inspect or trust them.
  
  # What
  - add a startup review prompt for new or changed hooks before normal
  composer use
  - add a top-level `t` shortcut in `/hooks` to trust every review-needed
  hook at once
  - make pending-review rows and helper copy use warning styling
  
  ## TUI
  
  ### Startup review interstitial
  
  ```text
  Hooks need review
  2 hooks are new or changed.
  Hooks can run outside the sandbox after you trust them.
  
  › 1. Review hooks
    2. Trust all and continue
    3. Continue without trusting (hooks won't run)
  ```
  
  ### Top-level `/hooks` page when review is needed
  
  ```text
  Hooks
  Lifecycle hooks from config and enabled plugins.
  
  ⚠ 1 hook needs review before it can run.
  
  Event                 Installed   Active   Review   Description
  PreToolUse            1           0        1        Before a tool executes
  ...
  
  Press t to trust all; enter to review hooks; esc to close
  ```

  Abhinav · 2026-05-09 21:17:30 +00:00
  6d747db7d8
• [codex] Generalize service tier slash commands (#21745)

  ## Why
  
  `/fast` was wired as a one-off slash command even though model metadata
  now exposes service tiers as catalog data. That meant adding another
  tier, such as a slower/cheaper tier, would require more hardcoded TUI
  plumbing instead of letting the model catalog drive the available
  commands.
  
  This change makes service-tier commands data-driven: each advertised
  `service_tiers` entry becomes a `/name` command using the catalog
  description, while the request path sends the tier `id` only when the
  selected model supports it.
  
  ## What Changed
  
  - Removed the hardcoded `/fast` slash-command variant and introduced
  dynamic service-tier command items in the composer and command popup.
  - Added toggle behavior for service-tier commands: invoking `/name`
  selects that tier, and invoking it again clears the selection.
  - Preserved the existing Fast-mode keybinding/status affordances by
  resolving the current model tier whose name is `fast`, while still
  sending the tier request value such as `priority`.
  - Persisted service-tier selections as raw request strings so non-fast
  tiers can round-trip through config.
  - Updated the Bedrock catalog entry to advertise fast support through
  `service_tiers` with `id: "priority"` and `name: "fast"`.
  - Added defensive filtering in core so unsupported selected service
  tiers are omitted from `/responses` requests.
  
  ## Validation
  
  - Added/updated coverage for dynamic service-tier slash command lookup,
  popup descriptions, composer dispatch, TUI fast toggling, and
  unsupported-tier omission in core request construction.
  - Local tests were not run per request.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-08 20:09:51 +03:00
  7c0e54bf59
• fix(tui): persist ctrl-c draft via app event (#21397)

  ## Why
  
  The main branch started failing after #21351 merged because the merge
  commit kept calling `AppCommand::add_to_history` from
  `BottomPane::clear_composer_for_ctrl_c`, but main had already removed
  that helper as part of the history persistence refactor. The PR head
  passed because it was based on an older main commit where the helper
  still existed.
  
  This restores the Ctrl+C draft-stashing behavior using the current
  app-event path instead of the removed command helper.
  
  ## What Changed
  
  - Store the active `ThreadId` in `BottomPane` when history metadata is
  provided.
  - Emit `AppEvent::AppendMessageHistoryEntry` for Ctrl+C-cleared drafts.
  - Update the slash-clear regression test to assert the current history
  event shape.
  
  ## How to Test
  
  Targeted tests:
  - `cargo test -p codex-tui
  slash_clear_after_ctrl_c_keeps_stashed_draft_recallable`
  
  Broader local checks:
  - `just fix -p codex-tui`
  - `just argument-comment-lint -p codex-tui`
  - `git diff --check origin/main...HEAD`
  - `cargo test -p codex-tui` reached completion; the fixed test passed,
  and the only local failures were
  `status::tests::status_permissions_full_disk_managed_*`, blocked by this
  machine config rejecting `DangerFullAccess` via
  `/etc/codex/requirements.toml`.

  Felipe Coury · 2026-05-06 19:03:11 +00:00
  6b7d6cafa0
• fix(tui): keep Ctrl-C stashed drafts after /clear (#21351)

  ## Why
  
  When a user stashes a draft with Ctrl+C, then runs `/clear`, the fresh
  chat session loses the in-memory composer history that held the stashed
  draft. Pressing Up after `/clear` can then recall an older submitted
  prompt instead of the draft the user explicitly saved for later.
  
  ## What Changed
  
  - Record Ctrl+C-cleared composer text through the existing message
  history path, so it survives the fresh session created by `/clear`.
  - Keep `/clear` itself out of local slash-command recall so it does not
  sit ahead of the stashed draft.
  - Add regression coverage for the full flow: submit a prompt, stash a
  later draft with Ctrl+C, run `/clear`, then recall the stashed draft
  before the older prompt.
  
  ## How to Test
  
  1. Start Codex with `just c`.
  2. Submit a short prompt such as `ok` and wait for the turn to complete.
  3. Type a new draft, press Ctrl+C, then run `/clear`.
  4. Press Up and confirm the stashed draft is restored.
  5. Press Up again and confirm the older submitted prompt is still
  reachable after the stashed draft.
  
  Targeted tests:
  
  - `cargo test -p codex-tui
  slash_clear_after_ctrl_c_keeps_stashed_draft_recallable`
  
  Manual verification:
  
  - Reproduced the issue in tmux with `RUST_LOG=trace just c -c
  log_dir=...`: before the fix, Up after `/clear` recalled the older
  submitted prompt.
  - Re-tested the same tmux flow after the fix: Up after `/clear` restored
  the Ctrl+C-stashed draft.

  Felipe Coury · 2026-05-06 14:46:18 -03:00
  e97610cf3b
• Move message history out of core (#21278)

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

  pakrym-oai · 2026-05-06 08:35:42 -07:00
  2004173cd7
• Support Codex Apps auth elicitations (#19193)

  ## Summary
  
  - request URL-mode MCP elicitations when Codex Apps tool calls fail with
  connector auth metadata
  - route Codex Apps auth URL elicitations into the TUI app-link flow
  
  ## Test plan
  
  - `just fmt`
  - `cargo test -p codex-core mcp_tool_call::tests`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-tui bottom_pane::app_link_view::tests`
  - `just fix -p codex-core`
  - `just fix -p codex-mcp`
  - `just fix -p codex-tui`
  
  Also attempted broader local runs:
  
  - `cargo test -p codex-core` fails in unrelated
  config/request-permission/proxy-sensitive tests under the current Codex
  Desktop environment.
  - `cargo test -p codex-tui` fails in unrelated status
  snapshots/trust-default tests because the ambient environment renders
  workspace-write/network permission defaults.

  Matthew Zeng · 2026-05-06 07:18:00 +00:00
  f9a907aebe
• Add plugin ID to skill analytics (#20923)

  ## Summary
  - thread plugin skill roots through the skills loader with their plugin
  ID
  - store plugin ID on loaded skill metadata for plugin-provided skills
  - include plugin ID on skill invocation analytics events
  
  ## Test plan
  - cargo check -p codex-core-skills
  - cargo check -p codex-core -p codex-core-plugins -p codex-analytics
  - cargo check -p codex-tui
  - cargo check -p codex-plugin -p codex-core -p codex-core-plugins -p
  codex-analytics
  - cargo check -p codex-app-server
  - cargo test -p codex-analytics
  - HOME=/private/tmp/codex-empty-home cargo test -p codex-core-skills
  - just fix -p codex-core-skills
  - just fix -p codex-analytics
  - just fix -p codex-core-plugins
  - just fix -p codex-core
  - just fmt
  - git diff --check

  alexsong-oai · 2026-05-04 20:36:29 -07:00
  3ad7cf0993
• feat(tui): add PR summary statusline items (#20892)

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

  Felipe Coury · 2026-05-04 16:11:15 -03:00
  cc16995cc6
• feat(tui): add keymap debug inspector (#20794)

  ## Why
  
  We constantly get bug reports about keys not being recognized by Codex
  when the terminal is not handling the key press. Running `/keymap debug`
  or `/keymap` and going to the Debug tab, we can allow the user to either
  understand that the key being pressed is not being recognized or to
  check what it's being recognized as and report or reassign that key.
  
  | Menu | Inspector | Hint |
  |---|---|---|
  | <img width="1369" height="796" alt="CleanShot 2026-05-02 at 12 57 12"
  src="https://github.com/user-attachments/assets/512b6faa-344e-4aee-9c00-b4bdc633a662"
  /> | <img width="1261" height="754" alt="CleanShot 2026-05-02 at 12 56
  36"
  src="https://github.com/user-attachments/assets/a6ddae7d-e174-4ee4-893f-e6bec4fff4ab"
  /> | <img width="1369" height="796" alt="CleanShot 2026-05-02 at 12 57
  30"
  src="https://github.com/user-attachments/assets/db507784-f40a-4cff-ac23-a61d9703769b"
  /> |
  ## Summary
  - add a Debug tab to `/keymap` and support `/keymap debug` for direct
  access
  - show what key Codex receives, the config key representation, raw event
  details, and matching actions
  - add a progressive missing-key hint that escalates after a few seconds
  with no detected keypress
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-tui keymap_setup::tests::debug_view`
  - `cargo test -p codex-tui keymap_setup::tests`
  - `cargo test -p codex-tui slash_keymap`
  - `cargo test -p codex-tui` (unit tests passed; integration test
  `suite::model_availability_nux::resume_startup_does_not_consume_model_availability_nux_count`
  failed locally by itself with `codex resume` exiting 1 and terminal
  probe escape output)
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  - `cargo insta pending-snapshots`
  - `git diff --check`

  Felipe Coury · 2026-05-04 14:40:50 -03:00
  94800ecbbf
• Add /ide context support to the TUI (#20294)

  ## Why
  
  Users have asked for a `/ide` command in the TUI so Codex can use the
  active IDE session for live context such as the current file, open tabs,
  and selected ranges. We already support a similar feature in the Codex
  desktop app, so bringing it to the TUI makes sense.
  
  One subtle compatibility constraint is that the injected prompt wrapper
  and transcript stripping should match the desktop app and IDE extension.
  By using the same `## My request for Codex:` delimiter and hiding the
  injected context from transcript rendering the same way, threads created
  in the TUI render correctly in desktop and IDE surfaces, and threads
  created there replay correctly in the TUI, even when IDE context was
  included.
  
  Addresses https://github.com/openai/codex/issues/13834.
  
  ## What changed
  ### Summary
  This PR consists of four four pieces:
  1. An IPC client that uses a socket (Mac/Linux) or named pipe (Windows)
  to talk to the IDE Extension
  2. Logic that establishes the IPC connection and requests IDE context
  (open files, selection) on demand
  3. Logic that injects this context into the user prompt (using the same
  technique as the desktop app) and hides the added context when rendering
  the prompt in the TUI transcript
  4. A new slash command for enabling/disabling this mode and text within
  the footer to indicate when it's enabled
  
  ### Details
  - Added `/ide [on|off|status]` to the TUI, with bare `/ide` toggling IDE
  context on or off.
  - Added a Rust IDE context client that connects to the local Codex IDE
  IPC route as a client and requests context from the IDE extension flow.
  - Injected IDE context using the same prompt delimiter and
  transcript-stripping convention as the desktop app and IDE extension so
  shared threads render consistently across surfaces.
  - Added an `IDE context` status-line indicator while the feature is
  active and cleared it when enabling or fetching context fails.
  - Added handling for multiple selection ranges, oversized selections,
  interleaved IPC messages, and transient reconnect timing after quick
  toggles.
  
  ## Verification
  
  Did extensive manual testing in addition to running automated unit and
  regression tests.
  
  To test:
  
  - Launch VS Code (or Cursor) with the IDE extension.
  - Open one or more files in the IDE and select a range of text within
  one of them.
  - Start the TUI.
  - Ask the agent which files you have open in your IDE, and it should say
  that it does not know.
  - Enable `/ide` mode; note that `IDE context` appears in the lower
  right.
  - Ask the agent what files you have open in your IDE and what text is
  selected.

  Eric Traut · 2026-05-01 09:39:48 -07:00
  6784db51c0
• Color TUI statusline from active theme (#19631)

  ## Why
  
  Users have shared that the TUI can feel too visually flat because themes
  mostly show up in code syntax highlighting. The configurable statusline
  is a natural place to make the active theme more visible, while still
  letting users keep the existing monotone statusline if they prefer it.
  
  ## What Changed
  
  - Added a statusline styling helper that builds the rendered statusline
  from `(StatusLineItem, text)` segments, preserving item identity while
  keeping the plain text output unchanged.
  - Derived foreground accent colors from the active syntax theme by
  looking up TextMate scopes through the existing syntax highlighter, with
  conservative ANSI fallbacks when a scope does not provide a foreground.
  - Tuned theme-derived colors to keep the accents visible without making
  the statusline feel overly bright.
  - Added `[tui].status_line_use_colors`, defaulting to `true`, plus a
  separated `/statusline` toggle so users can enable or disable
  theme-derived statusline colors from the setup UI.
  - Updated the live statusline and `/statusline` preview to use the same
  styled builder, while keeping terminal-title preview text plain.
  - Kept statusline separators and active-agent add-ons subdued while
  removing blanket dimming from the whole passive statusline.
  
  ## Verification
  
  - `cargo test -p codex-tui status_line`
  - `cargo test -p codex-tui theme_picker`
  - `cargo test -p codex-tui foreground_style_for_scopes`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-config`
  - `cargo test -p codex-core status_line_use_colors`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`
  
  ## Visual
  
  <img width="369" height="23" alt="Screenshot 2026-04-30 at 6 16 08 PM"
  src="https://github.com/user-attachments/assets/11d03efb-8e4f-4450-8f4d-00a9659ef4cd"
  />
  
  <img width="385" height="23" alt="Screenshot 2026-04-30 at 6 16 02 PM"
  src="https://github.com/user-attachments/assets/a3d89f36-bdc1-42e8-8e84-61350e3999e2"
  />

  Eric Traut · 2026-04-30 22:42:48 -07:00
  a93c89f497
• feat(tui): add vim composer mode (#18595)

  ## Why
  
  Codex now has configurable TUI keymaps, but the composer still behaves
  like a plain text field. Users who prefer modal editing need a way to
  keep Vim muscle memory while drafting prompts, and the keymap picker
  needs to expose Vim-specific actions if those bindings are configurable
  instead of hardcoded.
  
  ## What Changed
  
  - Adds composer Vim mode with insert/normal state, common normal-mode
  movement and editing commands, `d`/`y` operator-pending flows, and
  mode-aware footer and cursor indicators.
  - Adds `/vim`, an optional global `toggle_vim_mode` binding, and
  `tui.vim_mode_default` so Vim mode can be toggled per session or enabled
  as the default composer state.
  - Extends runtime and config keymaps with `vim_normal` and
  `vim_operator` contexts, exposes those contexts in `/keymap`, refreshes
  the config schema, and validates Vim bindings separately.
  - Integrates Vim normal mode with existing composer behavior: `/` opens
  slash command entry, `!` enters shell mode, `j`/`k` navigate history at
  history boundaries, successful submissions reset back to normal mode,
  and paste burst handling remains insert-mode only.
  - Teaches the TUI render path to apply and restore cursor style so Vim
  insert mode can use a bar cursor without leaving the terminal in that
  state after exit.
  
  ## Validation
  
  - `cargo test -p codex-tui keymap -- --nocapture` on the keymap/Vim
  coverage
  - `cargo insta pending-snapshots`
  
  ## Docs
  
  This introduces user-facing `/vim`, `tui.vim_mode_default`, and Vim
  keymap contexts under `tui.keymap`, so the public CLI configuration and
  slash-command docs should be updated before the feature ships.

  Felipe Coury · 2026-04-30 17:20:51 -07:00
  b6f81257f8
• Add /hooks browser for lifecycle hooks (#19882)

  ## Why
  
  `hooks/list` and `hooks/config/write` give us read/write access to hooks
  and their state. This hooks up the TUI as a client so users can inspect
  and manage that state directly.
  
  ## What
  
  - add a two-page `/hooks` browser in the TUI: an event overview with
  installed/active counts, followed by a per-event handler page with
  toggle controls and detail rendering
  - thread managed-state metadata through hook discovery and `hooks/list`
  so the UI can label admin-managed hooks and suppress toggles for them
  - persist hook toggles through the existing config-write path and add
  snapshot coverage for the event list, handler list, managed-hook, and
  empty states
  
  ## Stack
  
  1. openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. This PR - openai/codex#19882
  
  ## Reviewer Notes
  
  - Main UI logic is in
  `codex-rs/tui/src/bottom_pane/hooks_browser_view.rs`; most of the diff
  is the new view plus its snapshot coverage
  - Request / write plumbing for opening the browser and persisting
  toggles is in `codex-rs/tui/src/app/background_requests.rs` and
  `codex-rs/tui/src/chatwidget/hooks.rs`
  - Outside the TUI, the only behavioral change in this PR is threading
  `is_managed` through hook discovery and `hooks/list` so managed hooks
  render as non-toggleable
  - The `codex-rs/tui/src/status/snapshots/` churn is unrelated merge
  fallout from the stacked base branch's newer permission-label rendering
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-30 11:58:27 -07:00
  93d53f655b
• Remove core protocol dependency [2/2] (#20325)

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

  Eric Traut · 2026-04-30 11:34:34 -07:00
  f2bc2f26a9
• TUI: Remove core protocol dependency [3/7] (#20174)

  ## Why
  
  This is part 3 of a 7-PR stack to remove direct
  `codex_protocol::protocol` usage from `codex-tui` while keeping each
  layer reviewable and shippable.
  
  With `AppCommand` now explicit, the internal app event bus can carry TUI
  commands directly instead of bouncing through core `Op` values.
  
  ## What changed
  
  - Changed `AppEvent::CodexOp` and `AppEvent::SubmitThreadOp` to carry
  `AppCommand`.
  - Updated app-event senders and direct emitters to submit `AppCommand`
  values.
  - Adjusted tests to match `AppCommand` or convert back through
  `into_core()` where they intentionally assert legacy payload equality.
  
  ## Verification
  
  - `cargo test -p codex-tui --no-run`

  Eric Traut · 2026-04-29 10:52:10 -07:00
  d0204c3dcc
• feat(tui): suggest plan mode from composer drafts (#19901)

  ## Summary
  
  - suggest Plan mode when the current composer draft contains the
  standalone word `plan`
  - shares the Codex App heuristics for detection
  - excludes things line `/plan` and the word plan in shell mode
  - reuse the existing `Shift+Tab` mode cycle and add thread-scoped
  dismissal with `Esc`
  - replace the normal footer hint while the reminder is visible so the
  statusline stays anchored
  
  
  https://github.com/user-attachments/assets/01123ae8-cee6-4e95-b563-44655c071cde
  
  ## Why
  
  The desktop app already nudges users toward Plan mode when their draft
  clearly signals planning intent. The TUI had the underlying `/plan` and
  `Shift+Tab` flows, but no equivalent reminder at the moment the user was
  most likely to benefit from them.
  
  ## Details
  
  The reminder is shown only when Plan mode is available, the draft
  contains standalone `plan`, the user is not already in Plan mode, the
  composer is actionable, and the current thread has not dismissed the
  reminder. Slash-command and shell-command drafts are excluded.
  
  The first implementation used an extra composer row, but that moved the
  statusline whenever the heuristic fired. This version keeps the layout
  stable by rendering the reminder in the existing footer row instead.
  
  ## Validation
  
  - `INSTA_UPDATE=always cargo test -p codex-tui
  chatwidget::tests::plan_mode::plan_mode_nudge -- --nocapture`
  - `just fmt`
  - `just fix -p codex-tui`
  - `./tools/argument-comment-lint/run.py -p codex-tui`
  - `cargo insta pending-snapshots`
  - `git diff --check`

  Felipe Coury · 2026-04-28 14:34:10 -03:00
  c6bcd27832
• feat(tui): add configurable keymap support (#18593)

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

  Felipe Coury · 2026-04-28 12:52:25 -03:00
  5e737372ee
• Show action required in terminal title (#18372)

  Implements #18162
  
  This updates the TUI terminal title to show an explicit action-required
  state when Codex is blocked on user approval or input. The terminal
  title now uses the activity title item to cover both active work and
  blocked-on-user states, while still accepting the legacy spinner config
  value.
  
  Changes
  - Rename the terminal title item from `spinner` to `activity` while
  preserving legacy config compatibility
  - Show `[ ! ] Action Required `while approval or input overlays are
  active, with a blinking `[ . ]` alternate state
  - Suppress the normal working spinner while Codex is blocked on user
  action
  - Add targeted coverage for action-required title behavior and legacy
  title-item parsing
  
  Testing
  - Trigger an approval or input modal and confirm the tab title
  alternates between `[ ! ] Action Required` and `[ . ] Action Required`
  - Disable the activity title item and confirm the action-required title
  does not appear
  - Resolve the prompt and confirm the title returns to the normal
  spinning/idel state
  
  
  https://github.com/user-attachments/assets/e9ecc530-a6be-4fd7-b9a6-d550a790eb2c

  canvrno-oai · 2026-04-27 15:27:11 -07:00
  e64c765673
• Delay approval prompts while typing (#19513)

  ## Why
  
  Fixes #7744. Approval modals can currently appear while the user is
  typing ahead in the TUI composer, which lets plain letters like `y` or
  `a` get consumed as approval shortcuts instead of staying in the draft
  input.
  
  ## What changed
  
  - Track recent composer typing activity in `bottom_pane/mod.rs`.
  - Delay new approval overlays for 1 second while the composer is active,
  keeping delayed requests queued until the user is idle.
  - Preserve the existing active-overlay behavior so approvals that arrive
  while an approval modal is already open are still queued into that
  overlay.
  - Prune delayed approvals when app-server resolution says the request
  has already been handled.
  
  ## Verification
  
  Added unit coverage for immediate approvals, delayed approvals, idle
  deadline reset, typed shortcut letters staying in the composer, shortcut
  handling after the delay, and resolved delayed-request pruning.
  
  Focused `codex-tui` test groups pass locally. The full `cargo test -p
  codex-tui` run currently aborts in
  `app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads`;
  that same test also fails when run alone with the same stack overflow.
  
  Manual reviewer check:
  
  1. Start the TUI from the repo root:
  
     ```bash
     RUST_LOG=trace just codex \
       -c log_dir=<temp-log-dir> \
       --ask-for-approval untrusted \
       --sandbox workspace-write
     ```
  
  2. Submit this prompt:
  
     ```text
     create a file text.txt on my desktop
     ```
  
  3. While the agent is preparing the approval request, immediately type
  text such as `ya this should stay in the composer`.
  4. Confirm the typed-ahead `y`/`a` remains in the composer instead of
  approving the request.
  5. Stop typing for about 1 second; the approval modal should then
  appear.
  6. Once the modal is visible, press `y` and confirm the approval
  shortcut works normally.

  Eric Traut · 2026-04-27 13:20:55 -07:00
  0bd25ab374
• Add goal TUI UX (5 / 5) (#18077)

  Adds the TUI user experience for goals on top of the core runtime from
  PR 4.
  
  ## Why
  
  Users need a direct TUI control surface for long-running goals. The UI
  should make the current goal visible, support common goal actions
  without waiting for a model turn, and avoid confusing end-of-turn
  notifications while an active goal is immediately continuing.
  
  ## What changed
  
  - Added `/goal` summary rendering for the current goal, including
  active, paused, budget-limited, and complete states.
  - Added `/goal <objective>` creation/replacement through the app-server
  goal API rather than a model prompt.
  - Added `/goal clear`, `/goal pause`, and `/goal unpause` command
  variants.
  - Added a confirmation menu when the user enters a new goal while
  another goal already exists.
  - Updated `/goal` help and summary tip text so it reflects the supported
  command variants without advertising slash-command token budgets.
  - Added footer/statusline goal indicators, including elapsed time and
  token budget display when a budget exists from API/tool-created goals.
  - Consumes goal updated/cleared notifications so the TUI stays in sync
  with external app-server changes.
  - Suppresses end-of-turn desktop notifications only when a goal is still
  active and follow-up work is expected.
  - Preserves slash-command history behavior and avoids leaking queued
  `/goal` state into unrelated submissions.
  
  ## Verification
  
  - Added TUI unit and snapshot coverage for goal command availability,
  summary rendering, control commands, replacement menu behavior,
  status/footer display, notification handling, and command history.

  Eric Traut · 2026-04-24 21:16:45 -07:00
  f1c963d77e
• /statusline & /title - Shared preview values (#18435)

  This PR makes the `/statusline` and `/title` setup UIs share one
  preview-value source instead of each surface using its own examples.
  Both pickers now render consistent live values when available, and
  stable placeholders when they are not. It also resolves live preview
  values at the shared preview-item layer, so `/title` preview can use
  real runtime values for title-specific cases like status text, task
  progress, and project-name fallback behavior.
  
  - Adds a shared preview data model for status surfaces
  - Maps status-line items and terminal-title items onto that shared
  preview list
  - Feeds both setup views from the same chatwidget-derived preview data,
  with terminal-title-specific formatting applied before `/title` preview
  renders
  - Keeps project-root preview aligned with status-line behavior while
  project in /title keeps its title fallback/truncation behavior
  - Adds snapshot coverage for live-only, hardcoded-only, and mixed cases
  
  Test Steps
  - Open Codex TUI and launch `/statusline`.
  - Toggle and reorder items, then verify the preview uses current session
  values when possible, and placeholder values for missing values (ex: no
  thread ID).
  - Open `/title` and verify it shows the same normalized values,
  including live status/task-progress values when available.

  canvrno-oai · 2026-04-20 17:46:11 -07:00
  9a2b34213b
• TUI: remove simple legacy_core re-exports (#18605)

  ## Summary
  
  The TUI still imported several symbols through the transitional
  app-server-client `legacy_core` facade even though those symbols are
  already owned by smaller crates. This PR narrows that facade by rewiring
  those imports directly to their owner crates.
  
  ## Changes
  
  No functional changes, just import rewiring. This is part of our ongoing
  effort to whittle away at the `legacy_core` namespace, which represents
  all of the remaining symbols that the TUI imports from the core.

  Eric Traut · 2026-04-19 22:39:53 -07:00
  87fc21ff60
• Add /side conversations (#18190)

  The TUI supports long-running turns and agent threads, but quick side
  questions have required interrupting the main flow or manually
  forking/navigating threads. This PR adds a guarded `/side` flow so users
  can ask brief side-conversation questions in an ephemeral fork while
  keeping the primary thread focused. This also helps address the feature
  request in #18125.
  
  The implementation creates one side conversation at a time, lets `/side`
  open either an empty side thread or immediately submit `/side
  <question>`, and returns to the parent with Esc or Ctrl+C. Side
  conversations get hidden developer guardrails that treat inherited
  history as reference-only and steer the model away from workspace
  mutations unless explicitly requested in the side conversation.
  
  The TUI hides most slash commands while side mode is active, leaving
  only `/copy`, `/diff`, `/mention`, and `/status` available there.

  Eric Traut · 2026-04-19 11:59:41 -07:00
  95dafbc7b5
• Queue slash and shell prompts in the TUI (#18542)

  ## Why
  
  Users have asked to queue follow-up slash commands while a task is
  running, including in #14081, #14588, #14286, and #13779. The previous
  TUI behavior validated slash commands immediately, so commands that are
  only meaningful once the current turn is idle could not be queued
  consistently.
  
  The queue should preserve what the user typed and defer command parsing
  until the item is actually dispatched. This also gives `/fast`, `/review
  ...`, `/rename ...`, `/model`, `/permissions`, and similar slash
  workflows the same FIFO behavior as plain queued prompts.
  
  ## What Changed
  
  - Added a queued-input action enum so queued items can be dispatched as
  plain prompts, slash commands, or user shell commands.
  - Changed `Tab` queueing to accept slash-led prompts without validating
  them up front, then parse and dispatch them when dequeued.
  - Added `!` shell-command queueing for `Tab` while a task is running,
  while preserving existing `Enter` behavior for immediate shell
  execution.
  - Moved queued slash dispatch through shared slash-command parsing so
  inline commands, unavailable commands, unknown commands, and local
  config commands report at dequeue time.
  - Continued queue draining after local-only actions and after slash menu
  cancellation or selection when no task is running.
  - Preserved slash-popup completion behavior so `/mo<Tab>` completes to
  `/model ` instead of queueing the prefix.
  - Updated pending-input preview snapshots to show queued follow-up
  inputs.
  
  ## Verification
  
  I did a bunch of manual validation (and found and fixed a few bugs along
  the way).

  Eric Traut · 2026-04-19 10:52:16 -07:00
  917a85b0d6
• /plugins: Add inline enablement toggles (#18395)

  This PR adds inline enable/disable controls to the new /plugins browse
  menu. Installed plugins can now be toggled directly from the list with
  keyboard interaction, and the associated config-write plumbing is
  included so the UI and persisted plugin state stay in sync. This also
  includes the queued-write handling needed to avoid stale toggle
  completions overwriting newer intent.
  
  - Add toggleable plugin rows for installed plugins in /plugins
  - Support Space to enable or disable without leaving the list
  - Persist plugin enablement through the existing app/config write path
  - Preserve the current selection while the list refreshes after a toggle
  - Add tests and snapshot updates for toggling behavior
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  canvrno-oai · 2026-04-17 17:33:11 -07:00
  06f8ec54db
• /plugins: Add v2 tabbed marketplace menu (#18222)

  This PR moves `/plugins` onto the shared tabbed selection-list
  infrastructure and introduces the new v2 menu. The menu now groups
  plugins into All Plugins, Installed, OpenAI Curated, and per-marketplace
  tabs.
  
  - Rebuild /plugins on top of the shared tabbed selection list
  - Add All Plugins, Installed, OpenAI Curated, and per-marketplace tabs
  - Preserve active tab and selected-row behavior across popup refreshes
  - Add duplicate marketplace tab-label disambiguation
  - Update browse-mode popup tests and snapshots
  
  Co-authored-by: Codex <noreply@openai.com>

  canvrno-oai · 2026-04-17 12:59:18 -07:00
  f017a23835
• Add tabbed lists, single line rendering, col width changes (#18188)

  This PR adds shared bottom-pane selection-list for future `/plugins`
  menu work and wires the existing `/plugins` menu into the new
  list-rendering path without changing it to tabs yet. The main
  user-visible effect is that the current plugin list now renders as a
  denser single-line list with shared name-column sizing, while the tabbed
  selection support remains available for follow-up PRs but is currently
  unused in production menus.
  
  - Add generic tabbed selection-list support to the bottom pane,
  including per-tab headers/items and tab-aware list state
  - Add single-line row rendering with ellipsis truncation for dense list
  UIs
  - Add shared name-column width support so descriptions align
  consistently across rows
  - Wire the current /plugins menu to the new single-line and shared
  column-width behavior only
  - Keep tabbed menu adoption deferred; no existing menu is switched to
  tabs in this PR
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  canvrno-oai · 2026-04-16 15:27:59 -07:00
  fa5d14e276