64 Commits

• [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
• chore(app-server): document experimental API opt-in (#10667)

  Add a section on how to opt in to the experimental API.

  Owen Lin · 2026-02-04 16:19:13 -08:00
  224c9f768d
• feat(app-server, core): allow text + image content items for dynamic tool outputs (#10567)

  Took over the work that @aaronl-openai started here:
  https://github.com/openai/codex/pull/10397
  
  Now that app-server clients are able to set up custom tools (called
  `dynamic_tools` in app-server), we should expose a way for clients to
  pass in not just text, but also image outputs. This is something the
  Responses API already supports for function call outputs, where you can
  pass in either a string or an array of content outputs (text, image,
  file):
  https://platform.openai.com/docs/api-reference/responses/create#responses_create-input-input_item_list-item-function_tool_call_output-output-array-input_image
  
  So let's just plumb it through in Codex (with the caveat that we only
  support text and image for now). This is implemented end-to-end across
  app-server v2 protocol types and core tool handling.
  
  ## Breaking API change
  NOTE: This introduces a breaking change with dynamic tools, but I think
  it's ok since this concept was only recently introduced
  (https://github.com/openai/codex/pull/9539) and it's better to get the
  API contract correct. I don't think there are any real consumers of this
  yet (not even the Codex App).
  
  Old shape:
  `{ "output": "dynamic-ok", "success": true }`
  
  New shape:
  ```
  {
      "contentItems": [
        { "type": "inputText", "text": "dynamic-ok" },
        { "type": "inputImage", "imageUrl": "data:image/png;base64,AAA" }
      ]
    "success": true
  }
  ```

  Owen Lin · 2026-02-04 16:12:47 -08:00
  5ea107a088
• add none personality option (#10688)

  - add none personality enum value and empty placeholder behavior\n- add
  docs/schema updates and e2e coverage

  Ahmed Ibrahim · 2026-02-04 15:40:33 -08:00
  f9c38f531c
• Add thread/compact v2 (#10445)

  - add `thread/compact` as a trigger-only v2 RPC that submits
  `Op::Compact` and returns `{}` immediately.
  - add v2 compaction e2e coverage for success and invalid/unknown thread
  ids, and update protocol schemas/docs.

  Ahmed Ibrahim · 2026-02-03 18:15:55 -08:00
  38a47700b5
• Feat: add upgrade to app server modelList (#10556)

  ### Summary
  * Add model upgrade to listModel app server endpoint to support
  dynamically show model upgrade banner.

  Shijie Rao · 2026-02-03 14:53:36 -08:00
  750ebe154d
• feat: add APIs to list and download public remote skills (#10448)

  Add API to list / download from remote public skills

  xl-openai · 2026-02-03 14:09:37 -08:00
  f38d181795
• feat: add --experimental to generate-ts (#10402)

  Adding a `--experimental` flag to the `generate-ts` fct in the
  app-sever.
  
  It can be called through one of those 2 command
  ```
  just write-app-server-schema --experimental
  codex app-server generate-ts --experimental
  ```

  jif-oai · 2026-02-02 20:30:01 +00:00
  059d386f03
• 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
• add missing fields to WebSearchAction and update app-server types (#10276)

  - add `WebSearchAction` to app-server v2 types
  - add `queries` to `WebSearchAction::Search` type
  
  Updated tests.

  sayan-oai · 2026-01-30 16:37:56 -08:00
  eb86663dcb
• Add enforce_residency to requirements (#10263)

  Add `enforce_residency` to requirements.toml and thread it through to a
  header on `default_client`.

  gt-oai · 2026-01-31 00:26:25 +00:00
  149f3aa27a
• 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
• Conversation naming (#8991)

  Session renaming:
  - `/rename my_session`
  - `/rename` without arg and passing an argument in `customViewPrompt`
  - AppExitInfo shows resume hint using the session name if set instead of
  uuid, defaults to uuid if not set
  - Names are stored in `CODEX_HOME/sessions.jsonl`
  
  Session resuming:
  - codex resume <name> lookup for `CODEX_HOME/sessions.jsonl` first entry
  matching the name and resumes the session
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  pap-openai · 2026-01-30 10:40:09 +00:00
  1ef5455eb6
• feat(app-server): support external auth mode (#10012)

  This enables a new use case where `codex app-server` is embedded into a
  parent application that will directly own the user's ChatGPT auth
  lifecycle, which means it owns the user’s auth tokens and refreshes it
  when necessary. The parent application would just want a way to pass in
  the auth tokens for codex to use directly.
  
  The idea is that we are introducing a new "auth mode" currently only
  exposed via app server: **`chatgptAuthTokens`** which consist of the
  `id_token` (stores account metadata) and `access_token` (the bearer
  token used directly for backend API calls). These auth tokens are only
  stored in-memory. This new mode is in addition to the existing `apiKey`
  and `chatgpt` auth modes.
  
  This PR reuses the shape of our existing app-server account APIs as much
  as possible:
  - Update `account/login/start` with a new `chatgptAuthTokens` variant,
  which will allow the client to pass in the tokens and have codex
  app-server use them directly. Upon success, the server emits
  `account/login/completed` and `account/updated` notifications.
  - A new server->client request called
  `account/chatgptAuthTokens/refresh` which the server can use whenever
  the access token previously passed in has expired and it needs a new one
  from the parent application.
  
  I leveraged the core 401 retry loop which typically triggers auth token
  refreshes automatically, but made it pluggable:
  - **chatgpt** mode refreshes internally, as usual.
  - **chatgptAuthTokens** mode calls the client via
  `account/chatgptAuthTokens/refresh`, the client responds with updated
  tokens, codex updates its in-memory auth, then retries. This RPC has a
  10s timeout and handles JSON-RPC errors from the client.
  
  Also some additional things:
  - chatgpt logins are blocked while external auth is active (have to log
  out first. typically clients will pick one OR the other, not support
  both)
  - `account/logout` clears external auth in memory
  - Ensures that if `forced_chatgpt_workspace_id` is set via the user's
  config, we respect it in both:
  - `account/login/start` with `chatgptAuthTokens` (returns a JSON-RPC
  error back to the client)
  - `account/chatgptAuthTokens/refresh` (fails the turn, and on next
  request app-server will send another `account/chatgptAuthTokens/refresh`
  request to the client).

  Owen Lin · 2026-01-29 23:46:04 +00:00
  81a17bb2c1
• [connectors] Support connectors part 2 - slash command and tui (#9728)

  - [x] Support `/apps` slash command to browse the apps in tui.
  - [x] Support inserting apps to prompt using `$`.
  - [x] Lots of simplification/renaming from connectors to apps.

  Matthew Zeng · 2026-01-28 19:51:58 -08:00
  b9cd089d1f
• compaction (#10034)

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

  Ahmed Ibrahim · 2026-01-28 11:36:11 -08:00
  b7edeee8ca
• [app-server] feat: add filtering on thread list (#9897)
  jif-oai · 2026-01-26 21:54:19 +00:00
  247fb2de64
• Add thread/unarchive to restore archived rollouts (#9843)

  ## Summary
  - Adds a new `thread/unarchive` RPC to move archived thread rollouts
  back into the active `sessions/` tree.
  
  ## What changed
  - **Protocol**
    - Adds `thread/unarchive` request/response types and wiring.
  - **Server**
    - Implements `thread_unarchive` in the app server.
    - Validates the archived rollout path and thread ID.
  - Restores the rollout to `sessions/YYYY/MM/DD/...` based on the rollout
  filename timestamp.
  - **Core**
  - Adds `find_archived_thread_path_by_id_str` helper for archived
  rollouts.
  - **Docs**
    - Documents the new RPC and usage example.
  - **Tests**
    - Adds an end-to-end server test that:
      1) starts a thread,
      2) archives it,
      3) unarchives it,
      4) asserts the file is restored to `sessions/`.
  
  ## How to use
  ```json
  { "method": "thread/unarchive", "id": 24, "params": { "threadId": "<thread-id>" } }
  ```
  
  ## Author Codex Session
  
  `codex resume 019bf158-54b6-7960-a696-9d85df7e1bc1` (soon I'll make this
  kind of session UUID forkable by anyone with the right
  `session_object_storage_url` line in their config, but for now just
  pasting it here for my reference)

  Charley Cunningham · 2026-01-26 11:24:36 -08:00
  62266b13f8
• feat: dynamic tools injection (#9539)

  ## Summary
  Add dynamic tool injection to thread startup in API v2, wire dynamic
  tool calls through the app server to clients, and plumb responses back
  into the model tool pipeline.
  
  ### Flow (high level)
  - Thread start injects `dynamic_tools` into the model tool list for that
  thread (validation is done here).
  - When the model emits a tool call for one of those names, core raises a
  `DynamicToolCallRequest` event.
  - The app server forwards it to the client as `item/tool/call`, waits
  for the client’s response, then submits a `DynamicToolResponse` back to
  core.
  - Core turns that into a `function_call_output` in the next model
  request so the model can continue.
  
  ### What changed
  - Added dynamic tool specs to v2 thread start params and protocol types;
  introduced `item/tool/call` (request/response) for dynamic tool
  execution.
  - Core now registers dynamic tool specs at request time and routes those
  calls via a new dynamic tool handler.
  - App server validates tool names/schemas, forwards dynamic tool call
  requests to clients, and publishes tool outputs back into the session.
  - Integration tests

  jif-oai · 2026-01-26 10:06:44 +00:00
  d594693d1a
• feat(app-server) Expose personality (#9674)

  ### Motivation
  Exposes a per-thread / per-turn `personality` override in the v2
  app-server API so clients can influence model communication style at
  thread/turn start. Ensures the override is passed into the session
  configuration resolution so it becomes effective for subsequent turns
  and headless runners.
  
  ### Testing
  - [x] Add an integration-style test
  `turn_start_accepts_personality_override_v2` in
  `codex-rs/app-server/tests/suite/v2/turn_start.rs` that verifies a
  `/personality` override results in a developer update message containing
  `<personality_spec>` in the outbound model request.
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6971d646b1c08322a689a54d2649f3fe)

  Dylan Hurd · 2026-01-22 18:00:20 -08:00
  2b1ee24e11
• [connectors] Support connectors part 1 - App server & MCP (#9667)

  In order to make Codex work with connectors, we add a built-in gateway
  MCP that acts as a transparent proxy between the client and the
  connectors. The gateway MCP collects actions that are accessible to the
  user and sends them down to the user, when a connector action is chosen
  to be called, the client invokes the action through the gateway MCP as
  well.
  
   - [x] Add the system built-in gateway MCP to list and run connectors.
   - [x] Add the app server methods and protocol

  Matthew Zeng · 2026-01-22 16:48:43 -08:00
  a2c829a808
• feat(app-server): support archived threads in thread/list (#9571)
  Owen Lin · 2026-01-22 12:22:36 -08:00
  733cb68496
• feat(app-server): thread/read API (#9569)
  Owen Lin · 2026-01-22 12:22:01 -08:00
  80240b3b67
• Chore: add cmd related info to exec approval request (#9659)

  ### Summary
  We now rely purely on `item/commandExecution/requestApproval` item to
  render pending approval in VSCE and app. With v2 approach, it does not
  include the actual cmd that it is attempting and therefore we can only
  use `proposedExecpolicyAmendment` to render which can be incomplete.
  
  ### Reproduce
  * Add `prefix_rule(pattern=["echo"], decision="prompt")` to your
  `~/.codex/rules.default.rules`.
  * Ask to `Run  echo "approval-test" please` in VSCE or app. 
  * The pending approval protal does show up but with no content
  
  #### Example screenshot
  <img width="3434" height="3648" alt="Screenshot 2026-01-21 at 8 23
  25 PM"
  src="https://github.com/user-attachments/assets/75644837-21f1-40f8-8b02-858d361ff817"
  />
  
  #### Sample output
  ```
    {"method":"item/commandExecution/requestApproval","id":0,"params":{
      "threadId":"019be439-5a90-7600-a7ea-2d2dcc50302a",
      "turnId":"0",
      "itemId":"call_usgnQ4qEX5U9roNdjT7fPzhb",
      "reason":"`/bin/zsh -lc 'echo \"testing\"'` requires approval by policy",
      "proposedExecpolicyAmendment":null
    }}
  
  ```
  
  ### Fix
  Inlude `command` string, `cwd` and `command_actions` in
  `CommandExecutionRequestApprovalParams` so that consumers can display
  the correct command instead of relying on exec policy output.

  Shijie Rao · 2026-01-21 23:58:53 -08:00
  a4cb97ba5a
• Update skills/list protocol readme (#9623)

  Updates readme example for `skills/list` to reflect latest response
  spec.

  Gav Verma · 2026-01-21 12:51:51 -08:00
  2e06d61339
• Feat: request user input tool (#9472)

  ### Summary
  * Add `requestUserInput` tool that the model can use for gather
  feedback/asking question mid turn.
  
  
  ### Tool input schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput input",
    "type": "object",
    "additionalProperties": false,
    "required": ["questions"],
    "properties": {
      "questions": {
        "type": "array",
        "description": "Questions to show the user (1-3). Prefer 1 unless multiple independent decisions block progress.",
        "minItems": 1,
        "maxItems": 3,
        "items": {
          "type": "object",
          "additionalProperties": false,
          "required": ["id", "header", "question"],
          "properties": {
            "id": {
              "type": "string",
              "description": "Stable identifier for mapping answers (snake_case)."
            },
            "header": {
              "type": "string",
              "description": "Short header label shown in the UI (12 or fewer chars)."
            },
            "question": {
              "type": "string",
              "description": "Single-sentence prompt shown to the user."
            },
            "options": {
              "type": "array",
              "description": "Optional 2-3 mutually exclusive choices. Put the recommended option first and suffix its label with \"(Recommended)\". Only include \"Other\" option if we want to include a free form option. If the question is free form in nature, do not include any option.",
              "minItems": 2,
              "maxItems": 3,
              "items": {
                "type": "object",
                "additionalProperties": false,
                "required": ["value", "label", "description"],
                "properties": {
                  "value": {
                    "type": "string",
                    "description": "Machine-readable value (snake_case)."
                  },
                  "label": {
                    "type": "string",
                    "description": "User-facing label (1-5 words)."
                  },
                  "description": {
                    "type": "string",
                    "description": "One short sentence explaining impact/tradeoff if selected."
                  }
                }
              }
            }
          }
        }
      }
    }
  }
  ```
  
  ### Tool output schema
  ```
  {
    "$schema": "http://json-schema.org/draft-07/schema#",
    "title": "requestUserInput output",
    "type": "object",
    "additionalProperties": false,
    "required": ["answers"],
    "properties": {
      "answers": {
        "type": "object",
        "description": "Map of question id to user answer.",
        "additionalProperties": {
          "type": "object",
          "additionalProperties": false,
          "required": ["selected"],
          "properties": {
            "selected": {
              "type": "array",
              "items": { "type": "string" }
            },
            "other": {
              "type": ["string", "null"]
            }
          }
        }
      }
    }
  }
  ```

  Shijie Rao · 2026-01-19 10:17:30 -08:00
  57ec3a8277
• Expose collaboration presets (#9421)

  Expose collaboration presets for clients
  
  ---------
  
  Co-authored-by: Josh McKinney <joshka@openai.com>

  Ahmed Ibrahim · 2026-01-17 12:32:50 -08:00
  8f0e0300d2
• Support enable/disable skill via config/api. (#9328)

  In config.toml:
  ```
  [[skills.config]]
  path = "/Users/xl/.codex/skills/my_skill/SKILL.md"
  enabled = false
  ```
  
  API:
  skills/list, skills/config/write

  xl-openai · 2026-01-16 20:22:05 -08:00
  ad8bf59cbf
• feat(app-server, core): return threads by created_at or updated_at (#9247)

  Add support for returning threads by either `created_at` OR `updated_at`
  descending. Previously core always returned threads ordered by
  `created_at`.
  
  This PR:
  - updates core to be able to list threads by `updated_at` OR
  `created_at` descending based on what the caller wants
  - also update `thread/list` in app-server to expose this (default to
  `created_at` if not specified)
  
  All existing codepaths (app-server, TUI) still default to `created_at`,
  so no behavior change is expected with this PR.
  
  **Implementation**
  To sort by `updated_at` is a bit nontrivial (whereas `created_at` is
  easy due to the way we structure the folders and filenames on disk,
  which are all based on `created_at`).
  
  The most naive way to do this without introducing a cache file or sqlite
  DB (which we have to implement/maintain) is to scan files in reverse
  `created_at` order on disk, and look at the file's mtime (last modified
  timestamp according to the filesystem) until we reach `MAX_SCAN_FILES`
  (currently set to 10,000). Then, we can return the most recent N
  threads.
  
  Based on some quick and dirty benchmarking on my machine with ~1000
  rollout files, calling `thread/list` with limit 50, the `updated_at`
  path is slower as expected due to all the I/O:
  - updated-at: average 103.10 ms
  - created-at: average 41.10 ms
  
  Those absolute numbers aren't a big deal IMO, but we can certainly
  optimize this in a followup if needed by introducing more state stored
  on disk.
  
  **Caveat**
  There's also a limitation in that any files older than `MAX_SCAN_FILES`
  will be excluded, which means if a user continues a REALLY old thread,
  it's possible to not be included. In practice that should not be too big
  of an issue.
  
  If a user makes...
  - 1000 rollouts/day → threads older than 10 days won't show up
  - 100 rollouts/day → ~100 days
  
  If this becomes a problem for some reason, even more motivation to
  implement an updated_at cache.

  Owen Lin · 2026-01-16 20:58:55 +00:00
  f1653dd4d3
• feat: collab tools app-server event mapping (#9213)
  jif-oai · 2026-01-15 09:03:26 +00:00
  bad4c12b9d
• feat: hot reload mcp servers (#8957)

  ### Summary
  * Added `mcpServer/refresh` command to inform app servers and active
  threads to refresh mcpServer on next turn event.
  * Added `pending_mcp_server_refresh_config` to codex core so that if the
  value is populated, we reinitialize the mcp server manager on the thread
  level.
  * The config is updated on `mcpServer/refresh` command which we iterate
  through threads and provide with the latest config value after last
  write.

  Shijie Rao · 2026-01-12 11:17:50 -08:00
  3e91a95ce1
• fix(app-server): set originator header from initialize (re-revert) (#8988)

  Reapplies https://github.com/openai/codex/pull/8873 which was reverted
  due to merge conflicts

  Owen Lin · 2026-01-09 12:09:30 -08:00
  fbe883318d
• Revert "fix(app-server): set originator header from initialize JSON-RPC request" (#8986)

  Reverts openai/codex#8873

  jif-oai · 2026-01-09 17:00:53 +00:00
  5c380d5b1e
• fix(app-server): set originator header from initialize JSON-RPC request (#8873)

  **Motivation**
  The `originator` header is important for codex-backend’s Responses API
  proxy because it identifies the real end client (codex cli, codex vscode
  extension, codex exec, future IDEs) and is used to categorize requests
  by client for our enterprise compliance API.
  
  Today the `originator` header is set by either:
  - the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var (our VSCode extension
  does this)
  - calling `set_default_originator()` which sets a global immutable
  singleton (`codex exec` does this)
  
  For `codex app-server`, we want the `initialize` JSON-RPC request to set
  that header because it is a natural place to do so. Example:
  ```json
  {
    "method": "initialize",
    "id": 0,
    "params": {
      "clientInfo": {
        "name": "codex_vscode",
        "title": "Codex VS Code Extension",
        "version": "0.1.0"
      }
    }
  }
  ```
  and when app-server receives that request, it can call
  `set_default_originator()`. This is a much more natural interface than
  asking third party developers to set an env var.
  
  One hiccup is that `originator()` reads the global singleton and locks
  in the value, preventing a later `set_default_originator()` call from
  setting it. This would be fine but is brittle, since any codepath that
  calls `originator()` before app-server can process an `initialize`
  JSON-RPC call would prevent app-server from setting it. This was
  actually the case with OTEL initialization which runs on boot, but I
  also saw this behavior in certain tests.
  
  Instead, what we now do is:
  - [unchanged] If `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var is set,
  `originator()` would return that value and `set_default_originator()`
  with some other value does NOT override it.
  - [new] If no env var is set, `originator()` would return the default
  value which is `codex_cli_rs` UNTIL `set_default_originator()` is called
  once, in which case it is set to the new value and becomes immutable.
  Later calls to `set_default_originator()` returns
  `SetOriginatorError::AlreadyInitialized`.
  
  **Other notes**
  - I updated `codex_core::otel_init::build_provider` to accepts a service
  name override, and app-server sends a hardcoded `codex_app_server`
  service name to distinguish it from `codex_cli_rs` used by default (e.g.
  TUI).
  
  **Next steps**
  - Update VSCE to set the proper value for `clientInfo.name` on
  `initialize` and drop the `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` env var.
  - Delete support for `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` in codex-rs.

  Owen Lin · 2026-01-09 08:17:13 -08:00
  ea56186c2b
• feat: fork conversation/thread (#8866)

  ## Summary
  - add thread/conversation fork endpoints to the protocol (v1 + v2)
  - implement fork handling in app-server using thread manager and config
  overrides
  - add fork coverage in app-server tests and document `thread/fork` usage

  Anton Panasenko · 2026-01-08 12:54:20 -08:00
  41a317321d
• feat: add list loaded threads to app server (#8902)
  jif-oai · 2026-01-08 17:48:20 +00:00
  5b7707dfb1
• Support UserInput::Skill in V2 API. (#8864)

  Allow client to specify explicit skill invocation in v2 API.

  xl-openai · 2026-01-07 18:26:35 -08:00
  75076aabfe
• Feat: appServer.requirementList for requirement.toml (#8800)

  ### Summary
  We are exposing requirements via `requirement/list` method from
  app-server so that we can conditionally disable the agent mode dropdown
  selection in VSCE and correctly setting the default value.
  
  ### Sample output
  #### `etc/codex/requirements.toml`
  <img width="497" height="49" alt="Screenshot 2026-01-06 at 11 32 06 PM"
  src="https://github.com/user-attachments/assets/fbd9402e-515f-4b9e-a158-2abb23e866a0"
  />
  
  #### App server response
  <img width="1107" height="79" alt="Screenshot 2026-01-06 at 11 30 18 PM"
  src="https://github.com/user-attachments/assets/c0d669cd-54ef-4789-a26c-adb2c41950af"
  />

  Shijie Rao · 2026-01-07 13:57:44 -08:00
  efd0c21b9b
• [chore] update app server doc with skills (#8853)
  Celia Chen · 2026-01-07 20:07:01 +00:00
  e8421c761c
• feat(app-server): thread/rollback API (#8454)

  Add `thread/rollback` to app-server to support IDEs undo-ing the last N
  turns of a thread.
  
  For context, an IDE partner will be supporting an "undo" capability
  where the IDE (the app-server client) will be responsible for reverting
  the local changes made during the last turn. To support this well, we
  also need a way to drop the last turn (or more generally, the last N
  turns) from the agent's context. This is what `thread/rollback` does.
  
  **Core idea**: A Thread rollback is represented as a persisted event
  message (EventMsg::ThreadRollback) in the rollout JSONL file, not by
  rewriting history. On resume, both the model's context (core replay) and
  the UI turn list (app-server v2's thread history builder) apply these
  markers so the pruned history is consistent across live conversations
  and `thread/resume`.
  
  Implementation notes:
  - Rollback only affects agent context and appends to the rollout file;
  clients are responsible for reverting files on disk.
  - If a thread rollback is currently in progress, subsequent
  `thread/rollback` calls are rejected.
  - Because we use `CodexConversation::submit` and codex core tracks
  active turns, returning an error on concurrent rollbacks is communicated
  via an `EventMsg::Error` with a new variant
  `CodexErrorInfo::ThreadRollbackFailed`. app-server watches for that and
  sends the BAD_REQUEST RPC response.
  
  Tests cover thread rollbacks in both core and app-server, including when
  `num_turns` > existing turns (which clears all turns).
  
  **Note**: this explicitly does **not** behave like `/undo` which we just
  removed from the CLI, which does the opposite of what `thread/rollback`
  does. `/undo` reverts local changes via ghost commits/snapshots and does
  not modify the agent's context / conversation history.

  Owen Lin · 2026-01-06 21:23:48 +00:00
  8b7ec31ba7
• feat: expose outputSchema to user_turn/turn_start app_server API (#8377)

  What changed
  - Added `outputSchema` support to the app-server APIs, mirroring `codex
  exec --output-schema` behavior.
  - V1 `sendUserTurn` now accepts `outputSchema` and constrains the final
  assistant message for that turn.
  - V2 `turn/start` now accepts `outputSchema` and constrains the final
  assistant message for that turn (explicitly per-turn only).
  
  Core behavior
  - `Op::UserTurn` already supported `final_output_json_schema`; now V1
  `sendUserTurn` forwards `outputSchema` into that field.
  - `Op::UserInput` now carries `final_output_json_schema` for per-turn
  settings updates; core maps it into
  `SessionSettingsUpdate.final_output_json_schema` so it applies to the
  created turn context.
  - V2 `turn/start` does NOT persist the schema via `OverrideTurnContext`
  (it’s applied only for the current turn). Other overrides
  (cwd/model/etc) keep their existing persistent behavior.
  
  API / docs
  - `codex-rs/app-server-protocol/src/protocol/v1.rs`: add `output_schema:
  Option<serde_json::Value>` to `SendUserTurnParams` (serialized as
  `outputSchema`).
  - `codex-rs/app-server-protocol/src/protocol/v2.rs`: add `output_schema:
  Option<JsonValue>` to `TurnStartParams` (serialized as `outputSchema`).
  - `codex-rs/app-server/README.md`: document `outputSchema` for
  `turn/start` and clarify it applies only to the current turn.
  - `codex-rs/docs/codex_mcp_interface.md`: document `outputSchema` for v1
  `sendUserTurn` and v2 `turn/start`.
  
  Tests added/updated
  - New app-server integration tests asserting `outputSchema` is forwarded
  into outbound `/responses` requests as `text.format`:
    - `codex-rs/app-server/tests/suite/output_schema.rs`
    - `codex-rs/app-server/tests/suite/v2/output_schema.rs`
  - Added per-turn semantics tests (schema does not leak to the next
  turn):
    - `send_user_turn_output_schema_is_per_turn_v1`
    - `turn_start_output_schema_is_per_turn_v2`
  - Added protocol wire-compat tests for the merged op:
    - serialize omits `final_output_json_schema` when `None`
    - deserialize works when field is missing
    - serialize includes `final_output_json_schema` when `Some(schema)`
  
  Call site updates (high level)
  - Updated all `Op::UserInput { .. }` constructions to include
  `final_output_json_schema`:
    - `codex-rs/app-server/src/codex_message_processor.rs`
    - `codex-rs/core/src/codex_delegate.rs`
    - `codex-rs/mcp-server/src/codex_tool_runner.rs`
    - `codex-rs/tui/src/chatwidget.rs`
    - `codex-rs/tui2/src/chatwidget.rs`
    - plus impacted core tests.
  
  Validation
  - `just fmt`
  - `cargo test -p codex-core`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-mcp-server`
  - `cargo test -p codex-tui`
  - `cargo test -p codex-tui2`
  - `cargo test -p codex-protocol`
  - `cargo clippy --all-features --tests --profile dev --fix -- -D
  warnings`

  Anton Panasenko · 2026-01-05 10:27:00 -08:00
  807f8a43c2
• [chore] add additional_details to StreamErrorEvent + wire through (#8307)

  ### What
  
  Builds on #8293.
  
  Add `additional_details`, which contains the upstream error message, to
  relevant structures used to pass along retryable `StreamError`s.
  
  Uses the new TUI status indicator's `details` field (shows under the
  status header) to display the `additional_details` error to the user on
  retryable `Reconnecting...` errors. This adds clarity for users for
  retryable errors.
  
  Will make corresponding change to VSCode extension to show
  `additional_details` as expandable from the `Reconnecting...` cell.
  
  Examples:
  <img width="1012" height="326" alt="image"
  src="https://github.com/user-attachments/assets/f35e7e6a-8f5e-4a2f-a764-358101776996"
  />
  
  <img width="1526" height="358" alt="image"
  src="https://github.com/user-attachments/assets/0029cbc0-f062-4233-8650-cc216c7808f0"
  />

  sayan-oai · 2025-12-24 10:07:38 -08:00
  bf732600ea
• feat: introduce ExternalSandbox policy (#8290)

  ## Description
  
  Introduced `ExternalSandbox` policy to cover use case when sandbox
  defined by outside environment, effectively it translates to
  `SandboxMode#DangerFullAccess` for file system (since sandbox configured
  on container level) and configurable `network_access` (either Restricted
  or Enabled by outside environment).
  
  as example you can configure `ExternalSandbox` policy as part of
  `sendUserTurn` v1 app_server API:
  
  ```
   {
              "conversationId": <id>,
              "cwd": <cwd>,
              "approvalPolicy": "never",
              "sandboxPolicy": {
                    "type": ""external-sandbox",
                    "network_access": "enabled"/"restricted"
              },
              "model": <model>,
              "effort": <effort>,
              ....
          }
  ```

  Anton Panasenko · 2025-12-18 17:02:03 -08:00
  3429de21b3
• Support SYSTEM skills. (#8220)

  1. Remove PUBLIC skills and introduce SYSTEM skills embedded in the
  binary and installed into $CODEX_HOME/skills/.system at startup.
  2. Skills are now always enabled (feature flag removed).
  3. Update skills/list to accept forceReload and plumb it through (not
  used by clients yet).

  xl-openai · 2025-12-17 18:48:28 -08:00
  da3869eeb6
• chore: update listMcpServers to listMcpServerStatus (#8114)

  ### Summary
  * rename app server `listMcpServers` to `listMcpServerStatuses`.

  Shijie Rao · 2025-12-16 15:28:45 -08:00
  600d01b33a
• Reimplement skills loading using SkillsManager + skills/list op. (#7914)

  refactor the way we load and manage skills:
  1. Move skill discovery/caching into SkillsManager and reuse it across
  sessions.
  2. Add the skills/list API (Op::ListSkills/SkillsListResponse) to fetch
  skills for one or more cwds. Also update app-server for VSCE/App;
  3. Trigger skills/list during session startup so UIs preload skills and
  handle errors immediately.

  xl-openai · 2025-12-14 09:58:17 -08:00
  5d77d4db6b
• [app-server] Update readme to include mcp endpoints (#7850)

  n/a

  Celia Chen · 2025-12-11 01:08:31 +00:00
  ce19dbbb22
• chore: update app-server README (#7510)

  Just keeping the README up to date.
  
  - Reorganize structure a bit to read more naturally
  - Update RPC methods
  - Update events

  Owen Lin · 2025-12-03 10:41:38 -08:00
  343aa35db1
• chore: remove mention of experimental/unstable from app-server README (#7474)
  Owen Lin · 2025-12-02 17:35:05 +00:00
  37ee6bf2c3
• feat: add one off commands to app-server v2 (#7452)
  jif-oai · 2025-12-02 11:56:09 +00:00
  85e687c74a