770 Commits

• [codex] Add interruptible sleep tool (#28429)

  ## Why
  
  Models sometimes need to pause briefly while waiting for external work,
  but using a shell command for that delay ties the wait to a process and
  does not naturally resume when new turn input arrives.
  
  ## What changed
  
  - add a built-in `sleep` tool behind the under-development `sleep_tool`
  feature
  - accept a bounded `duration_ms` argument, matching the millisecond
  convention used by unified exec
  - end the sleep early when either steered user input or mailbox input
  arrives
  - include elapsed wall-clock time in completed and interrupted outputs
  - emit a dedicated core `SleepItem` through `item/started` and
  `item/completed`
  - expose the sleep item as app-server v2 `ThreadItem::Sleep` and retain
  it in reconstructed thread history
  - regenerate the configuration schema for the new feature flag
  - regenerate app-server JSON and TypeScript schema fixtures
  
  ## Test plan
  
  - `just test -p codex-core sleep_tool_follows_feature_gate`
  - `just test -p codex-core any_new_input_interrupts_sleep`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  sleep_emits_started_and_completed_items`

  pakrym-oai · 2026-06-15 21:39:21 -07:00
  08901fc8e1
• Use ApiPathString in app-server filesystem permission paths (#28367)

  ## Why
  
  Clients running an app-server on one OS and an exec-server on another OS
  need to be able to pass sandbox config to app-server that refers to
  resources on the executor's foreign OS.
  
  ## What
  
  `AbsolutePathBuf` can't represent these paths and we don't want users to
  be exposed to `PathUri` yet, so this moves the public app-server API to
  be expressed in terms of `ApiPathString`.
  
  Stacked on #28165.
  
  - change app-server v2 filesystem permission paths, including legacy
  read/write roots, to `ApiPathString`
  - localize API paths through `PathUri` when converting into the current
  native core permission types
  - make path-bearing permission conversions fallible and surface
  localization failures instead of silently treating malformed grants as
  ordinary denials
  - propagate conversion failures through app-server and TUI approval
  handling
  - regenerate the app-server JSON and TypeScript schemas
  - leave migration TODOs on native-path conversions so they can be
  removed once core permission paths use `PathUri`

  Adam Perry @ OpenAI · 2026-06-15 19:25:54 -07:00
  ecfe174d5f
• [codex] Load API curated marketplace by auth (#28383)

  ## Summary
  - choose the local OpenAI curated marketplace manifest based on auth:
  Codex backend auth gets the existing marketplace, direct provider auth
  gets `api_marketplace.json`
  - include Bedrock API key auth in the direct-provider API marketplace
  path
  - safely skip the API marketplace when `api_marketplace.json` is absent
  
  ## Validation
  - `just fmt`
  - `git diff --check origin/main...HEAD`
  - CI should run the full validation
  
  ## Manual Testing
  
  ### - New api marketplace not available for API key sign
  1. Safely not display anything from api marketplace
  <img width="1161" height="289" alt="Screenshot 2026-06-15 at 21 37 43"
  src="https://github.com/user-attachments/assets/a5f16642-8a20-4ac1-a0de-1274a4c7b5b2"
  />
  
  ### - New api marketplace for API key sign in
  1. Setup api_marketplace.json
  ```
  {
    "name": "openai-curated",
    "interface": {
      "displayName": "Codex official"
    },
    "plugins": [
      {
        "name": "linear",
        "source": {
          "source": "local",
          "path": "./plugins/linear"
        },
        "policy": {
          "installation": "AVAILABLE",
          "authentication": "ON_INSTALL"
        },
        "category": "Productivity"
      }
    ]
  }
  ```
  
  2. Log in with API key, observe that only the defined plugin from
  api_marketplace.json is available from "Codex Official" (outside of
  local testing marketplaces)
  <img width="1167" height="446" alt="Screenshot 2026-06-15 at 21 16 53"
  src="https://github.com/user-attachments/assets/7cf61477-d826-4ef6-bc05-0a23ac1c0259"
  />
  
  also checked functionality on codex app
  
  ### - SiWC users 
  Still uses 'default' marketplace.json and renders all plugins
  <img width="1171" height="502" alt="Screenshot 2026-06-15 at 21 40 25"
  src="https://github.com/user-attachments/assets/d212ea9b-0aa5-470b-8ea4-450efe65bb2b"
  />
  
  also checked functionality on codex app
  
  
  ## Notes
  - `just test -p codex-core-plugins` was started locally before splitting
  branches, but I stopped relying on local tests per follow-up and left
  final validation to PR CI.

  felixxia-oai · 2026-06-16 01:16:11 +00:00
  02dce8eb8d
• TUI Plugin Sharing 2 - add remote plugin section plumbing (#26702)

  This adds the background plumbing for remote-backed plugin catalog
  sections while leaving the fuller directory presentation to the next PR.
  The TUI can fetch section-specific remote marketplace results, keep
  local plugin data available, and carry section errors forward for later
  rendering.
  
  - Fetches explicit remote marketplace kinds for curated, workspace, and
  shared-with-me sections.
  - Gates shared-with-me loading on the plugin sharing feature flag.
  - Adds section-level error state and user-actionable error copy.
  - Merges remote marketplace results into the cached plugin list without
  discarding local results.

  canvrno-oai · 2026-06-15 10:25:37 -07:00
  29224d945b
• feat(tui): reland token activity command (#27925)

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

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

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

  Eric Traut · 2026-06-12 17:14:27 -07:00
  9e07892253
• Promote TUI unified mentions in composer to default mentions feature (#27499)

  ## Summary
  
  This PR promotes Mentions 2.0 (unified TUI mention popup) to stable and
  enables it by default.
  
  - Keep `mentions_v2` as a temporary rollback path to the legacy split
  popups (`--disable mentions_v2`).
  - Add feature-default and snapshot coverage for the default experience.
  
  ## Prior work
  
  - [#19068 — Unified mentions in
  TUI](https://github.com/openai/codex/pull/19068)
  - [#22375 — Use plugin/list to get plugins for
  mentions](https://github.com/openai/codex/pull/22375)
  - [#23363 — Unified mentions tweaks and rendering
  polish](https://github.com/openai/codex/pull/23363)
  
  ## Test plan
  
  - Launch Codex without any feature overrides.
  - Type `@` in the TUI composer.
  - Confirm the unified mentions menu opens and displays filesystem,
  plugin, and skill results.

  canvrno-oai · 2026-06-12 16:29:40 -07:00
  1bd6b4c41a
• [2 of 3] Support long pasted text in TUI goals (#27509)

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

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

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

  Eric Traut · 2026-06-12 14:20:55 -07:00
  576f603440
• Handle standalone image generation failures as terminal items (#27920)

  ## Why
  
  Standalone image generation emitted a started item but no terminal item
  when the backend failed. Clients could leave the operation unresolved or
  render it as successful.
  
  ## What changed
  
  - Emit a terminal image-generation item with `status: "failed"` when
  generation or editing fails.
  - Skip image persistence for failed terminal items.
  - Render failed image generation distinctly in TUI history.
  - Preserve the status when handling live and replayed terminal items.
  
  ## Looks for TUI, App-Side change needed 
  
  <img width="867" height="89" alt="image"
  src="https://github.com/user-attachments/assets/9e32342f-a982-411e-8498-456639fc468a"
  />
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - App-server image-generation tests
  - Core stream-event tests
  - TUI image-generation lifecycle and snapshot tests
  - Scoped Clippy and formatting

  Won Park · 2026-06-12 11:57:22 -07:00
  b6baa77eec
• [codex] expose remote plugin share URL (#27890)

  ## Summary
  
  - expose the remote plugin detail endpoint's `share_url` as nullable
  `PluginDetail.shareUrl`
  - preserve existing `PluginSummary.shareContext` behavior for local and
  workspace sharing flows
  - regenerate the app-server TypeScript and JSON schema fixtures
  
  ## Why
  
  The remote plugin detail response already includes a canonical
  `share_url`, but that value was not surfaced by `plugin/read` for global
  plugins. Global plugins intentionally have no `shareContext`, so using
  that model for the URL would change the semantics consumed by the
  existing share modal.
  
  ## User impact
  
  Codex clients can use `PluginDetail.shareUrl` for a remote plugin's
  copy-link action, including when the plugin is disabled by an
  administrator, without changing existing share-modal or ownership
  behavior.
  
  ## Validation
  
  - `cargo test -p codex-app-server
  plugin_read_includes_share_url_for_admin_disabled_remote_plugin`
  - `cargo test -p codex-app-server-protocol
  typescript_schema_fixtures_match_generated`
  - `cargo test -p codex-app-server-protocol
  json_schema_fixtures_match_generated`
  - `cargo fmt --all`

  Eric Ning · 2026-06-12 11:53:55 -07:00
  9600afb1a1
• tui: Allow extra o's in /goal command (#27814)

  ## Why
  
  The TUI rejected playful `/goal` spellings such as `/goooooooooooal`,
  even though Codex Apps accepts them for the World Cup promotion. This
  keeps the TUI behavior consistent without changing how the canonical
  command is presented.
  
  ## How it works
  
  Built-in command lookup recognizes lowercase `go+al` as the existing
  `goal` command after normal exact-name parsing fails. The command
  catalog remains unchanged, so autocomplete continues to advertise
  `/goal` normally.
  
  ## Verification
  
  Added lookup-level and end-to-end TUI coverage for the flexible
  spelling. The focused tests, scoped Clippy checks, and formatting pass.
  The full `codex-tui` suite passed 2,833 of 2,835 tests; the two failing
  guardian feature-flag tests reproduce unchanged on fresh `origin/main`.

  Brent Traut · 2026-06-12 09:30:25 -07:00
  d735ef162f
• Add request_user_input auto-resolution window contract (#27256)

  ## Why
  
  `request_user_input` is moving beyond its original plan-mode-only
  workflow, and future default/goal-mode usage needs a way for the model
  to ask helpful but non-blocking questions without forcing the turn to
  wait forever. This PR adds an explicit `autoResolutionMs` contract so a
  later client/runtime change can auto-resolve unanswered prompts after a
  bounded window while leaving truly blocking questions unchanged.
  
  This is contract plumbing only; it does not implement the client-side
  timer or auto-selection behavior, and the model-facing description
  treats the field as reserved unless the current runtime explicitly
  supports auto-resolution.
  
  ## What Changed
  
  - Added optional `autoResolutionMs` to the model-facing
  `request_user_input` args and core `RequestUserInputEvent`.
  - Added model-facing schema text for `autoResolutionMs` while marking it
  reserved for runtimes that explicitly support auto-resolution.
  - Bounds `autoResolutionMs` to `60_000..=240_000` ms during argument
  normalization by clamping out-of-range model-provided values.
  - Propagated the field through app-server v2
  `ToolRequestUserInputParams`, app-server request forwarding, generated
  TypeScript, and JSON schema fixtures.
  - Updated app-server, core, protocol, and TUI call sites/tests so
  omitted values preserve existing `None`/`null` behavior and coverage
  verifies a `Some(60_000)` round trip.
  
  ## Verification
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core request_user_input`
  - `just test -p codex-app-server request_user_input_round_trip`
  - `just test -p codex-tui request_user_input`
  - `just test -p codex-protocol`

  Shijie Rao · 2026-06-11 22:30:41 -07:00
  216ce03031
• [1 of 3] Support long raw TUI goal objectives (#27508)

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

  Eric Traut · 2026-06-11 22:26:31 -07:00
  78bab04116
• tui: clear stale hook row after turn completion (#27619)

  Fixes #27210.
  
  ## Why
  When the app server reports a visible `HookStarted` event for a
  `PostToolUse` hook but the turn reaches `TurnCompleted` before a
  matching hook completion event arrives, the TUI can leave the transient
  `Running PostToolUse hook` row visible after the agent is done.
  Interrupted and failed turn cleanup already drops transient live hook
  rows; the normal completion path did not.
  
  ## What Changed
  - Added `ChatWidget::clear_active_hook_cell()` for dropping transient
  live hook status without writing it to history.
  - Call that cleanup from normal task completion, while reusing it for
  the existing start/finalize cleanup paths.
  - Added `completed_turn_clears_visible_running_hook` snapshot coverage
  for the reported `PostToolUse` case.
  
  ## Tests
  - `just test -p codex-tui completed_turn_clears_visible_running_hook`
  - `just test -p codex-tui` (fails on current `main` in unrelated
  guardian tests:
  `update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default`
  and
  `update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history`)

  Mitsuhiro Kotake · 2026-06-12 09:15:04 +09:00
  44403dd3dd
• [codex] Load user instructions through an injected provider (#27101)

  ## Why
  
  We want to remove implicit use of `$CODEX_HOME` from `codex-core` and
  make embedders responsible for supplying user-level instructions. This
  also ensures user instructions load when no primary environment is
  selected.
  
  ## What changed
  
  Stacked on #27415, which makes `codex exec` surface thread-scoped
  runtime warnings.
  
  - Added `UserInstructionsProvider` to `codex-extension-api`, with
  absolute source attribution and recoverable loading warnings.
  - Added `codex-home` with the filesystem-backed provider for
  `AGENTS.override.md` and `AGENTS.md`, preserving precedence, fallback,
  trimming, lossy UTF-8 handling, and the existing uncapped global
  instruction size.
  - Removed global instruction loading from `Config` and require
  `ThreadManager` callers to inject a provider.
  - Load provider instructions once for each fresh root runtime, including
  runtimes without a primary environment. Running sessions retain their
  snapshot, while child agents inherit the parent snapshot without
  invoking the provider.
  - Keep provider instructions separate while loading project `AGENTS.md`,
  then assemble the model-visible instructions with the existing ordering,
  source attribution, warning, and turn-context behavior.
  - Wired the Codex home provider through the CLI, app server, MCP server,
  core facade, and thread-manager sample.
  
  ## Validation
  
  - `just test -p codex-home -p codex-extension-api`
  - `just test -p codex-core agents_md`
  - `just test -p codex-core guardian`
  - `just test -p codex-app-server
  thread_start_without_selected_environment_includes_only_global_instruction_source`
  - `just test -p codex-exec warning`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• [codex] Propagate plugin app categories (#27420)

  ## What
  - Parse optional `.app.json` `category` overrides for plugin apps.
  - Add nullable `category` to `AppSummary` and `AppTemplateSummary` in
  the app-server protocol.
  - Fall back from `branding.category` to the first non-empty
  `app_metadata.categories` value when building app/template summaries.
  - Regenerate schema/type fixtures and update plugin read/install tests.
  
  ## Why
  The plugin details UI needs a normalized per-app category. Some apps
  only provide their default category in metadata, while others need a
  local `.app.json` override.

  charlesgong-openai · 2026-06-11 10:34:41 -07:00
  eb76336f60
• Remove TUI legacy Windows sandbox dependency (#27490)

  ## Why
  
  This is part of an ongoing attempt to eliminate the TUI's direct
  dependency on core features. When we moved the TUI to the app server, we
  left a `legacy_core` shim that re-exported some remaining core symbols
  for the TUI. The intent was to eventually remove all of these.
  
  In this PR, we remove the symbols related to the Windows sandbox.
  
  The change should be behavior-neutral and low risk because it's just
  refactoring and removal of code that is now effectively dead.
  
  When working on this PR, I noticed a big existing problem that affects
  mixed-platform remoting. For example, if you run the TUI on a Linux box
  and remote into a Windows box, the TUI logic doesn't properly handle
  Windows sandbox setup properly. Fixing this is beyond the scope of this
  PR, but I've left a TODO comment in place so we don't forget.
  
  ## What changed
  
  - Move the remaining TUI-specific sandbox level, setup, telemetry, and
  read-root helpers into `codex-tui`, calling `codex-windows-sandbox`
  directly.
  - Remove the Windows sandbox namespace and read-root grant re-exports
  from the client-side `legacy_core` facade.
  - Remove the dormant pre-elevation prompt fallback guarded by the
  permanently enabled `ELEVATED_SANDBOX_NUX_ENABLED` switch. The reachable
  elevated and non-elevated setup flows remain unchanged.

  Eric Traut · 2026-06-11 09:23:08 -07:00
  1e5b87b4d7
• Add session delete commands in CLI and TUI (#27476)

  ## Summary
  
  The app server exposes `thread/delete`, but users cannot invoke it from
  the CLI or TUI. Because deletion is irreversible, the user-facing
  commands need deliberate confirmation and safer handling of name-based
  targets.
  
  - Add `codex delete <SESSION>` with interactive confirmation,
  restricting `--force` to UUID targets.
  - Resolve exact names across active and archived sessions, including
  renamed sessions, and validate prompted UUID targets before
  confirmation.
  - Add a `/delete` command with a confirmation popup that warns the
  current session and its subagent threads will be permanently deleted.
  
  ## Manual testing
  
  - Deleted by UUID with `--force` and verified the rollout, session-index
  entry, and database row were removed.
  - Exercised name-based confirmation for both cancellation and
  affirmative deletion; cancellation preserved the session and
  confirmation removed it.
  - Verified deletion refuses to proceed without `--force`, while
  `--force` rejects names, including duplicate names.
  - Verified duplicate-name confirmation displays the concrete UUID
  selected.
  - Deleted an archived session by name.
  - Verified an already-missing UUID fails before displaying a
  confirmation prompt.
  - Exercised `/delete` in the TUI: the popup defaults to No, cancellation
  preserves the session, and confirmation deletes the session and exits.
  - Verified that `codex delete` works for both archived and non-archived
  sessions.

  Eric Traut · 2026-06-10 18:04:02 -07:00
  9d87b771ce
• Remove TUI legacy core test_support dependencies (#27484)

  ## Why
  
  The TUI now sits on the app-server layer, but
  `app-server-client::legacy_core` still exposed core test helpers solely
  for TUI tests. We've been whittling away the remaining dependencies.
  This is the next step on that journey.
  
  There is no functional change — just a refactor, and this affects only
  test code, so it should be low risk.
  
  ## What changed
  
  - remove the `legacy_core::test_support` re-export and call
  model-manager test helpers directly
  - keep the bundled model-preset cache local to TUI test support
  - import constraint types directly from `codex-config`

  Eric Traut · 2026-06-10 17:55:49 -07:00
  36fc79c6f4
• [codex] Remove redundant plugin app auth state (#27465)

  ## Summary
  
  - remove the redundant `needsAuth` field from `AppSummary` and generated
  app-server schemas
  - stop `plugin/read` from querying Apps MCP solely to hydrate unused
  connector auth state
  - preserve `plugin/install.appsNeedingAuth` membership and
  `app/list.isAccessible` as the authentication signals
  
  ## Why
  
  Codex App and TUI do not consume `plugin/read.plugin.apps[].needsAuth`.
  Hydrating it could establish an Apps MCP connection and discover tools
  on a cold `plugin/read` request, adding avoidable latency. The plugin
  APIs are still marked under development, so removing this wire field is
  preferable to retaining a misleading default.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  plugin_install_uses_remote_apps_needing_auth_response`
  - `just test -p codex-app-server
  plugin_install_returns_apps_needing_auth`
  - `just test -p codex-app-server
  plugin_read_returns_plugin_details_with_bundle_contents`
  - `just test -p codex-tui
  plugin_detail_popup_snapshot_shows_install_actions_and_capability_summaries`
  - `$xin-build` simplify and debug reviews

  xl-openai · 2026-06-10 17:33:56 -07:00
  1a9efd473b
• [codex] add /import for external agents (#27071)

  ## Why
  
  External-agent import should be discoverable and deliberate without
  blocking startup or claiming the public `codex [PROMPT]` CLI namespace.
  The slash command keeps the flow local to the interactive TUI and reuses
  the existing app-server import API.
  
  ## What changed
  
  - add the user-facing `/import` slash command
  - detect external-agent importable items only when the command is
  invoked
  - run imports through the embedded local app-server
  - show start and completion messages, refresh configuration, and block
  duplicate imports while one is pending
  - reject the flow for unsupported remote and local-daemon sessions
  
  ## Validation
  
  - `just test -p codex-tui external_agent_config_migration` (10 passed)
  - manually exercised an isolated TUI fixture with existing
  external-agent setup and session data using a fresh `CODEX_HOME`
  - verified picker customization, plugin and session detection, import
  completion, repeated invocation, and imported-session resume context
  - the broader `just test -p codex-tui` run passed 2,805 tests, with 2
  unrelated guardian feature-flag failures and 4 skipped tests
  
  ## Draft follow-ups
  
  - review whether completion messaging should remain attached to the
  initiating chat if the user switches chats during an import
  - review shutdown semantics for an in-progress background import
  
  ## Stack
  
  1. [#27064](https://github.com/openai/codex/pull/27064): remove the
  startup migration flow
  2. [#27065](https://github.com/openai/codex/pull/27065): extract the
  picker renderer
  3. [#27070](https://github.com/openai/codex/pull/27070): add the
  external-agent import picker UX
  4. [#27071](https://github.com/openai/codex/pull/27071): expose the flow
  through `/import`
  
  **This PR is stack item 4.** Draft while the lower stack dependencies
  are reviewed.

  stefanstokic-oai · 2026-06-10 15:53:15 -04:00
  b4445f2758
• Add app-server thread/delete API (#25018)

  ## Why
  
  Clients can archive and unarchive threads today, but there is no
  app-server API for permanently removing a thread. Deletion also needs to
  cover the full session tree: deleting a main thread should remove
  spawned subagent threads and the related local metadata instead of
  leaving orphaned rollout files, goals, or subagent state behind.
  
  ## What
  
  - Adds the v2 `thread/delete` request and `thread/deleted` notification,
  with the response shape kept consistent with `thread/archive`.
  - Implements local hard delete for active and archived rollout files.
  - Deletes the requested thread's state DB row as the commit point, then
  best-effort cleans associated state including spawned descendants,
  goals, spawn edges, logs, dynamic tools, and agent job assignments.
  - Updates app-server API docs and generated protocol schema/TypeScript
  fixtures.

  Eric Traut · 2026-06-10 11:22:12 -07:00
  a19d43a40a
• feat: keep child MCP warnings out of parent transcript (#27174)

  ## Why
  
  MCP startup status notifications are thread-owned, but `ChatWidget`
  trusted upstream routing. If routing state delivered a tagged child
  notification to the active parent widget, the child MCP failure could
  still mutate the parent's startup state and transcript. Rejecting it
  only inside the MCP handler was also too late because shared
  notification handling could already restore and consume the parent's
  retry status.
  
  ## What changed
  
  - Validate a tagged MCP status notification against the visible
  `ChatWidget` thread before shared notification handling mutates any
  parent state.
  - Cover child `Starting` and `Failed` notifications delivered to a
  retrying parent widget, asserting that they preserve its visible retry
  error and saved status header while producing no history or MCP status
  mutation.
  
  ## User impact
  
  Subagent MCP startup failures remain scoped to the child transcript
  instead of appearing as duplicate warnings in the parent transcript.
  
  ## Testing
  
  - `just test -p codex-tui mcp_startup_ignores_status_for_other_thread`
  - `just test -p codex-tui
  primary_thread_ignores_child_mcp_startup_notifications`
  - `just fmt`

  jif · 2026-06-10 11:45:49 +02:00
  0ffcefaf3d
• TUI Plugin Sharing 1 - add remote plugin identity (#26701)
  canvrno-oai · 2026-06-09 16:34:38 -07:00
  fb8f1ea0d5
• Reduce TUI legacy core dependencies (#26711)

  ## Why
  
  The TUI still reached through `app-server-client::legacy_core` for
  thread-name normalization and project-instruction filename details. In
  particular, checking the TUI's local filesystem for `/init` is incorrect
  for remote app-server sessions, where the server owns the working
  directory and instruction discovery.
  
  ## What changed
  
  - use the instruction source paths supplied by the app server to decide
  whether `/init` should avoid overwriting project instructions
  - keep the small thread-name normalization helper local to the TUI
  - remove the now-unused instruction filename constants, utility module,
  and other unused `legacy_core` re-exports
  - make status helper tests independent of concrete instruction filenames
  
  ## Verification
  
  - `just test -p codex-app-server-client`
  - `just test -p codex-tui
  slash_init_skips_when_project_instructions_are_loaded`
  - `just test -p codex-tui` ran 2,799 tests; 2,797 passed and two
  unrelated guardian feature-flag tests failed reproducibly in untouched
  code
  
  ### Manual test
  
  Started an app server over WebSocket with a remote workspace containing
  `AGENTS.md`, then connected the TUI using `--remote`. After confirming
  `thread/start` returned the file in `instructionSources`, deleted
  `AGENTS.md` and ran `/init` in the existing session.
  
  The TUI still reported that project instructions already existed and
  skipped `/init`. The trace contained no `turn/start` request, confirming
  the decision came from app-server session state rather than a new
  client-local filesystem check.

  Eric Traut · 2026-06-09 13:26:00 -07:00
  8e69d29521
• fix: Prevent /review crash when entering Esc on steer message (#22879)

  This changes the `/review` escape path so `Esc` no longer behaves like
  the normal queued-follow-up interrupt flow while a review is running.
  Steering is not currently supported in `/review` mode, without this
  change users are able to attempt a steer but it leads to a crash (see
  #22815). If the user has already tried to send additional guidance
  during `/review`, the TUI now keeps the review running and shows a
  warning that steer messages are not supported in that mode, while still
  pointing users to `Ctrl+C` if they actually want to cancel. It also adds
  regression coverage for the review-specific warning behavior. When users
  do cancel with Ctrl+C during /review, the TUI now tolerates the
  active-turn race that can happen during review handoff, and any queued
  steer messages are restored to the composer instead of being discarded.
  
  - Special-case `Esc` during an active `/review` when follow-up steer
  input is pending or has already been deferred.
  - Show a clear warning instead of interrupting the running review.
  - Make the Ctrl+C cancel path during /review resilient to active-turn
  races, while preserving any queued steer text by restoring it to the
  composer.
  - Add review-mode test coverage for the warning path.
  
  ## Testing
  
  1. Start a `/review` with a diff large enough that the review stays
  active for more than a few seconds.
  
  2. While the review is still running, type a follow-up / steer message,
  submit it, and then press `Esc`.
     Before: `Esc` causes the TUI to close abruptly.  
  After: the review keeps running and the transcript shows a warning that
  steer messages are not supported during `/review`, with guidance to use
  `Ctrl+C` if you want to cancel.
  
  3. Press `Ctrl+C` if you actually want to stop the review.  
  Before: (after restarting the test since Pt. 2 crashed) this is the
  intentional cancellation path.
  After: this remains the intentional cancellation path, and any queued
  follow-up steer text is restored to the composer instead of being lost.
     
  ## Note:
  `/review` mode explicitly does not support steering at this time (as
  noted in `turn_processer.rs`, if we want to explore that in the future
  this code will need to be modified). This change keeps unsupported steer
  attempts from crashing the TUI and preserves queued follow-up text if
  the user cancels with Ctrl+C.

  canvrno-oai · 2026-06-09 09:41:58 -07:00
  8a299fb704
• multi-agent: add path-based v2 activity tracking (#27007)

  ## Why
  
  Multi-agent v2 identifies agents by canonical paths, but its tool
  handlers still emitted the larger legacy collaboration begin/end events
  built around nickname and role metadata. App-server, rollout-trace,
  analytics, and TUI consumers therefore lacked one compact path-based
  completion signal that behaved consistently across live events and
  replay.
  
  The TUI also needs a bounded `/agent` status surface for v2 agents. It
  should use recent local activity for previews, refresh liveness without
  loading full histories, and keep the legacy picker available when no
  path-backed v2 agent is known.
  
  ## What changed
  
  - Replace the v2 `spawn_agent`, `send_message`, `followup_task`, and
  `interrupt_agent` legacy lifecycle emissions with a success-only
  `SubAgentActivity` event. The event records the tool call ID, occurrence
  time, affected thread, canonical agent path, and `started`,
  `interacted`, or `interrupted` kind.
  - Expose the activity as a completion-only app-server v2
  `subAgentActivity` thread item in live notifications and reconstructed
  history, regenerate the protocol schemas, and count it in sub-agent tool
  analytics.
  - Track canonical paths from live activity and loaded-thread metadata in
  the TUI, and render the activity in live and replayed transcripts.
  - Make `/agent` list running path-backed agents with summaries from
  bounded local event buffers. Each summary is capped at 240 graphemes,
  the scan is capped at six recent items, only the last three wrapped
  lines are shown, and command output is omitted. Liveness falls back to
  metadata-only `thread/read` when local turn state is unavailable.
  - Persist the activity as a terminal rollout-trace runtime payload and
  reduce it to the corresponding spawn, send, follow-up, or close
  interaction edge. `interrupt_agent` is classified as a close-edge
  operation.
  - Preserve the legacy picker when no path-backed v2 agent is known.
  
  ## Compatibility
  
  App-server v2 clients that consumed `collabAgentToolCall` begin/end
  pairs for these tools must handle the new completion-only
  `subAgentActivity` item. Legacy v1 collaboration behavior is unchanged.
  
  ## Screenshot
  
  <img width="684" height="288" alt="Screenshot 2026-06-08 at 15 40 47"
  src="https://github.com/user-attachments/assets/194b3cd0-619d-45fb-b587-cf3e2b1b8a1d"
  />
  
  ## Testing
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-rollout-trace`
  - Added focused coverage for activity analytics, terminal trace
  serialization, spawn-edge reduction, `interrupt_agent` classification,
  TUI status rendering without aggregated command output, and clearing
  stale running state after a completed turn.

  jif · 2026-06-09 12:14:48 +02:00
  fae2709320
• fix(tui): scope MCP startup status by thread (#26639)

  ## Why
  
  MCP startup failures from spawned subagents were rendered as global
  notifications, so a child thread's failure could pollute the visible
  parent transcript. Routing the notification to the child exposed two
  related replay problems: session refresh could discard the buffered
  event, and a newly created child `ChatWidget` did not know the expected
  MCP server set, which could leave its startup spinner running after
  every server had settled.
  
  MCP startup diagnostics should remain visible in the thread that owns
  the startup without affecting other transcripts. The protocol also needs
  to support a future app-scoped MCP lifecycle where startup is not owned
  by any thread.
  
  ## Reported Behavior
  
  The [originating Slack
  report](https://openai.slack.com/archives/C08JZTV654K/p1780604538859939)
  called out that using subagents could turn MCP startup failures into a
  wall of yellow CLI warnings because repeated failures were not
  deduplicated. The intended behavior is for those diagnostics to remain
  visible once in the thread that owns the startup, without polluting the
  parent transcript.
  
  ## What Changed
  
  - add nullable `threadId` ownership to `mcpServer/startupStatus/updated`
  - populate it from the app-server conversation ID for the current
  thread-scoped lifecycle and regenerate the protocol schema and
  TypeScript artifacts
  - treat a missing or null `threadId` as app-scoped without injecting it
  into the active chat transcript
  - route and buffer thread-owned MCP startup notifications by thread in
  the TUI
  - preserve buffered MCP startup events across child session refresh
  - seed expected MCP servers before replaying a thread snapshot so
  startup reaches its terminal state
  - suppress an identical repeated failure warning for the same server
  within one startup round
  
  The owning thread still renders the detailed failure and final `MCP
  startup incomplete (...)` summary.
  
  ## How to Test
  
  1. Configure an optional MCP server named `smoke` that exits during
  initialization.
  2. Launch the TUI with multi-agent support enabled.
  3. Confirm the main thread's own startup failure renders one detailed
  `smoke` warning and one incomplete-startup summary.
  4. Spawn exactly one subagent.
  5. Confirm the parent transcript does not receive the subagent's MCP
  startup failure.
  6. Switch to the subagent thread and confirm it contains exactly one
  detailed `smoke` failure and one incomplete-startup summary.
  7. Confirm the subagent's MCP startup spinner disappears and the thread
  remains usable.
  8. Switch between the parent and subagent and confirm the warnings
  neither move nor duplicate.
  
  Targeted tests:
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  thread_start_emits_mcp_server_status_updated_notifications`
  - `just test -p codex-tui mcp_startup`
  
  The parent/child behavior and spinner completion were also exercised
  manually in tmux. `just argument-comment-lint` was attempted but blocked
  by an unrelated local Bazel LLVM empty-glob failure; touched Rust
  callsites were inspected manually.

  Felipe Coury · 2026-06-07 20:12:05 -07:00
  5a440c03f2
• fix(tui): restore cancelled prompt cursor at end (#26457)

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

  Felipe Coury · 2026-06-05 15:10:13 -03:00
  679a944dbc
• Render code comment directives in TUI replay (#26554)

  ## Summary
  
  Resumed Codex App or VS Code review sessions can contain
  `::code-comment` directives that the TUI previously displayed verbatim
  because only rich clients interpret them.
  
  This change rewrites valid line-start directives into readable Markdown
  during assistant-message parsing, using the session working directory
  for relative file paths. The fallback is applied consistently to live
  messages, replayed transcripts, and resume previews while preserving
  malformed directives and existing `::git-*` parsing.
  
  ## Before
  
  The TUI exposed the raw client directive:
  
  ```text
  ::code-comment{title="Fix body= parsing" body="Keep role=\"tab\", ::git-stage{cwd=/tmp}, file=, and \n literal." file="/repo/src/app.ts" start=10 end=12 priority="P2"}
  ```
  
  ## After
  
  The same directive is rendered as readable review feedback:
  
  ```text
  - [P2] Fix body= parsing — src/app.ts:10-12
    Keep role="tab", ::git-stage{cwd=/tmp}, file=, and \n literal.
  ```
  
  Fixes #25658

  Eric Traut · 2026-06-05 08:34:34 -07:00
  e5af672d73
• Fix /goal usage text for control commands (#26551)

  ## Why
  
  The TUI's `/goal` usage text only advertised the objective form even
  though `/goal clear`, `/goal edit`, `/goal pause`, and `/goal resume`
  are implemented. This made the lifecycle controls difficult to discover
  and allowed the duplicated help text to drift from actual behavior.
  
  Fixes #25530.
  
  ## What changed
  
  - Show the complete `/goal [<objective>|clear|edit|pause|resume]` syntax
  in usage messages.
  - Share one usage string across slash-command dispatch and goal-related
  app messages.
  - Add inline snapshot coverage for the control-command usage path.

  Eric Traut · 2026-06-05 08:32:53 -07:00
  fb0993dd3b
• Surface TUI config write error causes (#26537)

  ## Summary
  
  TUI config writes currently wrap app-server failures with local context
  like `config/batchWrite failed in TUI`, but several user-visible paths
  only render the outer error. That hides the actionable app-server
  message, such as validation constraints or read-only `CODEX_HOME`
  failures, leaving users with a dead-end diagnostic.
  
  This change adds a small formatter next to the TUI config write helpers
  that renders the error source chain, then uses it for model persistence,
  feature persistence, project trust, status line writes, hook trust, and
  hook enablement.
  
  Fixes #26077

  Eric Traut · 2026-06-05 08:32:07 -07:00
  3acd71fedb
• [codex] Forward turn moderation metadata through app-server (#25710)

  ## Why
  First-party backends can supply turn-scoped moderation metadata that
  app-server clients need for client-side presentation. Exposing this as
  an experimental typed notification lets opted-in clients consume it
  without interpreting raw Responses API events.
  
  ## What changed
  - forward `response.metadata.openai_chatgpt_moderation_metadata` from
  Responses API SSE and WebSocket streams as turn-scoped moderation
  metadata
  - emit the experimental app-server v2 `turn/moderationMetadata`
  notification with `{ threadId, turnId, metadata }`
  - add app-server integration coverage for the typed moderation metadata
  notification
  
  ## Testing
  - `just test -p codex-core
  build_ws_client_metadata_includes_window_lineage_and_turn_metadata`
  - `just test -p codex-core` (fails locally: 46 failures and 1 timeout,
  primarily missing `test_stdio_server` and shell snapshot timeouts)
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  turn_moderation_metadata_emits_typed_notification_v2`
  - `just test -p codex-app-server` (fails locally: 792 passed, 10 failed,
  and 5 timed out; failures are in existing environment-sensitive tests,
  primarily because nested macOS `sandbox-exec` is not permitted)
  - `just write-app-server-schema --experimental --schema-root
  /tmp/codex-app-server-schema-experimental`

  carlc-oai · 2026-06-05 02:41:06 -07:00
  55aa071b17
• [codex] Expose unavailable app templates in plugin detail (#26317)

  ## Summary
  - Adds `unavailable_app_templates` to the app-server protocol and
  generated schemas/types.
  - Parses plugin-service `release.unavailable_app_templates` in the
  remote plugin client.
  - Maps remote unavailable templates into app-server `PluginDetail`.
  - Defaults local plugins to an empty unavailable app template list.
  
  ## Validation
  - `just write-app-server-schema`
  - `cargo +1.95.0 fmt --manifest-path codex-rs/Cargo.toml --all --check`
  - `cargo +1.95.0 test --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol schema_fixtures`
  - `cargo +1.95.0 check --manifest-path codex-rs/Cargo.toml -p
  codex-app-server-protocol -p codex-core-plugins -p codex-app-server`
  - `git diff --check`
  
  Note: default `cargo check` uses rustc 1.89 locally and failed because
  dependencies require newer Rust, so validation was rerun with installed
  Rust 1.95.

  charlesgong-openai · 2026-06-04 23:42:27 +00:00
  b9ff450902
• [codex] Use model-advertised reasoning effort order (#26446)

  ## Summary
  - preserve the model catalog order for app-server
  `supportedReasoningEfforts` and document that client contract
  - render TUI reasoning choices in the advertised order
  - step reasoning shortcuts by adjacent list position instead of deriving
  order from known effort names
  - anchor unsupported configured values to the advertised default, or the
  first option when needed
  - remove canonical effort ordering helpers and the unused upgrade effort
  mapping
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.
  
  Stacked on #26444.

  Ahmed Ibrahim · 2026-06-04 14:01:14 -07:00
  f6e529656f
• [codex] Support model-defined reasoning efforts (#26444)

  ## Summary
  - accept non-empty model-defined reasoning effort values while
  preserving built-in effort behavior
  - propagate the non-Copy effort type through core, app-server, TUI,
  telemetry, and persistence call sites
  - preserve string wire encoding and expose an open-string schema for
  clients
  - update model selection and shortcut behavior for model-advertised
  effort values
  
  ## Root cause
  `ReasoningEffort` gained a string-backed custom variant, so it could no
  longer implement `Copy` or rely on derived closed-enum serialization.
  Existing consumers still moved effort values from shared references and
  assumed a fixed built-in value set.
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.

  Ahmed Ibrahim · 2026-06-04 13:36:24 -07:00
  8ac304c299
• feat(tui): add /app desktop handoff (#25638)
  Felipe Coury · 2026-06-03 20:30:15 -03:00
  80b65e9945
• fix(tui): add reasoning effort fallback shortcuts (#25623)
  Felipe Coury · 2026-06-03 20:28:31 -03:00
  8285cd278b
• Fix multiline paste in /goal edit (#26047)

  Fixes #26025.
  
  ## Why
  `/goal edit` opens `CustomPromptView`, which did not use the paste-burst
  handling that protects the main composer when terminals deliver paste as
  rapid key events. On Windows terminals, the first pasted newline could
  be treated as Enter-to-submit, truncating the goal edit and leaving the
  rest of the paste behind.
  
  ## What
  This reuses `PasteBurst` in `CustomPromptView` as a lightweight
  Enter-suppression detector for paste-like key streams. Characters still
  insert directly, explicit paste still goes through the view paste path,
  and ordinary text entry still submits on Enter.

  Eric Traut · 2026-06-03 09:36:50 -07:00
  a2a9e767f7
• Propagate permission approval environment id (#25862)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. This PR (#25862) - Propagate permission approval environment id:
  carries the selected environment id through approval events, app-server
  requests, TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  This PR is stacked on #25858, and #25867 is stacked on this PR.
  
  ## Why
  
  PR2 lets the model bind a `request_permissions` call to a selected
  environment, but the approval event and client-facing request still
  needed to carry that binding. For CCA, the user-facing prompt and
  delegated approval path should know which environment the grant applies
  to instead of relying on cwd alone.
  
  ## What Changed
  
  - Added optional `environmentId` to `RequestPermissionsEvent`.
  - Emit the selected environment id from core permission approval events.
  - Preserve the environment id through delegate forwarding, including
  cwd-based delegated requests.
  - Added `environmentId` to app-server permission approval params,
  generated schema/TypeScript artifacts, and README examples.
  - Preserve and display the environment id in TUI permission approval
  prompts.
  - Updated focused core, app-server protocol, and TUI conversion
  coverage.
  
  ## Testing
  
  Not run locally per instruction. Performed read-only `git diff --check`.

  jif · 2026-06-02 21:09:34 +02:00
  9de568372d
• feat: show enterprise monthly credit limits in status (#24812)

  ## Summary
  
  Enterprise users can have an effective monthly credit limit, but Codex
  `/status` currently drops that metadata from the account-usage response.
  
  This change adds the optional `spend_control.individual_limit`
  projection to the existing rate-limit snapshot flow. The backend client
  reads the monthly limit, app-server exposes it as `individualLimit`, and
  the TUI renders a `Monthly credit limit` row through the existing
  progress-bar renderer.
  
  When the backend does not return an effective monthly limit, existing
  rate-limit behavior is unchanged.
  
  ## Existing backend state
  
  The account-usage backend already returns the effective monthly limit
  and current usage together:
  
  ```json
  {
    "spend_control": {
      "reached": false,
      "individual_limit": {
        "limit": "25000",
        "used": "8000",
        "remaining": "17000",
        "used_percent": 32,
        "remaining_percent": 68,
        "reset_after_seconds": 86400,
        "reset_at": 1778137680
      }
    }
  }
  ```
  
  Before this change, Codex projected rolling `primary` and `secondary`
  windows plus `credits`. It ignored `spend_control.individual_limit`, so
  app-server clients and `/status` could not render the monthly cap.
  
  The updated flow is:
  
  ```text
  account usage backend
    -> backend-client reads spend_control.individual_limit
    -> existing rate-limit snapshot carries optional individual_limit
    -> app-server exposes optional individualLimit
    -> TUI renders Monthly credit limit
  ```
  
  ## App-server contract
  
  `account/rateLimits/read` and sparse `account/rateLimits/updated`
  notifications now include an additive nullable
  `rateLimits.individualLimit` field:
  
  ```json
  {
    "individualLimit": {
      "limit": "25000",
      "used": "8000",
      "remainingPercent": 68,
      "resetsAt": 1778137680
    }
  }
  ```
  
  In an `account/rateLimits/read` response, `null` means no monthly limit
  is available. `account/rateLimits/updated` remains a sparse rolling
  notification: clients merge available values into their most recent
  `account/rateLimits/read` snapshot or refetch. Nullable account metadata
  in a rolling notification does not clear a previously observed value.
  
  ## Design decisions
  
  - Extend the existing rate-limit snapshot instead of introducing a
  separate request or wire-level update protocol.
  - Keep the Codex projection narrow: `/status` needs the effective limit,
  current usage, remaining percentage, and reset timestamp.
  - Render the monthly row through the existing progress-bar renderer,
  with one optional detail line for `8,000 of 25,000 credits used`.
  - Keep the backend response optional so existing accounts and older
  usage states preserve their current behavior.
  - Preserve cached monthly metadata when sparse rolling notifications
  omit it. Live account-usage reads remain authoritative and can clear a
  removed limit.
  
  ## Visual evidence
  
  ```text
   Monthly credit limit:   [██████████████░░░░░░] 68% left (resets 07:08 on 7 May)
                           8,000 of 25,000 credits used
  ```
  
  Snapshot:
  `codex-rs/tui/src/status/snapshots/codex_tui__status__tests__status_snapshot_includes_enterprise_monthly_credit_limit.snap`
  
  ## Testing
  
  Tests: generated app-server schema verification, protocol tests,
  backend-client tests, app-server integration coverage, TUI snapshot
  coverage, formatting, and workspace lint cleanup.

  efrazer-oai · 2026-06-01 21:25:42 -07:00
  c8e5db16c9
• Add reasoning-only status surface item (#25504)

  Closes #24886.
  
  ## Why
  Users can configure the TUI status line and terminal title with
  `model-with-reasoning`, but issue #24886 asks for a compact
  reasoning-only item. That lets a setup show just `default`, `low`,
  `medium`, `high`, or `xhigh` without repeating the model name.
  
  ## What changed
  - Added a `reasoning` item for `/statusline` and `/title` setup flows.
  - Rendered the item from the effective reasoning effort, including
  collaboration-mode overrides.
  - Registered `reasoning` with `codex doctor` so Codex-generated
  terminal-title config is not reported as invalid.
  - Updated TUI setup snapshots so the picker previews include the new
  item.

  Eric Traut · 2026-06-01 09:30:20 -07:00
  f1d029cf75
• feat(tui): restore output-free cancelled prompts (#25316)

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

  Felipe Coury · 2026-06-01 11:49:14 -03:00
  c0ea566bb5
• Constrain Windows sandbox requirements (#23766)

  # Why
  
  Managed requirements can already constrain sandbox policy choices, but
  Windows sandbox implementation selection was still resolved
  independently from those requirements. That left the TUI able to
  continue through the unelevated fallback even when an organization wants
  to require the elevated Windows sandbox implementation.
  
  # What
  
  - Add `[windows].allowed_sandbox_implementations` requirements support
  for the Windows `elevated` and `unelevated` implementations.
  - Apply that allowlist during core config resolution so disallowed
  configured or feature-selected Windows sandbox implementations fall back
  to an allowed implementation with the existing requirements warning
  path.
  - Reuse the existing TUI Windows setup prompts to block disallowed
  unelevated continuation, keep required elevated setup in front of the
  user, and refuse to persist a TUI-selected Windows sandbox mode that
  requirements disallow.
  
  # Semantics
  
  | Allowed | Selected | Effective |
  | --- | --- | --- |
  | `["elevated"]` | `unelevated` / unset | `elevated` |
  | `["unelevated"]` | `elevated` / unset | `unelevated` |
  | `["elevated", "unelevated"]` | `elevated` | `elevated` |
  | `["elevated", "unelevated"]` | `unelevated` | `unelevated` |
  | `["elevated", "unelevated"]` | unset | `elevated` |
  
  Availability is handled by interactive setup surfaces after allowlist
  resolution. If the effective elevated implementation is not ready,
  elevated-only requirements block on setup. When unelevated is also
  allowed, the UI may offer the existing unelevated fallback.
  
  ## TUI Screens
  
  If elevated setup is not already complete:
  ```
    Your organization requires the default Codex agent sandbox to continue. Set it up to protect your files and control
    network access.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Set up default sandbox (requires Administrator permissions)
    2. Quit
  ```
  
  If admin setup fails under `["elevated"]`:
  ```
    Couldn't set up your sandbox with Administrator permissions
  
    Your organization requires the default sandbox before Codex can continue.
    Learn more <https://developers.openai.com/codex/windows>
  
  › 1. Try setting up admin sandbox again
    2. Quit
  ```
  
  # Next Steps
  
  
  - extend the requirements/readout surface, such as
  `configRequirements/read`, so clients can inspect the loaded
  `[windows].allowed_sandbox_implementations` requirement instead of
  inferring it from Windows setup state
  - consider extending `windowsSandbox/readiness` as well
  - update the App startup guide, setup flow, and banner surfaces so an
  elevated-only requirement omits any continue-unelevated escape hatch and
  blocks startup until a permitted implementation is ready;
  - preserve the existing unelevated fallback path when requirements allow
  it, including the `["unelevated"]` case where elevated is disallowed

  Abhinav · 2026-05-29 16:31:33 -07:00
  a5a94ee5a7
• Use session wording in /rename confirmation (#25035)

  ## Why
  
  The TUI `/rename` confirmation should use the term "session" for
  consistency.

  Eric Traut · 2026-05-29 11:09:40 -07:00
  62039e8d35
• Add /archive slash command (#25027)

  ## Why
  
  TUI users can archive saved sessions from other surfaces, but there is
  no in-session command for archiving the active session. Since archiving
  the active session also exits the TUI, the command should ask for
  explicit confirmation instead of firing immediately.
  
  I'm also working on [a companion
  PR](https://github.com/openai/codex/pull/25021) that adds `codex
  archive` and `codex unarchive` top-level CLI commands.
  
  ## What changed
  
  - Adds a new `/archive` slash command described as `archive this session
  and exit`.
  - Shows a confirmation dialog with `No, don't archive` selected first
  and `Yes, archive and exit` as the explicit action.
  - On confirmation, calls the existing `thread/archive` app-server RPC
  for the active main session and exits after success.
  - Keeps `/archive` disabled while a task is running and unavailable in
  side conversations.
  
  ## Verification
  
  Added focused TUI coverage for the `/archive` confirmation flow,
  disabled-while-task-running behavior, and the `/ar` slash-command popup
  snapshot.

  Eric Traut · 2026-05-29 11:07:19 -07:00
  36cd36626d
• Align TUI permissions labels with app (#25017)

  ## Summary
  
  The desktop app now presents the on-request permissions mode as `Ask for
  approval` and the manual-review-backed mode as `Approve for me`. The TUI
  still exposed older/internal labels like `Default` and `Auto-review`,
  which made the same underlying settings look different across clients.
  
  This updates the TUI UX copy to match the app without changing the
  underlying default behavior. Fresh threads continue to use the existing
  on-request approval mode, now displayed as `Ask for approval`.
  
  The label changes cover `/permissions`, explicit profile permissions
  menus, status surfaces, config persistence history/error text, and the
  corresponding TUI snapshots.
  
  ### Before
  <img width="1181" height="119" alt="Screenshot 2026-05-28 at 10 19
  47 PM"
  src="https://github.com/user-attachments/assets/0664846b-b6dd-4931-b4dd-d0af0d42058e"
  />
  <img width="523" height="19" alt="Screenshot 2026-05-28 at 10 21 29 PM"
  src="https://github.com/user-attachments/assets/7899c33e-b35d-4684-8389-97e357803423"
  />
  
  ### After
  <img width="1216" height="117" alt="Screenshot 2026-05-28 at 10 19
  32 PM"
  src="https://github.com/user-attachments/assets/015aab43-ac97-411f-8031-75cdd887251b"
  />
  <img width="567" height="18" alt="Screenshot 2026-05-28 at 10 20 24 PM"
  src="https://github.com/user-attachments/assets/28b6422c-b823-4298-b221-c83d46d09d66"
  />

  Eric Traut · 2026-05-29 11:06:40 -07:00
  1333f4a689
• Render multiline hook output in TUI (#24965)

  # Why
  
  Fixes #24529. Completed hook output in the TUI rendered each
  `HookOutputEntry` as one ratatui line, so explicit newlines inside hook
  output were not shown as separate transcript rows. That made multiline
  `SessionStart.additionalContext` hard to inspect even though the
  model-facing context path preserved the original text.
  
  # What
  
  - Split completed hook output entries on explicit newlines before
  rendering them in `codex-rs/tui/src/history_cell/hook_cell.rs`.
  - Keep the hook output prefix, such as `hook context:` or `warning:`, on
  the first physical line only.
  - Preserve explicit blank lines and render continuation lines with the
  hook body indent.
  - Add unit coverage for multiline context and warning output, plus a
  chatwidget snapshot regression for `SessionStart` history output.
  
  # Testing
  
  - `cargo nextest run -p codex-tui completed_hook_multiline
  hook_completed_before_reveal_renders_completed_without_running_flash`
  - `just argument-comment-lint -p codex-tui -- --ignore-rust-version
  --lib --tests`

  Abhinav · 2026-05-29 15:12:40 +00:00
  251b2412b2
• Seed prompt history from resumed messages (#24298)

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

  Eric Traut · 2026-05-28 22:08:05 -07:00
  56958f2512