327 Commits

• Unify realtime stop handling in TUI (#15529)

  ## Summary
  - route /realtime, Ctrl+C, and deleted realtime meters through the same
  realtime stop path
  - keep generic transcription placeholder cleanup free of realtime
  shutdown side effects
  
  ## Testing
  - Ran 
  - Relied on CI for verification; did not run local tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-23 13:47:33 -07:00
  7b92a90612
• Plugins TUI install/uninstall (#15342)

  - Add install/uninstall actions to the TUI plugins menu
  - Wire plugin install/uninstall through both TUI and `tui_app_server`
  - Refresh config/plugin state after changes so the UI updates
  immediately
  - Add a post-install app setup flow for plugins that require additional
  app auth
  
  <img width="1567" height="300" alt="Screenshot 2026-03-20 at 4 08 44 PM"
  src="https://github.com/user-attachments/assets/366bd31b-2ffd-4e80-b4a3-3a9a9c674a5f"
  />
  <img width="445" height="240" alt="Screenshot 2026-03-20 at 4 08 54 PM"
  src="https://github.com/user-attachments/assets/613999ab-269a-4758-ab59-7c057a1742dc"
  />
  <img width="797" height="219" alt="Screenshot 2026-03-20 at 4 09 07 PM"
  src="https://github.com/user-attachments/assets/b9679e60-40f5-49bb-ade0-2e40449c3fbf"
  />
  <img width="499" height="235" alt="Screenshot 2026-03-20 at 4 09 24 PM"
  src="https://github.com/user-attachments/assets/261ce2fe-f356-4e99-8ac9-f29ed850bc75"
  />
  
  
  
  
  Note/known issue: The /plugin install flow fails in `tui_app_server`
  because after a successful install it tries to trigger a
  ReloadUserConfig operation, but `tui_app_server` has not yet implemented
  transport for that operation, so it falls through to the generic “Not
  available in app-server TUI yet” stub.

  canvrno-oai · 2026-03-23 12:38:39 -07:00
  b5d0a5518d
• tui: queue follow-ups during manual /compact (#15259)

  ## Summary
  - queue input after the user submits `/compact` until that manual
  compact turn ends
  - mirror the same behavior in the app-server TUI
  - add regressions for input queued before compact starts and while it is
  running
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-23 10:19:44 -07:00
  e838645fa2
• fix: fall back to vendored bubblewrap when system bwrap lacks --argv0 (#15338)

  ## Why
  
  Fixes [#15283](https://github.com/openai/codex/issues/15283), where
  sandboxed tool calls fail on older distro `bubblewrap` builds because
  `/usr/bin/bwrap` does not understand `--argv0`. The upstream [bubblewrap
  v0.9.0 release
  notes](https://github.com/containers/bubblewrap/releases/tag/v0.9.0)
  explicitly call out `Add --argv0`. Flipping `use_legacy_landlock`
  globally works around that compatibility bug, but it also weakens the
  default Linux sandbox and breaks proxy-routed and split-policy cases
  called out in review.
  
  The follow-up Linux CI failure was in the new launcher test rather than
  the launcher logic: the fake `bwrap` helper stayed open for writing, so
  Linux would not exec it. This update also closes the user-visibility gap
  from review by surfacing the same startup warning when `/usr/bin/bwrap`
  is present but too old for `--argv0`, not only when it is missing.
  
  ## What Changed
  
  - keep `use_legacy_landlock` default-disabled
  - teach `codex-rs/linux-sandbox/src/launcher.rs` to fall back to the
  vendored bubblewrap build when `/usr/bin/bwrap` does not advertise
  `--argv0` support
  - add launcher tests for supported, unsupported, and missing system
  `bwrap`
  - write the fake `bwrap` test helper to a closed temp path so the
  supported-path launcher test works on Linux too
  - extend the startup warning path so Codex warns when `/usr/bin/bwrap`
  is missing or too old to support `--argv0`
  - mirror the warning/fallback wording across
  `codex-rs/linux-sandbox/README.md` and `codex-rs/core/README.md`,
  including that the fallback is the vendored bubblewrap compiled into the
  binary
  - cite the upstream `bubblewrap` release that introduced `--argv0`
  
  ## Verification
  
  - `bazel test --config=remote --platforms=//:rbe
  //codex-rs/linux-sandbox:linux-sandbox-unit-tests
  --test_filter=launcher::tests::prefers_system_bwrap_when_help_lists_argv0
  --test_output=errors`
  - `cargo test -p codex-core system_bwrap_warning`
  - `cargo check -p codex-exec -p codex-tui -p codex-tui-app-server -p
  codex-app-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-23 09:46:51 -07:00
  d1088158b8
• Initial plugins TUI menu - list and read only. tui + tui_app_server (#15215)

  ### Preliminary /plugins TUI menu
  - Adds a preliminary /plugins menu flow in both tui and tui_app_server.
  - Fetches plugin list data asynchronously and shows loading/error/cached
  states.
    - Limits this first pass to the curated ChatGPT marketplace.
    - Shows available plugins with installed/status metadata.
  - Supports in-menu search over plugin display name, plugin id, plugin
  name, and marketplace label.
  - Opens a plugin detail view on selection, including summaries for
  Skills, Apps, and MCP Servers, with back navigation.
  
  ### Testing
    - Launch codex-cli with plugins enabled (`--enable plugins`).
    - Run /plugins and verify:
        - loading state appears first
        - plugin list is shown
        - search filters results
  - selecting a plugin opens detail view, with a list of
  skills/connectors/MCP servers for the plugin
        - back action returns to the list.
  - Verify disabled behavior by running /plugins without plugins enabled
  (shows “Plugins are disabled” message).
  - Launch with `--enable tui_app_server` (and plugins enabled) and repeat
  the same /plugins flow; behavior should match.

  canvrno-oai · 2026-03-19 21:28:33 -07:00
  f7201e5a9f
• Use released DotSlash package for argument-comment lint (#15199)

  ## Why
  The argument-comment lint now has a packaged DotSlash artifact from
  [#15198](https://github.com/openai/codex/pull/15198), so the normal repo
  lint path should use that released payload instead of rebuilding the
  lint from source every time.
  
  That keeps `just clippy` and CI aligned with the shipped artifact while
  preserving a separate source-build path for people actively hacking on
  the lint crate.
  
  The current alpha package also exposed two integration wrinkles that the
  repo-side prebuilt wrapper needs to smooth over:
  - the bundled Dylint library filename includes the host triple, for
  example `@nightly-2025-09-18-aarch64-apple-darwin`, and Dylint derives
  `RUSTUP_TOOLCHAIN` from that filename
  - on Windows, Dylint's driver path also expects `RUSTUP_HOME` to be
  present in the environment
  
  Without those adjustments, the prebuilt CI jobs fail during `cargo
  metadata` or driver setup. This change makes the checked-in prebuilt
  wrapper normalize the packaged library name to the plain
  `nightly-2025-09-18` channel before invoking `cargo-dylint`, and it
  teaches both the wrapper and the packaged runner source to infer
  `RUSTUP_HOME` from `rustup show home` when the environment does not
  already provide it.
  
  After the prebuilt Windows lint job started running successfully, it
  also surfaced a handful of existing anonymous literal callsites in
  `windows-sandbox-rs`. This PR now annotates those callsites so the new
  cross-platform lint job is green on the current tree.
  
  ## What Changed
  - checked in the current
  `tools/argument-comment-lint/argument-comment-lint` DotSlash manifest
  - kept `tools/argument-comment-lint/run.sh` as the source-build wrapper
  for lint development
  - added `tools/argument-comment-lint/run-prebuilt-linter.sh` as the
  normal enforcement path, using the checked-in DotSlash package and
  bundled `cargo-dylint`
  - updated `just clippy` and `just argument-comment-lint` to use the
  prebuilt wrapper
  - split `.github/workflows/rust-ci.yml` so source-package checks live in
  a dedicated `argument_comment_lint_package` job, while the released lint
  runs in an `argument_comment_lint_prebuilt` matrix on Linux, macOS, and
  Windows
  - kept the pinned `nightly-2025-09-18` toolchain install in the prebuilt
  CI matrix, since the prebuilt package still relies on rustup-provided
  toolchain components
  - updated `tools/argument-comment-lint/run-prebuilt-linter.sh` to
  normalize host-qualified nightly library filenames, keep the `rustup`
  shim directory ahead of direct toolchain `cargo` binaries, and export
  `RUSTUP_HOME` when needed for Windows Dylint driver setup
  - updated `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
  so future published DotSlash artifacts apply the same nightly-filename
  normalization and `RUSTUP_HOME` inference internally
  - fixed the remaining Windows lint violations in
  `codex-rs/windows-sandbox-rs` by adding the required `/*param*/`
  comments at the reported callsites
  - documented the checked-in DotSlash file, wrapper split, archive
  layout, nightly prerequisite, and Windows `RUSTUP_HOME` requirement in
  `tools/argument-comment-lint/README.md`

  Michael Bolin · 2026-03-20 03:19:22 +00:00
  fa2a2f0be9
• Split features into codex-features crate (#15253)

  - Split the feature system into a new `codex-features` crate.
  - Cut `codex-core` and workspace consumers over to the new config and
  warning APIs.
  
  Co-authored-by: Ahmed Ibrahim <219906144+aibrahim-oai@users.noreply.github.com>
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 20:12:07 -07:00
  2e22885e79
• Move terminal module to terminal-detection crate (#15216)

  - Move core/src/terminal.rs and its tests into a standalone
  terminal-detection workspace crate.
  - Update direct consumers to depend on codex-terminal-detection and
  import terminal APIs directly.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-19 14:08:04 -07:00
  7eb19e5319
• feat(tui): add /title terminal title configuration (#12334)

  ## Problem
  
  When multiple Codex sessions are open at once, terminal tabs and windows
  are hard to distinguish from each other. The existing status line only
  helps once the TUI is already focused, so it does not solve the "which
  tab is this?" problem.
  
  This PR adds a first-class `/title` command so the terminal window or
  tab title can carry a short, configurable summary of the current
  session.
  
  ## Screenshot
  
  <img width="849" height="320" alt="image"
  src="https://github.com/user-attachments/assets/8b112927-7890-45ed-bb1e-adf2f584663d"
  />
  
  ## Mental model
  
  `/statusline` and `/title` are separate status surfaces with different
  constraints. The status line is an in-app footer that can be denser and
  more detailed. The terminal title is external terminal metadata, so it
  needs short, stable segments that still make multiple sessions easy to
  tell apart.
  
  The `/title` configuration is an ordered list of compact items. By
  default it renders `spinner,project`, so active sessions show
  lightweight progress first while idle sessions still stay easy to
  disambiguate. Each configured item is omitted when its value is not
  currently available rather than forcing a placeholder.
  
  ## Non-goals
  
  This does not merge `/title` into `/statusline`, and it does not add an
  arbitrary free-form title string. The feature is intentionally limited
  to a small set of structured items so the title stays short and
  reviewable.
  
  This also does not attempt to restore whatever title the terminal or
  shell had before Codex started. When Codex clears the title, it clears
  the title Codex last wrote.
  
  ## Tradeoffs
  
  A separate `/title` command adds some conceptual overlap with
  `/statusline`, but it keeps title-specific constraints explicit instead
  of forcing the status line model to cover two different surfaces.
  
  Title refresh can happen frequently, so the implementation now shares
  parsing and git-branch orchestration between the status line and title
  paths, and caches the derived project-root name by cwd. That keeps the
  hot path cheap without introducing background polling.
  
  ## Architecture
  
  The TUI gets a new `/title` slash command and a dedicated picker UI for
  selecting and ordering terminal-title items. The chosen ids are
  persisted in `tui.terminal_title`, with `spinner` and `project` as the
  default when the config is unset. `status` remains available as a
  separate text item, so configurations like `spinner,status` render
  compact progress like `⠋ Working`.
  
  `ChatWidget` now refreshes both status surfaces through a shared
  `refresh_status_surfaces()` path. That shared path parses configured
  items once, warns on invalid ids once, synchronizes shared cached state
  such as git-branch lookup, then renders the footer status line and
  terminal title from the same snapshot.
  
  Low-level OSC title writes live in `codex-rs/tui/src/terminal_title.rs`,
  which owns the terminal write path and last-mile sanitization before
  emitting OSC 0.
  
  ## Security
  
  Terminal-title text is treated as untrusted display content before Codex
  emits it. The write path strips control characters, removes invisible
  and bidi formatting characters that can make the title visually
  misleading, normalizes whitespace, and caps the emitted length.
  
  References used while implementing this:
  
  - [xterm control
  sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html)
  - [WezTerm escape sequences](https://wezterm.org/escape-sequences.html)
  - [CWE-150: Improper Neutralization of Escape, Meta, or Control
  Sequences](https://cwe.mitre.org/data/definitions/150.html)
  - [CERT VU#999008 (Trojan Source)](https://kb.cert.org/vuls/id/999008)
  - [Trojan Source disclosure site](https://trojansource.codes/)
  - [Unicode Bidirectional Algorithm (UAX
  #9)](https://www.unicode.org/reports/tr9/)
  - [Unicode Security Considerations (UTR
  #36)](https://www.unicode.org/reports/tr36/)
  
  ## Observability
  
  Unknown configured title item ids are warned about once instead of
  repeatedly spamming the transcript. Live preview applies immediately
  while the `/title` picker is open, and cancel rolls the in-memory title
  selection back to the pre-picker value.
  
  If terminal title writes fail, the TUI emits debug logs around set and
  clear attempts. The rendered status label intentionally collapses richer
  internal states into compact title text such as `Starting...`, `Ready`,
  `Thinking...`, `Working...`, `Waiting...`, and `Undoing...` when
  `status` is configured.
  
  ## Tests
  
  Ran:
  
  - `just fmt`
  - `cargo test -p codex-tui`
  
  At the moment, the red Windows `rust-ci` failures are due to existing
  `codex-core` `apply_patch_cli` stack-overflow tests that also reproduce
  on `main`. The `/title`-specific `codex-tui` suite is green.

  Yaroslav Volovich · 2026-03-19 19:26:36 +00:00
  60cd0cf75e
• Support featured plugins (#15042)
  alexsong-oai · 2026-03-18 17:45:30 -07:00
  825d09373d
• Revert "fix: harden plugin feature gating" (#15102)

  Reverts openai/codex#15020
  
  I messed up the commit in my PR and accidentally merged changes that
  were still under review.

  xl-openai · 2026-03-18 15:19:29 -07:00
  86982ca1f9
• Add a startup deprecation warning for custom prompts (#15076)

  ## Summary
  - detect custom prompts in `$CODEX_HOME/prompts` during TUI startup
  - show a deprecation notice only when prompts are present, with guidance
  to use `$skill-creator`
  - add TUI tests and snapshot coverage for present, missing, and empty
  prompts directories
  
  ## Testing
  - Manually tested

  Eric Traut · 2026-03-18 15:21:30 -06:00
  e5de13644d
• fix: harden plugin feature gating (#15020)

  1. Use requirement-resolved config.features as the plugin gate.
  2. Guard plugin/list, plugin/read, and related flows behind that gate.
  3. Skip bad marketplace.json files instead of failing the whole list.
  4. Simplify plugin state and caching.

  xl-openai · 2026-03-18 10:11:43 -07:00
  580f32ad2a
• fix(linux-sandbox): prefer system /usr/bin/bwrap when available (#14963)

  ## Problem
  Ubuntu/AppArmor hosts started failing in the default Linux sandbox path
  after the switch to vendored/default bubblewrap in `0.115.0`.
  
  The clearest report is in
  [#14919](https://github.com/openai/codex/issues/14919), especially [this
  investigation
  comment](https://github.com/openai/codex/issues/14919#issuecomment-4076504751):
  on affected Ubuntu systems, `/usr/bin/bwrap` works, but a copied or
  vendored `bwrap` binary fails with errors like `bwrap: setting up uid
  map: Permission denied` or `bwrap: loopback: Failed RTM_NEWADDR:
  Operation not permitted`.
  
  The root cause is Ubuntu's `/etc/apparmor.d/bwrap-userns-restrict`
  profile, which grants `userns` access specifically to `/usr/bin/bwrap`.
  Once Codex started using a vendored/internal bubblewrap path, that path
  was no longer covered by the distro AppArmor exception, so sandbox
  namespace setup could fail even when user namespaces were otherwise
  enabled and `uidmap` was installed.
  
  ## What this PR changes
  - prefer system `/usr/bin/bwrap` whenever it is available
  - keep vendored bubblewrap as the fallback when `/usr/bin/bwrap` is
  missing
  - when `/usr/bin/bwrap` is missing, surface a Codex startup warning
  through the app-server/TUI warning path instead of printing directly
  from the sandbox helper with `eprintln!`
  - use the same launcher decision for both the main sandbox execution
  path and the `/proc` preflight path
  - document the updated Linux bubblewrap behavior in the Linux sandbox
  and core READMEs
  
  ## Why this fix
  This still fixes the Ubuntu/AppArmor regression from
  [#14919](https://github.com/openai/codex/issues/14919), but it keeps the
  runtime rule simple and platform-agnostic: if the standard system
  bubblewrap is installed, use it; otherwise fall back to the vendored
  helper.
  
  The warning now follows that same simple rule. If Codex cannot find
  `/usr/bin/bwrap`, it tells the user that it is falling back to the
  vendored helper, and it does so through the existing startup warning
  plumbing that reaches the TUI and app-server instead of low-level
  sandbox stderr.
  
  ## Testing
  - `cargo test -p codex-linux-sandbox`
  - `cargo test -p codex-app-server --lib`
  - `cargo test -p codex-tui-app-server
  tests::embedded_app_server_start_failure_is_returned`
  - `cargo clippy -p codex-linux-sandbox --all-targets`
  - `cargo clippy -p codex-app-server --all-targets`
  - `cargo clippy -p codex-tui-app-server --all-targets`

  viyatb-oai · 2026-03-17 23:05:34 +00:00
  0d1539e74c
• Revert tui code so it does not rely on in-process app server (#14899)

  PR https://github.com/openai/codex/pull/14512 added an in-process app
  server and started to wire up the tui to use it. We were originally
  planning to modify the `tui` code in place, converting it to use the app
  server a bit at a time using a hybrid adapter. We've since decided to
  create an entirely new parallel `tui_app_server` implementation and do
  the conversion all at once but retain the existing `tui` while we work
  the bugs out of the new implementation.
  
  This PR undoes the changes to the `tui` made in the PR #14512 and
  restores the old initialization to its previous state. This allows us to
  modify the `tui_app_server` without the risk of regressing the old `tui`
  code. For example, we can start to remove support for all legacy core
  events, like the ones that PR https://github.com/openai/codex/pull/14892
  needed to ignore.
  
  Testing:
  * I manually verified that the old `tui` starts and shuts down without a
  problem.

  Eric Traut · 2026-03-17 00:56:32 -06:00
  d37dcca7e0
• Apply argument comment lint across codex-rs (#14652)

  ## Why
  
  Once the repo-local lint exists, `codex-rs` needs to follow the
  checked-in convention and CI needs to keep it from drifting. This commit
  applies the fallback `/*param*/` style consistently across existing
  positional literal call sites without changing those APIs.
  
  The longer-term preference is still to avoid APIs that require comments
  by choosing clearer parameter types and call shapes. This PR is
  intentionally the mechanical follow-through for the places where the
  existing signatures stay in place.
  
  After rebasing onto newer `main`, the rollout also had to cover newly
  introduced `tui_app_server` call sites. That made it clear the first cut
  of the CI job was too expensive for the common path: it was spending
  almost as much time installing `cargo-dylint` and re-testing the lint
  crate as a representative test job spends running product tests. The CI
  update keeps the full workspace enforcement but trims that extra
  overhead from ordinary `codex-rs` PRs.
  
  ## What changed
  
  - keep a dedicated `argument_comment_lint` job in `rust-ci`
  - mechanically annotate remaining opaque positional literals across
  `codex-rs` with exact `/*param*/` comments, including the rebased
  `tui_app_server` call sites that now fall under the lint
  - keep the checked-in style aligned with the lint policy by using
  `/*param*/` and leaving string and char literals uncommented
  - cache `cargo-dylint`, `dylint-link`, and the relevant Cargo
  registry/git metadata in the lint job
  - split changed-path detection so the lint crate's own `cargo test` step
  runs only when `tools/argument-comment-lint/*` or `rust-ci.yml` changes
  - continue to run the repo wrapper over the `codex-rs` workspace, so
  product-code enforcement is unchanged
  
  Most of the code changes in this commit are intentionally mechanical
  comment rewrites or insertions driven by the lint itself.
  
  ## Verification
  
  - `./tools/argument-comment-lint/run.sh --workspace`
  - `cargo test -p codex-tui-app-server -p codex-tui`
  - parsed `.github/workflows/rust-ci.yml` locally with PyYAML
  
  ---
  
  * -> #14652
  * #14651

  Michael Bolin · 2026-03-16 16:48:15 -07:00
  b77fe8fefe
• Reuse guardian session across approvals (#14668)

  ## Summary
  - reuse a guardian subagent session across approvals so reviews keep a
  stable prompt cache key and avoid one-shot startup overhead
  - clear the guardian child history before each review so prior guardian
  decisions do not leak into later approvals
  - include the `smart_approvals` -> `guardian_approval` feature flag
  rename in the same PR to minimize release latency on a very tight
  timeline
  - add regression coverage for prompt-cache-key reuse without
  prior-review prompt bleed
  
  ## Request
  - Bug/enhancement request: internal guardian prompt-cache and latency
  improvement request
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-15 22:56:18 -07:00
  6fdeb1d602
• Add Smart Approvals guardian review across core, app-server, and TUI (#13860)

  ## Summary
  - add `approvals_reviewer = "user" | "guardian_subagent"` as the runtime
  control for who reviews approval requests
  - route Smart Approvals guardian review through core for command
  execution, file changes, managed-network approvals, MCP approvals, and
  delegated/subagent approval flows
  - expose guardian review in app-server with temporary unstable
  `item/autoApprovalReview/{started,completed}` notifications carrying
  `targetItemId`, `review`, and `action`
  - update the TUI so Smart Approvals can be enabled from `/experimental`,
  aligned with the matching `/approvals` mode, and surfaced clearly while
  reviews are pending or resolved
  
  ## Runtime model
  This PR does not introduce a new `approval_policy`.
  
  Instead:
  - `approval_policy` still controls when approval is needed
  - `approvals_reviewer` controls who reviewable approval requests are
  routed to:
    - `user`
    - `guardian_subagent`
  
  `guardian_subagent` is a carefully prompted reviewer subagent that
  gathers relevant context and applies a risk-based decision framework
  before approving or denying the request.
  
  The `smart_approvals` feature flag is a rollout/UI gate. Core runtime
  behavior keys off `approvals_reviewer`.
  
  When Smart Approvals is enabled from the TUI, it also switches the
  current `/approvals` settings to the matching Smart Approvals mode so
  users immediately see guardian review in the active thread:
  - `approval_policy = on-request`
  - `approvals_reviewer = guardian_subagent`
  - `sandbox_mode = workspace-write`
  
  Users can still change `/approvals` afterward.
  
  Config-load behavior stays intentionally narrow:
  - plain `smart_approvals = true` in `config.toml` remains just the
  rollout/UI gate and does not auto-set `approvals_reviewer`
  - the deprecated `guardian_approval = true` alias migration does
  backfill `approvals_reviewer = "guardian_subagent"` in the same scope
  when that reviewer is not already configured there, so old configs
  preserve their original guardian-enabled behavior
  
  ARC remains a separate safety check. For MCP tool approvals, ARC
  escalations now flow into the configured reviewer instead of always
  bypassing guardian and forcing manual review.
  
  ## Config stability
  The runtime reviewer override is stable, but the config-backed
  app-server protocol shape is still settling.
  
  - `thread/start`, `thread/resume`, and `turn/start` keep stable
  `approvalsReviewer` overrides
  - the config-backed `approvals_reviewer` exposure returned via
  `config/read` (including profile-level config) is now marked
  `[UNSTABLE]` / experimental in the app-server protocol until we are more
  confident in that config surface
  
  ## App-server surface
  This PR intentionally keeps the guardian app-server shape narrow and
  temporary.
  
  It adds generic unstable lifecycle notifications:
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`
  
  with payloads of the form:
  - `{ threadId, turnId, targetItemId, review, action? }`
  
  `review` is currently:
  - `{ status, riskScore?, riskLevel?, rationale? }`
  - where `status` is one of `inProgress`, `approved`, `denied`, or
  `aborted`
  
  `action` carries the guardian action summary payload from core when
  available. This lets clients render temporary standalone pending-review
  UI, including parallel reviews, even when the underlying tool item has
  not been emitted yet.
  
  These notifications are explicitly documented as `[UNSTABLE]` and
  expected to change soon.
  
  This PR does **not** persist guardian review state onto `thread/read`
  tool items. The intended follow-up is to attach guardian review state to
  the reviewed tool item lifecycle instead, which would improve
  consistency with manual approvals and allow thread history / reconnect
  flows to replay guardian review state directly.
  
  ## TUI behavior
  - `/experimental` exposes the rollout gate as `Smart Approvals`
  - enabling it in the TUI enables the feature and switches the current
  session to the matching Smart Approvals `/approvals` mode
  - disabling it in the TUI clears the persisted `approvals_reviewer`
  override when appropriate and returns the session to default manual
  review when the effective reviewer changes
  - `/approvals` still exposes the reviewer choice directly
  - the TUI renders:
  - pending guardian review state in the live status footer, including
  parallel review aggregation
    - resolved approval/denial state in history
  
  ## Scope notes
  This PR includes the supporting core/runtime work needed to make Smart
  Approvals usable end-to-end:
  - shell / unified-exec / apply_patch / managed-network / MCP guardian
  review
  - delegated/subagent approval routing into guardian review
  - guardian review risk metadata and action summaries for app-server/TUI
  - config/profile/TUI handling for `smart_approvals`, `guardian_approval`
  alias migration, and `approvals_reviewer`
  - a small internal cleanup of delegated approval forwarding to dedupe
  fallback paths and simplify guardian-vs-parent approval waiting (no
  intended behavior change)
  
  Out of scope for this PR:
  - redesigning the existing manual approval protocol shapes
  - persisting guardian review state onto app-server `ThreadItem`s
  - delegated MCP elicitation auto-review (the current delegated MCP
  guardian shim only covers the legacy `RequestUserInput` path)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-13 15:27:00 -07:00
  bc24017d64
• Stabilize multi-agent feature flag (#14622)

  - make multi_agent stable and enabled by default
  - update feature and tool-spec coverage to match the new default
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-13 14:38:15 -07:00
  36dfb84427
• Use subagents naming in the TUI (#14618)

  - rename user-facing TUI multi-agent wording to subagents
  - rename the surfaced slash command to `subagents` and update
  tests/snapshots
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-13 19:08:38 +00:00
  d58620c852
• Start TUI on embedded app server (#14512)

  This PR is part of the effort to move the TUI on top of the app server.
  In a previous PR, we introduced an in-process app server and moved
  `exec` on top of it.
  
  For the TUI, we want to do the migration in stages. The app server
  doesn't currently expose all of the functionality required by the TUI,
  so we're going to need to support a hybrid approach as we make the
  transition.
  
  This PR changes the TUI initialization to instantiate an in-process app
  server and access its `AuthManager` and `ThreadManager` rather than
  constructing its own copies. It also adds a placeholder TUI event
  handler that will eventually translate app server events into TUI
  events. App server notifications are accepted but ignored for now. It
  also adds proper shutdown of the app server when the TUI terminates.

  Eric Traut · 2026-03-13 12:04:41 -06:00
  9dba7337f2
• Simplify permissions available in request permissions tool (#14529)
  Jack Mousseau · 2026-03-12 21:13:17 -07:00
  7c7e267501
• [apps] Add tool_suggest tool. (#14287)

  - [x] Add tool_suggest tool.
  - [x] Move chatgpt/src/connectors.rs and core/src/connectors.rs into a
  dedicated mod so that we have all the logic and global cache in one
  place.
  - [x] Update TUI app link view to support rendering the installation
  view for mcp elicitation.
  
  ---------
  
  Co-authored-by: Shaqayeq <shaqayeq@openai.com>
  Co-authored-by: Eric Traut <etraut@openai.com>
  Co-authored-by: pakrym-oai <pakrym@openai.com>
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>
  Co-authored-by: guinness-oai <guinness@openai.com>
  Co-authored-by: Eugene Brevdo <ebrevdo@users.noreply.github.com>
  Co-authored-by: Charlie Guo <cguo@openai.com>
  Co-authored-by: Fouad Matin <fouad@openai.com>
  Co-authored-by: Fouad Matin <169186268+fouad-openai@users.noreply.github.com>
  Co-authored-by: xl-openai <xl@openai.com>
  Co-authored-by: alexsong-oai <alexsong@openai.com>
  Co-authored-by: Owen Lin <owenlin0@gmail.com>
  Co-authored-by: sdcoffey <stevendcoffey@gmail.com>
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Won Park <won@openai.com>
  Co-authored-by: Dylan Hurd <dylan.hurd@openai.com>
  Co-authored-by: celia-oai <celia@openai.com>
  Co-authored-by: gabec-openai <gabec@openai.com>
  Co-authored-by: joeytrasatti-openai <joey.trasatti@openai.com>
  Co-authored-by: Leo Shimonaka <leoshimo@openai.com>
  Co-authored-by: Rasmus Rygaard <rasmus@openai.com>
  Co-authored-by: maja-openai <163171781+maja-openai@users.noreply.github.com>
  Co-authored-by: pash-openai <pash@openai.com>
  Co-authored-by: Josh McKinney <joshka@openai.com>

  Matthew Zeng · 2026-03-11 22:06:59 -07:00
  ba5b94287e
• feat(app-server): propagate traces across tasks and core ops (#14387)

  ## Summary
  
  This PR keeps app-server RPC request trace context alive for the full
  lifetime of the work that request kicks off (e.g. for `thread/start`,
  this is `app-server rpc handler -> tokio background task -> core op
  submissions`). Previously we lose trace lineage once the request handler
  returns or hands work off to background tasks.
  
  This approach is especially relevant for `thread/start` and other RPC
  handlers that run in a non-blocking way. In the near future we'll most
  likely want to make all app-server handlers run in a non-blocking way by
  default, and only queue operations that must operate in order (e.g.
  thread RPCs per thread?), so we want to make sure tracing in app-server
  just generally works.
  
  Depends on https://github.com/openai/codex/pull/14300
  
  **Before**
  <img width="155" height="207" alt="image"
  src="https://github.com/user-attachments/assets/c9487459-36f1-436c-beb7-fafeb40737af"
  />
  
  
  **After**
  <img width="299" height="337" alt="image"
  src="https://github.com/user-attachments/assets/727392b2-d072-4427-9dc4-0502d8652dea"
  />
  
  ## What changed
  
  - Keep request-scoped trace context around until we send the final
  response or error, or the connection closes.
  - Thread that trace context through detached `thread/start` work so
  background startup stays attached to the originating request.
  - Pass request trace context through to downstream core operations,
  including:
    - thread creation
    - resume/fork flows
    - turn submission
    - review
    - interrupt
    - realtime conversation operations
  - Add tracing tests that verify:
    - remote W3C trace context is preserved for `thread/start`
    - remote W3C trace context is preserved for `turn/start`
    - downstream core spans stay under the originating request span
    - request-scoped tracing state is cleaned up correctly
  - Clean up shutdown behavior so detached background tasks and spawned
  threads are drained before process exit.

  Owen Lin · 2026-03-11 20:18:31 -07:00
  5bc82c5b93
• Keep agent-switch word-motion keys out of draft editing (#14376)

  ## Summary
  - only trigger multi-agent fast-switch shortcuts when the composer is
  empty
  - keep the Option+b/f fallback for terminals that encode Option+arrow
  that way
  - document why the empty-composer gate preserves expected word-wise
  editing behavior
  
  ## Testing
  - just fmt
  - cargo test -p codex-tui
  
  Co-authored-by: Codex <noreply@openai.com>

  Josh McKinney · 2026-03-11 14:52:40 -07:00
  f548309797
• Add keyboard based fast switching between agents in TUI (#13923)
  gabec-openai · 2026-03-11 12:33:10 -07:00
  180a5820fc
• feat: support disabling bundled system skills (#13792)

  Support disable bundled system skills with a config:
  
  [skills.bundled]
  enabled = false

  xl-openai · 2026-03-09 22:02:53 -07:00
  0c33af7746
• tui: only show fast status for gpt-5.4 (#14135)
  pash-openai · 2026-03-09 21:12:05 -07:00
  63597d1b2d
• fix(plugin): Also load curated plugins for TUI. (#14050)

  Also run maybe_start_curated_repo_sync_for_config at TUI start time.

  xl-openai · 2026-03-09 11:05:02 -07:00
  c1f3ef16ec
• feat(tui) render request_permissions calls (#14004)

  ## Summary
  Adds support for tui rendering of request_permission calls
  
  <img width="724" height="245" alt="Screenshot 2026-03-08 at 9 04 07 PM"
  src="https://github.com/user-attachments/assets/e1997825-a496-4bfb-bbda-43d0006460a5"
  />
  
  
  ## Testing
  - [x] Added snapshot test

  Dylan Hurd · 2026-03-09 04:24:04 +00:00
  06f82c123c
• app-server: include experimental skill metadata in exec approval requests (#13929)

  ## Summary
  
  This change surfaces skill metadata on command approval requests so
  app-server clients can tell when an approval came from a skill script
  and identify the originating `SKILL.md`.
  
  - add `skill_metadata` to exec approval events in the shared protocol
  - thread skill metadata through core shell escalation and delegated
  approval handling for skill-triggered approvals
  - expose the field in app-server v2 as experimental `skillMetadata`
  - regenerate the JSON/TypeScript schemas and cover the new field in
  protocol, transport, core, and TUI tests
  
  ## Why
  
  Skill-triggered approvals already carry skill context inside core, but
  app-server clients could not see which skill caused the prompt. Sending
  the skill metadata with the approval request makes it possible for
  clients to present better approval UX and connect the prompt back to the
  relevant skill definition.
  
  
  ## example event in app-server-v2
  verified that we see this event when experimental api is on:
  ```
  < {
  <   "id": 11,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "additionalPermissions": {
  <       "fileSystem": null,
  <       "macos": {
  <         "accessibility": false,
  <         "automations": {
  <           "bundle_ids": [
  <             "com.apple.Notes"
  <           ]
  <         },
  <         "calendar": false,
  <         "preferences": "read_only"
  <       },
  <       "network": null
  <     },
  <     "approvalId": "25d600ee-5a3c-4746-8d17-e2e61fb4c563",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes",
  <     "itemId": "call_jZp3xFpNg4D8iKAD49cvEvZy",
  <     "skillMetadata": {
  <       "pathToSkillsMd": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/SKILL.md"
  <     },
  <     "threadId": "019ccc10-b7d3-7ff2-84fe-3a75e7681e69",
  <     "turnId": "019ccc10-b848-76f1-81b3-4a1fa225493f"
  <   }
  < }`
  ```
  
  & verified that this is the event when experimental api is off:
  ```
  < {
  <   "id": 13,
  <   "method": "item/commandExecution/requestApproval",
  <   "params": {
  <     "approvalId": "5fbbf776-261b-4cf8-899b-c125b547f2c0",
  <     "availableDecisions": [
  <       "accept",
  <       "acceptForSession",
  <       "cancel"
  <     ],
  <     "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <     "commandActions": [
  <       {
  <         "command": "/Applications/ChatGPT.app/Contents/Resources/CodexAppServer_CodexAppServerBundledSkills.bundle/Contents/Resources/skills/apple-notes/scripts/notes_info",
  <         "type": "unknown"
  <       }
  <     ],
  <     "cwd": "/Users/celia/code/codex/codex-rs",
  <     "itemId": "call_OV2DHzTgYcbYtWaTTBWlocOt",
  <     "threadId": "019ccc16-2a2b-7be1-8500-e00d45b892d4",
  <     "turnId": "019ccc16-2a8e-7961-98ec-649600e7d06a"
  <   }
  < }
  ```

  Celia Chen · 2026-03-08 18:07:46 -07:00
  340f9c9ecb
• [elicitations] Support always allow option for mcp tool calls. (#13807)

  - [x] Support always allow option for mcp tool calls, writes to
  config.toml.
  - [x] Fix config hot-reload after starting a new thread for TUI.

  Matthew Zeng · 2026-03-08 01:46:40 +00:00
  a4a9536fd7
• Fix TUI context window display before first TokenCount (#13896)

  The TUI was showing the raw configured `model_context_window` until the
  first
  `TokenCount` event arrived, even though core had already emitted the
  effective
  runtime window on `TurnStarted`. This made the footer, status-line
  context
  window, and `/status` output briefly inconsistent for models/configs
  where the
  effective window differs from the configured value, such as the
  `gpt-5.4`
  1,000,000-token override reported in #13623.
  
  Update the TUI to cache `TurnStarted.model_context_window` immediately
  so
  pre-token-count displays use the runtime effective window, and add
  regression
  coverage for the startup path.
  
  ---------
  
  Co-authored-by: Charles Cunningham <ccunningham@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Eric Traut · 2026-03-07 17:01:47 -07:00
  e8d7ede83c
• Add guardian approval MVP (#13692)

  ## Summary
  - add the guardian reviewer flow for `on-request` approvals in command,
  patch, sandbox-retry, and managed-network approval paths
  - keep guardian behind `features.guardian_approval` instead of exposing
  a public `approval_policy = guardian` mode
  - route ordinary `OnRequest` approvals to the guardian subagent when the
  feature is enabled, without changing the public approval-mode surface
  
  ## Public model
  - public approval modes stay unchanged
  - guardian is enabled via `features.guardian_approval`
  - when that feature is on, `approval_policy = on-request` keeps the same
  approval boundaries but sends those approval requests to the guardian
  reviewer instead of the user
  - `/experimental` only persists the feature flag; it does not rewrite
  `approval_policy`
  - CLI and app-server no longer expose a separate `guardian` approval
  mode in this PR
  
  ## Guardian reviewer
  - the reviewer runs as a normal subagent and reuses the existing
  subagent/thread machinery
  - it is locked to a read-only sandbox and `approval_policy = never`
  - it does not inherit user/project exec-policy rules
  - it prefers `gpt-5.4` when the current provider exposes it, otherwise
  falls back to the parent turn's active model
  - it fail-closes on timeout, startup failure, malformed output, or any
  other review error
  - it currently auto-approves only when `risk_score < 80`
  
  ## Review context and policy
  - guardian mirrors `OnRequest` approval semantics rather than
  introducing a separate approval policy
  - explicit `require_escalated` requests follow the same approval surface
  as `OnRequest`; the difference is only who reviews them
  - managed-network allowlist misses that enter the approval flow are also
  reviewed by guardian
  - the review prompt includes bounded recent transcript history plus
  recent tool call/result evidence
  - transcript entries and planned-action strings are truncated with
  explicit `<guardian_truncated ... />` markers so large payloads stay
  bounded
  - apply-patch reviews include the full patch content (without
  duplicating the structured `changes` payload)
  - the guardian request layout is snapshot-tested using the same
  model-visible Responses request formatter used elsewhere in core
  
  ## Guardian network behavior
  - the guardian subagent inherits the parent session's managed-network
  allowlist when one exists, so it can use the same approved network
  surface while reviewing
  - exact session-scoped network approvals are copied into the guardian
  session with protocol/port scope preserved
  - those copied approvals are now seeded before the guardian's first turn
  is submitted, so inherited approvals are available during any immediate
  review-time checks
  
  ## Out of scope / follow-ups
  - the sandbox-permission validation split was pulled into a separate PR
  and is not part of this diff
  - a future follow-up can enable `serde_json` preserve-order in
  `codex-core` and then simplify the guardian action rendering further
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-07 05:40:10 -08:00
  e84ee33cc0
• chore(otel): rename OtelManager to SessionTelemetry (#13808)

  ## Summary
  This is a purely mechanical refactor of `OtelManager` ->
  `SessionTelemetry` to better convey what the struct is doing. No
  behavior change.
  
  ## Why
  
  `OtelManager` ended up sounding much broader than what this type
  actually does. It doesn't manage OTEL globally; it's the session-scoped
  telemetry surface for emitting log/trace events and recording metrics
  with consistent session metadata (`app_version`, `model`, `slug`,
  `originator`, etc.).
  
  `SessionTelemetry` is a more accurate name, and updating the call sites
  makes that boundary a lot easier to follow.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core`

  Owen Lin · 2026-03-06 16:23:30 -08:00
  289ed549cf
• [elicitations] Switch to use MCP style elicitation payload for mcp tool approvals. (#13621)

  - [x] Switch to use MCP style elicitation payload for mcp tool
  approvals.
  - [ ] TODO: Update the UI to support the full spec.

  Matthew Zeng · 2026-03-06 01:50:26 -08:00
  98dca99db7
• feat(app-server): support mcp elicitations in v2 api (#13425)

  This adds a first-class server request for MCP server elicitations:
  `mcpServer/elicitation/request`.
  
  Until now, MCP elicitation requests only showed up as a raw
  `codex/event/elicitation_request` event from core. That made it hard for
  v2 clients to handle elicitations using the same request/response flow
  as other server-driven interactions (like shell and `apply_patch`
  tools).
  
  This also updates the underlying MCP elicitation request handling in
  core to pass through the full MCP request (including URL and form data)
  so we can expose it properly in app-server.
  
  ### Why not `item/mcpToolCall/elicitationRequest`?
  This is because MCP elicitations are related to MCP servers first, and
  only optionally to a specific MCP tool call.
  
  In the MCP protocol, elicitation is a server-to-client capability: the
  server sends `elicitation/create`, and the client replies with an
  elicitation result. RMCP models it that way as well.
  
  In practice an elicitation is often triggered by an MCP tool call, but
  not always.
  
  ### What changed
  - add `mcpServer/elicitation/request` to the v2 app-server API
  - translate core `codex/event/elicitation_request` events into the new
  v2 server request
  - map client responses back into `Op::ResolveElicitation` so the MCP
  server can continue
  - update app-server docs and generated protocol schema
  - add an end-to-end app-server test that covers the full round trip
  through a real RMCP elicitation flow
  - The new test exercises a realistic case where an MCP tool call
  triggers an elicitation, the app-server emits
  mcpServer/elicitation/request, the client accepts it, and the tool call
  resumes and completes successfully.
  
  ### app-server API flow
  - Client starts a thread with `thread/start`.
  - Client starts a turn with `turn/start`.
  - App-server sends `item/started` for the `mcpToolCall`.
  - While that tool call is in progress, app-server sends
  `mcpServer/elicitation/request`.
  - Client responds to that request with `{ action: "accept" | "decline" |
  "cancel" }`.
  - App-server sends `serverRequest/resolved`.
  - App-server sends `item/completed` for the mcpToolCall.
  - App-server sends `turn/completed`.
  - If the turn is interrupted while the elicitation is pending,
  app-server still sends `serverRequest/resolved` before the turn
  finishes.

  Owen Lin · 2026-03-05 07:20:20 -08:00
  926b2f19e8
• [tui] Show speed in session header (#13446)

  - add a speed row to the startup/session header under the model row
  - render the speed row with the same styling pattern as the model row,
  using /fast to change
  - show only Fast or Standard to users and update the affected snapshots
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  pash-openai · 2026-03-05 00:00:16 -08:00
  1ce1712aeb
• fix: bad merge (#13461)
  jif-oai · 2026-03-04 11:00:48 +00:00
  e6b2e3a9f7
• fix: pending messages in /agent (#13240)
  jif-oai · 2026-03-04 10:17:29 +00:00
  e4a202ea52
• config: enforce enterprise feature requirements (#13388)

  ## Why
  
  Enterprises can already constrain approvals, sandboxing, and web search
  through `requirements.toml` and MDM, but feature flags were still only
  configurable as managed defaults. That meant an enterprise could suggest
  feature values, but it could not actually pin them.
  
  This change closes that gap and makes enterprise feature requirements
  behave like the other constrained settings. The effective feature set
  now stays consistent with enterprise requirements during config load,
  when config writes are validated, and when runtime code mutates feature
  flags later in the session.
  
  It also tightens the runtime API for managed features. `ManagedFeatures`
  now follows the same constraint-oriented shape as `Constrained<T>`
  instead of exposing panic-prone mutation helpers, and production code
  can no longer construct it through an unconstrained `From<Features>`
  path.
  
  The PR also hardens the `compact_resume_fork` integration coverage on
  Windows. After the feature-management changes,
  `compact_resume_after_second_compaction_preserves_history` was
  overflowing the libtest/Tokio thread stacks on Windows, so the test now
  uses an explicit larger-stack harness as a pragmatic mitigation. That
  may not be the ideal root-cause fix, and it merits a parallel
  investigation into whether part of the async future chain should be
  boxed to reduce stack pressure instead.
  
  ## What Changed
  
  Enterprises can now pin feature values in `requirements.toml` with the
  requirements-side `features` table:
  
  ```toml
  [features]
  personality = true
  unified_exec = false
  ```
  
  Only canonical feature keys are allowed in the requirements `features`
  table; omitted keys remain unconstrained.
  
  - Added a requirements-side pinned feature map to
  `ConfigRequirementsToml`, threaded it through source-preserving
  requirements merge and normalization in `codex-config`, and made the
  TOML surface use `[features]` (while still accepting legacy
  `[feature_requirements]` for compatibility).
  - Exposed `featureRequirements` from `configRequirements/read`,
  regenerated the JSON/TypeScript schema artifacts, and updated the
  app-server README.
  - Wrapped the effective feature set in `ManagedFeatures`, backed by
  `ConstrainedWithSource<Features>`, and changed its API to mirror
  `Constrained<T>`: `can_set(...)`, `set(...) -> ConstraintResult<()>`,
  and result-returning `enable` / `disable` / `set_enabled` helpers.
  - Removed the legacy-usage and bulk-map passthroughs from
  `ManagedFeatures`; callers that need those behaviors now mutate a plain
  `Features` value and reapply it through `set(...)`, so the constrained
  wrapper remains the enforcement boundary.
  - Removed the production loophole for constructing unconstrained
  `ManagedFeatures`. Non-test code now creates it through the configured
  feature-loading path, and `impl From<Features> for ManagedFeatures` is
  restricted to `#[cfg(test)]`.
  - Rejected legacy feature aliases in enterprise feature requirements,
  and return a load error when a pinned combination cannot survive
  dependency normalization.
  - Validated config writes against enterprise feature requirements before
  persisting changes, including explicit conflicting writes and
  profile-specific feature states that normalize into invalid
  combinations.
  - Updated runtime and TUI feature-toggle paths to use the constrained
  setter API and to persist or apply the effective post-constraint value
  rather than the requested value.
  - Updated the `core_test_support` Bazel target to include the bundled
  core model-catalog fixtures in its runtime data, so helper code that
  resolves `core/models.json` through runfiles works in remote Bazel test
  environments.
  - Renamed the core config test coverage to emphasize that effective
  feature values are normalized at runtime, while conflicting persisted
  config writes are rejected.
  - Ran `compact_resume_after_second_compaction_preserves_history` inside
  an explicit 8 MiB test thread and Tokio runtime worker stack, following
  the existing larger-stack integration-test pattern, to keep the Windows
  `compact_resume_fork` test slice from aborting while a parallel
  investigation continues into whether some of the underlying async
  futures should be boxed.
  
  ## Verification
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core feature_requirements_ -- --nocapture`
  - `cargo test -p codex-core
  load_requirements_toml_produces_expected_constraints -- --nocapture`
  - `cargo test -p codex-core
  compact_resume_after_second_compaction_preserves_history -- --nocapture`
  - `cargo test -p codex-core compact_resume_fork -- --nocapture`
  - Re-ran the built `codex-core` `tests/all` binary with
  `RUST_MIN_STACK=262144` for
  `compact_resume_after_second_compaction_preserves_history` to confirm
  the explicit-stack harness fixes the deterministic low-stack repro.
  - `cargo test -p codex-core`
  - This still fails locally in unrelated integration areas that expect
  the `codex` / `test_stdio_server` binaries or hit existing `search_tool`
  wiremock mismatches.
  
  ## Docs
  
  `developers.openai.com/codex` should document the requirements-side
  `[features]` table for enterprise and MDM-managed configuration,
  including that it only accepts canonical feature keys and that
  conflicting config writes are rejected.

  Michael Bolin · 2026-03-04 04:40:22 +00:00
  bfff0c729f
• app-server service tier plumbing (plus some cleanup) (#13334)

  followup to https://github.com/openai/codex/pull/13212 to expose fast
  tier controls to app server
  (majority of this PR is generated schema jsons - actual code is +69 /
  -35 and +24 tests )
  
  - add service tier fields to the app-server protocol surfaces used by
  thread lifecycle, turn start, config, and session configured events
  - thread service tier through the app-server message processor and core
  thread config snapshots
  - allow runtime config overrides to carry service tier for app-server
  callers
  
  cleanup:
  - Removing useless "legacy" code supporting "standard" - we moved to
  None | "fast", so "standard" is not needed.

  pash-openai · 2026-03-03 02:35:09 -08:00
  07e532dcb9
• add fast mode toggle (#13212)

  - add a local Fast mode setting in codex-core (similar to how model id
  is currently stored on disk locally)
  - send `service_tier=priority` on requests when Fast is enabled
  - add `/fast` in the TUI and persist it locally
  - feature flag

  pash-openai · 2026-03-02 20:29:33 -08:00
  2f5b01abd6
• feat: enable ma through /agent (#13246)

  <img width="639" height="139" alt="Screenshot 2026-03-02 at 16 06 41"
  src="https://github.com/user-attachments/assets/c006fcec-c1e7-41ce-bb84-c121d5ffb501"
  />
  
  Then
  <img width="372" height="37" alt="Screenshot 2026-03-02 at 16 06 49"
  src="https://github.com/user-attachments/assets/aa4ad703-e7e7-4620-9032-f5cd4f48ff79"
  />

  jif-oai · 2026-03-02 18:37:29 +00:00
  f8838fd6f3
• chore: /multiagent alias for /agent (#13249)

  Add a `/mutli-agents` alias for `/agent` and update the wording

  jif-oai · 2026-03-02 16:51:54 +00:00
  9a42a56d8f
• feat: approval for sub-agent in the TUI (#12995)

  <img width="766" height="290" alt="Screenshot 2026-02-27 at 10 50 48"
  src="https://github.com/user-attachments/assets/3bc96cd9-ed2c-4d67-a317-8f7b60abbbb1"
  />

  jif-oai · 2026-02-28 14:07:07 +01:00
  2b38b4e03b
• Add model availability NUX tooltips (#13021)

  - override startup tooltips with model availability NUX and persist
  per-model show counts in config
  - stop showing each model after four exposures and fall back to normal
  tooltips

  Ahmed Ibrahim · 2026-02-27 17:14:06 -08:00
  ec6f6aacbf
• Add realtime audio device picker (#12850)

  ## Summary
  - add a dedicated /audio picker for realtime microphone and speaker
  selection
  - persist realtime audio choices and prompt to restart only local audio
  when voice is live
  - add snapshot coverage for the new picker surfaces
  
  ## Validation
  - cargo test -p codex-tui
  - cargo insta accept
  - just fix -p codex-tui
  - just fmt

  Ahmed Ibrahim · 2026-02-26 17:27:44 -08:00
  f90e97e414
• tui: use thread_id for resume/fork cwd resolution (#12727)

  ## Summary
  - make resume/fork targets explicit and typed as `SessionTarget { path,
  thread_id }` (non-optional `thread_id`)
  - resolve `thread_id` centrally via `resolve_session_thread_id(...)`:
  - use CLI input directly when it is a UUID (`--resume <uuid>` / `--fork
  <uuid>`)
  - otherwise read `thread_id` from rollout `SessionMeta` for path-based
  selections (picker, `--resume-last`, name-based resume/fork)
  - use `thread_id` to read cwd from SQLite first during resume/fork cwd
  resolution
  - keep rollout fallback for cwd resolution when SQLite is unavailable or
  does not return thread metadata (`TurnContext` tail, then `SessionMeta`)
  - keep the resume picker open when a selected row has unreadable session
  metadata, and show an inline recoverable error instead of aborting the
  TUI
  
  ## Why
  This removes ad-hoc rollout filename parsing and makes resume/fork
  target identity explicit. The resume/fork cwd check can use indexed
  SQLite lookup by `thread_id` in the common path, while preserving
  rollout-based fallback behavior. It also keeps malformed legacy rows
  recoverable in the picker instead of letting a selection failure unwind
  the app.
  
  ## Notes
  - minimal TUI-only change; no schema/protocol changes
  - includes TUI test coverage for SQLite cwd precedence when `thread_id`
  is available
  - includes TUI regression coverage for picker inline error rendering /
  non-fatal unreadable session rows
  
  ## Codex author
  `codex resume 019c9205-7f8b-7173-a2a2-f082d4df3de3`

  Charley Cunningham · 2026-02-26 12:52:31 -08:00
  c1afb8815a
• fix: ctrl c sub agent (#12911)
  jif-oai · 2026-02-26 17:06:20 +00:00
  f0a85ded18