714 Commits

• 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
• 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
• 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
• 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
• 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
• Refactor chatwidget input flow into modules (#22407)

  ## Why
  
  `chatwidget.rs` is still carrying too many unrelated responsibilities in
  one file. #22269 started a five-phase effort to move coherent behavior
  domains into focused modules while keeping `chatwidget.rs` as the
  composition layer.
  
  This PR is phase 2 of that plan. It extracts the input and submission
  flow as a mechanical move before the later protocol, popup/status, and
  constructor/orchestration phases.
  
  ## What Changed
  
  - Added `codex-rs/tui/src/chatwidget/input_flow.rs` for composer input
  results, queued user-message draining, pending-input previews, and
  mode-specific submission entry points.
  - Added `codex-rs/tui/src/chatwidget/input_submission.rs` for
  user-message construction/submission, shell prompt submission,
  structured mention resolution, and blocked image draft restoration.
  - Added `codex-rs/tui/src/chatwidget/input_restore.rs` for
  initial-message submission, pending steer restoration after interrupts,
  and thread input snapshot/restore behavior.
  - Registered the new modules and removed the moved `ChatWidget` impl
  methods from `codex-rs/tui/src/chatwidget.rs`.
  
  ## Follow-On Refactor Phases
  
  The five-phase plan from #22269 is:
  
  - Phase 1: mechanical helper and state moves. Completed in #22269.
  - Phase 2: extract input and submission flow, including queued user
  messages, shell prompt submission, pending steer restoration, and thread
  input snapshot/restore behavior. This PR.
  - Phase 3: extract protocol, replay, streaming, and tool lifecycle
  handling, while preserving active-cell grouping, transcript
  invalidation, interrupt deferral, and final-message separator behavior.
  - Phase 4: extract settings, popups, and status surfaces, including
  model/reasoning/collaboration/personality popups, permission prompts,
  rate-limit UI, and connectors helpers.
  - 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-12 21:17:35 -07:00
  2630a6ca35
• Refactor chatwidget state into modules (#22269)

  ## Why
  
  `chatwidget.rs` is still carrying too many unrelated responsibilities in
  one file. After #21866 consolidated some of the state it tracks, this
  starts the next phase by moving coherent state/helper clusters out of
  the main module without changing behavior.
  
  This PR is intentionally mechanical: it only moves existing functions,
  structs, and helpers into focused modules so the boundaries are easier
  to review before the less mechanical refactors that should follow.
  
  ## What Changed
  
  - Moved user-message, composer, queue, pending steer, and merge/remap
  helpers into `codex-rs/tui/src/chatwidget/user_messages.rs`.
  - Added `codex-rs/tui/src/chatwidget/exec_state.rs` for unified exec
  bookkeeping helpers.
  - Added `codex-rs/tui/src/chatwidget/rate_limits.rs` for rate-limit
  warning, prompt, and error classification state.
  - Moved plugin list fetch and install auth-flow state into
  `codex-rs/tui/src/chatwidget/plugins.rs`.
  - Made a couple of test-only `VecDeque` imports explicit now that those
  tests no longer inherit the parent module import.
  
  ## Verification
  
  - `cargo test -p codex-tui` was run
  
  ## Follow-On Refactor Phases
  
  This PR is phase 1: mechanical helper and state moves. Planned follow-up
  PRs:
  
  - Phase 2: extract input and submission flow, including queued user
  messages, shell prompt submission, pending steer restoration, and thread
  input snapshot/restore behavior.
  - Phase 3: extract protocol, replay, streaming, and tool lifecycle
  handling, while preserving active-cell grouping, transcript
  invalidation, interrupt deferral, and final-message separator behavior.
  - Phase 4: extract settings, popups, and status surfaces, including
  model/reasoning/collaboration/personality popups, permission prompts,
  rate-limit UI, and connectors helpers.
  - 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-12 17:33:33 -07:00
  92930a8d40
• [codex] Remove workspace owner usage nudge gate (#20509)

  ## Summary
  - make workspace owner nudge handling unconditional in the TUI now that
  it is fully rolled out
  - keep `workspace_owner_usage_nudge` as a removed no-op compatibility
  flag so old configs/app overrides remain accepted during rollout
  - remove flag-disabled test setup
  
  ## Companion PR
  - https://github.com/openai/openai/pull/876351 removes the Codex Apps
  Statsig rollout gate override after this change is available to the
  app/runtime path
  
  ## Validation
  - `just write-config-schema`
  - `just fmt`
  - `cargo test -p codex-features`
  - `cargo test -p codex-tui status_and_layout`

  richardopenai · 2026-05-12 17:07:33 -07:00
  b6e718591b
• 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
• fix(tui): handle hidden app git directives (#21946)
  Felipe Coury · 2026-05-11 21:08:40 -03:00
  e16b4e46d4
• 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
• feat(tui): render responsive Markdown tables in TUI (#22052)

  ## Why
  
  The TUI currently treats Markdown tables as ordinary wrapped text, which
  makes table-heavy responses hard to read and brittle across narrow panes
  and terminal resizes.
  
  This change teaches the TUI to render Markdown tables responsively while
  preserving the raw Markdown source needed to re-render streamed and
  finalized transcript content after width changes. The goal is to keep
  tables legible during streaming, after resize, and once a turn has
  finished, without corrupting scrollback ordering.
  
  ## What Changed
  
  - add table detection and responsive table rendering in the Markdown
  renderer
  - render standard tables with Unicode box-drawing borders when the pane
  is wide enough
  - add a vertical readability fallback for constrained or dense tables so
  narrow panes still show each row clearly
  - keep links and `<br>` content inside table cells instead of leaking
  text outside the table
  - avoid table normalization inside fenced or indented code blocks
  - preserve raw streamed Markdown source and keep the active table as a
  mutable tail until finalization
  - consolidate finalized streamed content into source-backed transcript
  cells so post-resize re-rendering stays correct
  - add snapshot and targeted streaming/resize regression coverage for the
  new table behavior
  
  ## How to Test
  
  1. Start Codex TUI from this branch.
  2. Paste this exact prompt:
  `This is a session to test codex, no need to do any thinking, just end
  different markdown tables, with columns exploring different markdown
  contents, like links, bold italic, code, etc. Make them different sizes,
  some 30+ rows, some not and intertwine them with some paragraphs with
  complex formatting as well.`
  3. Confirm the response includes several Markdown tables mixed with
  richly formatted paragraphs.
  4. Confirm wide-enough tables render with box-drawing borders instead of
  plain wrapped pipe text.
  5. Resize the terminal narrower while the answer is still streaming and
  confirm the in-progress table stays coherent instead of duplicating
  headers or leaving broken scrollback behind.
  6. Resize again after the turn finishes and confirm the finalized
  transcript re-renders cleanly at the new width.
  7. In a narrow pane, verify dense tables fall back to the vertical
  per-row layout instead of producing unreadable wrapped columns.
  8. Also verify pipe-heavy fenced code blocks still render as code, not
  as tables.
  
  Targeted tests:
  - `cargo test -p codex-tui table_readability_fallback --no-fail-fast`
  - `cargo test -p codex-tui markdown_render --no-fail-fast`
  - `cargo test -p codex-tui streaming::controller --no-fail-fast`
  - `cargo test -p codex-tui table_resize_lifecycle --no-fail-fast`
  
  ## Docs
  
  No developer docs update appears necessary.

  Felipe Coury · 2026-05-10 20:42:11 +00:00
  5248e3da2b
• Split ChatWidget state into focused modules (#21866)

  ## Summary
  
  `ChatWidget` has been carrying several independent domains in one large
  state bag: transcript bookkeeping, turn lifecycle, queued input, status
  surfaces, connectors, review mode, and protocol dispatch. That makes
  otherwise-local changes hard to reason about because unrelated fields
  and side effects live beside each other in `chatwidget.rs`.
  
  This is the first cleanup PR in a larger decomposition effort. It does
  not try to make `chatwidget.rs` small in one sweep; instead, it
  establishes focused state boundaries that later handler, popup,
  rendering, and effect-synchronization extractions can build on.
  
  This PR keeps `ChatWidget` as the composition layer while moving focused
  state into smaller `codex-tui` modules. The widget still owns effects
  that touch the bottom pane, app events, command submission, redraw
  scheduling, and terminal-title updates.
  
  ## Changes
  
  - Add focused state modules under `codex-rs/tui/src/chatwidget/` for
  input queues, turn lifecycle, transcript bookkeeping, status state,
  connectors, review mode, and app-server protocol dispatch.
  - Update `ChatWidget` to hold grouped state structs and route
  input/lifecycle/status operations through those focused helpers.
  - Move app-server notification dispatch into `chatwidget/protocol.rs`
  while leaving feature handlers and side effects on `ChatWidget`.
  - Replace the large manual `ChatWidget` test literal with the normal
  constructor plus narrow test overrides, so future state moves do not
  require every field to be restated in test setup.
  - Update existing tests to access the new grouped state or narrower
  helpers without changing snapshot behavior.
  
  ## Longer-term direction
  
  Follow-up PRs can continue shrinking `chatwidget.rs` by moving behavior,
  not just state, into focused modules:
  
  - Extract input/submission flow, turn/stream handling, and tool-cell
  lifecycles into domain modules that call the new state reducers.
  - Move popup/settings builders and rendering helpers out of the main
  widget file so `ChatWidget` stays focused on composition.
  - Reduce direct `BottomPane` mutation by applying domain-specific sync
  outputs at clearer boundaries.

  Eric Traut · 2026-05-09 15:16:01 -07:00
  789b7e39dc
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• Load configured environments from CODEX_HOME (#20667)

  ## Why
  
  The earlier PRs add stdio transport support and the config-backed
  environment provider, but the feature remains inert until normal Codex
  entrypoints construct `EnvironmentManager` with enough context to
  discover `CODEX_HOME/environments.toml`. This final stack PR activates
  the provider while preserving the legacy `CODEX_EXEC_SERVER_URL`
  fallback when no environments file exists.
  
  **Stack position:** this is PR 5 of 5. It is the product wiring PR that
  activates the configured environment provider added in PR 4.
  
  ## What Changed
  
  - Thread `codex_home` into `EnvironmentManagerArgs`.
  - Change `EnvironmentManager::new(...)` to load the provider from
  `CODEX_HOME`.
  - Preserve legacy behavior by falling back to
  `DefaultEnvironmentProvider::from_env()` when `environments.toml` is
  absent.
  - Make `environments.toml`-backed managers start new threads with all
  configured environments, default first, while keeping the legacy env-var
  path single-default.
  - Update the app-server, TUI, exec, MCP server, connector, prompt-debug,
  and thread-manager-sample callsites to pass `codex_home` and handle
  provider-loading errors.
  
  ## Self-Review Notes
  
  - The multi-environment startup path is intentionally tied to the
  `environments.toml` provider. Using `>1` configured environment as the
  only signal would also expand the legacy `CODEX_EXEC_SERVER_URL`
  provider because it keeps `local` addressable alongside `remote`.
  - The startup environment list is still derived inside
  `EnvironmentManager`; the provider only says whether its snapshot should
  start new threads with all configured environments.
  - The thread-manager sample was updated to pass the current
  `ThreadManager::new(...)` installation id argument so the stack compiles
  under Bazel.
  
  ## Stack
  
  - 1. https://github.com/openai/codex/pull/20663 - Add stdio exec-server
  listener
  - 2. https://github.com/openai/codex/pull/20664 - Add stdio exec-server
  client transport
  - 3. https://github.com/openai/codex/pull/20665 - Make environment
  providers own default selection
  - 4. https://github.com/openai/codex/pull/20666 - Add CODEX_HOME
  environments TOML provider
  - **5. This PR:** https://github.com/openai/codex/pull/20667 - Load
  configured environments from CODEX_HOME
  
  Split from original draft: https://github.com/openai/codex/pull/20508
  
  ## Validation
  
  - `just fmt`
  - `git diff --check`
  - `bazel build --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/thread-manager-sample:codex-thread-manager-sample`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel
  //codex-rs/exec-server:exec-server-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=default_thread_environment_selections_use_manager_default_id
  //codex-rs/core:core-unit-tests`
  - `bazel test --config=remote --strategy=remote
  --remote_download_toplevel --test_sharding_strategy=disabled
  --test_arg=start_thread_uses_all_default_environments_from_codex_home
  //codex-rs/core:core-unit-tests`
  
  ## Documentation
  
  This activates `CODEX_HOME/environments.toml`; user-facing documentation
  should be added before this stack is treated as a documented public
  workflow.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-05-08 11:17:56 -07:00
  5f2543b74e
• [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
• Show permissions and approval mode in the TUI status line (#21677)

  Fixes #21665.
  
  ## Why
  
  The TUI status line is the right place for compact, glanceable session
  state. The original request was motivated by the need to see the active
  permission posture without opening `/permissions` or `/status`,
  especially when switching between safer and more permissive modes during
  a session.
  
  This PR intentionally separates `permissions` from `approval-mode`
  instead of combining them into one status-line item. They answer related
  but different questions: `permissions` describes the active
  sandbox/profile shape, while `approval-mode` describes how command
  approvals are handled. Keeping them separate makes each item
  independently configurable and avoids long combined labels in an already
  space-constrained status line.
  
  The tradeoff is that users who want the full permission posture in the
  status line need to opt into both items. In exchange, users can show
  only the sandbox/profile label, only the approval behavior, or both, and
  named user-defined profiles remain concise. Non-standard permission
  shapes are rendered as `Custom permissions` rather than trying to
  squeeze detailed profile contents into the status line; `/status`
  remains the fuller explanatory surface.
  
  ## What changed
  
  - Added a configurable `permissions` status-line item.
  - Added a separate `approval-mode` status-line item, with `approval` as
  an alias.
  - Render standard permission states compactly as `Read Only`,
  `Workspace`, or `Full Access`.
  - Preserve user-defined permission profile names directly in the status
  line.
  - Render unnamed non-standard permission shapes as `Custom permissions`.
  - Refresh status surfaces when `/permissions` updates the permission
  profile, approval policy, or approval reviewer.
  - Updated status-line preview snapshot coverage for the new items.
  
  ## Verification
  
  - `cargo test -p codex-tui
  status_permissions_non_default_workspace_write_uses_workspace_label`
  - `cargo test -p codex-tui
  permissions_selection_emits_history_cell_when_selection_changes`
  - `cargo insta pending-snapshots --manifest-path tui/Cargo.toml`

  Eric Traut · 2026-05-08 08:03:11 -07:00
  e6312d44f0
• [codex-analytics] plumb protocol-native review timing (#21434)

  ## Why
  
  We want terminal tool review analytics, but the reducer should not stamp
  review timing from its own wall clock.
  
  This PR plumbs review timing through the real protocol and app-server
  seams so downstream analytics can consume the emitter's timestamps
  directly. Guardian reviews keep their enriched `started_at` /
  `completed_at` analytics fields by deriving those legacy second-based
  values from the same protocol-native millisecond lifecycle timestamps,
  rather than sampling a separate analytics clock.
  
  ## What changed
  
  - add `started_at_ms` to user approval request payloads
  - add `started_at_ms` / `completed_at_ms` to guardian review
  notifications
  - preserve Guardian review `started_at` / `completed_at` enrichment from
  the protocol-native timing source
  - stamp typed `ServerResponse` analytics facts with app-server-observed
  `completed_at_ms`
  - thread the new timing fields through core, protocol, app-server, TUI,
  and analytics fixtures
  
  ## Verification
  
  - `cargo test -p codex-app-server outgoing_message --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-app-server-protocol guardian --manifest-path
  codex-rs/Cargo.toml`
  - `cargo test -p codex-tui guardian --manifest-path codex-rs/Cargo.toml`
  - `cargo test -p codex-analytics analytics_client_tests --manifest-path
  codex-rs/Cargo.toml`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/21434).
  * #18748
  * __->__ #21434
  * #18747
  * #17090
  * #17089
  * #20514

  rhan-oai · 2026-05-07 20:31:41 -07:00
  99016ec732
• [codex] Dedupe fallback model metadata warnings (#21090)

  Fixes #21070.
  
  This is a small cleanup around model metadata handling for
  gateway/provider model names. It follows the report and proposed
  direction from @dkbush by keeping the fallback metadata warning useful
  without repeating it every turn, and by tightening the existing
  provider-prefix lookup path.
  
  - Track fallback metadata warning slugs in session state so each
  unresolved model warns once per session.
  - Keep warning emission outside the session-state lock and preserve the
  existing warning text.
  - Allow one-segment provider prefixes with hyphenated provider IDs,
  while preserving the multi-segment rejection behavior.
  - Add focused coverage for warning dedupe and hyphenated provider-prefix
  metadata matching.
  
  Testing:
  
  - Ran `just fmt`.
  - Ran `git diff --check`.
  - Added tests for the new warning dedupe and provider-prefix lookup
  behavior.

  canvrno-oai · 2026-05-06 13:11:44 -07:00
  d5f0b6d63a
• 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
• 2- Use string service tiers in session protocol (#20971)

  ## Summary
  - break service tier session/op/app-server protocol fields from the
  closed enum to string tier ids
  - send the service tier string directly through model requests, prewarm,
  compaction, memories, and TUI/app-server turn starts
  - regenerate app-server protocol JSON/TypeScript schemas, removing the
  standalone ServiceTier TS enum
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-app-server -p codex-tui
  - just write-app-server-schema
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-06 18:00:21 +03:00
  be1d3cff93
• 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 turn items view to app-server turns (#21063)

  ## Why
  
  `Turn.items` currently overloads an empty array to mean either that no
  items exist or that the server intentionally did not load them for this
  response. That ambiguity blocks future lazy-loading work where clients
  need to distinguish unloaded, summary, and fully hydrated turn payloads.
  
  ## What changed
  
  - add a new `TurnItemsView` enum with `notLoaded`, `summary`, and `full`
  variants
  - add required `itemsView` metadata to app-server `Turn` payloads
  - mark reconstructed persisted history as `full` and live shell-style
  turn payloads as `notLoaded`
  - keep current `thread/turns/list` behavior unchanged and document that
  it still returns `full` turns today
  - regenerate the JSON and TypeScript protocol fixtures
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server thread_read_can_include_turns`
  - `cargo test -p codex-app-server
  thread_turns_list_can_page_backward_and_forward`
  - `cargo test -p codex-app-server
  thread_resume_rejects_history_when_thread_is_running`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fmt`

  rhan-oai · 2026-05-05 19:17:16 +00:00
  9e0c191c13
• feat(tui): add raw scrollback mode (#20819)

  ## Why
  
  Granular copy is particularly difficult with the current output. Part of
  it was solved with the introduction of the `/copy` command but when you
  only need to copy parts of a response, you still encounter some issues:
  
  - When you copy a paragraph, the result is a sequence of separate lines
  instead of one correctly joined paragraph.
  - When a word wraps, part of it stays on the original line and the rest
  appears at the start of the next line.
  - When you copy a long command, extra line breaks are often inserted,
  and command arguments can be split across multiple lines.
  
  
  https://github.com/user-attachments/assets/0ef85c84-9363-4aad-b43a-15fce062a443
  
  ## Solution
  
  Now that we own the scrollback and we re-create it when we resize, we
  have the opportunity of toggling between the raw text and the rich text
  we see today.
  
  - Add TUI raw scrollback mode with `tui.raw_output_mode`, `/raw
  [on|off]`, and the configurable `tui.keymap.global.toggle_raw_output`
  action.
  - Render transcript cells through rich/raw-aware paths so raw mode
  preserves source text and lets the terminal soft-wrap selection-friendly
  output.
  - Bind raw-mode toggle to `alt-r` by default, with the keybinding path
  toggling silently while `/raw` continues to emit confirmation messages.
  
  ## Related Issues
  
  Likely addressed by raw mode:
  
  - #12200: clean copy for multiline and soft-wrapped output. Raw mode
  removes Codex-inserted wrapping/indentation and lets the terminal
  soft-wrap logical lines.
  - #9252: command suggestions gain unwanted leading spaces when copied.
  Raw mode renders transcript text without the rich-mode left
  padding/gutter.
  - #8258: prompt output is hard to copy because of leading indentation.
  Raw mode renders user/source-backed transcript text without that
  decorative indentation.
  
  Partially or conditionally addressed:
  
  - #2880: copy/export message as Markdown. Raw mode exposes raw Markdown
  for terminal selection, but this PR does not add a dedicated
  export/copy-message command.
  - #19820: mouse drag selection + copy in the TUI. Raw mode improves
  terminal-native selection of output/history text, but this PR does not
  implement in-TUI mouse selection, highlighting, auto-copy, or composer
  selection.
  - #18979: copied content is divided into two parts. This should improve
  cases caused by Codex-inserted wraps/padding in rendered output; if the
  report is about pasting into the composer/input path, that remains
  outside this PR.
  
  ## Validation
  
  - `just write-config-schema`
  - `just fmt`
  - `cargo test -p codex-config`
  - `cargo test -p codex-tui`
  - `just fix -p codex-tui`
  - `just argument-comment-lint`
  - `cargo test -p codex-tui
  raw_output_mode_can_change_without_inserting_notice -- --nocapture`
  - `cargo test -p codex-tui
  raw_slash_command_toggles_and_accepts_on_off_args -- --nocapture`
  - `cargo test -p codex-tui raw_output_toggle -- --nocapture`
  - `git diff --check`
  - `cargo insta pending-snapshots`

  Felipe Coury · 2026-05-05 11:17:47 -07:00
  5e0a4adbe5
• Validate /goal objective length in TUI (#20746)

  ## Why
  
  Long `/goal` definitions currently reach lower-level goal validation and
  can produce an opaque failure. This bug was reported by a user. Pasted
  instruction blocks are especially confusing because the composer can
  still contain a paste placeholder before expansion, which may otherwise
  fall into the generic prompt-size error path.
  
  There was also a related paste edge case where `/goal ` followed by a
  multiline block whose first pasted line was blank looked like a bare
  `/goal` command. That showed the goal usage/summary instead of setting
  the pasted objective.
  
  ## What Changed
  
  This adds TUI-side preflight validation for `/goal <objective>` using
  the shared `MAX_THREAD_GOAL_OBJECTIVE_CHARS` limit. Oversized typed,
  queued, and pasted goal objectives now fail locally with a goal-specific
  message that recommends putting longer instructions in a file and
  referencing that file from the goal.
  
  The TUI now also lets inline-argument slash commands consume later-line
  arguments before treating the first line as a bare command, so `/goal `
  followed by blank lines and then objective text sets the goal instead of
  opening the bare `/goal` flow.
  
  ## Manual Testing
  
  1. Start the TUI with goals enabled and an active session.
  2. Submit `/goal ` followed by exactly 4,000 objective characters. It
  should continue through the normal goal-setting path.
  3. Submit `/goal ` followed by 4,001 objective characters. It should not
  set a goal, and should show `Goal objective is too long: 4,001
  characters. Limit: 4,000 characters.` followed by the guidance to put
  longer instructions in a file and reference that file from the goal.
  4. Type `/goal `, paste a large block that becomes a `[Pasted Content
  ... chars]` placeholder, then submit. It should validate the expanded
  pasted text and show the goal-specific file guidance rather than the
  generic prompt-size error.
  5. Type `/goal `, paste a multiline block whose first line is blank,
  then submit. It should set the objective from the non-blank pasted
  content instead of showing `Usage: /goal <objective>` or the bare goal
  summary.
  6. While a turn is running, queue an oversized `/goal` command. When the
  queue drains, it should show the same goal-specific error and should not
  emit a goal-setting request.

  Eric Traut · 2026-05-05 09:55:07 -07:00
  f09e1936e0
• [codex] Add unsandboxed process exec API (#19040)

  ## Why
  
  App-server clients sometimes need argv-based local process execution
  while sandbox policy is controlled outside Codex. Those environments can
  reject sandbox-disabling paths before a command ever starts, even when
  the caller intentionally wants unsandboxed execution.
  
  This PR adds a distinct `process/*` API for that use case instead of
  extending `command/exec` with another sandbox-disabling shape. Keeping
  the new surface separate also makes the future removal of `command/exec`
  simpler: clients that need explicit process lifecycle control can move
  to the newer handle-based API without depending on `command/exec`
  business logic.
  
  ## What changed
  
  - Added v2 process lifecycle methods: `process/spawn`,
  `process/writeStdin`, `process/resizePty`, and `process/kill`.
  - Added process notifications: `process/outputDelta` for streamed
  stdout/stderr chunks and `process/exited` for final exit status and
  buffered output.
  - Made `process/spawn` intentionally unsandboxed and omitted
  sandbox-selection fields such as `sandboxPolicy` and
  `permissionProfile`.
  - Added client-supplied, connection-scoped `processHandle` values for
  follow-up control requests and notification routing.
  - Supported cwd, environment overrides, PTY mode and size, stdin
  streaming, stdout/stderr streaming, per-stream output caps, and timeout
  controls.
  - Killed active process sessions when the originating app-server
  connection closes.
  - Wired the implementation through the modular `request_processors/`
  app-server layout, with process-handle request serialization for
  follow-up control calls.
  - Updated generated JSON/TypeScript schema fixtures and documented the
  new API in `codex-rs/app-server/README.md`.
  - Added v2 app-server integration coverage in
  `codex-rs/app-server/tests/suite/v2/process_exec.rs` for spawn
  acknowledgement before exit, buffered output caps, and process
  termination.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  Ruslan Nigmatullin · 2026-05-04 16:43:58 -07:00
  4950e7d8a6
• feat(tui): improve TUI keymap coverage (#20798)

  ## Summary
  - normalize terminal-emitted C0 control characters through configurable
  editor keymaps, covering raw control-key fallbacks like
  Shift+Enter-as-LF in terminals from #20555 and #20898, plus part of the
  modified-Enter behavior in #20580
  - add default-unbound keymap actions for toggling Fast mode and killing
  the current composer line, giving #20698 users a configurable zsh-style
  Ctrl+U option without changing the existing default Ctrl+U behavior
  - wire the new actions through gated /keymap picker entries, schema
  generation, and snapshot coverage
  
  Fixes #20555.
  Fixes #20898.
  
  ## Testing
  - just write-config-schema
  - just fmt
  - cargo test -p codex-config
  - cargo test -p codex-tui keymap::tests
  - cargo test -p codex-tui bottom_pane::textarea::tests
  - cargo test -p codex-tui keymap_setup::tests
  - cargo insta pending-snapshots
  - just fix -p codex-tui
  - git diff --check
  - just argument-comment-lint

  Felipe Coury · 2026-05-04 19:18:56 +00:00
  48402be6fa
• 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
• tui: retire /approvals and rename /autoreview to /approve (#21034)

  ## Why
  
  The TUI currently exposes overlapping command names for the same
  permissions flow: `/permissions` and the older `/approvals` alias. It
  also uses `/autoreview` for the manual retry flow, even though the
  action users take there is approving one denied auto-review request.
  
  This change makes the command surface consistent with the hard rebrand:
  - `/permissions` is the only command for permission settings.
  - `/approve` is the command for approving a recent auto-review denial.
  
  ## What changed
  
  - Removed the legacy `/approvals` slash command and its dispatch path.
  - Kept `/permissions` as the single permissions command shown and
  accepted by the TUI.
  - Renamed the auto-review denial command from `/autoreview` to
  `/approve`.
  - Updated nearby comments so they refer to `/permissions` rather than
  the retired `/approvals` name.
  
  ## Verification
  
  - Updated the slash-command unit test to assert that `AutoReview` now
  renders and parses as `approve`.

  Won Park · 2026-05-04 17:50:34 +00:00
  5c1ec8f4fd
• Clear live hook rows when turns finalize (#20674)

  # Why
  
  When a user interrupts a turn while a hook is still running, the normal
  turn status is cleared but the separate live hook row can remain visible
  as `Running` because the TUI may never receive a matching
  `HookCompleted` event before cancellation. Once the turn itself is
  finalized, that turn-scoped live state should not remain on screen.
  
  # What
  
  - clear any still-live `active_hook_cell` during turn finalization
  - add a regression snapshot covering an interrupted turn with a visible
  `PreToolUse` hook row
  
  # Testing
  
  - `cargo test -p codex-tui interrupted_turn_clears_visible_running_hook`
  - attempted `cargo test -p codex-tui` (currently aborts on unrelated
  existing stack overflow in
  `app::tests::discard_side_thread_removes_agent_navigation_entry`)

  Abhinav · 2026-05-01 14:48:22 -07:00
  d55479488e
• /plugins: add marketplace upgrade flow (#20478)

  This PR adds marketplace upgrade to the `/plugins` menu so users can
  update configured marketplaces. It adds a `Ctrl+U` shortcut on eligible
  marketplace tabs, a loading state, and the app-server request flow
  needed to perform `marketplace/upgrade`. After a successful upgrade, the
  TUI refreshes plugin data, plugin mentions, and user config so updated
  marketplace contents show up across the menu and other plugin surfaces.
  It also preserves the current marketplace tab on no-op and failure paths
  and surfaces backend error details directly in the TUI.
  
  - Add a `Ctrl+U` upgrade option for user-configured marketplace tabs in
  `/plugins`
  - Show the upgrade footer hint only on upgradeable marketplace tabs
  - Show a loading state during `marketplace/upgrade`
  - Surface already-up-to-date and per-marketplace failure results from
  the backend
  - Refresh plugin data, plugin mentions, and user config after successful
  upgrades
  - Add tests and snapshot updates for the shortcut flow, loading state,
  and failure messaging
  
  Steps to test:
  1. Add a `/plugin` marketplace to Codex TUI.
  2. Open `/plugins`, move to that marketplace tab, and confirm the footer
  shows `Ctrl+U` to upgrade.
  3. Press `Ctrl+U` and confirm the popup switches into an upgrade loading
  state.
  4. When the request finishes, confirm you see the expected result:
  updated marketplace contents on success, an already-up-to-date message
  on no-op, or backend error details on failure. On no-op or failure,
  confirm the popup stays on the same marketplace tab.

  canvrno-oai · 2026-05-01 11:26:29 -07:00
  610eefb86b
• 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
• fix: show correct Bedrock runtime endpoint in /status (#20275)

  ## Why
  
  `/status` was showing the configured `ModelProviderInfo.base_url` for
  Amazon Bedrock, which can be stale or misleading because the actual
  Bedrock Mantle endpoint is derived at runtime from the resolved AWS
  region. This made sessions report the wrong provider endpoint even
  though requests used the correct runtime URL.
  
  ## What changed
  
  - Added `ModelProvider::runtime_base_url()` so provider implementations
  can expose the request-time base URL through the shared runtime provider
  abstraction.
  - Moved Bedrock region-to-Mantle URL resolution into
  `amazon_bedrock::mantle::runtime_base_url()`, keeping region resolution
  private to the Mantle module.
  - Overrode `runtime_base_url()` for Amazon Bedrock so it returns the
  resolved Mantle endpoint instead of the configured default.
  - Resolved and cached the runtime provider base URL during TUI startup,
  then used that cached value when rendering `/status`.
  - Added status coverage that verifies Bedrock displays the runtime URL
  and ignores the configured Bedrock `base_url` when they differ.
  
  ## Verification
  model provider is resolved correctly in local build:
  <img width="696" height="245" alt="Screenshot 2026-04-29 at 5 01 36 PM"
  src="https://github.com/user-attachments/assets/a13c10a5-3720-41ab-8ace-3c4bc573f971"
  />

  Celia Chen · 2026-04-30 19:02:34 +00:00
  31f8813e3e
• 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
• /plugins: remove marketplace (#19843)

  This PR adds marketplace removal to the /plugins menu, giving users a
  way to remove user-configured plugin marketplaces. It adds a `Ctrl+R`
  shortcut to remove selected marketplace tabs, a confirmation prompt,
  loading and error states, and the app-server request flow needed to
  perform marketplace/remove. After a successful removal, the TUI
  refreshes config, plugin mentions, user config, and plugin data so the
  removed marketplace disappears from the menu and other surfaces in the
  TUI.
  
  - Add `Ctrl+R` removal option for user-configured marketplace tabs
  - Show marketplace removal confirmation, loading, and error states
  - Route `marketplace/remove` through the TUI background request flow
  - Refresh config, plugin mentions, and plugin data after successful
  removal
  - Adds reusable per-tab footer hints so removal guidance only appears on
  applicable tabs
  - Add test coverage for `Ctrl+R` behavior while plugin search is active
  
  Steps to test:
  - Add a marketplace using the TUI /plugins menu
  - Use Ctrl+R to remove the marketplace
  - Accept the confirmation prompt
  - Confirm the marketplace is removed when the process completes.

  canvrno-oai · 2026-04-30 10:25:07 -07:00
  a85d265097
• realtime: rename provider session ids (#20361)

  ## Summary
  
  Codex is repurposing `session` to mean a thread group, so the realtime
  provider session id should no longer use `session_id` / `sessionId` in
  Codex-facing protocol payloads. This PR renames that provider-specific
  field to `realtime_session_id` / `realtimeSessionId` and intentionally
  breaks clients that still send the old field names.
  
  ## What Changed
  
  - Renamed realtime provider session fields in `ConversationStartParams`,
  `RealtimeConversationStartedEvent`, and `RealtimeEvent::SessionUpdated`.
  - Renamed app-server v2 realtime request and notification fields to
  `realtimeSessionId`.
  - Removed legacy serde aliases for `session_id` / `sessionId`; clients
  must send the new names.
  - Propagated the rename through core realtime startup, app-server
  adapters, codex-api websocket handling, and TUI realtime state.
  - Regenerated app-server protocol schema/TypeScript outputs and updated
  app-server README examples.
  - Kept upstream Realtime API concepts unchanged: provider `session.id`
  parsing and `x-session-id` headers still use the upstream wire names.
  
  ## Testing
  
  - CI is running on the latest pushed commit.
  - Earlier local verification on this PR:
    - `cargo test -p codex-protocol`
  - `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-core
  realtime_conversation`
    - `cargo test -p codex-app-server-protocol`
  - `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-app-server
  realtime_conversation`
  - attempted `CODEX_SKIP_VENDORED_BWRAP=1 cargo test -p codex-tui` (local
  linker bus error while linking the test binary)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-30 13:39:48 +03:00
  8a97f3cf03
• permissions: expose active profile metadata (#20095)
  Michael Bolin · 2026-04-29 20:54:59 -07:00
  ac4332c05b
• Include auto-review rollout in feedback uploads (#20064)

  ## Summary
  
  - include the live auto-review trunk rollout when `/feedback` uploads
  logs
  - upload that attachment as
  `auto-review-rollout-<parent-thread-id>.jsonl` so it is distinguishable
  from the parent rollout
  - show the same auto-review attachment name in the TUI consent popup
  
  ## Scope
  
  - this only covers the live cached auto-review trunk for the current
  parent thread
  - it does not add durable historical parent->auto-review lookup
  - it does not add persisted rollout support for ephemeral parallel
  review forks
  
  ## UI 
  
  <img width="599" height="185" alt="Screenshot 2026-04-28 at 1 17 18 PM"
  src="https://github.com/user-attachments/assets/6a0e79c2-5d21-4702-8a89-f765778bc9e9"
  />
  
  ## Validation
  
  - `cargo test -p codex-core
  cached_guardian_subagent_exposes_its_rollout_path`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-tui feedback_upload_consent_popup_snapshot`
  - `cargo test -p codex-tui
  feedback_good_result_consent_popup_includes_connectivity_diagnostics_filename`
  
  ## Known unrelated local failures
  
  - `cargo test -p codex-core` currently fails in the pre-existing proxy
  env snapshot test
  `tools::runtimes::tests::maybe_wrap_shell_lc_with_snapshot_keeps_user_proxy_env_when_proxy_inactive`
  - `cargo test -p codex-tui` currently hits pre-existing `status::*`
  snapshot drift unrelated to this change
  
  ## Follow-Up 
  - persist parallel auto-review fork sessions so /feedback can include
  their rollout history too
  - attach each persisted fork as its own clearly named file, for example
  auto-review-rollout-<parent-thread-id>-fork <n>.jsonl, instead of
  merging multiple Guardian sessions into one attachment
  - keep the same live-session-only scope initially; durable historical
  parent -> auto-review lookup can remain a separate decision if we later
  need feedback from resumed sessions

  Won Park · 2026-04-29 11:44:55 -07:00
  5cf0adba93
• 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
• TUI: Remove core protocol dependency [1/7] (#20172)

  ## Why
  
  This is part 1 of a 7-PR stack to remove direct
  `codex_protocol::protocol` usage from `codex-tui` while keeping each
  layer reviewable and shippable.
  
  This first layer reduces the size of the later `chatwidget` diff by
  mechanically moving MCP startup bookkeeping out of the central widget
  file without changing the event shapes or behavior.
  
  ## What changed
  
  - Extracted MCP startup status handling into
  `tui/src/chatwidget/mcp_startup.rs`.
  - Kept the existing core event types in place for this purely mechanical
  move.
  - Updated the MCP startup tests to import the moved test-only event
  types directly.
  
  ## Verification
  
  - `cargo test -p codex-tui chatwidget::tests::mcp_startup`

  Eric Traut · 2026-04-29 09:10:22 -07:00
  1c420a90cd
• Restore TUI working status after steer message is set (#19939)

  Fix for #19925
  
  Restore the `Working` indicator after a streamed final answer finishes
  when a user steer message is sent.
  Add regression coverage for long output plus a mid-stream steer:
  `cargo test -p codex-tui
  final_answer_completion_restores_status_indicator_for_pending_steer`
  
  Duplication/testing steps:
  1. Start a new thread and ask for a long response.
  2. While the response is streaming, submit a steer message.
  3. When the first response finishes, observe whether `Working...` is
  shown while waiting for the steer message response.

  canvrno-oai · 2026-04-28 18:10:40 -07:00
  24be9ac0a4
• app-server: notify clients of remote-control status changes (#19919)

  ## Why
  
  Remote-control app-server enrollments have both an internal server id
  and the environment id exposed to remote-control clients. App-server
  clients need one current status snapshot that says whether remote
  control is usable and which environment id, if any, is exposed.
  
  A temporary websocket disconnect is not itself an identity change.
  Account changes, stale enrollment invalidation, successful
  re-enrollment, and missing ChatGPT auth are meaningful status changes.
  Disabled remote control remains `disabled` regardless of auth or SQLite
  state. SQLite startup failure disablement and enrollment persistence
  failures are handled in #20068; this PR reports the resulting effective
  status to clients.
  
  ## What changed
  
  - Adds v2 `remoteControl/status/changed` carrying `state` and
  `environmentId`.
  - Adds `RemoteControlConnectionState` values: `disabled`, `connecting`,
  `connected`, and `errored`.
  - Exposes remote-control status updates through `RemoteControlHandle`
  using a Tokio watch channel.
  - Always sends the current remote-control status snapshot to newly
  initialized app-server clients.
  - Broadcasts status changes to initialized app-server clients when state
  or environment id changes.
  - Treats missing ChatGPT auth as an `errored` status while leaving it
  retryable because auth can change at runtime.
  - Clears `environmentId` when enrollment is cleared for account changes,
  auth loss, stale backend invalidation, or disabled remote control.
  - Updates app-server protocol schema fixtures, generated TypeScript,
  app-server README, remote-control tests, and TUI exhaustive notification
  matches.
  
  ## Stack
  
  - Builds on #20068.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server transport::remote_control --lib`
  - `cargo check -p codex-tui`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`

  Ruslan Nigmatullin · 2026-04-28 23:52:14 +00:00
  c6465c1ec2
• /plugins: add marketplace install flow (#18704)

  This PR adds a new feature to the `/plugins` menu that gives users the
  ability to add new plugin marketplaces. It introduces an Add Marketplace
  tab to the right of installed marketplaces, a source prompt, loading and
  error states, and the app-server request flow needed to perform the
  install. After a successful `marketplace/add`, the popup refreshes back
  into the newly added marketplace tab so the new plugins are immediately
  visible.
  
  - Add an Add Marketplace tab to the `/plugins` menu
  - Prompt for marketplace source input from git repo, URL, or local path
  - Show loading and error states during `marketplace/add`
  - Refresh plugin data after success and switch into the newly added
  marketplace tab
  - Add tests and snapshot updates

  canvrno-oai · 2026-04-28 14:22:39 -07:00
  66b0781502
• tui: use permission profiles for sandbox state (#20008)

  ## Summary
  - Move TUI permission state from legacy `SandboxPolicy` values to
  canonical `PermissionProfile` values across presets, app events, chat
  widget state, app commands, thread routing, and cached thread session
  state.
  - Keep app-server compatibility boundaries explicit: embedded sessions
  send `permissionProfile`, while remote sessions send only a legacy
  `sandbox` projection and fall back to read-only when a custom profile
  cannot be projected.
  - Update status/add-dir UI summaries and snapshots to render the active
  permission profile, including workspace profiles selected by the new
  built-in defaults.
  
  ## Verification
  - `rg '\bSandboxPolicy\b' codex-rs/tui -n` returns no matches.
  - `cargo test -p codex-tui`
  - `cargo check -p codex-tui --tests`
  - `cargo test -p codex-tui additional_dirs`
  - `just fmt`
  - `just fix -p codex-tui`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/20008).
  * #20041
  * #20040
  * #20037
  * #20035
  * #20034
  * #20033
  * #20032
  * #20030
  * #20028
  * #20027
  * #20026
  * #20024
  * #20021
  * #20018
  * #20016
  * #20015
  * #20013
  * #20011
  * #20010
  * __->__ #20008

  Michael Bolin · 2026-04-28 20:36:48 +00:00
  3b74a4d3b1
• 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
• TUI: use cumulative turn duration for worked-for separator (#19929)

  ## Why
  
  Fixes #19814.
  
  The TUI's current `Worked for ...` timing behavior is a leftover from
  #9599. At that point, models could emit multiple assistant messages in
  one turn for preambles/commentary, but the TUI did not yet have a
  reliable signal that an assistant message was the final answer when it
  started streaming. To avoid showing an ever-growing elapsed time on each
  preamble separator, #9599 made the separator timer incremental by
  tracking elapsed time since the previous separator.
  
  That workaround is no longer the right model for the final
  completed-turn display. Since then, #16638 added protocol-native turn
  timing, including `duration_ms` on turn completion. With that cumulative
  duration available at the point where the TUI renders the completed-turn
  separator, the UI can show the actual turn duration directly instead of
  carrying per-separator timing state.
  
  ## What Changed
  
  - Thread `duration_ms` into `ChatWidget::on_task_complete` from both
  legacy `TurnCompleteEvent` handling and app-server `TurnCompleted`
  notifications.
  - Use `duration_ms` for the final `Worked for ...` separator, falling
  back to the status indicator timer only when the protocol duration is
  unavailable.
  - Keep mid-turn separators before later assistant text as plain visual
  dividers instead of clocked `Worked for ...` separators.
  - Remove the old incremental separator timer state and helper
  (`last_separator_elapsed_secs` / `worked_elapsed_from`).
  - Add a snapshot regression test for a turn that runs a command and then
  completes with a final answer, verifying the final separator uses the
  cumulative turn duration.
  
  ## Verification
  
  - `cargo test -p codex-tui
  final_worked_for_uses_cumulative_turn_duration_snapshot`
  - `just fix -p codex-tui`
  
  Manual repro prompt:
  
  ```text
  Manual timing repro. First send a short preamble/commentary sentence before using tools. Then run exactly this shell command: sleep 75; echo MANUAL_TIMING_DONE. After the command finishes, give a final answer that says "done". Do not skip the preamble.
  ```
  
  After this change, the mid-turn break before the final answer should be
  a plain divider, and the final completed-turn separator should show
  `Worked for ...` using the cumulative turn duration.
  
  Before:
  <img width="414" height="102" alt="Screenshot 2026-04-27 at 10 09 01 PM"
  src="https://github.com/user-attachments/assets/b9e2ce01-2460-40e4-a5c4-c9ba8add2557"
  />
  
  
  After:
  <img width="485" height="149" alt="Screenshot 2026-04-27 at 10 09 07 PM"
  src="https://github.com/user-attachments/assets/d24089ae-d4e2-41b6-b966-07c98706ead4"
  />

  Eric Traut · 2026-04-28 09:24:29 -07:00
  087c9c1f1f