70 Commits

• enable/disable remote control at runtime, not via features (#22578)

  ## Why
  reapplies https://github.com/openai/codex/pull/22386 which was
  previously reverted
  
  Also, introduce `remoteControl/enable` and `remoteControl/disable`
  app-server APIs to toggle on/off remote control at runtime for a given
  running app-server instance.
  
  ## What Changed
  
  - Adds experimental v2 RPCs:
    - `remoteControl/enable`
    - `remoteControl/disable`
  - Adds `RemoteControlRequestProcessor` and routes the new RPCs through
  it instead of `ConfigRequestProcessor`.
  - Adds named `RemoteControlHandle::enable`, `disable`, and `status`
  methods.
  - Makes `remoteControl/enable` return an error when sqlite state DB is
  unavailable, while keeping enrollment/websocket failures as async status
  updates.
  - Adds `AppServerRuntimeOptions.remote_control_enabled` and hidden
  `--remote-control` flags for `codex app-server` and `codex-app-server`.
  - Updates managed daemon startup to use `codex app-server
  --remote-control --listen unix://`.
  - Marks `Feature::RemoteControl` as removed and ignores
  `[features].remote_control`.
  - Updates app-server README entries for the new remote-control methods.

  Owen Lin · 2026-05-14 01:07:46 +00:00
  4e368aa2e9
• [codex] request desktop attestation from app (#20619)

  ## Summary
  
  TL;DR: teaches `codex-rs` / app-server to request a desktop-provided
  attestation token and attach it as `x-oai-attestation` on the scoped
  ChatGPT Codex request paths.
  
  ![DeviceCheck attestation
  interface](https://raw.githubusercontent.com/openai/codex/dev/jm/devicecheck-diagram-assets/pr-assets/devicecheck-attestation-interface.png)
  
  ## Details
  
  This PR teaches the Codex app-server runtime how to request and attach
  an attestation token. It does not generate DeviceCheck tokens directly;
  instead, it relies on the connected desktop app to advertise that it can
  generate attestation and then asks that app for a fresh header value
  when needed.
  
  The flow is:
  
  1. The Codex desktop app connects to app-server.
  2. During `initialize`, the app can advertise that it supports
  `requestAttestation`.
  3. Before app-server calls selected ChatGPT Codex endpoints, it sends
  the internal server request `attestation/generate` to the app.
  4. app-server receives a pre-encoded header value back.
  5. app-server forwards that value as `x-oai-attestation` on the scoped
  outbound requests.
  
  The code in this repo is mostly protocol and runtime plumbing: it adds
  the app-server request/response shape, introduces an attestation
  provider in core, wires that provider into Responses / compaction /
  realtime setup paths, and covers the intended scoping with tests. The
  signed macOS DeviceCheck generation remains owned by the desktop app PR.
  
  ## Related PR
  
  - Codex desktop app implementation:
  https://github.com/openai/openai/pull/878649
  
  ## Validation
  
  <details>
  <summary>Tests run</summary>
  
  ```sh
  cargo test -p codex-app-server-protocol
  cargo test -p codex-core attestation --lib
  cargo test -p codex-app-server --lib attestation
  ```
  
  Also ran:
  
  ```sh
  just fix -p codex-core
  just fix -p codex-app-server
  just fix -p codex-app-server-protocol
  just fmt
  just write-app-server-schema
  ```
  
  </details>
  
  <details>
  <summary>E2E DeviceCheck validation</summary>
  
  First validated the signed desktop app boundary directly: launched a
  packaged signed `Codex.app`, sent `attestation/generate`, decoded the
  returned `v1.` attestation header, and validated the extracted
  DeviceCheck token with `personal/jm/verify_devicecheck_token.py` using
  bundle ID `com.openai.codex`. Apple returned `status_code: 200` and
  `is_ok: true`.
  
  Then ran the fuller app + app-server flow. The packaged `Codex.app`
  launched a current-branch app-server via `CODEX_CLI_PATH`, and a local
  MITM proxy intercepted outbound `chatgpt.com` traffic. The app-server
  requested `attestation/generate` from the real Electron app process, and
  the intercepted `/backend-api/codex/responses` traffic included
  `x-oai-attestation` on both routes:
  
  ```text
  GET  /backend-api/codex/responses  Upgrade: websocket  x-oai-attestation: present
  POST /backend-api/codex/responses  Upgrade: none       x-oai-attestation: present
  ```
  
  The captured header decoded to a DeviceCheck token that also validated
  with Apple for `com.openai.codex` (`status_code: 200`, `is_ok: true`,
  team `2DC432GLL2`).
  
  </details>
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Jiaming Zhang · 2026-05-08 12:36:02 -07:00
  5f4d0ec343
• device-key: clean up unused crate (#21487)
  Ruslan Nigmatullin · 2026-05-07 09:01:44 -07:00
  e64a8979b0
• [codex] Add unsandboxed process exec API (#19040)

  ## Why
  
  App-server clients sometimes need argv-based local process execution
  while sandbox policy is controlled outside Codex. Those environments can
  reject sandbox-disabling paths before a command ever starts, even when
  the caller intentionally wants unsandboxed execution.
  
  This PR adds a distinct `process/*` API for that use case instead of
  extending `command/exec` with another sandbox-disabling shape. Keeping
  the new surface separate also makes the future removal of `command/exec`
  simpler: clients that need explicit process lifecycle control can move
  to the newer handle-based API without depending on `command/exec`
  business logic.
  
  ## What changed
  
  - Added v2 process lifecycle methods: `process/spawn`,
  `process/writeStdin`, `process/resizePty`, and `process/kill`.
  - Added process notifications: `process/outputDelta` for streamed
  stdout/stderr chunks and `process/exited` for final exit status and
  buffered output.
  - Made `process/spawn` intentionally unsandboxed and omitted
  sandbox-selection fields such as `sandboxPolicy` and
  `permissionProfile`.
  - Added client-supplied, connection-scoped `processHandle` values for
  follow-up control requests and notification routing.
  - Supported cwd, environment overrides, PTY mode and size, stdin
  streaming, stdout/stderr streaming, per-stream output caps, and timeout
  controls.
  - Killed active process sessions when the originating app-server
  connection closes.
  - Wired the implementation through the modular `request_processors/`
  app-server layout, with process-handle request serialization for
  follow-up control calls.
  - Updated generated JSON/TypeScript schema fixtures and documented the
  new API in `codex-rs/app-server/README.md`.
  - Added v2 app-server integration coverage in
  `codex-rs/app-server/tests/suite/v2/process_exec.rs` for spawn
  acknowledgement before exit, buffered output caps, and process
  termination.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server`
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  Ruslan Nigmatullin · 2026-05-04 16:43:58 -07:00
  4950e7d8a6
• 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 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
• 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
• [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
• Add app-server marketplace upgrade RPC (#19074)

  ## Summary
  - add a v2 `marketplace/upgrade` app-server RPC that mirrors the
  existing configured Git marketplace upgrade path
  - expose typed request/response/error payloads and regenerate
  JSON/TypeScript schema fixtures
  - add app-server integration coverage for all, named, already
  up-to-date, and invalid marketplace upgrade requests
  
  ## Tests
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server marketplace_upgrade`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fmt`

  xli-oai · 2026-04-23 13:00:46 -07:00
  0d6a90cd6b
• app-server: implement device key v2 methods (#18430)

  ## Why
  
  The device-key protocol needs an app-server implementation that keeps
  local key operations behind the same request-processing boundary as
  other v2 APIs.
  
  app-server owns request dispatch, transport policy, documentation, and
  JSON-RPC error shaping. `codex-device-key` owns key binding, validation,
  platform provider selection, and signing mechanics. Keeping the adapter
  thin makes the boundary easier to review and avoids moving local
  key-management details into thread orchestration code.
  
  ## What changed
  
  - Added `DeviceKeyApi` as the app-server adapter around
  `DeviceKeyStore`.
  - Converted protocol protection policies, payload variants, algorithms,
  and protection classes to and from the device-key crate types.
  - Encoded SPKI public keys and DER signatures as base64 protocol fields.
  - Routed `device/key/create`, `device/key/public`, and `device/key/sign`
  through `MessageProcessor`.
  - Rejected remote transports before provider access while allowing local
  `stdio` and in-process callers to reach the device-key API.
  - Added stdio, in-process, and websocket tests for device-key validation
  and transport policy.
  - Documented the device-key methods in the app-server v2 method list.
  
  ## Test coverage
  
  - `device_key_create_rejects_empty_account_user_id`
  - `in_process_allows_device_key_requests_to_reach_device_key_api`
  - `device_key_methods_are_rejected_over_websocket`
  
  ## Stack
  
  This is PR 3 of 4 in the device-key app-server stack. It is stacked on
  #18429.
  
  ## Validation
  
  - `cargo test -p codex-app-server device_key`
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-21 14:07:08 -07:00
  69c3d12274
• [codex] Add marketplace/remove app-server RPC (#17751)

  ## Summary
  
  Add a new app-server `marketplace/remove` RPC on top of the shared
  marketplace-remove implementation.
  
  This change:
  - adds `MarketplaceRemoveParams` / `MarketplaceRemoveResponse` to the
  app-server protocol
  - wires the new request through `codex_message_processor`
  - reuses the shared core marketplace-remove flow from the stacked
  refactor PR
  - updates generated schema files and adds focused app-server coverage
  
  ## Validation
  
  - `just write-app-server-schema`
  - `just fmt`
  - heavy compile/test coverage deferred to GitHub CI per request

  xli-oai · 2026-04-19 23:22:49 -07:00
  1dc3535e17
• Sync local plugin imports, async remote imports, refresh caches after… (#18246)

  … import
  
  ## Why
  
  `externalAgentConfig/import` used to spawn plugin imports in the
  background and return immediately. That meant local marketplace imports
  could still be in flight when the caller refreshed plugin state, so
  newly imported plugins would not show up right away.
  
  This change makes local marketplace imports complete before the RPC
  returns, while keeping remote marketplace imports asynchronous so we do
  not block on remote fetches.
  
  ## What changed
  
  - split plugin migration details into local and remote marketplace
  imports based on the external config source
  - import local marketplaces synchronously during
  `externalAgentConfig/import`
  - return pending remote plugin imports to the app-server so it can
  finish them in the background
  - clear the plugin and skills caches before responding to plugin
  imports, and again after background remote imports complete, so the next
  `plugin/list` reloads fresh state
  - keep marketplace source parsing encapsulated behind
  `is_local_marketplace_source(...)` instead of re-exporting the internal
  enum
  - add core and app-server coverage for the synchronous local import path
  and the pending remote import path
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core` (currently fails an existing unrelated
  test:
  `config_loader::tests::cli_override_can_update_project_local_mcp_server_when_project_is_trusted`)
  - `cargo test` (currently fails existing `codex-app-server` integration
  tests in MCP/skills/thread-start areas, plus the unrelated `codex-core`
  failure above)

  alexsong-oai · 2026-04-17 09:34:55 +00:00
  20b4b80426
• feat: add endpoint to delete memories (#17913)
  jif-oai · 2026-04-15 10:35:06 +01:00
  7579d5ad75
• [codex] Refactor marketplace add into shared core flow (#17717)

  ## Summary
  
  Move `codex marketplace add` onto a shared core implementation so the
  CLI and app-server path can use one source of truth.
  
  This change:
  - adds shared marketplace-add orchestration in `codex-core`
  - switches the CLI command to call that shared implementation
  - removes duplicated CLI-only marketplace add helpers
  - preserves focused parser and add-path coverage while moving the shared
  behavior into core tests
  
  ## Why
  
  The new `marketplace/add` RPC should reuse the same underlying
  marketplace-add flow as the CLI. This refactor lands that consolidation
  first so the follow-up app-server PR can be mostly protocol and handler
  wiring.
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_cmd`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  - `just fmt`

  xli-oai · 2026-04-13 20:37:11 -07:00
  ff584c5a4b
• Add turn item injection API (#17703)

  ## Summary
  - Add `turn/inject_items` app-server v2 request support for appending
  raw Responses API items to a loaded thread history without starting a
  turn.
  - Generate JSON schema and TypeScript protocol artifacts for the new
  params and empty response.
  - Document the new endpoint and include a request/response example.
  - Preserve compatibility with the typo alias `turn/injet_items` while
  returning the canonical method name.
  
  ## Testing
  - Not run (not requested)

  pakrym-oai · 2026-04-13 16:11:05 -07:00
  d4be06adea
• feat: disable memory endpoint (#17626)
  jif-oai · 2026-04-13 18:29:49 +01:00
  46a266cd6a
• [mcp] Support MCP Apps part 3 - Add mcp tool call support. (#17364)

  - [x] Add a new app-server method so that MCP Apps can call their own
  MCP server directly.

  Matthew Zeng · 2026-04-11 04:39:19 +00:00
  b7139a7e8f
• Revert "Option to Notify Workspace Owner When Usage Limit is Reached" (#17391)

  Reverts openai/codex#16969
  
  #sev3-2026-04-10-accountscheckversion-500s-for-openai-workspace-7300

  Shijie Rao · 2026-04-10 23:33:13 +00:00
  930e5adb7e
• Option to Notify Workspace Owner When Usage Limit is Reached (#16969)

  ## Summary
  - Replace the manual `/notify-owner` flow with an inline confirmation
  prompt when a usage-based workspace member hits a credits-depleted
  limit.
  - Fetch the current workspace role from the live ChatGPT
  `accounts/check/v4-2023-04-27` endpoint so owner/member behavior matches
  the desktop and web clients.
  - Keep owner, member, and spend-cap messaging distinct so we only offer
  the owner nudge when the workspace is actually out of credits.
  
  ## What Changed
  - `backend-client`
  - Added a typed fetch for the current account role from
  `accounts/check`.
    - Mapped backend role values into a Rust workspace-role enum.
  - `app-server` and protocol
    - Added `workspaceRole` to `account/read` and `account/updated`.
  - Derived `isWorkspaceOwner` from the live role, with a fallback to the
  cached token claim when the role fetch is unavailable.
  - `tui`
    - Removed the explicit `/notify-owner` slash command.
  - When a member is blocked because the workspace is out of credits, the
  error now prompts:
  - `Your workspace is out of credits. Request more from your workspace
  owner? [y/N]`
    - Choosing `y` sends the existing owner-notification request.
  - Choosing `n`, pressing `Esc`, or accepting the default selection
  dismisses the prompt without sending anything.
  - Selection popups now honor explicit item shortcuts, which is how the
  `y` / `n` interaction is wired.
  
  ## Reviewer Notes
  - The main behavior change is scoped to usage-based workspace members
  whose workspace credits are depleted.
  - Spend-cap reached should not show the owner-notification prompt.
  - Owners and admins should continue to see `/usage` guidance instead of
  the member prompt.
  - The live role fetch is best-effort; if it fails, we fall back to the
  existing token-derived ownership signal.
  
  ## Testing
  - Manual verification
    - Workspace owner does not see the member prompt.
  - Workspace member with depleted credits sees the confirmation prompt
  and can send the nudge with `y`.
  - Workspace member with spend cap reached does not see the
  owner-notification prompt.
  
  ### Workspace member out of usage
  
  https://github.com/user-attachments/assets/341ac396-eff4-4a7f-bf0c-60660becbea1
  
  ### Workspace owner
  <img width="1728" height="1086" alt="Screenshot 2026-04-09 at 11 48
  22 AM"
  src="https://github.com/user-attachments/assets/06262a45-e3fc-4cc4-8326-1cbedad46ed6"
  />

  richardopenai · 2026-04-09 21:15:17 -07:00
  9f2a585153
• Forward app-server turn clientMetadata to Responses (#16009)

  ## Summary
  App-server v2 already receives turn-scoped `clientMetadata`, but the
  Rust app-server was dropping it before the outbound Responses request.
  This change keeps the fix lightweight by threading that metadata through
  the existing turn-metadata path rather than inventing a new transport.
  
  ## What we're trying to do and why
  We want turn-scoped metadata from the app-server protocol layer,
  especially fields like Hermes/GAAS run IDs, to survive all the way to
  the actual Responses API request so it is visible in downstream
  websocket request logging and analytics.
  
  The specific bug was:
  - app-server protocol uses camelCase `clientMetadata`
  - Responses transport already has an existing turn metadata carrier:
  `x-codex-turn-metadata`
  - websocket transport already rewrites that header into
  `request.request_body.client_metadata["x-codex-turn-metadata"]`
  - but the Rust app-server never parsed or stored `clientMetadata`, so
  nothing from the app-server request was making it into that existing
  path
  
  This PR fixes that without adding a new header or a second metadata
  channel.
  
  ## How we did it
  ### Protocol surface
  - Add optional `clientMetadata` to v2 `TurnStartParams` and
  `TurnSteerParams`
  - Regenerate the JSON schema / TypeScript fixtures
  - Update app-server docs to describe the field and its behavior
  
  ### Runtime plumbing
  - Add a dedicated core op for app-server user input carrying turn-scoped
  metadata: `Op::UserInputWithClientMetadata`
  - Wire `turn/start` and `turn/steer` through that op / signature path
  instead of dropping the metadata at the message-processor boundary
  - Store the metadata in `TurnMetadataState`
  
  ### Transport behavior
  - Reuse the existing serialized `x-codex-turn-metadata` payload
  - Merge the new app-server `clientMetadata` into that JSON additively
  - Do **not** replace built-in reserved fields already present in the
  turn metadata payload
  - Keep websocket behavior unchanged at the outer shape level: it still
  sends only `client_metadata["x-codex-turn-metadata"]`, but that JSON
  string now contains the merged fields
  - Keep HTTP fallback behavior unchanged except that the existing
  `x-codex-turn-metadata` header now includes the merged fields too
  
  ### Request shape before / after
  Before, a websocket `response.create` looked like:
  ```json
  {
    "type": "response.create",
    "client_metadata": {
      "x-codex-turn-metadata": "{\"session_id\":\"...\",\"turn_id\":\"...\"}"
    }
  }
  ```
  Even if the app-server caller supplied `clientMetadata`, it was not
  represented there.
  
  After, the same request shape is preserved, but the serialized payload
  now includes the new turn-scoped fields:
  ```json
  {
    "type": "response.create",
    "client_metadata": {
      "x-codex-turn-metadata": "{\"session_id\":\"...\",\"turn_id\":\"...\",\"fiber_run_id\":\"fiber-start-123\",\"origin\":\"gaas\"}"
    }
  }
  ```
  
  ## Validation
  ### Targeted tests added / updated
  - protocol round-trip coverage for `clientMetadata` on `turn/start` and
  `turn/steer`
  - protocol round-trip coverage for `Op::UserInputWithClientMetadata`
  - `TurnMetadataState` merge test proving client metadata is added
  without overwriting reserved built-in fields
  - websocket request-shape test proving outbound `response.create`
  contains merged metadata inside
  `client_metadata["x-codex-turn-metadata"]`
  - app-server integration tests proving:
  - `turn/start` forwards `clientMetadata` into the outbound Responses
  request path
    - websocket warmup + real turn request both behave correctly
    - `turn/steer` updates the follow-up request metadata
  
  ### Commands run
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-core
  turn_metadata_state_merges_client_metadata_without_replacing_reserved_fields
  --lib`
  - `cargo test -p codex-core --test all
  responses_websocket_preserves_custom_turn_metadata_fields`
  - `cargo test -p codex-app-server --test all client_metadata`
  - `cargo test -p codex-app-server --test all
  turn_start_forwards_client_metadata_to_responses_websocket_request_body_v2
  -- --nocapture`
  - `just fmt`
  - `just fix -p codex-core -p codex-protocol -p codex-app-server-protocol
  -p codex-app-server`
  - `just fix -p codex-exec -p codex-tui-app-server`
  - `just argument-comment-lint`
  
  ### Full suite note
  `cargo test` in `codex-rs` still fails in:
  -
  `suite::v2::turn_interrupt::turn_interrupt_resolves_pending_command_approval_request`
  
  I verified that same failure on a clean detached `HEAD` worktree with an
  isolated `CARGO_TARGET_DIR`, so it is not caused by this patch.

  neil-oai · 2026-04-09 11:52:37 -07:00
  a92a5085bd
• [mcp] Support MCP Apps part 1. (#16082)

  - [x] Add `mcpResource/read` method to read mcp resource.

  Matthew Zeng · 2026-04-06 19:17:14 -07:00
  5fe9ef06ce
• Fix MCP tool listing for hyphenated server names (#16674)

  Addresses #16671 and #14927
  
  Problem: `mcpServerStatus/list` rebuilt MCP tool groups from sanitized
  tool prefixes but looked them up by unsanitized server names, so
  hyphenated servers rendered as having no tools in `/mcp`. This was
  reported as a regression when the TUI switched to use the app server.
  
  Solution: Build each server's tool map using the original server name's
  sanitized prefix, include effective runtime MCP servers in the status
  response, and add a regression test for hyphenated server names.

  Eric Traut · 2026-04-03 09:05:50 -07:00
  a3b3e7a6cc
• Add thread/shellCommand to app server API surface (#14988)

  This PR adds a new `thread/shellCommand` app server API so clients can
  implement `!` shell commands. These commands are executed within the
  sandbox, and the command text and output are visible to the model.
  
  The internal implementation mirrors the current TUI `!` behavior.
  - persist shell command execution as `CommandExecution` thread items,
  including source and formatted output metadata
  - bridge live and replayed app-server command execution events back into
  the existing `tui_app_server` exec rendering path
  
  This PR also wires `tui_app_server` to submit `!` commands through the
  new API.

  Eric Traut · 2026-03-18 23:42:40 -06:00
  01df50cf42
• app-server: add v2 filesystem APIs (#14245)

  Add a protocol-level filesystem surface to the v2 app-server so Codex
  clients can read and write files, inspect directories, and subscribe to
  path changes without relying on host-specific helpers.
  
  High-level changes:
  - define the new v2 fs/readFile, fs/writeFile, fs/createDirectory,
  fs/getMetadata, fs/readDirectory, fs/remove, fs/copy RPCs
  - implement the app-server handlers, including absolute-path validation,
  base64 file payloads, recursive copy/remove semantics
  - document the API, regenerate protocol schemas/types, and add
  end-to-end tests for filesystem operations, copy edge cases
  
  Testing plan:
  - validate protocol serialization and generated schema output for the
  new fs request, response, and notification types
  - run app-server integration coverage for file and directory CRUD paths,
  metadata/readDirectory responses, copy failure modes, and absolute-path
  validation

  Ruslan Nigmatullin · 2026-03-13 14:42:20 -07:00
  f8f82bfc2b
• feat: add plugin/read. (#14445)

  return more information for a specific plugin.

  xl-openai · 2026-03-12 16:52:21 -07:00
  1ea69e8d50
• chore: plugin/uninstall endpoint (#14111)

  add `plugin/uninstall` app-server endpoint to fully rm plugin from
  plugins cache dir and rm entry from user config file.
  
  plugin-enablement is session-scoped, so uninstalls are only picked up in
  new sessions (like installs).
  
  added tests.

  sayan-oai · 2026-03-09 12:40:25 -07:00
  6ad448b658
• Add request permissions tool (#13092)

  Adds a built-in `request_permissions` tool and wires it through the
  Codex core, protocol, and app-server layers so a running turn can ask
  the client for additional permissions instead of relying on a static
  session policy.
  
  The new flow emits a `RequestPermissions` event from core, tracks the
  pending request by call ID, forwards it through app-server v2 as an
  `item/permissions/requestApproval` request, and resumes the tool call
  once the client returns an approved subset of the requested permission
  profile.

  Jack Mousseau · 2026-03-08 20:23:06 -07:00
  e6b93841c5
• app-server: Add streaming and tty/pty capabilities to command/exec (#13640)

  * Add an ability to stream stdin, stdout, and stderr
  * Streaming of stdout and stderr has a configurable cap for total amount
  of transmitted bytes (with an ability to disable it)
  * Add support for overriding environment variables
  * Add an ability to terminate running applications (using
  `command/exec/terminate`)
  * Add TTY/PTY support, with an ability to resize the terminal (using
  `command/exec/resize`)

  Ruslan Nigmatullin · 2026-03-06 17:30:17 -08:00
  e9bd8b20a1
• app-server: Emit thread/name/updated event globally (#13674)
  Ruslan Nigmatullin · 2026-03-06 10:25:18 -08:00
  51fcdc760d
• support plugin/list. (#13540)

  Introduce a plugin/list which reads from local marketplace.json.
  Also update the signature for plugin/install.

  xl-openai · 2026-03-05 21:58:50 -05:00
  520ed724d2
• feat(app-server): support mcp elicitations in v2 api (#13425)

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

  Owen Lin · 2026-03-05 07:20:20 -08:00
  926b2f19e8
• Add thread metadata update endpoint to app server (#13280)

  ## Summary
  - add the v2 `thread/metadata/update` API, including
  protocol/schema/TypeScript exports and app-server docs
  - patch stored thread `gitInfo` in sqlite without resuming the thread,
  with validation plus support for explicit `null` clears
  - repair missing sqlite thread rows from rollout data before patching,
  and make those repairs safe by inserting only when absent and updating
  only git columns so newer metadata is not clobbered
  - keep sqlite authoritative for mutable thread git metadata by
  preserving existing sqlite git fields during reconcile/backfill and only
  using rollout `SessionMeta` git fields to fill gaps
  - add regression coverage for the endpoint, repair paths, concurrent
  sqlite writes, clearing git fields, and rollout/backfill reconciliation
  - fix the login server shutdown race so cancelling before the waiter
  starts still terminates `block_until_done()` correctly
  
  ## Testing
  - `cargo test -p codex-state
  apply_rollout_items_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-state
  update_thread_git_info_preserves_newer_non_git_metadata`
  - `cargo test -p codex-core
  backfill_sessions_preserves_existing_git_branch_and_fills_missing_git_fields`
  - `cargo test -p codex-app-server thread_metadata_update`
  - `cargo test`
  - currently fails in existing `codex-core` grep-files tests with
  `unsupported call: grep_files`:
      - `suite::grep_files::grep_files_tool_collects_matches`
      - `suite::grep_files::grep_files_tool_reports_empty_results`

  joeytrasatti-openai · 2026-03-03 15:56:11 -08:00
  935754baa3
• Revert "Add skill approval event/response (#12633)" (#12811)

  This reverts commit https://github.com/openai/codex/pull/12633. We no
  longer need this PR, because we favor sending normal exec command
  approval server request with `additional_permissions` of skill
  permissions instead

  Celia Chen · 2026-02-26 01:02:42 +00:00
  4f45668106
• feat(app-server): thread/unsubscribe API (#10954)

  Adds a new v2 app-server API for a client to be able to unsubscribe to a
  thread:
  - New RPC method: `thread/unsubscribe`
  - New server notification: `thread/closed`
  
  Today clients can start/resume/archive threads, but there wasn’t a way
  to explicitly unload a live thread from memory without archiving it.
  With `thread/unsubscribe`, a client can indicate it is no longer
  actively working with a live Thread. If this is the only client
  subscribed to that given thread, the thread will be automatically closed
  by app-server, at which point the server will send `thread/closed` and
  `thread/status/changed` with `status: notLoaded` notifications.
  
  This gives clients a way to prevent long-running app-server processes
  from accumulating too many thread (and related) objects in memory.
  
  Closed threads will also be removed from `thread/loaded/list`.

  Owen Lin · 2026-02-25 13:14:30 -08:00
  21f7032dbb
• Add app-server v2 thread realtime API (#12715)

  Add experimental `thread/realtime/*` v2 requests and notifications, then
  route app-server realtime events through that thread-scoped surface with
  integration coverage.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-02-25 09:59:10 -08:00
  947092283a
• codex-rs/app-server: graceful websocket restart on Ctrl-C (#12517)

  ## Summary
  - add graceful websocket app-server restart on Ctrl-C by draining until
  no assistant turns are running
  - stop the websocket acceptor and disconnect existing connections once
  the drain condition is met
  - add a websocket integration test that verifies Ctrl-C waits for an
  in-flight turn before exit
  
  ## Verification
  - `cargo check -p codex-app-server --quiet`
  - `cargo test -p codex-app-server --test all
  suite::v2::connection_handling_websocket`
  - I (maxj) tested remote and local Codex.app
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Max Johnson · 2026-02-24 16:27:59 -08:00
  5163850025
• Add skill approval event/response (#12633)

  Set the stage for skill-level permission approval in addition to
  command-level.
  
  Behind a feature flag.

  pakrym-oai · 2026-02-23 22:28:58 -08:00
  58763afa0f
• app-server: expose loaded thread status via read/list and notifications (#11786)

  Motivation
  - Today, a newly connected client has no direct way to determine the
  current runtime status of threads from read/list responses alone.
  - This forces clients to infer state from transient events, which can
  lead to stale or inconsistent UI when reconnecting or attaching late.
  
  Changes
  - Add `status` to `thread/read` responses.
  - Add `statuses` to `thread/list` responses.
  - Emit `thread/status/changed` notifications with `threadId` and the new
  status.
  - Track runtime status for all loaded threads and default unknown
  threads to `idle`.
  - Update protocol/docs/tests/schema fixtures for the revised API.
  
  Testing
  - Validated protocol API changes with automated protocol tests and
  regenerated schema/type fixtures.
  - Validated app-server behavior with unit and integration test suites,
  including status transitions and notifications.

  Ruslan Nigmatullin · 2026-02-18 15:20:03 -08:00
  1f54496c48
• app-server support for Windows sandbox setup. (#12025)

  app-server support for initiating Windows sandbox setup.
  server responds quickly to setup request and makes a future RPC call
  back to client when the setup finishes.
  
  The TUI implementation is unaffected but in a future PR I'll update the
  TUI to use the shared setup helper
  (`windows_sandbox.run_windows_sandbox_setup`)

  iceweasel-oai · 2026-02-18 13:03:16 -08:00
  292542616a
• feat(core): zsh exec bridge (#12052)

  zsh fork PR stack:
  - https://github.com/openai/codex/pull/12051 
  - https://github.com/openai/codex/pull/12052 👈 
  
  ### Summary
  This PR introduces a feature-gated native shell runtime path that routes
  shell execution through a patched zsh exec bridge, removing MCP-specific
  behavior from the shell hot path while preserving existing
  CommandExecution lifecycle semantics.
  
  When shell_zsh_fork is enabled, shell commands run via patched zsh with
  per-`execve` interception through EXEC_WRAPPER. Core receives wrapper
  IPC requests over a Unix socket, applies existing approval policy, and
  returns allow/deny before the subcommand executes.
  
  ### What’s included
  **1) New zsh exec bridge runtime in core**
  - Wrapper-mode entrypoint (maybe_run_zsh_exec_wrapper_mode) for
  EXEC_WRAPPER invocations.
  - Per-execution Unix-socket IPC handling for wrapper requests/responses.
  - Approval callback integration using existing core approval
  orchestration.
  - Streaming stdout/stderr deltas to existing command output event
  pipeline.
  - Error handling for malformed IPC, denial/abort, and execution
  failures.
  
  **2) Session lifecycle integration**
  SessionServices now owns a `ZshExecBridge`.
  Session startup initializes bridge state; shutdown tears it down
  cleanly.
  
  **3) Shell runtime routing (feature-gated)**
  When `shell_zsh_fork` is enabled:
  - Build execution env/spec as usual.
  - Add wrapper socket env wiring.
  - Execute via `zsh_exec_bridge.execute_shell_request(...)` instead of
  the regular shell path.
  - Non-zsh-fork behavior remains unchanged.
  
  **4) Config + feature wiring**
  - Added `Feature::ShellZshFork` (under development).
  - Added config support for `zsh_path` (optional absolute path to patched
  zsh):
  - `Config`, `ConfigToml`, `ConfigProfile`, overrides, and schema.
  - Session startup validates that `zsh_path` exists/usable when zsh-fork
  is enabled.
  - Added startup test for missing `zsh_path` failure mode.
  
  **5) Seatbelt/sandbox updates for wrapper IPC**
  - Extended seatbelt policy generation to optionally allow outbound
  connection to explicitly permitted Unix sockets.
  - Wired sandboxing path to pass wrapper socket path through to seatbelt
  policy generation.
  - Added/updated seatbelt tests for explicit socket allow rule and
  argument emission.
  
  **6) Runtime entrypoint hooks**
  - This allows the same binary to act as the zsh wrapper subprocess when
  invoked via `EXEC_WRAPPER`.
  
  **7) Tool selection behavior**
  - ToolsConfig now prefers ShellCommand type when shell_zsh_fork is
  enabled.
  - Added test coverage for precedence with unified-exec enabled.

  Owen Lin · 2026-02-17 20:19:53 -08:00
  edacbf7b6e
• add(core): safety check downgrade warning (#11964)

  Add per-turn notice when a request is downgraded to a fallback model due
  to cyber safety checks.
  
  **Changes**
  
  - codex-api: Emit a ServerModel event based on the openai-model response
  header and/or response payload (SSE + WebSocket), including when the
  model changes mid-stream.
  - core: When the server-reported model differs from the requested model,
  emit a single per-turn warning explaining the reroute to gpt-5.2 and
  directing users to Trusted
      Access verification and the cyber safety explainer.
  - app-server (v2): Surface these cyber model-routing warnings as
  synthetic userMessage items with text prefixed by Warning: (and document
  this behavior).

  Fouad Matin · 2026-02-16 22:13:36 -08:00
  02e9006547
• Reapply "Add app-server transport layer with websocket support" (#11370)

  Reapply "Add app-server transport layer with websocket support" with
  additional fixes from https://github.com/openai/codex/pull/11313/changes
  to avoid deadlocking.
  
  This reverts commit 47356ff83c.
  
  ## Summary
  
  To avoid deadlocking when queues are full, we maintain separate tokio
  tasks dedicated to incoming vs outgoing event handling
  - split the app-server main loop into two tasks in
  `run_main_with_transport`
     - inbound handling (`transport_event_rx`)
     - outbound handling (`outgoing_rx` + `thread_created_rx`)
  - separate incoming and outgoing websocket tasks
  
  ## Validation
  
  Integration tests, testing thoroughly e2e in codex app w/ >10 concurrent
  requests
  
  <img width="1365" height="979" alt="Screenshot 2026-02-10 at 2 54 22 PM"
  src="https://github.com/user-attachments/assets/47ca2c13-f322-4e5c-bedd-25859cbdc45f"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Max Johnson · 2026-02-11 18:13:39 +00:00
  7053aa5457
• Revert "Add app-server transport layer with websocket support (#10693)" (#11323)

  Suspected cause of deadlocking bug

  Max Johnson · 2026-02-10 17:37:49 +00:00
  47356ff83c
• feat: extend skills/list to support additional roots. (#10835)

  Add an optional perCwdExtraUserRoots

  xl-openai · 2026-02-09 13:30:38 -08:00
  a33ee46e3b
• feat(app-server): turn/steer API (#10821)

  This PR adds a dedicated `turn/steer` API for appending user input to an
  in-flight turn.
  
  ## Motivation
  Currently, steering in the app is implemented by just calling
  `turn/start` while a turn is running. This has some really weird quirks:
  - Client gets back a new `turn.id`, even though streamed
  events/approvals remained tied to the original active turn ID.
  - All the various turn-level override params on `turn/start` do not
  apply to the "steer", and would only apply to the next real turn.
  - There can also be a race condition where the client thinks the turn is
  active but the server has already completed it, so there might be bugs
  if the client has baked in some client-specific behavior thinking it's a
  steer when in fact the server kicked off a new turn. This is
  particularly possible when running a client against a remote app-server.
  
  Having a dedicated `turn/steer` API eliminates all those quirks.
  
  `turn/steer` behavior:
  - Requires an active turn on threadId. Returns a JSON-RPC error if there
  is no active turn.
  - If expectedTurnId is provided, it must match the active turn (more
  useful when connecting to a remote app-server).
  - Does not emit `turn/started`.
  - Does not accept turn overrides (`cwd`, `model`, `sandbox`, etc.) or
  `outputSchema` to accurately reflect that these are not applied when
  steering.

  Owen Lin · 2026-02-06 00:35:04 +00:00
  0d8b2b74c4
• Add app-server transport layer with websocket support (#10693)

  - Adds --listen <URL> to codex app-server with two listen modes:
        - stdio:// (default, existing behavior)
        - ws://IP:PORT (new websocket transport)
    - Refactors message routing to be connection-aware:
  - Tracks per-connection session state (initialize/experimental
  capability)
        - Routes responses/errors to the originating connection
  - Broadcasts server notifications/requests to initialized connections
  - Updates initialization semantics to be per connection (not
  process-global), and updates app-server docs accordingly.
  - Adds websocket accept/read/write handling (JSON-RPC per text frame,
  ping/pong handling, connection lifecycle events).
  
  Testing
  
  - Unit tests for transport URL parsing and targeted response/error
  routing.
    - New websocket integration test validating:
        - per-connection initialization requirements
        - no cross-connection response leakage
        - same request IDs on different connections route independently.

  Max Johnson · 2026-02-05 20:56:34 +00:00
  8473096efb
• [app-server] Add a method to list experimental features. (#10721)

  - [x] Add a method to list experimental features.

  Matthew Zeng · 2026-02-05 20:04:01 +00:00
  7e81f63698
• feat: experimental flags (#10231)

  ## Problem being solved
  - We need a single, reliable way to mark app-server API surface as
  experimental so that:
    1. the runtime can reject experimental usage unless the client opts in
  2. generated TS/JSON schemas can exclude experimental methods/fields for
  stable clients.
  
  Right now that’s easy to drift or miss when done ad-hoc.
  
  ## How to declare experimental methods and fields
  - **Experimental method**: add `#[experimental("method/name")]` to the
  `ClientRequest` variant in `client_request_definitions!`.
  - **Experimental field**: on the params struct, derive `ExperimentalApi`
  and annotate the field with `#[experimental("method/name.field")]` + set
  `inspect_params: true` for the method variant so
  `ClientRequest::experimental_reason()` inspects params for experimental
  fields.
  
  ## How the macro solves it
  - The new derive macro lives in
  `codex-rs/codex-experimental-api-macros/src/lib.rs` and is used via
  `#[derive(ExperimentalApi)]` plus `#[experimental("reason")]`
  attributes.
  - **Structs**:
  - Generates `ExperimentalApi::experimental_reason(&self)` that checks
  only annotated fields.
    - The “presence” check is type-aware:
      - `Option<T>`: `is_some_and(...)` recursively checks inner.
      - `Vec`/`HashMap`/`BTreeMap`: must be non-empty.
      - `bool`: must be `true`.
      - Other types: considered present (returns `true`).
  - Registers each experimental field in an `inventory` with `(type_name,
  serialized field name, reason)` and exposes `EXPERIMENTAL_FIELDS` for
  that type. Field names are converted from `snake_case` to `camelCase`
  for schema/TS filtering.
  - **Enums**:
  - Generates an exhaustive `match` returning `Some(reason)` for annotated
  variants and `None` otherwise (no wildcard arm).
  - **Wiring**:
  - Runtime gating uses `ExperimentalApi::experimental_reason()` in
  `codex-rs/app-server/src/message_processor.rs` to reject requests unless
  `InitializeParams.capabilities.experimental_api == true`.
  - Schema/TS export filters use the inventory list and
  `EXPERIMENTAL_CLIENT_METHODS` from `client_request_definitions!` to
  strip experimental methods/fields when `experimental_api` is false.

  jif-oai · 2026-02-02 11:06:50 +00:00
  3cc9122ee2
• Plan mode: stream proposed plans, emit plan items, and render in TUI (#9786)

  ## Summary
  - Stream proposed plans in Plan Mode using `<proposed_plan>` tags parsed
  in core, emitting plan deltas plus a plan `ThreadItem`, while stripping
  tags from normal assistant output.
  - Persist plan items and rebuild them on resume so proposed plans show
  in thread history.
  - Wire plan items/deltas through app-server protocol v2 and render a
  dedicated proposed-plan view in the TUI, including the “Implement this
  plan?” prompt only when a plan item is present.
  
  ## Changes
  
  ### Core (`codex-rs/core`)
  - Added a generic, line-based tag parser that buffers each line until it
  can disprove a tag prefix; implements auto-close on `finish()` for
  unterminated tags. `codex-rs/core/src/tagged_block_parser.rs`
  - Refactored proposed plan parsing to wrap the generic parser.
  `codex-rs/core/src/proposed_plan_parser.rs`
  - In plan mode, stream assistant deltas as:
    - **Normal text** → `AgentMessageContentDelta`
    - **Plan text** → `PlanDelta` + `TurnItem::Plan` start/completion  
    (`codex-rs/core/src/codex.rs`)
  - Final plan item content is derived from the completed assistant
  message (authoritative), not necessarily the concatenated deltas.
  - Strips `<proposed_plan>` blocks from assistant text in plan mode so
  tags don’t appear in normal messages.
  (`codex-rs/core/src/stream_events_utils.rs`)
  - Persist `ItemCompleted` events only for plan items for rollout replay.
  (`codex-rs/core/src/rollout/policy.rs`)
  - Guard `update_plan` tool in Plan Mode with a clear error message.
  (`codex-rs/core/src/tools/handlers/plan.rs`)
  - Updated Plan Mode prompt to:  
    - keep `<proposed_plan>` out of non-final reasoning/preambles  
    - require exact tag formatting  
    - allow only one `<proposed_plan>` block per turn  
    (`codex-rs/core/templates/collaboration_mode/plan.md`)
  
  ### Protocol / App-server protocol
  - Added `TurnItem::Plan` and `PlanDeltaEvent` to core protocol items.
  (`codex-rs/protocol/src/items.rs`, `codex-rs/protocol/src/protocol.rs`)
  - Added v2 `ThreadItem::Plan` and `PlanDeltaNotification` with
  EXPERIMENTAL markers and note that deltas may not match the final plan
  item. (`codex-rs/app-server-protocol/src/protocol/v2.rs`)
  - Added plan delta route in app-server protocol common mapping.
  (`codex-rs/app-server-protocol/src/protocol/common.rs`)
  - Rebuild plan items from persisted `ItemCompleted` events on resume.
  (`codex-rs/app-server-protocol/src/protocol/thread_history.rs`)
  
  ### App-server
  - Forward plan deltas to v2 clients and map core plan items to v2 plan
  items. (`codex-rs/app-server/src/bespoke_event_handling.rs`,
  `codex-rs/app-server/src/codex_message_processor.rs`)
  - Added v2 plan item tests.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ### TUI
  - Added a dedicated proposed plan history cell with special background
  and padding, and moved “• Proposed Plan” outside the highlighted block.
  (`codex-rs/tui/src/history_cell.rs`, `codex-rs/tui/src/style.rs`)
  - Only show “Implement this plan?” when a plan item exists.
  (`codex-rs/tui/src/chatwidget.rs`,
  `codex-rs/tui/src/chatwidget/tests.rs`)
  
  <img width="831" height="847" alt="Screenshot 2026-01-29 at 7 06 24 PM"
  src="https://github.com/user-attachments/assets/69794c8c-f96b-4d36-92ef-c1f5c3a8f286"
  />
  
  ### Docs / Misc
  - Updated protocol docs to mention plan deltas.
  (`codex-rs/docs/protocol_v1.md`)
  - Minor plumbing updates in exec/debug clients to tolerate plan deltas.
  (`codex-rs/debug-client/src/reader.rs`, `codex-rs/exec/...`)
  
  ## Tests
  - Added core integration tests:
    - Plan mode strips plan from agent messages.
    - Missing `</proposed_plan>` closes at end-of-message.  
    (`codex-rs/core/tests/suite/items.rs`)
  - Added unit tests for generic tag parser (prefix buffering, non-tag
  lines, auto-close). (`codex-rs/core/src/tagged_block_parser.rs`)
  - Existing app-server plan item tests in v2.
  (`codex-rs/app-server/tests/suite/v2/plan_item.rs`)
  
  ## Notes / Behavior
  - Plan output no longer appears in standard assistant text in Plan Mode;
  it streams via `PlanDelta` and completes as a `TurnItem::Plan`.
  - The final plan item content is authoritative and may diverge from
  streamed deltas (documented as experimental).
  - Reasoning summaries are not filtered; prompt instructs the model not
  to include `<proposed_plan>` outside the final plan message.
  
  ## Codex Author
  `codex fork 019bec2d-b09d-7450-b292-d7bcdddcdbfb`

  Charley Cunningham · 2026-01-30 18:59:30 +00:00
  ec4a2d07e4
• Add app-server compaction item notifications tests (#10123)

  - add v2 tests covering local + remote auto-compaction item
  started/completed notifications

  Ahmed Ibrahim · 2026-01-29 01:00:38 +00:00
  52609c6f42