655 Commits

• 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
• Fix goal update and add /goal edit command in TUI (#21954)

  ## Why
  
  Users have requested the ability to edit a goal's objective after a goal
  has been created. This PR exposes a new `/goal edit` command in the TUI
  to address this request.
  
  In the process of implementing this, I also noticed an existing bug in
  the goal runtime. When a goal's objective is updated through the
  `thread/goal/set` app server API, the goal runtime didn't emit a new
  steering prompt to tell the agent about the new objective. This PR also
  fixes this hole.
  
  ## What Changed
  
  - Adds `/goal edit` in the TUI, opening an edit box prefilled with the
  current goal objective.
  - Keeps active and paused goals in their current state, resets completed
  goals to active, keeps budget-limited goals budget-limited, and
  preserves the existing token budget.
  - Changes the existing `thread/goal/set` behavior so editing an
  objective preserves goal accounting instead of resetting it. The older
  reset-on-new-objective behavior was left over from before
  `thread/goal/clear`; clients that need to reset accounting can now clear
  the existing goal and create a new one.
  - Reuses the existing goal set API path; this does not add or change
  app-server protocol surface area.
  - Adds a dedicated goal runtime steering prompt when an externally
  persisted goal mutation changes the objective, so active turns receive
  the updated objective.
  
  ## Validation
  
  - Make sure `/goal edit` returns an error if no goal currently exists
  - Make sure `/goal edit` displays an edit box that can be optionally
  canceled with no side effects
  - Make sure that an edited goal results in a steer so the agent starts
  pursuing the new objective
  - Make sure the new objective is reflected in the goal if you use
  `/goal` to display the goal summary
  - Make sure that `/goal edit` doesn't reset the token budget, time/token
  accounting on the updated goal

  Eric Traut · 2026-05-11 10:49:19 -07:00
  1e65b3e0af
• Persist /goal commands in history (#21860)

  ## Summary
  
  A user reported that `/goal` was not saved to the TUI command history,
  which made it unavailable for later recall even though other accepted
  input paths persist history entries.
  
  This updates the TUI goal slash-command dispatch so successful `/goal`
  invocations append the command text to message history. The change
  covers the bare `/goal` menu command, goal control commands such as
  `/goal pause`, and objective-setting commands such as `/goal improve
  benchmark coverage`.
  
  ## Verification
  
  - `cargo test -p codex-tui goal_slash_command -- --nocapture`

  Eric Traut · 2026-05-11 08:43:55 -07:00
  2229c8daf2
• 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
• Improve hooks trust flow in TUI (#21755)

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

  Abhinav · 2026-05-09 21:17:30 +00:00
  6d747db7d8
• fix(tui): preserve wrapped prose beside URLs (#21760)

  ## Why
  
  Mixed prose lines that contained URLs started taking the URL-preserving
  wrapping path, but that path could split ordinary words mid-token. A
  follow-up issue remained in scrollback insertion: when already-rendered
  indented rows were wrapped again, continuation rows could lose their
  margin and fall back to terminal hard wrapping. Together those bugs made
  normal Markdown output look broken around links, lists, blockquotes, and
  indented content.
  
  Separately, the local argument-comment lint wrappers failed under
  environments that set `PYTHONSAFEPATH=1`, because Python no longer adds
  the script directory to `sys.path` automatically. That prevented the
  lint from reaching Rust callsites at all.
  
  <img width="1778" height="1558" alt="CleanShot 2026-05-09 at 11 51 38"
  src="https://github.com/user-attachments/assets/9274d150-1757-4f1a-89ac-5bdc9997d8cb"
  />
  
  ## What Changed
  
  - Preserve URL tokens without turning every neighboring prose word into
  a character-level split point.
  - Add a mixed URL/prose wrapper that keeps ordinary words whole,
  preserves leading whitespace, and re-splits long non-URL tokens against
  the actual width available on continuation rows.
  - Reuse a rendered history row's leading whitespace as the continuation
  indent when scrollback insertion has to pre-wrap it again.
  - Add regression coverage for markdown wrapping, history-cell rendering,
  scrollback continuation margins, leading-indent width accounting, and
  continuation-row re-splitting.
  - Make both argument-comment lint entrypoints explicitly add their own
  directory to `sys.path`, so sibling imports still work when
  `PYTHONSAFEPATH=1`.
  
  ## How to Test
  
  1. Start Codex and render a long Markdown response that mixes prose with
  inline links, blockquotes, lists, and indented code-like text.
  2. Confirm that ordinary words next to links stay whole instead of
  breaking mid-word.
  3. Resize or replay the transcript and confirm wrapped continuation rows
  keep their expected left margin for blockquotes, lists, and indented
  content.
  4. Run the source argument-comment lint from a shell with
  `PYTHONSAFEPATH=1` and confirm it starts normally instead of failing to
  import `wrapper_common`.
  
  Targeted tests:
  - `cargo test -p codex-tui mixed_line --lib`
  - `cargo test -p codex-tui preserves_prefix_on_wrapped_rows --lib`
  - `cargo test -p codex-tui
  agent_markdown_cell_does_not_split_words_after_inline_markdown --lib`
  - `cargo test -p codex-tui
  mixed_url_markdown_wraps_prose_without_splitting_words_snapshot --lib`
  - `python3 tools/argument-comment-lint/test_wrapper_common.py`
  - `just argument-comment-lint-from-source -p codex-tui -- --lib`
  
  Notes:
  - `cargo test -p codex-tui` currently reaches the new tests
  successfully, then still aborts in the pre-existing
  `tests::fork_last_filters_latest_session_by_cwd_unless_show_all`
  stack-overflow failure.

  Felipe Coury · 2026-05-09 13:58:10 -03:00
  f27cf9db09
• [codex] Lowercase TUI service tier commands (#21906)

  ## Why
  
  Service-tier slash commands are built from model-catalog metadata. If
  the catalog returns a name like `Fast`, the TUI currently exposes
  `/Fast` and exact dispatch expects that casing, which is inconsistent
  with the lowercase command style used elsewhere.
  
  ## What
  
  - Lowercase service-tier command names when converting catalog tiers
  into `ServiceTierCommand` values.
  - Add regression coverage that seeds a catalog tier named `Fast` and
  expects the generated command to be `fast`.
  
  ## Testing
  
  Not run locally per repo instruction; PR CI should run the new
  `service_tier_commands_lowercase_catalog_names` coverage.

  Ahmed Ibrahim · 2026-05-09 14:29:12 +03:00
  fca81eeb5b
• 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
• chore: thread tui (#21767)
  jif-oai · 2026-05-08 17:53:23 +02:00
  5b87bd2845
• 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
• Display blended token count in status line (#21669)

  ## Why
  
  The configurable `/statusline` and terminal title can display session
  token usage. That display was using the raw total token count, which
  includes cached input tokens, so it significantly overstated the token
  usage compared with the blended token count shown elsewhere (in
  `/status` and tracked in goals). This inconsistency resulted in user
  confusion. We don't want to report cached tokens because we don't charge
  for them and they are somewhat of an implementation detail that users
  shouldn't care about.
  
  ## What changed
  
  - Use `TokenUsage::blended_total()` for the `used-tokens` status surface
  item so cached input is excluded.
  - Add a brief comment to `tokens_in_context_window()` clarifying that it
  returns raw `total_tokens`, whose meaning depends on whether the caller
  has last-turn or accumulated usage.

  Eric Traut · 2026-05-08 07:56:13 -07:00
  f86d95a242
• Update models.json (#19896)

  Automated update of models.json.
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>

  github-actions[bot] · 2026-05-08 17:41:55 +03:00
  aadcae9f3c
• [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
• Show plugin hooks in plugin details (#21447)

  Supersedes the abandoned #19859, rebuilt on latest `main`.
  
  # Why
  
  PR #19705 adds discovery for hooks bundled with plugins, but `/plugins`
  still only shows skills, apps, and MCP servers. This follow-up makes
  bundled hooks visible in the same plugin detail view so users can
  inspect the full plugin surface in one place.
  
  We also need `PluginHookSummary` to populate Plugin Hooks in the app;
  `hooks/list` is not enough there because plugin detail needs to show
  hooks for disabled plugins too.
  
  # What
  
  - extend `plugin/read` with `PluginHookSummary` entries for bundled
  hooks
  - summarize plugin hooks while loading plugin details
  - render a `Hooks` row in the `/plugins` detail popup
  
  <img width="3456" height="848" alt="CleanShot 2026-04-27 at 11 45 34@2x"
  src="https://github.com/user-attachments/assets/fe3a38d6-a260-4351-8513-fb04c93d725b"
  />

  Abhinav · 2026-05-07 00:21:14 -07:00
  40e282849c
• Add compact lifecycle hooks (started by vincentkoc - external contrib) (#19905)

  Based on work from Vincent K -
  https://github.com/openai/codex/pull/19060
  
  <img width="1836" height="642" alt="CleanShot 2026-04-29 at 20 47 40@2x"
  src="https://github.com/user-attachments/assets/b647bb89-65fe-40c8-80b0-7a6b7c984634"
  />
  
  ## Why
  
  Compaction rewrites the conversation context that future model turns
  receive, but hooks currently have no deterministic lifecycle point
  around that rewrite. This adds compact lifecycle hooks so users can
  audit manual and automatic compaction, surface hook messages in the UI,
  and run post-compaction follow-up without overloading tool or prompt
  hooks.
  
  ## What Changed
  
  - Added `PreCompact` and `PostCompact` hook events across hook config,
  discovery, dispatch, generated schemas, app-server notifications,
  analytics, and TUI hook rendering.
  - Added trigger matching for compact hooks with the documented `manual`
  and `auto` matcher values.
  - Wired `PreCompact` before both local and remote compaction, and
  `PostCompact` after successful local or remote compaction.
  - Kept compact hook command input to lifecycle metadata: session id,
  Codex turn id, transcript path, cwd, hook event name, model, and
  trigger.
  - Made compact stdout handling consistent with other hooks: plain stdout
  is ignored as debug output, while malformed JSON-looking stdout is
  reported as failed hook output.
  - Added integration coverage for compact hook dispatch, trigger
  matching, post-compact execution, and the audited behavior that
  `decision:"block"` does not block compaction.
  
  ## Out of Scope
  
  - Hook-specific compaction blocking is not implemented;
  `decision:"block"` and exit-code-2 blocking semantics are intentionally
  unsupported for `PreCompact`.
  - Custom compaction instructions are not exposed to compact hooks in
  this PR.
  - Compact summaries, summary character counts, and summary previews are
  not exposed to compact hooks in this PR.
  
  ## Verification
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core
  manual_pre_compact_block_decision_does_not_block_compaction`
  - `cargo test -p codex-app-server hooks_list`
  - `cargo test -p codex-core config_schema_matches_fixture`
  - `cargo test -p codex-tui hooks_browser`
  
  ## Docs
  
  The developer documentation for Codex hooks should be updated alongside
  this feature to document `PreCompact` and `PostCompact`, the
  `manual`/`auto` matcher values, and the compact hook payload fields.
  
  ---------
  
  Co-authored-by: Vincent Koc <vincentkoc@ieee.org>

  Andrei Eternal · 2026-05-06 18:08:31 -07:00
  527d52df03
• feat: Add marketplace source filtering and plugin share context (#21419)

  Adds marketplaceKinds to plugin/list for local, workspace-directory, and
  shared-with-me; omitted params keep default local plus gated global
  behavior, while explicit kinds are exact.
  
  Exposes shareContext on plugin summaries from local share mappings and
  remote workspace/shared responses, including remotePluginId and nullable
  creator metadata.
  
  Adds shared-with-me listing through /ps/plugins/workspace/shared,
  renames the workspace remote namespace to workspace-directory, and keeps
  direct remote read/share/install/update/delete paths gated by plugins
  rather than remote_plugin.

  xl-openai · 2026-05-06 16:12:23 -07:00
  11106016ff
• [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
• fix(tui): persist ctrl-c draft via app event (#21397)

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

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

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

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

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

  pakrym-oai · 2026-05-06 08:35:42 -07:00
  2004173cd7
• 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
• feat: add session_id (#20437)

  ## Summary
  
  Related to
  https://openai.slack.com/archives/C095U48JNL9/p1777537279707449
  TLDR:
  We update the meaning of session ids and thread ids:
  * thread_id stays as now
  * session_id become a shared id between every thread under a /root
  thread (i.e. every sub-agent share the same session id)
  
  This PR introduces an explicit `SessionId` and threads it through the
  protocol/client boundary so `session_id` and `thread_id` can diverge
  when they need to, while preserving compatibility for older serialized
  `session_configured` events.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-05-06 10:48:37 +02:00
  a98623511b
• 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
• Expose plugin manifest keywords in app server (#21271)

  ## Summary
  - Add plugin manifest keywords to core plugin marketplace/detail models
  - Expose keywords on app-server v2 PluginSummary and generated
  schema/types
  - Populate keywords in plugin/list and plugin/read responses for local
  plugins
  
  Depends on https://github.com/openai/openai/pull/891087
  
  ## Validation
  - just fmt
  - just write-app-server-schema
  - cargo test -p codex-app-server-protocol
  - cargo test -p codex-core-plugins
  - cargo test -p codex-app-server
  plugin_list_keeps_valid_marketplaces_when_another_marketplace_fails_to_load
  - cargo test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents

  Abdulrahman Alfozan · 2026-05-06 02:09:05 +00:00
  94db03d5af
• feat(tui): route /diff through workspace commands (#21001)

  Stacked on #20892.
  
  ## Why
  
  #20892 adds the TUI workspace command abstraction so branch status
  metadata can run through app-server instead of assuming the CLI process
  has the active workspace locally. `/diff` still used direct local
  process execution, which means remote app-server sessions could compute
  the diff against the wrong machine or fail to see the active workspace
  at all.
  
  This PR moves `/diff` onto that same app-server-backed command path so
  Git runs wherever the active workspace lives.
  
  ## What Changed
  
  - Route `/diff` through the TUI `WorkspaceCommandExecutor` using the
  active chat cwd.
  - Replace direct `tokio::process::Command` usage in `get_git_diff` with
  argv-based workspace command requests.
  - Preserve the existing `/diff` behavior: tracked diff output, untracked
  file diffs, treating Git diff exit code `1` as success, and showing the
  existing non-git-repository message.
  - Extend `WorkspaceCommand` with caller-set timeouts and an explicit
  uncapped-output opt-out. Metadata probes remain capped by default;
  `/diff` opts out because its full output is the user-visible payload.
  
  ## How to Test
  
  Manual reviewer path:
  
  1. Start the Codex TUI from a Git worktree with one tracked file change
  and one untracked file.
  2. Run `/diff`.
  3. Confirm the rendered diff includes both the tracked diff and the
  untracked file diff.
  4. Start the TUI outside a Git worktree, or switch to a non-git cwd,
  then run `/diff`.
  5. Confirm it shows the existing `/diff` not-inside-a-git-repository
  message.
  
  Targeted tests run:
  
  - `cargo test -p codex-tui get_git_diff -- --nocapture`
  - `cargo test -p codex-tui branch_summary -- --nocapture`
  - `cargo test -p codex-tui`

  Felipe Coury · 2026-05-05 17:09:25 -03:00
  52fbbe7cdd
• 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
• 1- Add model service tiers metadata (#20969)

  ## Why
  
  The model list needs to carry display-ready service tier metadata so
  clients can render tier choices with stable IDs, names, and
  descriptions. A raw speed-tier string list is not enough for richer UI
  copy or future tier labels.
  
  ## What changed
  
  - Added `ModelServiceTier` to shared model metadata with string `id`,
  `name`, and `description` fields.
  - Added `service_tiers` to `ModelInfo` and `ModelPreset`, preserving
  empty defaults for older cached model payloads.
  - Exposed `serviceTiers` on app-server v2 `Model` responses and threaded
  it through TUI app-server model conversion.
  - Marked legacy `additional_speed_tiers` / `additionalSpeedTiers`
  metadata as deprecated in source and generated schema output.
  - Regenerated app-server protocol JSON schema and TypeScript fixtures,
  including `ModelServiceTier.ts`.
  
  ## Verification
  
  - Ran `just write-app-server-schema`.
  - Did not run local tests per repo instruction; relying on PR CI.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-05-05 09:51:18 +03:00
  9d579813bb
• Add plugin ID to skill analytics (#20923)

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

  alexsong-oai · 2026-05-04 20:36:29 -07:00
  3ad7cf0993
• [codex-analytics] add item lifecycle timing (#20514)

  ## Why
  
  Tool families already disagree on what their existing `duration` fields
  mean, so lifecycle latency should live on the shared item envelope
  instead of being inferred from per-tool execution fields. Carrying that
  envelope through app-server notifications gives downstream consumers one
  reusable timing signal without pretending every tool has the same
  execution semantics.
  
  ## What changed
  
  - Adds `started_at_ms` to core `ItemStartedEvent` values and
  `completed_at_ms` to core `ItemCompletedEvent` values.
  - Populates those timestamps in the shared session lifecycle emitters,
  so protocol-native items get timing without each producer tracking its
  own clock state.
  - Exposes `startedAtMs` on app-server `item/started` notifications and
  `completedAtMs` on `item/completed` notifications.
  - Maps the lifecycle timestamps through the app-server boundary while
  leaving legacy-converted notifications nullable when no lifecycle
  timestamp exists.
  - Regenerates the app-server JSON schema and TypeScript fixtures for the
  notification-envelope change and updates downstream fixtures that
  construct those notifications directly.
  - Extends the existing web-search and image-generation integration flows
  to assert the new lifecycle timestamps on the native item events.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-tui -p codex-exec
  -p codex-app-server-client`
  - `cargo test -p codex-core --test all web_search_item_is_emitted`
  - `cargo test -p codex-core --test all
  image_generation_call_event_is_emitted`
  - `cargo test -p codex-app-server-protocol`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/20514).
  * #18748
  * #18747
  * #17090
  * #17089
  * __->__ #20514

  rhan-oai · 2026-05-04 22:33:20 +00:00
  aee1fe2659
• 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
• feat(tui): add keymap debug inspector (#20794)

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

  Felipe Coury · 2026-05-04 14:40:50 -03:00
  94800ecbbf
• Keep paused goals paused on thread resume (#20790)

  ## Summary
  
  Early adopters of the `/goal` feature have provided feedback that they
  expect a goal they explicitly paused to remain paused when they resume a
  thread. Previously, resuming a thread would reactivate a paused goal.
  
  This PR keeps persisted goal status unchanged during thread resume. This
  honors the user feedback while also simplifying the core goal logic.
  
  Rather than have the core logic automatically resume a paused goal, that
  responsibility is transferred to the client. The TUI now detects a
  resumed thread with a paused goal and asks the user whether to `Resume
  goal` or `Leave paused`. The prompt appears only for quiet resume flows,
  so users who resume with an immediate prompt are not interrupted.
  
  <img width="544" height="111" alt="image"
  src="https://github.com/user-attachments/assets/0ac9de1c-6ee6-47ba-b223-c03c8eb4c192"
  />

  Eric Traut · 2026-05-04 08:58:07 -07:00
  3c2dcbef85
• 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
• Enforce animations = false for screen readers (#20564)

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

  Eric Traut · 2026-05-01 09:07:56 -07:00
  227bee0445
• 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
• Format multi-day goal durations in the TUI (#20558)

  ## Why
  
  Goal mode shows elapsed time in compact hour/minute form. That is easy
  to scan for shorter runs, but once a goal runs past 24 hours, large hour
  counts become harder to read at a glance.
  
  ## What changed
  
  Updated `codex-rs/tui/src/goal_display.rs` so unbudgeted goal elapsed
  time keeps the existing compact format below one day, then switches to a
  day-aware format once the elapsed time reaches 24 hours:
  
  - `23h 59m`
  - `1d 0h 0m`
  - `2d 23h 42m`
  
  The formatter now covers the 24-hour boundary in unit tests, and the TUI
  status-line snapshot for a completed elapsed goal now exercises the
  multi-day display.
  
  ## Verification
  
  - `cargo test -p codex-tui`
  
  Here's my longest-running test task:
  
  <img width="186" height="23" alt="image"
  src="https://github.com/user-attachments/assets/cedfcdab-7f6e-44e6-8495-8a39f63973fb"
  />

  Eric Traut · 2026-04-30 22:42:07 -07:00
  d898cc8f3f
• [codex] Remove unused event messages (#20511)

  ## Why
  
  Several legacy `EventMsg` variants were still emitted or mapped even
  though clients either ignored them or had moved to item/lifecycle
  events. `Op::Undo` had also degraded to an unavailable shim, so this
  removes that dead task path instead of preserving a command that cannot
  do useful work.
  
  `McpStartupComplete`, `WebSearchBegin`, and `ImageGenerationBegin` are
  intentionally kept because useful consumers still depend on them: MCP
  startup completion drives readiness behavior, and the begin events let
  app-server/core consumers surface in-progress web-search and
  image-generation items before the final payload arrives.
  
  ## What Changed
  
  - Removed weak legacy event variants and payloads from `codex-protocol`,
  including legacy agent deltas, background events, and undo lifecycle
  events.
  - Kept/restored `EventMsg::McpStartupComplete`,
  `EventMsg::WebSearchBegin`, and `EventMsg::ImageGenerationBegin` with
  serializer and emission coverage.
  - Updated core, rollout, MCP server, app-server thread history,
  review/delegate filtering, and tests to rely on the useful replacement
  events that remain.
  - Removed `Op::Undo`, `UndoTask`, the undo test module, and stale TUI
  slash-command comments.
  - Stopped agent job/background progress and compaction retry notices
  from emitting `BackgroundEvent` payloads.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-app-server-protocol -p
  codex-core -p codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - `cargo test -p codex-protocol -p codex-app-server-protocol -p
  codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - `cargo test -p codex-core --test all suite::items`
  - `just fix -p codex-protocol -p codex-app-server-protocol -p codex-core
  -p codex-rollout -p codex-rollout-trace -p codex-mcp-server`
  - Earlier coverage on this PR also included `codex-mcp`, `codex-tui`,
  core library tests, MCP/plugin/delegate/review/agent job tests, and MCP
  startup TUI tests.

  pakrym-oai · 2026-04-30 20:03:26 -07:00
  f50c02d7bc
• Surface admin-disabled remote plugin status (#20298)

  ## Summary
  
  Remote plugin-service returns plugin availability separately from a
  user's installed/enabled state. This adds `PluginAvailabilityStatus` to
  the app-server protocol, propagates remote catalog `status` into
  `PluginSummary`, and rejects install attempts for remote plugins marked
  `DISABLED_BY_ADMIN` before downloading or caching the bundle.
  
  This is the `openai/codex` half of the change. The companion
  `openai/openai` webview PR is
  https://github.com/openai/openai/pull/873269.
  
  ## Validation
  
  - `cargo run -p codex-app-server-protocol --bin write_schema_fixtures`
  - `cargo test -p codex-app-server --test all
  plugin_list_marks_remote_plugin_disabled_by_admin`
  - `cargo test -p codex-app-server --test all
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`
  - `cargo test -p codex-app-server --test all
  plugin_install_rejects_remote_plugin_disabled_by_admin_before_download`
  - `cargo test -p codex-app-server-protocol schema_fixtures`

  xli-oai · 2026-04-30 20:00:07 -07:00
  bb60b78c46
• 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