577 Commits

• feat(app-server): always return limited thread history (#20682)

  ## Why
  
  Whenever we return a thread's history (turns and items) over app-server,
  always return the limited form as specified by the rollout policy
  `EventPersistenceMode::Limited`, even if the thread was previously
  started with `EventPersistenceMode::Extended`.
  
  We're finding it is quite unscalable to be returning the extended
  history, so let's apply the same filtering logic of the rollout policy
  when we load and return the thread's history.
  
  ## What Changed
  
  - Reuse the rollout persistence policy when reconstructing app-server
  `ThreadItem` history so only `EventPersistenceMode::Limited` rollout
  items are replayed into API turns.
  - Route `thread/read`, `thread/resume`, `thread/fork`,
  `thread/turns/list`, and rollback responses through the same filtered
  app-server history projection.
  - Keep live active turns intact when composing a response for a
  currently running thread.
  - Update command execution coverage so persisted extended command events
  are excluded from returned history for `thread/read`, `thread/fork`, and
  `thread/turns/list`.
  
  ## Test Plan
  
  - `cargo test -p codex-app-server limited`
  - `cargo test -p codex-app-server thread_shell_command`
  - `cargo test -p codex-app-server thread_read`
  - `cargo test -p codex-app-server thread_rollback`
  - `cargo test -p codex-app-server thread_fork`
  - `cargo test -p codex-app-server-protocol`

  Owen Lin · 2026-05-04 10:37:35 -07:00
  541e99cf09
• Keep paused goals paused on thread resume (#20790)

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

  Eric Traut · 2026-05-04 08:58:07 -07:00
  3c2dcbef85
• Use the 2025-06-18 elicitation capability shape (#20562)

  # Why
  
  Codex currently negotiates MCP `2025-06-18`, where the client
  elicitation capability is represented as an empty object. We were still
  serializing `capabilities.elicitation.form`, which belongs to the later
  capability shape and can cause strict `2025-06-18` servers to reject
  `initialize` with an unrecognized-field error.
  
  This keeps the handshake aligned with the protocol version Codex
  actually negotiates and fixes the compatibility regression tracked in
  #17492.
  
  # What
  
  - Serialize the client elicitation capability as `elicitation: {}` for
  `2025-06-18`.
  - Keep elicitation advertised for both Codex Apps and custom MCP
  servers.
  - Tighten regression coverage so the unit test asserts both the Rust
  value and the serialized wire shape.
  - Add an app-server integration test that round-trips a form elicitation
  from a custom MCP server; the existing connector round-trip continues to
  cover the connector path.
  
  # Verification
  
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-app-server mcp_server_elicitation_round_trip`
  - `cargo test -p codex-app-server
  mcp_server_tool_call_round_trips_elicitation`
  
  # Next steps
  
  - Decide whether `tool_call_mcp_elicitation=false` should also suppress
  capability advertisement during `initialize`.
  - Revisit `form` / `url` capability advertisement when Codex is ready to
  negotiate MCP `2025-11-25`, which defines that newer shape.

  Abhinav · 2026-05-01 14:16:22 -07:00
  443f6b831e
• [codex] Migrate loaded thread/read history to ThreadStore (#20486)

  ## Summary
  
  - Route loaded `thread/read` + `includeTurns` through
  `CodexThread::load_history` / ThreadStore history instead of direct
  rollout JSONL reads.
  - Add an in-memory ThreadStore regression test covering loaded
  `thread/read includeTurns` without a local rollout path.

  Tom · 2026-05-01 10:55:04 -07:00
  e4d6675632
• feat: Track local paths for shared plugins (#20560)

  When a local plugin is shared, Codex now records the local plugin path
  by remote plugin id under CODEX_HOME/.tmp.
  
  plugin/share/list includes the remote share URL and the matching local
  plugin path when available, and plugin/share/delete
  clears the local mapping after deleting the remote share.
  
  Also add sharedURL to plugin/share/list.

  xl-openai · 2026-05-01 00:50:12 -07:00
  48791920a8
• Add remote plugin skill read API (#20150)

  ## Summary
  
  Adds an app-server `plugin/skill/read` method for remote plugin skill
  markdown. The new method calls the plugin-service skill detail endpoint
  and returns `skill_md_contents`, so clients can preview skills for
  remote plugins before the bundle is installed locally.
  
  ## Why
  
  Uninstalled remote plugin skills do not have local `SKILL.md` files.
  Without an on-demand remote read, the desktop plugin details UI cannot
  render the skill details modal for those skills.
  
  ## Validation
  
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server --test all --
  suite::v2::plugin_read::plugin_skill_read_reads_remote_skill_contents_when_remote_plugin_enabled
  --exact`
  - `just fix -p codex-app-server-protocol -p codex-core-plugins -p
  codex-app-server`

  xli-oai · 2026-05-01 00:16:25 -07:00
  96d2ea9058
• Make thread store process-scoped (#19474)

  - Build one app-server process ThreadStore from startup config and share
  it with ThreadManager and CodexMessageProcessor.
  - Remove per-thread/fork store reconstruction so effective thread config
  cannot switch the persistence backend.
  - Add params to ThreadStore create/resume for specifying thread
  metadata, since otherwise the metadata from store creation would be used
  (incorrectly).

  Tom · 2026-04-30 21:24:59 -07:00
  fe05acad23
• Surface admin-disabled remote plugin status (#20298)

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

  xli-oai · 2026-04-30 20:00:07 -07:00
  bb60b78c46
• Alias codex_hooks feature as hooks (#20522)

  # Why
  
  The hooks feature flag should use the concise canonical name `hooks`,
  while existing configs that still use `codex_hooks` continue to work
  during the rename.
  
  # What
  
  - change the canonical `Feature::CodexHooks` key from `codex_hooks` to
  `hooks`
  - register `codex_hooks` through the existing legacy-alias path
  - update the config schema and canonical config fixtures to prefer
  `hooks`
  - add regression coverage that both `hooks` and `codex_hooks` resolve to
  `Feature::CodexHooks`
  
  # Verification
  
  - `cargo test -p codex-features`
  - `cargo test -p codex-core config::schema_tests`
  - `cargo test -p codex-core
  pre_tool_use_blocks_shell_when_defined_in_config_toml`
  - `cargo test -p codex-app-server
  hooks_list_uses_each_cwds_effective_feature_enablement`

  Abhinav · 2026-05-01 00:46:33 +00:00
  0d9a5d20ec
• Emit analytics for remote plugin installs (#20267)

  ## Summary
  
  - emit `codex_plugin_installed` after a remote plugin install succeeds
  - keep local installs unchanged, but let remote installs override the
  analytics `plugin_id` with the backend remote plugin id
  (`plugins~Plugin_...`)
  - preserve the local/display identity in `plugin_name` and
  `marketplace_name`, plus capability metadata from the installed bundle
  - add regression coverage for local install analytics, remote install
  analytics, and analytics id override serialization
  
  ## Testing
  
  - `just fmt`
  - `cargo test -p codex-analytics`
  - `cargo test -p codex-app-server`

  xli-oai · 2026-04-30 17:27:16 -07:00
  acdf908268
• Sync remote installed plugin bundles (#20268)

  ## Summary
  - Download missing remote installed plugin bundles during app-server
  startup and plugin/list refresh.
  - Upgrade cached remote installed bundles when the backend installed
  version changes.
  - Remove stale remote installed bundle caches without writing remote
  plugin state into config.toml.
  
  ## Review note
  This is a clean PR branch cut from the current diff on top of latest
  `origin/main`. The diff intentionally has no `codex-rs/core/**` files,
  so CODEOWNERS should not request the core-directory owner review from
  stale PR history.
  
  ## Validation
  Already run on the source branch before creating this clean PR:
  - `just fmt`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-app-server --test all
  app_server_startup_sync_downloads_remote_installed_plugin_bundles --
  --nocapture`
  - `cargo test -p codex-app-server --test all
  plugin_list_sync_upgrades_and_removes_remote_installed_plugin_bundles --
  --nocapture`
  - `cargo test -p codex-app-server --test all
  app_server_startup_remote_plugin_sync_runs_once -- --nocapture`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-app-server`
  - `git diff --check`

  xli-oai · 2026-04-30 16:05:14 -07:00
  2686873e77
• [codex] Migrate thread turns list to thread store (#19280)

  - migrate `thread/turns/list` to ThreadStore. Uses ThreadStore for most
  data now but merges in the in-memory state from thread manager
  - keep v2 `thread/list` pathless-store friendly by converting
  `StoredThread` directly to API `Thread`
  - add regression coverage for pathless store history/listing

  Tom · 2026-04-30 14:16:42 -07:00
  127be0612c
• Send external import completion for sync imports (#20379)
  alexsong-oai · 2026-04-30 13:03:21 -07:00
  9121132c8f
• Stop emitting item/fileChange/outputDelta output delta notifications (#20471)

  ## Why
  
  `item/fileChange/outputDelta` text output was only the tool's summary or
  error text and not used by client surfaces.
  
  We keep `item/fileChange/outputDelta` in the app-server protocol as a
  deprecated compatibility entry, but the server no longer emits it.
  
  ## What changed
  
  - stop the `apply_patch` runtime from emitting `ExecCommandOutputDelta`
  events
  - simplify `item_event_to_server_notification` so command output deltas
  always map to `item/commandExecution/outputDelta`
  - remove the app-server bookkeeping that tried to detect whether an
  output delta belonged to a file change
  - mark `item/fileChange/outputDelta` as a deprecated legacy protocol
  entry in the v2 types, schema, and README
  - simplify the file-change approval tests so they only wait for
  completion instead of expecting output-delta notifications
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-thread-manager-sample`
  - `cargo test -p codex-app-server-protocol
  protocol::event_mapping::tests::exec_command_output_delta_maps_to_command_execution_output_delta
  -- --exact`
  - `cargo test -p codex-app-server
  turn_start_file_change_approval_accept_for_session_persists_v2 --
  --exact` *(failed before the test assertions because the wiremock
  `/responses` mock received 0 requests in setup)*

  pakrym-oai · 2026-04-30 11:42:07 -07:00
  b52083146c
• fix(core): truncate large mcp tool outputs in rollouts (#20260)

  ## Why
  Large MCP tool call outputs can make rollout JSONL files enormous. In
  the session that motivated this change, the biggest JSONL records were:
  - `event_msg/mcp_tool_call_end`
  - `response_item/function_call_output`
  
  both containing the same unbounded MCP payloads - just 3 MCP tool calls
  that each were multi-hundred MBs 😱
  
  This PR truncates both of those JSONL records.
  
  ## How
  
  #### For `response_item/function_call_output`
  Unified exec already bounds tool output before it is injected into
  model-facing history, which also keeps the corresponding rollout
  `response_item/function_call_output` records small.
  
  MCP should follow the same pattern: truncate the model-facing tool
  output at the tool-output boundary, while leaving code-mode/raw hook
  consumers alone.
  
  #### For `event_msg/mcp_tool_call_end`
  `McpToolCallEnd` also needs its own bounded event copy because it is the
  app-server/replay/UI event shape that backs `ThreadItem::McpToolCall`.
  Unfortunately this is _not_ downstream of the `ToolOutput` trait.
  
  ## Model behavior 
  Model behavior is actually unchanged as a result of this PR. 
  
  Before this PR, MCP output was:
  1. Converted to `FunctionCallOutput`.
  2. Recorded into in-memory history.
  3. Truncated by `ContextManager::record_items()` before later model
  turns saw it.
  
  After this branch, MCP output is truncated earlier, in
  `McpToolOutput::response_payload()`, using the same helper. Then
  `ContextManager::record_items()` sees an already-truncated output and
  effectively has little/no additional work to do.
  
  So the model should still see the same kind of truncated function-call
  output. The practical difference is where truncation happens: earlier,
  before rollout persistence/app-server emission can see the giant
  payload.
  
  ## Verification
  
  - `cargo test -p codex-core mcp_tool_output`
  - `cargo test -p codex-core
  mcp_tool_call::tests::truncate_mcp_tool_result_for_event`
  - `cargo test -p codex-core
  mcp_post_tool_use_payload_uses_model_tool_name_args_and_result`
  - `just fmt`
  - `just fix -p codex-core`
  - `git diff --check`

  Owen Lin · 2026-04-30 16:30:43 +00:00
  3516cb9751
• realtime: rename provider session ids (#20361)

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

  Ahmed Ibrahim · 2026-04-30 13:39:48 +03:00
  8a97f3cf03
• feat: Add workspace plugin sharing APIs (#20278)

  1. Adds v2 plugin/share/save, plugin/share/list, and plugin/share/delete
  RPCs.
  2. Implements save by archiving a local plugin root, enforcing a size
  limit, uploading through the workspace upload flow, and supporting
  updates via remotePluginId.
  3. Lists created workspace plugins
  4. Deletes a previously uploaded/shared plugin.

  xl-openai · 2026-04-29 23:49:20 -07:00
  87d0cf1a62
• Add persisted hook enablement state (#19840)

  ## Why
  
  After `hooks/list` exposes the hook inventory, clients need a way to
  persist user hook preferences, make those changes effective in
  already-open sessions, and distinguish user-controllable hooks from
  managed requirements without adding another bespoke app-server write
  API.
  
  ## What
  
  - Extends `hooks/list` entries with effective `enabled` state.
  - Persists user-level hook state under `hooks.state.<hook-id>` so the
  model can grow beyond a single boolean over time.
  - Uses the existing `config/batchWrite` path for hook state updates
  instead of introducing a dedicated hook write RPC.
  - Refreshes live session hook engines after config writes so
  already-open threads observe updated enablement without a restart.
  
  ## Stack
  
  1. openai/codex#19705
  2. openai/codex#19778
  3. This PR - openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  The generated schema files account for much of the raw diff. The core
  behavior is in:
  
  - `hooks/src/config_rules.rs`, which resolves per-hook user state from
  the config layer stack.
  - `hooks/src/engine/discovery.rs`, which projects effective enablement
  into `hooks/list` from source-derived managedness.
  - `config/src/hook_config.rs`, which defines the new `hooks.state`
  representation.
  - `core/src/session/mod.rs`, which rebuilds live hook state after user
  config reloads.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-30 04:46:32 +00:00
  8f3c06cc97
• permissions: expose active profile metadata (#20095)
  Michael Bolin · 2026-04-29 20:54:59 -07:00
  ac4332c05b
• update codex_plugins_beta_setting (from workspace settings) (#20250)

  update the name after rename internally
  
  see https://github.com/openai/openai/pull/871006

  Alex Zamoshchin · 2026-04-30 00:40:25 +00:00
  8b07132e09
• Reduce the surface of collaboration modes (#20149)

  Collaboration modes were slightly invasive both into ThreadManager
  construction and ModelProvider

  pakrym-oai · 2026-04-29 17:22:41 -07:00
  fedcefe9da
• Import external agent sessions in background (#20284)

  Summary:
  - Return from external agent import before session history import
  finishes
  - Run session import work in the background and emit the existing
  completion notification when it is done
  - Serialize session imports so duplicate requests do not create
  duplicate imported threads
  
  Verification:
  - cargo test -p codex-app-server external_agent_config_
  - cargo test -p codex-external-agent-sessions
  - just fix -p codex-app-server
  - just fix -p codex-external-agent-sessions
  - git diff --check

  stefanstokic-oai · 2026-04-30 00:00:41 +00:00
  c8abcbf925
• Consume ai-title from external sessions and add end marker (#20261)

  ## Summary
  - Support Claude Code `ai-title` / `aiTitle` records when detecting and
  importing external agent sessions.
  - Preserve existing `custom-title` / `customTitle` precedence; only fall
  back to `aiTitle` when no custom title is present.
  - Add coverage for both detection and import title selection, including
  the custom-title-over-ai-title case.
  
  ## Testing
  - `cargo test -p codex-external-agent-sessions`
  - `just fix -p codex-external-agent-sessions`

  alexsong-oai · 2026-04-30 00:00:13 +00:00
  7bcd4626c4
• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• Require remote plugin detail before uninstall (#19966)

  ## Summary
  - Fetch remote plugin detail before sending the uninstall request.
  - Use the detail response to derive the marketplace namespace and plugin
  name for cache cleanup.
  - Stop the uninstall before the backend POST if detail lookup fails, so
  backend state and local cache state do not diverge.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-app-server plugin_uninstall`
  - `cargo test -p codex-core-plugins`
  - `git diff --check`

  xli-oai · 2026-04-29 14:01:11 -07:00
  afbddabc8b
• feat: Use remote installed plugin cache for skills and MCP (#20096)

  - Fetches and caches remote /installed plugin state
  - Lets skills/list load skills from remote-installed cached plugins
  without requiring a local marketplace entry
  - Routes plugin list/startup/install/uninstall changes through async
  plugin cache invalidation and MCP refresh

  xl-openai · 2026-04-29 12:09:49 -07:00
  73cd831952
• Soften skill description budget warnings (#20112)

  Updates skill description budget messaging to be less alarming

  xl-openai · 2026-04-28 19:56:25 -07:00
  6f328d5e02
• feat: expose provider capability bounds to app server clients (#20049)

  follow up of #19442. The app server now exposes provider-derived bounds
  through a new v2 `modelProvider/read` method. The response reports the
  configured provider map key as `modelProvider` and returns the effective
  capability booleans so clients can align their UI with the same
  provider-owned limits used by core.

  Celia Chen · 2026-04-29 01:36:19 +00:00
  8c47e36504
• Fix plugin list workspace settings test isolation (#20086)

  Fixes test that often fails locally when running `cargo test`
  - Add an app-server test helper that combines managed-config isolation
  with custom env overrides.
  - Isolate `HOME` / `USERPROFILE` in plugin-list workspace settings tests
  so host home marketplaces do not affect results.

  canvrno-oai · 2026-04-28 18:34:38 -07:00
  4c39ad33cb
• Return None when auth refresh fails (#20092)

  Right now, if Codex winds up in a state with auth but it can't refresh
  the token, the user is left with an unhelpful message that says to log
  out and log back in again.
  
  Ultimately, we should prevent that from happening but if it does,
  returning None will allow the caller to redirect the user back to the
  login page

  Gabriel Peal · 2026-04-28 16:15:47 -07:00
  5e6cbbadf7
• app-server: allow remote_control runtime feature override (#20047)
  Ruslan Nigmatullin · 2026-04-28 13:36:12 -07:00
  1de7a9bf69
• External agent session support (#19895)

  ## Summary
  
  This extends external agent detection/import beyond config artifacts so
  Codex can detect recent sessions files from the external agent home and
  import them into Codex rollout history.
  
  ## What changed
  
  - Added a focused `external_agent_sessions` module for:
    - session discovery
    - source-record parsing
    - rollout construction
    - import ledger tracking
  - Wired session detection/import into the app-server external agent
  config API.
  - Added compaction handling so large imported sessions can be resumed
  safely before the first follow-up turn.
  
  ## Testing
  
  Added coverage for:
  - recent-session detection
  - custom-title handling
  - recency filtering
  - dedupe and re-detect-after-source-change behavior
  - visible imported turn construction
  - backward-compatible import payload deserialization
  - end-to-end RPC import flow
  - rejection of undetected session paths
  - repeat-import behavior
  - large-session compaction before first follow-up
  
  Ran:
  - `cargo test -p codex-app-server external_agent_config_import_ --test
  all`

  stefanstokic-oai · 2026-04-28 17:42:36 +00:00
  4c68bd728f
• Add remote plugin uninstall API (#19456)

  ## Summary
  - Adds the remote `plugin/uninstall` request form using required
  `pluginId` plus optional `remoteMarketplaceName`, while preserving local
  `pluginId` uninstall.
  - Adds `codex_core_plugins::remote::uninstall_remote_plugin` for the
  deployed ChatGPT plugin backend uninstall path and validates the backend
  returns the same id with `enabled: false`.
  - Routes app-server remote uninstall through feature checks, remote
  plugin id validation, backend mutation, local downloaded cache deletion,
  cache clearing, docs, and regenerated protocol schemas.
  
  ## Tests
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol
  plugin_uninstall_params_serialization_omits_force_remote_sync`
  - `cargo test -p codex-app-server plugin_uninstall --test all`
  - `cargo test -p codex-app-server plugin_uninstall`
  - `cargo build -p codex-cli`
  - `CODEX_BIN=/Users/xli/code/codex/codex-rs/target/debug/codex python3
  /Users/xli/.codex/skills/xli-test-marketplace-api/scripts/run_marketplace_api_matrix.py`
  (44 pass / 0 fail)
  - `just fix -p codex-app-server-protocol -p codex-app-server -p
  codex-tui`
  - `just fix -p codex-app-server`

  xli-oai · 2026-04-28 03:27:53 -07:00
  803705f795
• feat: Cache remote plugin bundles on install (#19914)

  Remote installs now fetch, validate, download, and cache the plugin
  bundle locally

  xl-openai · 2026-04-28 00:53:27 -07:00
  7d72fc8f53
• permissions: remove cwd special path (#19841)

  ## Why
  
  The experimental `PermissionProfile` API had both `:cwd` and
  `:project_roots` special filesystem paths, which made the permission
  root ambiguous. This PR removes the unstable `current_working_directory`
  special path before the permissions API is stabilized, so callers use
  `:project_roots` for symbolic project-root access.
  
  ## What changed
  
  - Removes `FileSystemSpecialPath::CurrentWorkingDirectory` from protocol
  and app-server protocol models, plus regenerated app-server
  JSON/TypeScript schemas.
  - Replaces internal `:cwd` permission entries with `:project_roots`
  entries.
  - Keeps the existing cwd-update behavior for legacy-shaped
  workspace-write profiles, while removing the deleted
  `CurrentWorkingDirectory` case from that compatibility path.
  - Keeps `PermissionProfile::workspace_write()` as the reusable symbolic
  workspace-write helper, with docs noting that `:project_roots` entries
  resolve at enforcement time.
  - Updates app-server docs/examples and approval UI labeling to stop
  advertising `:cwd` as a permission token.
  
  ## Compatibility
  
  Persisted rollout items may contain the old
  `{"kind":"current_working_directory"}` tag from earlier experimental
  `permissionProfile` snapshots. This PR keeps that tag as a
  deserialize-only alias for `ProjectRoots { subpath: None }`, while
  continuing to serialize only the new `project_roots` tag.
  
  ## Follow-up
  
  This PR intentionally does not introduce an explicit project-root set on
  `SessionConfiguration` or runtime sandbox resolution. Today, the
  resolver still uses the active cwd as the single implicit project root.
  A follow-up should model project roots separately from tool cwd so
  `:project_roots` entries can resolve against the configured project
  roots, and resolve to no entries when there are no project roots.
  
  ## Verification
  
  - `cargo test -p codex-protocol permissions:: --lib`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-sandboxing -p codex-exec-server --lib`
  - `cargo test -p codex-core session_configuration_apply_ --lib`
  - `cargo test -p codex-app-server
  command_exec_permission_profile_project_roots_use_command_cwd --test
  all`
  - `cargo test -p codex-tui
  thread_read_session_state_does_not_reuse_primary_permission_profile
  --lib`
  - `cargo test -p codex-tui
  preset_matching_accepts_workspace_write_with_extra_roots --lib`
  - `cargo test -p codex-config --lib`

  Michael Bolin · 2026-04-27 13:41:27 -07:00
  4b55979755
• [codex-analytics] remove ga flag (#19863)
  rhan-oai · 2026-04-27 19:29:19 +00:00
  215d5a8f7c
• Delete unused ResponseItem::Message.end_turn (#19605)

  This field is unused. Delete it.

  Andrey Mishchenko · 2026-04-26 17:18:09 -07:00
  35bc6e3d01
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• permissions: make runtime config profile-backed (#19606)

  ## Why
  
  This supersedes #19391. During stack repair, GitHub marked #19391 as
  merged into a temporary stack branch rather than into `main`, so the
  runtime-config change needed a fresh PR.
  
  `PermissionProfile` is now the canonical permissions shape after #19231
  because it can distinguish `Managed`, `Disabled`, and `External`
  enforcement while also carrying filesystem rules that legacy
  `SandboxPolicy` cannot represent cleanly. Core config and session state
  still needed to accept profile-backed permissions without forcing every
  profile through the strict legacy bridge, which rejected valid runtime
  profiles such as direct write roots.
  
  The unrelated CI/test hardening that previously rode along with this PR
  has been split into #19683 so this PR stays focused on the permissions
  model migration.
  
  ## What Changed
  
  - Adds `Permissions.permission_profile` and
  `SessionConfiguration.permission_profile` as constrained runtime state,
  while keeping `sandbox_policy` as a legacy compatibility projection.
  - Introduces profile setters that keep `PermissionProfile`, split
  filesystem/network policies, and legacy `SandboxPolicy` projections
  synchronized.
  - Uses a compatibility projection for requirement checks and legacy
  consumers instead of rejecting profiles that cannot round-trip through
  `SandboxPolicy` exactly.
  - Updates config loading, config overrides, session updates, turn
  context plumbing, prompt permission text, sandbox tags, and exec request
  construction to carry profile-backed runtime permissions.
  - Preserves configured deny-read entries and `glob_scan_max_depth` when
  command/session profiles are narrowed.
  - Adds `PermissionProfile::read_only()` and
  `PermissionProfile::workspace_write()` presets that match legacy
  defaults.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19606).
  * #19395
  * #19394
  * #19393
  * #19392
  * __->__ #19606

  Michael Bolin · 2026-04-26 13:29:54 -07:00
  4d7ce3447d
• test: harden app-server integration tests (#19683)

  ## Why
  
  Windows Bazel runs in the permissions stack exposed that app-server
  integration tests were launching normal plugin startup warmups in every
  subprocess. Those warmups can call
  `https://chatgpt.com/backend-api/plugins/featured` when a test is not
  specifically exercising plugin startup, which adds slow background work,
  noisy stderr, and dependence on external network state. The relevant
  startup/featured-plugin behavior was introduced across #15042 and
  #15264.
  
  A few app-server tests also had long optional waits or unbounded cleanup
  paths, making failures expensive to diagnose and contributing to slow
  Windows shards. One external-agent config test from #18246 used a
  GitHub-style marketplace source, which was enough to exercise the
  pending remote-import path but also meant the background completion task
  could attempt a real clone.
  
  ## What Changed
  
  - Adds explicit `AppServerRuntimeOptions` / `PluginStartupTasks`
  plumbing and a hidden debug-only
  `--disable-plugin-startup-tasks-for-tests` app-server flag, so
  integration tests can suppress startup plugin warmups without adding a
  production env-var gate.
  - Has the app-server test harness pass that hidden flag by default,
  while opting plugin-startup coverage back in for tests that
  intentionally exercise startup sync and featured-plugin warmup behavior.
  - Lowers normal app-server subprocess logging from `info`/`debug` to
  `warn` to avoid multi-megabyte stderr output in Bazel logs.
  - Prevents the external-agent config test from attempting a real
  marketplace clone by using an invalid non-local source while still
  exercising the pending-import completion path.
  - Bounds optional filesystem/realtime waits and fake WebSocket
  test-server shutdown so failures produce targeted timeouts instead of
  hanging a shard.
  - Fixes the Unix script-resolution test in `rmcp-client` to exercise
  PATH resolution directly and include the actual spawn error in failures.
  
  ## Verification
  
  - `cargo check -p codex-app-server`
  - `cargo clippy -p codex-app-server --tests -- -D warnings`
  - `cargo test -p codex-rmcp-client
  program_resolver::tests::test_unix_executes_script_without_extension`
  - `cargo test -p codex-app-server --test all
  external_agent_config_import_sends_completion_notification_after_pending_plugins_finish
  -- --nocapture`
  - `cargo test -p codex-app-server --test all
  plugin_list_uses_warmed_featured_plugin_ids_cache_on_first_request --
  --nocapture`
  - Windows Local Bazel passed with this test-hardening bundle before it
  was extracted from #19606.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19683).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19606
  * __->__ #19683

  Michael Bolin · 2026-04-26 12:43:16 -07:00
  ac2bffa443
• test: stabilize app-server path assertions on Windows (#19604)

  ## Why
  
  Windows can represent the same canonical local path with either a normal
  drive path or a verbatim device path prefix. The failure pattern that
  motivated this PR was an assertion diff like `C:\...` versus
  `\\?\C:\...`: different spellings, same file.
  
  That became visible while validating the permissions stack above this
  PR. The stack increasingly routes paths through `AbsolutePathBuf`, which
  normalizes supported Windows device prefixes, while several existing
  tests still built expected values directly with
  `std::fs::canonicalize()` or compared `AbsolutePathBuf::as_path()` to a
  raw `PathBuf`. On Windows, that can make tests fail because the two
  sides choose different textual forms for an otherwise equivalent
  canonical path.
  
  This PR is intentionally split out as the bottom PR below #19606. The
  runtime permissions migration should not carry unrelated Windows test
  stabilization, and reviewers should be able to verify this as a
  test-only change before looking at the larger permissions changes.
  
  ## Failure Modes Covered
  
  - `conversation_summary` expected rollout paths were built from raw
  canonicalized `PathBuf`s, while app-server responses could carry
  `AbsolutePathBuf`-normalized paths.
  - `thread_resume` compared returned thread paths directly to previously
  stored or fixture paths, so a verbatim-prefix spelling could fail an
  otherwise correct resume.
  - `marketplace_add` compared plugin install roots through `as_path()`
  against raw canonicalized paths, reproducing the same `C:\...` versus
  `\\?\C:\...` mismatch in both app-server and core-plugin coverage.
  
  ## What Changed
  
  - In `app-server/tests/suite/conversation_summary.rs`, normalize both
  expected rollout paths and received `ConversationSummary.path` values
  through `AbsolutePathBuf` before comparing the full summary object.
  - In `app-server/tests/suite/v2/thread_resume.rs`, normalize both sides
  of thread path comparisons before asserting equality. This keeps the
  tests focused on whether resume returned the same existing path, not
  whether Windows used the same string spelling.
  - In `app-server/tests/suite/v2/marketplace_add.rs` and
  `core-plugins/src/marketplace_add.rs`, compare install roots as
  `AbsolutePathBuf` values instead of comparing an absolute-path wrapper
  to a raw canonicalized `PathBuf`.
  
  ## Behavior
  
  This PR does not change production app-server or marketplace behavior.
  It only changes tests to assert semantic path identity across Windows
  path spelling variants. It also leaves API response values untouched;
  the normalization happens inside assertions only.
  
  ## Verification
  
  Targeted local checks run while extracting this fix:
  
  - `cargo test -p codex-app-server
  get_conversation_summary_by_thread_id_reads_rollout`
  - `cargo test -p codex-app-server
  get_conversation_summary_by_relative_rollout_path_resolves_from_codex_home`
  - `cargo test -p codex-app-server
  thread_resume_prefers_path_over_thread_id`
  
  Windows-specific confidence comes from the Bazel Windows CI job for this
  PR, since the failure is platform-specific.
  
  ## Docs
  
  No docs update is needed because this is test-only infrastructure
  stabilization.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19604).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19606
  * __->__ #19604

  Michael Bolin · 2026-04-25 16:25:28 -07:00
  d54493ba1c
• test: isolate remote thread store regression from plugin warmups (#19593)

  Follow-up to #19266.
  
  ## Why
  
  
  `thread_start_with_non_local_thread_store_does_not_create_local_persistence`
  is meant to catch accidental local thread persistence when a non-local
  thread store is configured. The Windows flake reported in [this
  BuildBuddy
  invocation](https://app.buildbuddy.io/invocation/0b75dde4-6828-4e7b-a35b-e45b73fb005d)
  showed that the assertion was tripping on an unexpected top-level `.tmp`
  entry:
  
  ```diff
   {
  +    ".tmp",
       "config.toml",
       "installation_id",
       "memories",
       "skills",
   }
  ```
  
  That `.tmp` does not appear to come from `tempfile::TempDir`; it comes
  from unrelated plugin startup work that can legitimately materialize
  `codex_home/.tmp`, including the startup remote plugin sync marker in
  [`core/src/plugins/startup_sync.rs`](https://github.com/openai/codex/blob/bce74c70ce058982534507330ff33f7b196708ef/codex-rs/core/src/plugins/startup_sync.rs#L13-L15)
  and the curated plugin snapshot under
  [`.tmp/plugins`](https://github.com/openai/codex/blob/bce74c70ce058982534507330ff33f7b196708ef/codex-rs/core-plugins/src/startup_sync.rs#L25-L26).
  
  That makes the regression race unrelated background startup tasks
  instead of validating the thread-store invariant it was added to cover.
  Rather than weakening the assertion to allow arbitrary `.tmp` entries,
  this change isolates the test from plugin warmups so it can stay strict
  about unexpected local thread persistence artifacts.
  
  ## What changed
  
  - disable plugins in the generated config used by
  `app-server/tests/suite/v2/remote_thread_store.rs`
  - keep the existing `codex_home` assertions unchanged so the test still
  fails if local session or sqlite persistence is introduced
  
  ## Verification
  
  - `cargo test -p codex-app-server
  suite::v2::remote_thread_store::thread_start_with_non_local_thread_store_does_not_create_local_persistence
  -- --exact`

  Michael Bolin · 2026-04-25 20:45:31 +00:00
  f41306b4f3
• Add goal core runtime (4 / 5) (#18076)

  Adds the core runtime behavior for active goals on top of the model
  tools from PR 3.
  
  ## Why
  
  A long-running goal should be a core runtime concern, not something
  every client has to implement. Core owns the turn lifecycle, tool
  completion boundaries, interruptions, resume behavior, and token usage,
  so it is the right place to account progress, enforce budgets, and
  decide when to continue work.
  
  ## What changed
  
  - Centralized goal lifecycle side effects behind
  `Session::goal_runtime_apply(GoalRuntimeEvent::...)`.
  - Starts goal continuation turns only when the session is idle; pending
  user input and mailbox work take priority.
  - Accounts token and wall-clock usage at turn, tool, mutation,
  interrupt, and resume boundaries; `get_thread_goal` remains read-only.
  - Preserves sub-second wall-clock remainder across accounting boundaries
  so long-running goals do not drift downward over time.
  - Treats token budget exhaustion as a soft stop by marking the goal
  `budget_limited` and injecting wrap-up steering instead of aborting the
  active turn.
  - Suppresses budget steering when `update_goal` marks a goal complete.
  - Pauses active goals on interrupt and auto-reactivates paused goals
  when a thread resumes outside plan mode.
  - Suppresses repeated automatic continuation when a continuation turn
  makes no tool calls.
  - Added continuation and budget-limit prompt templates.
  
  ## Verification
  
  - Added focused core coverage for continuation scheduling, accounting
  boundaries, budget-limit steering, completion accounting, interrupt
  pause behavior, resume auto-activation, and wall-clock remainder
  accounting.

  Eric Traut · 2026-04-24 21:16:00 -07:00
  4167628622
• Add goal app-server API (2 / 5) (#18074)

  Adds the app-server v2 goal API on top of the persisted goal state from
  PR 1.
  
  ## Why
  
  Clients need a stable app-server surface for reading and controlling
  materialized thread goals before the model tools and TUI can use them.
  Goal changes also need to be observable by app-server clients, including
  clients that resume an existing thread.
  
  ## What changed
  
  - Added v2 `thread/goal/get`, `thread/goal/set`, and `thread/goal/clear`
  RPCs for materialized threads.
  - Added `thread/goal/updated` and `thread/goal/cleared` notifications so
  clients can keep local goal state in sync.
  - Added resume/snapshot wiring so reconnecting clients see the current
  goal state for a thread.
  - Added app-server handlers that reconcile persisted rollout state
  before direct goal mutations.
  - Updated the app-server README plus generated JSON and TypeScript
  schema fixtures for the new API surface.
  
  ## Verification
  
  - Added app-server v2 coverage for goal get/set/clear behavior,
  notification emission, resume snapshots, and non-local thread-store
  interactions.

  Eric Traut · 2026-04-24 20:53:41 -07:00
  6c874f9b34
• permissions: remove legacy read-only access modes (#19449)

  ## Why
  
  `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`:
  `FullAccess` meant the historical read-only/workspace-write modes could
  read the full filesystem, while `Restricted` tried to carry partial
  readable roots. The partial-read model now belongs in
  `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on
  `SandboxPolicy` makes every legacy projection reintroduce lossy
  read-root bookkeeping and creates unnecessary noise in the rest of the
  permissions migration.
  
  This PR makes the legacy policy model narrower and explicit:
  `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent
  the old full-read sandbox modes only. Split readable roots, deny-read
  globs, and platform-default/minimal read behavior stay in the runtime
  permissions model.
  
  ## What changed
  
  - Removes `ReadOnlyAccess` from
  `codex_protocol::protocol::SandboxPolicy`, including the generated
  `access` and `readOnlyAccess` API fields.
  - Updates legacy policy/profile conversions so restricted filesystem
  reads are represented only by `FileSystemSandboxPolicy` /
  `PermissionProfile` entries.
  - Keeps app-server v2 compatible with legacy `fullAccess` read-access
  payloads by accepting and ignoring that no-op shape, while rejecting
  legacy `restricted` read-access payloads instead of silently widening
  them to full-read legacy policies.
  - Carries Windows sandbox platform-default read behavior with an
  explicit override flag instead of depending on
  `ReadOnlyAccess::Restricted`.
  - Refreshes generated app-server schema/types and updates tests/docs for
  the simplified legacy policy shape.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol --tests`
  - `cargo check -p codex-windows-sandbox --tests`
  - `cargo test -p codex-app-server-protocol sandbox_policy_`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19449

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• [codex] add non-local thread store regression harness (#19266)

  - Add an integration test that guarantees nothing gets written to codex
  home dir or sqlite when running a rollout with a non-local ThreadStore
  - Add an in-memory "spy" ThreadStore for tests like this
  
  Note I could not find a good way to also ensure there were no filesystem
  _reads_ that didn't go through threadstore. I explored a more elaborate
  sandboxed-subprocess approach but it isn't platform portable and felt
  like it wasn't (yet) worth it.

  Tom · 2026-04-24 15:45:44 -07:00
  588f7a9fc4
• Migrate fork and resume reads to thread store (#18900)

  - Route cold thread/resume and thread/fork source loading through
  ThreadStore reads instead of direct rollout path operations
  - Keep lookups that explicitly specify a rollout-path using the local
  thread store methods but return an invalid-request error for remote
  ThreadStore configurations
  - Add some additional unit tests for code path coverage

  Tom · 2026-04-24 13:51:37 -07:00
  0a9b559c0b
• [codex] Omit fork turns from thread started notifications (#19093)

  ## Why
  
  `thread/fork` responses intentionally include copied history so the
  caller can render the fork immediately, but `thread/started` is a
  lifecycle notification. The v2 `Thread` contract says notifications
  should return `turns: []`, and the fork path was reusing the response
  thread directly, causing copied turns to be emitted through
  `thread/started` as well.
  
  ## What Changed
  
  - Route app-server `thread/started` notification construction through a
  helper that clears `thread.turns` before sending.
  - Keep `thread/fork` responses unchanged so callers still receive copied
  history.
  - Add persistent and ephemeral fork coverage that asserts
  `thread/started` emits an empty `turns` array while the response retains
  fork history.
  
  ## Testing
  
  - `just fmt`
  - `cargo test -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-24 12:31:13 -07:00
  a3cccbd8ed
• respect workspace option for disabling plugins (#18907)

  Respects the workspace setting for plugins in Codex
  
  Plugins menu disappears
  Plugins do not load
  Plugins do not load in composer
  
  no plugins loaded
  <img width="809" height="226" alt="Screenshot 2026-04-23 at 3 20 45 PM"
  src="https://github.com/user-attachments/assets/3a4dba8e-69c3-4046-a77e-f13ab77f84b4"
  />
  
  
  no plugins in menu
  <img width="293" height="204" alt="Screenshot 2026-04-23 at 3 20 35 PM"
  src="https://github.com/user-attachments/assets/5cb9bf52-ad72-488f-b90c-5eb457da09a3"
  />

  Alex Zamoshchin · 2026-04-24 17:38:45 +00:00
  bcc1caa920
• Fix hang on turn/interrupt (#18392)

  Fix a bug where the `turn/interrupt` RPC hangs when interrupting a turn
  that has already completed.
  
  Before this change, `turn/interrupt` requests were queued in app-server
  and only answered when a later TurnAborted event arrived. If the target
  turn was already complete, core treated Op::Interrupt as a no-op, so no
  abort event was emitted and the RPC could hang indefinitely.
  
  This change fixes that in two places:
  
  * Reject turn/interrupt immediately with `INVALID_REQUEST` when the
  requested turn is no longer the active turn.
  * Resolve any already-accepted pending interrupt requests when the turn
  reaches TurnComplete, covering the case where a turn finishes naturally
  after the interrupt request is accepted but before it aborts.
  
  I tested this by adding a failing test in
  707487c0634834f6741986b64f61886c2dc10108. You may view the results here:
  https://github.com/openai/codex/actions/runs/24585182419/
  
  <img width="1512" height="310" alt="CleanShot 2026-04-17 at 16 33 30@2x"
  src="https://github.com/user-attachments/assets/f4a88228-b2a4-41f4-9aaa-ec82814096af"
  />

  danwang-oai · 2026-04-24 10:47:50 -04:00
  11806faf71