460 Commits

• chore: remove codex-core public protocol/shell re-exports (#12432)

  ## Why
  
  `codex-rs/core/src/lib.rs` re-exported a broad set of types and modules
  from `codex-protocol` and `codex-shell-command`. That made it easy for
  workspace crates to import those APIs through `codex-core`, which in
  turn hides dependency edges and makes it harder to reduce compile-time
  coupling over time.
  
  This change removes those public re-exports so call sites must import
  from the source crates directly. Even when a crate still depends on
  `codex-core` today, this makes dependency boundaries explicit and
  unblocks future work to drop `codex-core` dependencies where possible.
  
  ## What Changed
  
  - Removed public re-exports from `codex-rs/core/src/lib.rs` for:
  - `codex_protocol::protocol` and related protocol/model types (including
  `InitialHistory`)
    - `codex_protocol::config_types` (`protocol_config_types`)
  - `codex_shell_command::{bash, is_dangerous_command, is_safe_command,
  parse_command, powershell}`
  - Migrated workspace Rust call sites to import directly from:
    - `codex_protocol::protocol`
    - `codex_protocol::config_types`
    - `codex_protocol::models`
    - `codex_shell_command`
  - Added explicit `Cargo.toml` dependencies (`codex-protocol` /
  `codex-shell-command`) in crates that now import those crates directly.
  - Kept `codex-core` internal modules compiling by using `pub(crate)`
  aliases in `core/src/lib.rs` (internal-only, not part of the public
  API).
  - Updated the two utility crates that can already drop a `codex-core`
  dependency edge entirely:
    - `codex-utils-approval-presets`
    - `codex-utils-cli`
  
  ## Verification
  
  - `cargo test -p codex-utils-approval-presets`
  - `cargo test -p codex-utils-cli`
  - `cargo check --workspace --all-targets`
  - `just clippy`

  Michael Bolin · 2026-02-20 23:45:35 -08:00
  1af2a37ada
• Improve Plan mode reasoning selection flow (#12303)

  Addresses https://github.com/openai/codex/issues/11013
  
  ## Summary
  - add a Plan implementation path in the TUI that lets users choose
  reasoning before switching to Default mode and implementing
  - add Plan-mode reasoning scope handling (Plan-only override vs
  all-modes default), including config/schema/docs plumbing for
  `plan_mode_reasoning_effort`
  - remove the hardcoded Plan preset medium default and make the reasoning
  popup reflect the active Plan override as `(current)`
  - split the collaboration-mode switch notification UI hint into #12307
  to keep this diff focused
  
  If I have `plan_mode_reasoning_effort = "medium"` set in my
  `config.toml`:
  <img width="699" height="127" alt="Screenshot 2026-02-20 at 6 59 37 PM"
  src="https://github.com/user-attachments/assets/b33abf04-6b7a-49ed-b2e9-d24b99795369"
  />
  
  If I don't have `plan_mode_reasoning_effort` set in my `config.toml`:
  <img width="704" height="129" alt="Screenshot 2026-02-20 at 7 01 51 PM"
  src="https://github.com/user-attachments/assets/88a086d4-d2f1-49c7-8be4-f6f0c0fa1b8d"
  />
  
  ## Codex author
  `codex resume 019c78a2-726b-7fe3-adac-3fa4523dcc2a`

  Charley Cunningham · 2026-02-20 20:08:56 -08:00
  4c1744afb2
• Wire realtime api to core (#12268)

  - Introduce `RealtimeConversationManager` for realtime API management 
  - Add `op::conversation` to start conversation, insert audio, insert
  text, and close conversation.
  - emit conversation lifecycle and realtime events.
  - Move shared realtime payload types into codex-protocol and add core
  e2e websocket tests for start/replace/transport-close paths.
  
  Things to consider:
  - Should we use the same `op::` and `Events` channel to carry audio? I
  think we should try this simple approach and later we can create
  separate one if the channels got congested.
  - Sending text updates to the client: we can start simple and later
  restrict that.
  - Provider auth isn't wired for now intentionally

  Ahmed Ibrahim · 2026-02-20 19:06:35 -08:00
  6817f0be8a
• fix(tui): queued-message edit shortcut unreachable in some terminals (#12240)

  ## Problem
  
  The TUI's "edit queued message" shortcut (Alt+Up) is either silently
  swallowed or recognized as another key combination by Apple Terminal,
  Warp, and VSCode's integrated terminal on macOS. Users in those
  environments see the hint but pressing the keys does nothing.
  
  ## Mental model
  
  When a model turn is in progress the user can still type follow-up
  messages. These are queued and displayed below the composer with a hint
  line showing how to pop the most recent one back into the editor. The
  hint text and the actual key handler must agree on which shortcut is
  used, and that shortcut must actually reach the TUI—i.e. it must not be
  intercepted by the host terminal.
  
  Three terminals are known to intercept Alt+Up: Apple Terminal (remaps it
  to cursor movement), Warp (consumes it for its own command palette), and
  VSCode (maps it to "move line up"). For these we use Shift+Left instead.
  
  <p align="center">
  <img width="283" height="182" alt="image"
  src="https://github.com/user-attachments/assets/4a9c5d13-6e47-4157-bb41-28b4ce96a914"
  />
  </p>
  
  | macOS Native Terminal | Warp | VSCode Terminal |
  |---|---|---|
  | <img width="1557" height="1010" alt="SCR-20260219-kigi"
  src="https://github.com/user-attachments/assets/f4ff52f8-119e-407b-a3f3-52f564c36d70"
  /> | <img width="1479" height="1261" alt="SCR-20260219-krrf"
  src="https://github.com/user-attachments/assets/5807d7c4-17ae-4a2b-aa27-238fd49d90fd"
  /> | <img width="1612" height="1312" alt="SCR-20260219-ksbz"
  src="https://github.com/user-attachments/assets/1cedb895-6966-4d63-ac5f-0eea0f7057e8"
  /> |
  
  ## Non-goals
  
  - Making the binding user-configurable at runtime (deferred to a broader
  keybinding-config effort).
  - Remapping any other shortcuts that might be terminal-specific.
  
  ## Tradeoffs
  
  - **Exhaustive match instead of a wildcard default.** The
  `queued_message_edit_binding_for_terminal` function explicitly lists
  every `TerminalName` variant. This is intentional: adding a new terminal
  to the enum will produce a compile error, forcing the author to decide
  which binding that terminal should use.
  
  - **Binding lives on `ChatWidget`, hint lives on `QueuedUserMessages`.**
  The key event handler that actually acts on the press is in
  `ChatWidget`, but the rendered hint text is inside `QueuedUserMessages`.
  These are kept in sync by `ChatWidget` calling
  `bottom_pane.set_queued_message_edit_binding(self.queued_message_edit_binding)`
  during construction. A mismatch would show the wrong hint but would not
  lose data.
  
  ## Architecture
  
  ```mermaid
    graph TD
        TI["terminal_info().name"] --> FN["queued_message_edit_binding_for_terminal(name)"]
        FN --> KB["KeyBinding"]
        KB --> CW["ChatWidget.queued_message_edit_binding<br/><i>key event matching</i>"]
        KB --> BP["BottomPane.set_queued_message_edit_binding()"]
        BP --> QUM["QueuedUserMessages.edit_binding<br/><i>rendered in hint line</i>"]
  
        subgraph "Special terminals (Shift+Left)"
            AT["Apple Terminal"]
            WT["Warp"]
            VS["VSCode"]
        end
  
        subgraph "Default (Alt+Up)"
            GH["Ghostty"]
            IT["iTerm2"]
            OT["Others…"]
        end
  
        AT --> FN
        WT --> FN
        VS --> FN
        GH --> FN
        IT --> FN
        OT --> FN
  ```
  
  No new crates or public API surface. The only cross-crate dependency
  added is `codex_core::terminal::{TerminalName, terminal_info}`, which
  already existed for telemetry.
  
  ## Observability
  
  No new logging. Terminal detection already emits a `tracing::debug!` log
  line at startup with the detected terminal name, which is sufficient to
  diagnose binding mismatches.
  
  ## Tests
  
  - Existing `alt_up_edits_most_recent_queued_message` test is preserved
  and explicitly sets the Alt+Up binding to isolate from the host
  terminal.
  - New parameterized async tests verify Shift+Left works for Apple
  Terminal, Warp, and VSCode.
  - A sync unit test asserts the mapping table covers the three special
  terminals (Shift+Left) and that iTerm2 still gets Alt+Up.
    
  Fixes #4490

  Felipe Coury · 2026-02-20 16:56:41 -08:00
  a5d0757ed1
• Show model/reasoning hint when switching modes (#12307)

  ## Summary
  - show an info message when switching collaboration modes changes the
  effective model or reasoning
  - include the target mode in the message (for example `... for Plan
  mode.`)
  - add TUI tests for model-change and reasoning-only change notifications
  on mode switch
  
  <img width="715" height="184" alt="Screenshot 2026-02-20 at 2 01 40 PM"
  src="https://github.com/user-attachments/assets/18d1beb3-ab87-4e1c-9ada-a10218520420"
  />

  Charley Cunningham · 2026-02-20 15:22:10 -08:00
  021e39b303
• [apps] Store apps tool cache in disk to reduce startup time. (#11822)

  We now write MCP tools from installed apps to disk cache so that they
  can be picked up instantly at startup. We still do a fresh fetch from
  remote MCP server but it's non blocking unless there's a cache miss.
  
  - [x] Store apps tool cache in disk to reduce startup time.

  Matthew Zeng · 2026-02-19 22:06:51 -08:00
  18bd6d2d71
• Restore phase when loading from history (#12244)
  Jack Mousseau · 2026-02-19 09:56:56 -08:00
  3a951f8096
• Enable default status line indicators in TUI config (#12015)

  Default statusline to something
  <img width="307" height="83" alt="Screenshot 2026-02-17 at 18 16 12"
  src="https://github.com/user-attachments/assets/44e16153-0aa2-4c1a-9b4a-02e2feb8b7f6"
  />

  jif-oai · 2026-02-18 09:51:15 +00:00
  0dcf8d9c8f
• got rid of experimental_mode for configtoml (#12077)
  won-openai · 2026-02-17 21:10:30 -08:00
  189f592014
• chore: rm remote models fflag (#11699)

  rm `remote_models` feature flag.
  
  We see issues like #11527 when a user has `remote_models` disabled, as
  we always use the default fallback `ModelInfo`. This causes issues with
  model performance.
  
  Builds on #11690, which helps by warning the user when they are using
  the default fallback. This PR will make that happen much less frequently
  as an accidental consequence of disabling `remote_models`.

  sayan-oai · 2026-02-17 11:43:16 -08:00
  41800fc876
• Feat: add model reroute notification (#12001)

  ### Summary
  Builiding off
  https://github.com/openai/codex/pull/11964/files/5c75aa7b89a70bc2cc410a6fd238749306ec4c5e#diff-058ae8f109a8b84b4b79bbfa45f522c2233b9d9e139696044ae374d50b6196e0,
  we have created a `model/rerouted` notification that captures the event
  so that consumers can render as expected. Keep the `EventMsg::Warning`
  path in core so that this does not affect TUI rendering.
  
  `model/rerouted` is meant to be generic to account for future usage
  including capacity planning etc.

  Shijie Rao · 2026-02-17 11:02:23 -08:00
  48018e9eac
• Rename collab modules to multi agents (#11939)

  Summary
  - rename the `collab` handlers and UI files to `multi_agents` to match
  the new naming
  - update module references and specs so the handlers and TUI widgets
  consistently use the renamed files
  - keep the existing functionality while aligning file and module names
  with the multi-agent terminology

  jif-oai · 2026-02-16 19:05:13 +00:00
  beb5cb4f48
• feat(tui) Permissions update history item (#11550)

  ## Summary
  We should document in the tui when you switch permissions!
  
  ## Testing
  - [x] Added unit tests
  - [x] Tested locally

  Dylan Hurd · 2026-02-13 23:44:27 -08:00
  ebceb71db6
• feat(tui): render structured network approval prompts in approval overlay (#11674)

  ### Description
  #### Summary
  Adds the TUI UX layer for structured network approvals
  
  #### What changed
  - Updated approval overlay to display network-specific approval context
  (host/protocol).
  - Added/updated TUI wiring so approval prompts show correct network
  messaging.
  - Added tests covering the new approval overlay behavior.
  
  #### Why
  Core orchestration can now request structured network approvals; this
  ensures users see clear, contextual prompts in the TUI.
  
  #### Notes
  - UX behavior activates only when network approval context is present.
  
  ---------
  
  Co-authored-by: Codex <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

  viyatb-oai · 2026-02-13 22:38:36 -08:00
  3164670101
• tui: preserve remote image attachments across resume/backtrack (#10590)

  ## Summary
  This PR makes app-server-provided image URLs first-class attachments in
  TUI, so they survive resume/backtrack/history recall and are resubmitted
  correctly.
  
  <img width="715" height="491" alt="Screenshot 2026-02-12 at 8 27 08 PM"
  src="https://github.com/user-attachments/assets/226cbd35-8f0c-4e51-a13e-459ef5dd1927"
  />
  
  Can delete the attached image upon backtracking:
  <img width="716" height="301" alt="Screenshot 2026-02-12 at 8 27 31 PM"
  src="https://github.com/user-attachments/assets/4558d230-f1bd-4eed-a093-8e1ab9c6db27"
  />
  
  In both history and composer, remote images are rendered as normal
  `[Image #N]` placeholders, with numbering unified with local images.
  
  ## What changed
  - Plumb remote image URLs through TUI message state:
    - `UserHistoryCell`
    - `BacktrackSelection`
    - `ChatComposerHistory::HistoryEntry`
    - `ChatWidget::UserMessage`
  - Show remote images as placeholder rows inside the composer box (above
  textarea), and in history cells.
  - Support keyboard selection/deletion for remote image rows in composer
  (`Up`/`Down`, `Delete`/`Backspace`).
  - Preserve remote-image-only turns in local composer history (Up/Down
  recall), including restore after backtrack.
  - Ensure submit/queue/backtrack resubmit include remote images in model
  input (`UserInput::Image`), and keep request shape stable for
  remote-image-only turns.
  - Keep image numbering contiguous across remote + local images:
    - remote images occupy `[Image #1]..[Image #M]`
    - local images start at `[Image #M+1]`
    - deletion renumbers consistently.
  - In protocol conversion, increment shared image index for remote images
  too, so mixed remote/local image tags stay in a single sequence.
  - Simplify restore logic to trust in-memory attachment order (no
  placeholder-number parsing path).
  - Backtrack/replay rollback handling now queues trims through
  `AppEvent::ApplyThreadRollback` and syncs transcript overlay/deferred
  lines after trims, so overlay/transcript state stays consistent.
  - Trim trailing blank rendered lines from user history rendering to
  avoid oversized blank padding.
  
  ## Docs + tests
  - Updated: `docs/tui-chat-composer.md` (remote image flow,
  selection/deletion, numbering offsets)
  - Added/updated tests across `tui/src/chatwidget/tests.rs`,
  `tui/src/app.rs`, `tui/src/app_backtrack.rs`, `tui/src/history_cell.rs`,
  and `tui/src/bottom_pane/chat_composer.rs`
  - Added snapshot coverage for remote image composer states, including
  deleting the first of two remote images.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-tui`
  
  ## Codex author
  `codex fork 019c2636-1571-74a1-8471-15a3b1c3f49d`

  Charley Cunningham · 2026-02-13 14:54:06 -08:00
  26a7cd21e2
• [apps] Improve app listing filtering. (#11697)

  - [x] If an installed app is not on the app listing, remove it from the
  final list.

  Matthew Zeng · 2026-02-13 11:54:16 -08:00
  8468871e2b
• feat(tui): prevent macOS idle sleep while turns run (#11711)

  ## Summary
  - add a shared `codex-core` sleep inhibitor that uses native macOS IOKit
  assertions (`IOPMAssertionCreateWithName` / `IOPMAssertionRelease`)
  instead of spawning `caffeinate`
  - wire sleep inhibition to turn lifecycle in `tui` (`TurnStarted`
  enables; `TurnComplete` and abort/error finalization disable)
  - gate this behavior behind a `/experimental` feature toggle
  (`[features].prevent_idle_sleep`) instead of a dedicated `[tui]` config
  flag
  - expose the toggle in `/experimental` on macOS; keep it under
  development on other platforms
  - keep behavior no-op on non-macOS targets
  
  <img width="1326" height="577" alt="image"
  src="https://github.com/user-attachments/assets/73fac06b-97ae-46a2-800a-30f9516cf8a3"
  />
  
  ## Testing
  - `cargo check -p codex-core -p codex-tui`
  - `cargo test -p codex-core sleep_inhibitor::tests -- --nocapture`
  - `cargo test -p codex-core
  tui_config_missing_notifications_field_defaults_to_enabled --
  --nocapture`
  - `cargo test -p codex-core prevent_idle_sleep_is_ -- --nocapture`
  
  ## Semantics and API references
  - This PR targets `caffeinate -i` semantics: prevent *idle system sleep*
  while allowing display idle sleep.
  - `caffeinate -i` mapping in Apple open source (`assertionMap`):
    - `kIdleAssertionFlag -> kIOPMAssertionTypePreventUserIdleSystemSleep`
  - Source:
  https://github.com/apple-oss-distributions/PowerManagement/blob/PowerManagement-1846.60.12/caffeinate/caffeinate.c#L52-L54
  - Apple IOKit docs for assertion types and API:
  -
  https://developer.apple.com/documentation/iokit/iopmlib_h/iopmassertiontypes
  -
  https://developer.apple.com/documentation/iokit/1557092-iopmassertioncreatewithname
    - https://developer.apple.com/library/archive/qa/qa1340/_index.html
  
  ## Codex Electron vs this PR (full stack path)
  - Codex Electron app requests sleep blocking with
  `powerSaveBlocker.start("prevent-app-suspension")`:
  -
  https://github.com/openai/codex/blob/main/codex/codex-vscode/electron/src/electron-message-handler.ts
  - Electron maps that string to Chromium wake lock type
  `kPreventAppSuspension`:
  -
  https://github.com/electron/electron/blob/main/shell/browser/api/electron_api_power_save_blocker.cc
  - Chromium macOS backend maps wake lock types to IOKit assertion
  constants and calls IOKit:
    - `kPreventAppSuspension -> kIOPMAssertionTypeNoIdleSleep`
  - `kPreventDisplaySleep / kPreventDisplaySleepAllowDimming ->
  kIOPMAssertionTypeNoDisplaySleep`
  -
  https://github.com/chromium/chromium/blob/main/services/device/wake_lock/power_save_blocker/power_save_blocker_mac.cc
  
  ## Why this PR uses a different macOS constant name
  - This PR uses `"PreventUserIdleSystemSleep"` directly, via
  `IOPMAssertionCreateWithName`, in
  `codex-rs/core/src/sleep_inhibitor.rs`.
  - Apple’s IOKit header documents `kIOPMAssertionTypeNoIdleSleep` as
  deprecated and recommends `kIOPMAssertPreventUserIdleSystemSleep` /
  `kIOPMAssertionTypePreventUserIdleSystemSleep`:
  -
  https://github.com/apple-oss-distributions/IOKitUser/blob/IOKitUser-100222.60.2/pwr_mgt.subproj/IOPMLib.h#L1000-L1030
  - So Chromium and this PR are using different constant names, but
  semantically equivalent idle-system-sleep prevention behavior.
  
  ## Future platform support
  The architecture is intentionally set up for multi-platform extensions:
  - UI code (`tui`) only calls `SleepInhibitor::set_turn_running(...)` on
  turn lifecycle boundaries.
  - Platform-specific behavior is isolated in
  `codex-rs/core/src/sleep_inhibitor.rs` behind `cfg(...)` blocks.
  - Feature exposure is centralized in `core/src/features.rs` and surfaced
  via `/experimental`.
  - Adding new OS backends should not require additional TUI wiring; only
  the backend internals and feature stage metadata need to change.
  
  Potential follow-up implementations:
  - Windows:
  - Add a backend using Win32 power APIs
  (`SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED)` as
  baseline).
  - Optionally move to `PowerCreateRequest` / `PowerSetRequest` /
  `PowerClearRequest` for richer assertion semantics.
  - Linux:
  - Add a backend using logind inhibitors over D-Bus
  (`org.freedesktop.login1.Manager.Inhibit` with `what="sleep"`).
    - Keep a no-op fallback where logind/D-Bus is unavailable.
  
  This PR keeps the cross-platform API surface minimal so future PRs can
  add Windows/Linux support incrementally with low churn.
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Yaroslav Volovich · 2026-02-13 10:31:39 -08:00
  32da5eb358
• sandbox NUX metrics update (#11667)

  just updating metrics to match the NUX tweaks we made this week.

  iceweasel-oai · 2026-02-13 10:01:47 -08:00
  99466f1f90
• [apps] Add is_enabled to app info. (#11417)

  - [x] Add is_enabled to app info and the response of `app/list`.
  - [x] Update TUI to have Enable/Disable button on the app detail page.

  Matthew Zeng · 2026-02-13 00:30:52 +00:00
  c37560069a
• feat: introduce Permissions (#11633)

  ## Why
  We currently carry multiple permission-related concepts directly on
  `Config` for shell/unified-exec behavior (`approval_policy`,
  `sandbox_policy`, `network`, `shell_environment_policy`,
  `windows_sandbox_mode`).
  
  Consolidating these into one in-memory struct makes permission handling
  easier to reason about and sets up the next step: supporting named
  permission profiles (`[permissions.PROFILE_NAME]`) without changing
  behavior now.
  
  This change is mostly mechanical: it updates existing callsites to go
  through `config.permissions`, but it does not yet refactor those
  callsites to take a single `Permissions` value in places where multiple
  permission fields are still threaded separately.
  
  This PR intentionally **does not** change the on-disk `config.toml`
  format yet and keeps compatibility with legacy config keys.
  
  ## What Changed
  - Introduced `Permissions` in `core/src/config/mod.rs`.
  - Added `Config::permissions` and moved effective runtime permission
  fields under it:
    - `approval_policy`
    - `sandbox_policy`
    - `network`
    - `shell_environment_policy`
    - `windows_sandbox_mode`
  - Updated config loading/building so these effective values are still
  derived from the same existing config inputs and constraints.
  - Updated Windows sandbox helpers/resolution to read/write via
  `permissions`.
  - Threaded the new field through all permission consumers across core
  runtime, app-server, CLI/exec, TUI, and sandbox summary code.
  - Updated affected tests to reference `config.permissions.*`.
  - Renamed the struct/field from
  `EffectivePermissions`/`effective_permissions` to
  `Permissions`/`permissions` and aligned variable naming accordingly.
  
  ## Verification
  - `just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server
  -p codex-exec -p codex-utils-sandbox-summary`
  - `cargo build -p codex-core -p codex-tui -p codex-cli -p
  codex-app-server -p codex-exec -p codex-utils-sandbox-summary`

  Michael Bolin · 2026-02-12 14:42:54 -08:00
  a4cc1a4a85
• add a slash command to grant sandbox read access to inaccessible directories (#11512)

  There is an edge case where a directory is not readable by the sandbox.
  In practice, we've seen very little of it, but it can happen so this
  slash command unlocks users when it does.
  
  Future idea is to make this a tool that the agent knows about so it can
  be more integrated.

  iceweasel-oai · 2026-02-12 12:48:36 -08:00
  5c3ca73914
• feat: mem slash commands (#11569)

  Add 2 slash commands for memories:
  * `/m_drop` delete all the memories
  * `/m_update` update the memories with phase 1 and 2

  jif-oai · 2026-02-12 10:39:43 +00:00
  a0dab25c68
• feat: make sandbox read access configurable with ReadOnlyAccess (#11387)

  `SandboxPolicy::ReadOnly` previously implied broad read access and could
  not express a narrower read surface.
  This change introduces an explicit read-access model so we can support
  user-configurable read restrictions in follow-up work, while preserving
  current behavior today.
  
  It also ensures unsupported backends fail closed for restricted-read
  policies instead of silently granting broader access than intended.
  
  ## What
  
  - Added `ReadOnlyAccess` in protocol with:
    - `Restricted { include_platform_defaults, readable_roots }`
    - `FullAccess`
  - Updated `SandboxPolicy` to carry read-access configuration:
    - `ReadOnly { access: ReadOnlyAccess }`
    - `WorkspaceWrite { ..., read_only_access: ReadOnlyAccess }`
  - Preserved existing behavior by defaulting current construction paths
  to `ReadOnlyAccess::FullAccess`.
  - Threaded the new fields through sandbox policy consumers and call
  sites across `core`, `tui`, `linux-sandbox`, `windows-sandbox`, and
  related tests.
  - Updated Seatbelt policy generation to honor restricted read roots by
  emitting scoped read rules when full read access is not granted.
  - Added fail-closed behavior on Linux and Windows backends when
  restricted read access is requested but not yet implemented there
  (`UnsupportedOperation`).
  - Regenerated app-server protocol schema and TypeScript artifacts,
  including `ReadOnlyAccess`.
  
  ## Compatibility / rollout
  
  - Runtime behavior remains unchanged by default (`FullAccess`).
  - API/schema changes are in place so future config wiring can enable
  restricted read access without another policy-shape migration.

  Michael Bolin · 2026-02-11 18:31:14 -08:00
  abbd74e2be
• Use slug in tui (#11519)

  Display name is for VSCE and App, TUI uses lowercase everywhere.

  pakrym-oai · 2026-02-11 17:42:58 -08:00
  58eaa7ba8f
• change model cap to server overload (#11388)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.

  willwang-openai · 2026-02-11 17:16:27 -08:00
  3f1b41689a
• chore(tui) Simplify /status Permissions (#11290)

  ## Summary
  Consolidate `/status` Permissions lines into a simpler view. It should
  only show "Default," "Full Access," or "Custom" (with specifics)
  
  ## Testing
  - [x] many snapshots updated

  Dylan Hurd · 2026-02-11 15:02:29 -08:00
  30cdfce1a5
• Promote Windows Sandbox (#11341)

  1. Move Windows Sandbox NUX to right after trust directory screen
  2. Don't offer read-only as an option in Sandbox NUX.
  Elevated/Legacy/Quit
  3. Don't allow new untrusted directories. It's trust or quit
  4. move experimental sandbox features to `[windows]
  sandbox="elevated|unelevatd"`
  5. Copy tweaks = elevated -> default, non-elevated -> non-admin

  iceweasel-oai · 2026-02-11 11:48:33 -08:00
  87279de434
• feat: split codex-common into smaller utils crates (#11422)

  We are removing feature-gated shared crates from the `codex-rs`
  workspace. `codex-common` grouped several unrelated utilities behind
  `[features]`, which made dependency boundaries harder to reason about
  and worked against the ongoing effort to eliminate feature flags from
  workspace crates.
  
  Splitting these utilities into dedicated crates under `utils/` aligns
  this area with existing workspace structure and keeps each dependency
  explicit at the crate boundary.
  
  ## What changed
  
  - Removed `codex-rs/common` (`codex-common`) from workspace members and
  workspace dependencies.
  - Added six new utility crates under `codex-rs/utils/`:
    - `codex-utils-cli`
    - `codex-utils-elapsed`
    - `codex-utils-sandbox-summary`
    - `codex-utils-approval-presets`
    - `codex-utils-oss`
    - `codex-utils-fuzzy-match`
  - Migrated the corresponding modules out of `codex-common` into these
  crates (with tests), and added matching `BUILD.bazel` targets.
  - Updated direct consumers to use the new crates instead of
  `codex-common`:
    - `codex-rs/cli`
    - `codex-rs/tui`
    - `codex-rs/exec`
    - `codex-rs/app-server`
    - `codex-rs/mcp-server`
    - `codex-rs/chatgpt`
    - `codex-rs/cloud-tasks`
  - Updated workspace lockfile entries to reflect the new dependency graph
  and removal of `codex-common`.

  Michael Bolin · 2026-02-11 12:59:24 +00:00
  8b7f8af343
• feat: support multiple rate limits (#11260)

  Added multi-limit support end-to-end by carrying limit_name in
  rate-limit snapshots and handling multiple buckets instead of only
  codex.
  Extended /usage client parsing to consume additional_rate_limits
  Updated TUI /status and in-memory state to store/render per-limit
  snapshots
  Extended app-server rate-limit read response: kept rate_limits and added
  rate_limits_by_name.
  Adjusted usage-limit error messaging for non-default codex limit buckets

  xl-openai · 2026-02-10 20:09:31 -08:00
  fdd0cd1de9
• chore: persist turn_id in rollout session and make turn_id uuid based (#11246)

  Problem:
  1. turn id is constructed in-memory;
  2. on resuming threads, turn_id might not be unique;
  3. client cannot no the boundary of a turn from rollout files easily.
  
  This PR does three things:
  1. persist `task_started` and `task_complete` events;
  1. persist `turn_id` in rollout turn events;
  5. generate turn_id as unique uuids instead of incrementing it in
  memory.
  
  This helps us resolve the issue of clients wanting to have unique turn
  ids for resuming a thread, and knowing the boundry of each turn in
  rollout files.
  
  example debug logs
  ```
  2026-02-11T00:32:10.746876Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=8 turn=Turn { id: "019c4a07-d809-74c3-bc4b-fd9618487b4b", items: [UserMessage { id: "item-24", content: [Text { text: "hi", text_elements: [] }] }, AgentMessage { id: "item-25", text: "Hi. I’m in the workspace with your current changes loaded and ready. Send the next task and I’ll execute it end-to-end." }], status: Completed, error: None }
  2026-02-11T00:32:10.746888Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=9 turn=Turn { id: "019c4a18-1004-76c0-a0fb-a77610f6a9b8", items: [UserMessage { id: "item-26", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-27", text: "Hello. Ready for the next change in `codex-rs`; I can continue from the current in-progress diff or start a new task." }], status: Completed, error: None }
  2026-02-11T00:32:10.746899Z DEBUG codex_app_server_protocol::protocol::thread_history: built turn from rollout items turn_index=10 turn=Turn { id: "019c4a19-41f0-7db0-ad78-74f1503baeb8", items: [UserMessage { id: "item-28", content: [Text { text: "hello", text_elements: [] }] }, AgentMessage { id: "item-29", text: "Hello. Send the specific change you want in `codex-rs`, and I’ll implement it and run the required checks." }], status: Completed, error: None }
  ```
  
  backward compatibility:
  if you try to resume an old session without task_started and
  task_complete event populated, the following happens:
  - If you resume and do nothing: those reconstructed historical IDs can
  differ next time you resume.
  - If you resume and send a new turn: the new turn gets a fresh UUID from
  live submission flow and is persisted, so that new turn’s ID is stable
  on later resumes.
  I think this behavior is fine, because we only care about deterministic
  turn id once a turn is triggered.

  Celia Chen · 2026-02-11 03:56:01 +00:00
  641d5268fa
• tui: queue non-pending rollback trims in app-event order (#11373)

  ## Summary
  
  This PR fixes TUI transcript-sync behavior for
  `EventMsg::ThreadRolledBack` and makes rollback application order
  deterministic.
  
  Previously, rollback handling depended on `pending_rollback`:
  
  - if `pending_rollback` was set (local backtrack), TUI trimmed correctly
  - otherwise, replayed/external rollbacks were either ignored or could be
  applied at the wrong time relative to queued transcript inserts
  
  This change keeps the local backtrack path intact and routes non-pending
  rollbacks through the app event queue so rollback trims are applied in
  FIFO order with transcript cell inserts.
  
  ## What changed
  
  - Added/used `trim_transcript_cells_drop_last_n_user_turns(...)` for
  rollback-by-`num_turns` semantics.
  - Renamed rollback app event:
  - `AppEvent::ApplyReplayedThreadRollback` ->
  `AppEvent::ApplyThreadRollback`
  - Replay path (`ChatWidget`) now emits `ApplyThreadRollback`.
  - Live non-pending rollback path (`App::handle_backtrack_event`) now
  emits `ApplyThreadRollback` instead of trimming immediately.
  - App-level event handler applies `ApplyThreadRollback` after queued
  `InsertHistoryCell` events and schedules redraw only when a trim
  occurred.
  - When a trim occurs with an overlay open, TUI now syncs transcript
  overlay committed cells, clamps backtrack preview selection, and clears
  stale `deferred_history_lines` so closed overlays do not re-append
  rolled-back lines.
  - Clarified inline comments around the `pending_rollback` branch so
  future readers can reason about why there are two paths.
  
  ## Why queueing matters
  
  During resume/replay, transcript cells are populated via queued
  `InsertHistoryCell` app events. If a rollback is applied immediately
  outside that queue, it can run against an incomplete transcript and
  under-trim. Queueing non-pending rollbacks ensures consistent ordering
  and correct final transcript state.
  
  ## Behavior by rollback source
  
  - `pending_rollback = Some(...)` (local backtrack requested by this
  TUI):
    - use `finish_pending_backtrack()` and the stored selection boundary
  - `pending_rollback = None` (replay/external/non-local rollback):
  - enqueue `AppEvent::ApplyThreadRollback { num_turns }` and trim in
  app-event order
  
  ## Tests
  
  Added/updated tests covering ordering and semantics:
  
  -
  `app_backtrack::tests::trim_drop_last_n_user_turns_applies_rollback_semantics`
  - `app_backtrack::tests::trim_drop_last_n_user_turns_allows_overflow`
  - `app::tests::replayed_initial_messages_apply_rollback_in_queue_order`
  -
  `app::tests::live_rollback_during_replay_is_applied_in_app_event_order`
  -
  `app::tests::queued_rollback_syncs_overlay_and_clears_deferred_history`
  - `chatwidget::tests::replayed_thread_rollback_emits_ordered_app_event`
  
  Validation run:
  
  - `just fmt`
  - `cargo test -p codex-tui`

  Charley Cunningham · 2026-02-10 18:53:43 -08:00
  8b46c0ce00
• [apps] Improve app installation flow. (#11249)

  - [x] Add buttons to start the installation flow and verify installation
  completes.
  - [x] Hard refresh apps list when the /apps view opens.

  Matthew Zeng · 2026-02-10 17:59:43 +00:00
  48e415bdef
• Fix: update parallel tool call exec approval to approve on request id (#11162)

  ### Summary
  
  In parallel tool call, exec command approvals were not approved at
  request level but at a turn level. i.e. when a single request is
  approved, the system currently treats all requests in turn as approved.
  
  ### Before
  
  https://github.com/user-attachments/assets/d50ed129-b3d2-4b2f-97fa-8601eb11f6a8
  
  ### After
  
  https://github.com/user-attachments/assets/36528a43-a4aa-4775-9e12-f13287ef19fc

  Shijie Rao · 2026-02-10 09:38:00 -08:00
  c4b771a16f
• feat: retain NetworkProxy, when appropriate (#11207)

  As of this PR, `SessionServices` retains a
  `Option<StartedNetworkProxy>`, if appropriate.
  
  Now the `network` field on `Config` is `Option<NetworkProxySpec>`
  instead of `Option<NetworkProxy>`.
  
  Over in `Session::new()`, we invoke `NetworkProxySpec::start_proxy()` to
  create the `StartedNetworkProxy`, which is a new struct that retains the
  `NetworkProxy` as well as the `NetworkProxyHandle`. (Note that `Drop` is
  implemented for `NetworkProxyHandle` to ensure the proxies are shutdown
  when it is dropped.)
  
  The `NetworkProxy` from the `StartedNetworkProxy` is threaded through to
  the appropriate places.
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/11207).
  * #11285
  * __->__ #11207

  Michael Bolin · 2026-02-10 02:09:23 -08:00
  44ebf4588f
• chore(tui) cleanup /approvals (#10215)

  ## Summary
  Consolidate on the new `/permissions` flow
  
  ## Testing
  - [x] updated snapshots

  Dylan Hurd · 2026-02-09 23:24:06 -08:00
  b61ea47e83
• feat: do not close unified exec processes across turns (#10799)

  With this PR we do not close the unified exec processes (i.e. background
  terminals) at the end of a turn unless:
  * The user interrupt the turn
  * The user decide to clean the processes through `app-server` or
  `/clean`
  
  I made sure that `codex exec` correctly kill all the processes

  jif-oai · 2026-02-09 10:27:46 +00:00
  6cf61725d0
• tui: avoid no-op status-line redraws (#11155)

  Rate-limit snapshots are polled every 60s, which causes unconditional
  redraws.
  This causes spurious "tab changed" indicators in terminal apps.

  rakan-oai · 2026-02-09 00:13:19 -08:00
  4e9e6ca243
• [apps] Improve app loading. (#10994)

  There are two concepts of apps that we load in the harness:
  
  - Directory apps, which is all the apps that the user can install.
  - Accessible apps, which is what the user actually installed and can be
  $ inserted and be used by the model. These are extracted from the tools
  that are loaded through the gateway MCP.
  
  Previously we wait for both sets of apps before returning the full apps
  list. Which causes many issues because accessible apps won't be
  available to the UI or the model if directory apps aren't loaded or
  failed to load.
  
  In this PR we are separating them so that accessible apps can be loaded
  separately and are instantly available to be shown in the UI and to be
  provided in model context. We also added an app-server event so that
  clients can subscribe to also get accessible apps without being blocked
  on the full app list.
  
  - [x] Separate accessible apps and directory apps loading.
  - [x] `app/list` request will also emit `app/list/updated` notifications
  that app-server clients can subscribe. Which allows clients to get
  accessible apps list to render in the $ menu without being blocked by
  directory apps.
  - [x] Cache both accessible and directory apps with 1 hour TTL to avoid
  reloading them when creating new threads.
  - [x] TUI improvements to redraw $ menu and /apps menu when app list is
  updated.

  Matthew Zeng · 2026-02-08 15:24:56 -08:00
  45b7763c3f
• Defer persistence of rollout file (#11028)

  - Defer rollout persistence for fresh threads (`InitialHistory::New`):
  keep rollout events in memory and only materialize rollout file + state
  DB row on first `EventMsg::UserMessage`.
  - Keep precomputed rollout path available before materialization.
  - Change `thread/start` to build thread response from live config
  snapshot and optional precomputed path.
  - Improve pre-materialization behavior in app-server/TUI: clearer
  invalid-request errors for file-backed ops and a friendlier `/fork` “not
  ready yet” UX.
  - Update tests to match deferred semantics across
  start/read/archive/unarchive/fork/resume/review flows.
  - Improved resilience of user_shell test, which should be unrelated to
  this change but must be affected by timing changes
  
  For Reviewers:
  * The primary change is in recorder.rs
  * Most of the other changes were to fix up broken assumptions in
  existing tests
  
  Testing:
  * Manually tested CLI
  * Exercised app server paths by manually running IDE Extension with
  rebuilt CLI binary
  * Only user-visible change is that `/fork` in TUI generates visible
  error if used prior to first turn

  Eric Traut · 2026-02-07 23:05:03 -08:00
  b3de6c7f2b
• Add resume_agent collab tool (#10903)

  Summary
  - add the new resume_agent collab tool path through core, protocol, and
  the app server API, including the resume events
  - update the schema/TypeScript definitions plus docs so resume_agent
  appears in generated artifacts and README
  - note that resumed agents rehydrate rollout history without overwriting
  their base instructions
  
  Testing
  - Not run (not requested)

  jif-oai · 2026-02-07 17:31:45 +01:00
  62605fa471
• Do not poll for usage when using API Key auth (#10973)

  Fixes #10869
  
  - Gate TUI rate-limit polling on ChatGPT-auth providers only.
  - `prefetch_rate_limits()` now checks `should_prefetch_rate_limits()`.
  - New gate requires:
    - `config.model_provider.requires_openai_auth`
    - cached auth is ChatGPT (`CodexAuth::is_chatgpt_auth`)
  - Prevents `/wham/usage` polling in API/custom-endpoint profiles.

  Eric Traut · 2026-02-06 23:26:44 -08:00
  3779b52e2d
• fix(tui): conditionally restore status indicator using message phase (#10947)

  TLDR: use new message phase field emitted by preamble-supported models
  to determine whether an AgentMessage is mid-turn commentary. if so,
  restore the status indicator afterwards to indicate the turn has not
  completed.
  
  ### Problem
  `commit_tick` hides the status indicator while streaming assistant text.
  For preamble-capable models, that text can be commentary mid-turn, so
  hiding was correct during streaming but restore timing mattered:
  - restoring too aggressively caused jitter/flashing
  - not restoring caused indicator to stay hidden before subsequent work
  (tool calls, web search, etc.)
  
  ### Fix
  - Add optional `phase` to `AgentMessageItem` and propagate it from
  `ResponseItem::Message`
  - Keep indicator hidden during streamed commit ticks, restore only when:
    - assistant item completes as `phase=commentary`, and
    - stream queues are idle + task is still running.
  - Treat `phase=None` as final-answer behavior (no restore) to keep
  existing behavior for non-preamble models
  
  ### Tests
  Add/update tests for:
  - no idle-tick restore without commentary completion
  - commentary completion restoring status before tool begin
  - snapshot coverage for preamble/status behavior
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  sayan-oai · 2026-02-07 02:39:52 +00:00
  5d2702f6b8
• TUI/Core: preserve duplicate skill/app mention selection across submit + resume (#10855)

  ## What changed
  
  - In `codex-rs/core/src/skills/injection.rs`, we now honor explicit
  `UserInput::Skill { name, path }` first, then fall back to text mentions
  only when safe.
  - In `codex-rs/tui/src/bottom_pane/chat_composer.rs`, mention selection
  is now token-bound (selected mention is tied to the specific inserted
  `$token`), and we snapshot bindings at submit time so selection is not
  lost.
  - In `codex-rs/tui/src/chatwidget.rs` and
  `codex-rs/tui/src/bottom_pane/mod.rs`, submit/queue paths now consume
  the submit-time mention snapshot (instead of rereading cleared composer
  state).
  - In `codex-rs/tui/src/mention_codec.rs` and
  `codex-rs/tui/src/bottom_pane/chat_composer_history.rs`, history now
  round-trips mention targets so resume restores the same selected
  duplicate.
  - In `codex-rs/tui/src/bottom_pane/skill_popup.rs` and
  `codex-rs/tui/src/bottom_pane/chat_composer.rs`, duplicate labels are
  normalized to `[Repo]` / `[App]`, app rows no longer show `Connected -`,
  and description space is a bit wider.
  
  <img width="550" height="163" alt="Screenshot 2026-02-05 at 9 56 56 PM"
  src="https://github.com/user-attachments/assets/346a7eb2-a342-4a49-aec8-68dfec0c7d89"
  />
  <img width="550" height="163" alt="Screenshot 2026-02-05 at 9 57 09 PM"
  src="https://github.com/user-attachments/assets/5e04d9af-cccf-4932-98b3-c37183e445ed"
  />
  
  
  ## Before vs now
  
  - Before: selecting a duplicate could still submit the default/repo
  match, and resume could lose which duplicate was originally selected.
  - Now: the exact selected target (skill path or app id) is preserved
  through submit, queue/restore, and resume.
  
  ## Manual test
  
  1. Build and run this branch locally:
     - `cd /Users/daniels/code/codex/codex-rs`
     - `cargo build -p codex-cli --bin codex`
     - `./target/debug/codex`
  2. Open mention picker with `$` and pick a duplicate entry (not the
  first one).
  3. Confirm duplicate UI:
     - repo duplicate rows show `[Repo]`
     - app duplicate rows show `[App]`
     - app description does **not** start with `Connected -`
  4. Submit the prompt, then press Up to restore draft and submit again.  
     Expected: it keeps the same selected duplicate target.
  5. Use `/resume` to reopen the session and send again.  
  Expected: restored mention still resolves to the same duplicate target.

  daniel-oai · 2026-02-06 15:59:00 -08:00
  84bce2b8e6
• Queue nudges while plan generating (#10457)

  ## Summary
  
  This PR fixes a UI/streaming race when nudged or steer-enabled messages
  are queued during an active Plan stream.
  
  Previously, `submit_user_message_with_mode` switched collaboration mode
  immediately (via `set_collaboration_mask`) even when the message was
  queued. If that happened mid-Plan stream, `active_mode_kind` could flip
  away from Plan before the turn finished, causing subsequent
  `on_plan_delta` updates to be ignored in the UI.
  
  Now, mode switching is deferred until the queued message is actually
  submitted.
  
  ## What changed
  
  - Added a per-message deferred mode override on `UserMessage`:
    - `collaboration_mode_override: Option<CollaborationModeMask>`
  - Updated `submit_user_message_with_mode` to:
    - create a `UserMessage` carrying the mode override
  - queue or submit that message without mutating global mode immediately
  - Updated `submit_user_message` to:
  - apply `collaboration_mode_override` just before constructing/sending
  `Op::UserTurn`
  - Kept queueing condition scoped to active Plan stream rendering:
  - queue only while plan output is actively streaming in TUI
  (`plan_stream_controller.is_some()`)
  
  ## Why
  
  This preserves Plan mode for the remainder of the in-flight Plan turn,
  so streamed plan deltas continue rendering correctly, while still
  ensuring the follow-up queued message is sent with the intended
  collaboration mode.
  
  ## Behavior after this change
  
  - If a nudged/steer submission happens while Plan output is actively
  streaming:
    - message is queued
    - UI stays in Plan mode for the running turn
  - once dequeued/submitted, mode override is applied and the message is
  sent in the intended mode
  - If no Plan stream is active:
  - submission proceeds immediately and mode override is applied as before
  
  ## Tests
  
  Added/updated coverage in `tui/src/chatwidget/tests.rs`:
  
  - `submit_user_message_with_mode_queues_while_plan_stream_is_active`
    - asserts mode remains Plan while queued
  - asserts mode switches to Code when queued message is actually
  submitted
  - `submit_user_message_with_mode_submits_when_plan_stream_is_not_active`
  - `steer_enter_queues_while_plan_stream_is_active`
  - `steer_enter_submits_when_plan_stream_is_not_active`
  
  Also updated existing `UserMessage { ... }` test fixtures to include the
  new field.
  
  ## Codex author
  `codex fork 019c1047-d5d5-7c92-a357-6009604dc7e8`

  Charley Cunningham · 2026-02-06 09:43:00 -08:00
  b7ecd166a6
• Personality setting is no longer available in experimental menu (#10852)

  This PR removes the inaccurate "Disable in /experimental." statement now
  that the "personality" feature flag is no longer experimental.
  
  This addresses #10850

  Eric Traut · 2026-02-05 22:19:09 -08:00
  f61226d32a
• feat: expose detailed metrics to runtime metrics (#10699)
  Anton Panasenko · 2026-02-05 18:22:30 -08:00
  4ee039744e
• Add analytics for /rename and /fork (#10655)
  pap-openai · 2026-02-05 20:18:29 +00:00
  529b539564
• feat(tui): add /statusline command for interactive status line configuration (#10546)

  ## Summary
  - Adds a new `/statusline` command to configure TUI footer status line
  - Introduces reusable `MultiSelectPicker` component with keyboard
  navigation, optional ordering and toggle support
  - Implement status line setup modal that persist configuration to
  config.toml
  
    ## Status Line Items
    The following items can be displayed in the status line:
    - **Model**: Current model name (with optional reasoning level)
    - **Context**: Remaining/used context window percentage
    - **Rate Limits**: 5-day and weekly usage limits
    - **Git**: Current branch (with optimized lookups)
    - **Tokens**: Used tokens, input/output token counts
    - **Session**: Session ID (full or shortened prefix)
    - **Paths**: Current directory, project root
    - **Version**: Codex version
  
    ## Features
    - Live preview while configuring status line items
    - Fuzzy search filtering in the picker
    - Intelligent truncation when items don't fit
    - Items gracefully omit when data is unavailable
    - Configuration persists to `config.toml`
    - Validates and warns about invalid status line items
  
    ## Test plan
    - [x] Run `/statusline` and verify picker UI appears
    - [x] Toggle items on/off and verify live preview updates
    - [x] Confirm selection persists after restart
    - [x] Verify truncation behavior with many items selected
    - [x] Test git branch detection in and out of git repos
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  Felipe Coury · 2026-02-05 08:50:21 -08:00
  b0e5a6305b
• adding fork information (UI) when forking (#10246)

  - shows `/fork` command that ran in prev session
  - shows `session forked from name (uuid) || uuid (if name is not set)` as an event in new session

  pap-openai · 2026-02-05 13:24:55 +00:00
  b2424cb635
• Sync collaboration mode naming across Default prompt, tools, and TUI (#10666)

  ## Summary
  - add shared `ModeKind` helpers for display names, TUI visibility, and
  `request_user_input` availability
  - derive TUI mode filtering/labels from shared `ModeKind` metadata
  instead of local hardcoded matches
  - derive `request_user_input` availability text and unavailable error
  mode names from shared mode metadata
  - replace hardcoded known mode names in the Default collaboration-mode
  template with `{{KNOWN_MODE_NAMES}}` and fill it from
  `TUI_VISIBLE_COLLABORATION_MODES`
  - add regression tests for mode metadata sync and placeholder
  replacement
  
  ## Notes
  - `cargo test -p codex-core` integration target (`tests/all`) still
  shows pre-existing env-specific failures in this environment due missing
  `test_stdio_server` binary resolution; core unit tests are green.
  
  ## Codex author
  `codex resume 019c26ff-dfe7-7173-bc04-c9e1fff1e447`

  Charley Cunningham · 2026-02-04 23:03:28 -08:00
  41b4962b0a