145 Commits

• Print warning if we skip config loading (#9611)

  https://github.com/openai/codex/pull/9533 silently ignored config if
  untrusted. Instead, we still load it but disable it. Maybe we shouldn't
  try to parse it either...
  
  <img width="939" height="515" alt="Screenshot 2026-01-21 at 14 56 38"
  src="https://github.com/user-attachments/assets/e753cc22-dd99-4242-8ffe-7589e85bef66"
  />

  gt-oai · 2026-01-23 20:06:37 +00:00
  7938c170d9
• 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
• Add layered config.toml support to app server (#9510)

  This PR adds support for chained (layered) config.toml file merging for
  clients that use the app server interface. This feature already exists
  for the TUI, but it does not work for GUI clients.
  
  It does the following:
  * Changes code paths for new thread, resume thread, and fork thread to
  use the effective config based on the cwd.
  * Updates the `config/read` API to accept an optional `cwd` parameter.
  If specified, the API returns the effective config based on that cwd
  path. Also optionally includes all layers including project config
  files. If cwd is not specified, the API falls back on its older behavior
  where it considers only the global (non-project) config files when
  computing the effective config.
  
  The changes in codex_message_processor.rs look deceptively large. They
  mostly just involve moving existing blocks of code to a later point in
  some functions so it can use the cwd to calculate the config.
  
  This PR builds upon #9509 and should be reviewed and merged after that
  PR.
  
  Tested:
  * Verified change with (dependent, as-yet-uncommitted) changes to IDE
  Extension and confirmed correct behavior
  
  The full fix requires additional changes in the IDE Extension code base,
  but they depend on this PR.

  Eric Traut · 2026-01-21 14:21:48 -08:00
  2ca9a56528
• Chore: update plan mode output in prompt (#9592)

  ### Summary
  * Update plan prompt output
  * Update requestUserInput response to be a single key value pair
  `answer: String`.

  Shijie Rao · 2026-01-21 14:12:18 -08:00
  3fcb40245e
• Add total (non-partial) TextElement placeholder accessors (#9545)

  ## Summary
  - Make `TextElement` placeholders private and add a text-backed accessor
  to avoid assuming `Some`.
  - Since they are optional in the protocol, we want to make sure any
  accessors properly handle the None case (getting the placeholder using
  the byte range in the text)
  - Preserve placeholders during protocol/app-server conversions using the
  accessor fallback.
  - Update TUI composer/remap logic and tests to use the new
  constructor/accessor.

  charley-oai · 2026-01-20 14:04:11 -08:00
  be9e55c5fc
• 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
• Add collaboration_mode override to turns (#9408)
  Ahmed Ibrahim · 2026-01-16 21:51:25 -08:00
  146d54cede
• 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 wait multiple IDs (#9294)
  jif-oai · 2026-01-16 12:05:04 +01:00
  c576756c81
• Add text element metadata to protocol, app server, and core (#9331)

  The second part of breaking up PR
  https://github.com/openai/codex/pull/9116
  
  Summary:
  
  - Add `TextElement` / `ByteRange` to protocol user inputs and user
  message events with defaults.
  - Thread `text_elements` through app-server v1/v2 request handling and
  history rebuild.
  - Preserve UI metadata only in user input/events (not `ContentItem`)
  while keeping local image attachments in user events for rehydration.
  
  Details:
  
  - Protocol: `UserInput::Text` carries `text_elements`;
  `UserMessageEvent` carries `text_elements` + `local_images`.
  Serialization includes empty vectors for backward compatibility.
  - app-server-protocol: v1 defines `V1TextElement` / `V1ByteRange` in
  camelCase with conversions; v2 uses its own camelCase wrapper.
  - app-server: v1/v2 input mapping includes `text_elements`; thread
  history rebuilds include them.
  - Core: user event emission preserves UI metadata while model history
  stays clean; history replay round-trips the metadata.

  charley-oai · 2026-01-15 17:26:41 -08:00
  1fa8350ae7
• Support SKILL.toml file. (#9125)

  We’re introducing a new SKILL.toml to hold skill metadata so Codex can
  deliver a richer Skills experience.
  
  Initial focus is the interface block:
  ```
  [interface]
  display_name = "Optional user-facing name"
  short_description = "Optional user-facing description"
  icon_small = "./assets/small-400px.png"
  icon_large = "./assets/large-logo.svg"
  brand_color = "#3B82F6"
  default_prompt = "Optional surrounding prompt to use the skill with"
  ```
  
  All fields are exposed via the app server API.
  display_name and short_description are consumed by the TUI.

  xl-openai · 2026-01-15 11:20:04 -08:00
  42fa4c237f
• feat: collab tools app-server event mapping (#9213)
  jif-oai · 2026-01-15 09:03:26 +00:00
  bad4c12b9d
• Add text element metadata to types (#9235)

  Initial type tweaking PR to make the diff of
  https://github.com/openai/codex/pull/9116 smaller
  
  This should not change any behavior, just adds some fields to types

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a
• add WebSearchMode enum (#9216)

  ### What
  Add `WebSearchMode` enum (disabled, cached live, defaults to cached) to
  config + V2 protocol. This enum takes precedence over legacy flags:
  `web_search_cached`, `web_search_request`, and `tools.web_search`.
  
  Keep `--search` as live.
  
  ### Tests
  Added tests

  sayan-oai · 2026-01-14 12:51:42 -08:00
  5e426ac270
• Improve handling of config and rules errors for app server clients (#9182)

  When an invalid config.toml key or value is detected, the CLI currently
  just quits. This leaves the VSCE in a dead state.
  
  This PR changes the behavior to not quit and bubble up the config error
  to users to make it actionable. It also surfaces errors related to
  "rules" parsing.
  
  This allows us to surface these errors to users in the VSCE, like this:
  
  <img width="342" height="129" alt="Screenshot 2026-01-13 at 4 29 22 PM"
  src="https://github.com/user-attachments/assets/a79ffbe7-7604-400c-a304-c5165b6eebc4"
  />
  
  <img width="346" height="244" alt="Screenshot 2026-01-13 at 4 45 06 PM"
  src="https://github.com/user-attachments/assets/de874f7c-16a2-4a95-8c6d-15f10482e67b"
  />

  Eric Traut · 2026-01-13 17:57:09 -08:00
  31d9b6f4d2
• 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
• feat: add support for building with Bazel (#8875)

  This PR configures Codex CLI so it can be built with
  [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc`
  includes configuration so that remote builds can be done using
  [BuildBuddy](https://www.buildbuddy.io).
  
  If you are familiar with Bazel, things should work as you expect, e.g.,
  run `bazel test //... --keep-going` to run all the tests in the repo,
  but we have also added some new aliases in the `justfile` for
  convenience:
  
  - `just bazel-test` to run tests locally
  - `just bazel-remote-test` to run tests remotely (currently, the remote
  build is for x86_64 Linux regardless of your host platform). Note we are
  currently seeing the following test failures in the remote build, so we
  still need to figure out what is happening here:
  
  ```
  failures:
      suite::compact::manual_compact_twice_preserves_latest_user_messages
      suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history
      suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view
  ```
  
  - `just build-for-release` to build release binaries for all
  platforms/architectures remotely
  
  To setup remote execution:
  - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI
  employees should also request org access at
  https://openai.buildbuddy.io/join/ with their `@openai.com` email
  address.)
  - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to
  `~/.bazelrc` (add the line `build
  --remote_header=x-buildbuddy-api-key=YOUR_KEY`)
  - Use `--config=remote` in your `bazel` invocations (or add `common
  --config=remote` to your `~/.bazelrc`, or use the `just` commands)
  
  ## CI
  
  In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which
  uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners
  (we are working on supporting Windows, but that is not ready yet). Note
  that the failures we are seeing in `just bazel-remote-test` do not occur
  on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml`
  is green right now.
  
  The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so
  that macOS CI jobs build _remotely_ on Linux hosts (using the
  `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the
  root `BUILD.bazel`) using cross-compilation to build the macOS
  artifacts. Then these artifacts are downloaded locally to GitHub's macOS
  runner so the tests can be executed natively. This is the relevant
  config that enables this:
  
  ```
  common:macos --config=remote
  common:macos --strategy=remote
  common:macos --strategy=TestRunner=darwin-sandbox,local
  ```
  
  Because of the remote caching benefits we get from BuildBuddy, these new
  CI jobs can be extremely fast! For example, consider these two jobs that
  ran all the tests on Linux x86_64:
  
  - Bazel 1m37s
  https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875
  - Cargo 9m20s
  https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875
  
  For now, we will continue to run both the Bazel and Cargo jobs for PRs,
  but once we add support for Windows and running Clippy, we should be
  able to cutover to using Bazel exclusively for PRs, which should still
  speed things up considerably. We will probably continue to run the Cargo
  jobs post-merge for commits that land on `main` as a sanity check.
  
  Release builds will also continue to be done by Cargo for now.
  
  Earlier attempt at this PR: https://github.com/openai/codex/pull/8832
  Earlier attempt to add support for Buck2, now abandoned:
  https://github.com/openai/codex/pull/8504
  
  ---------
  
  Co-authored-by: David Zbarsky <dzbarsky@gmail.com>
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  zbarsky-openai · 2026-01-09 11:09:43 -08:00
  2a06d64bc9
• 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
• fix: implement 'Allow this session' for apply_patch approvals (#8451)

  **Summary**
  This PR makes “ApprovalDecision::AcceptForSession / don’t ask again this
  session” actually work for `apply_patch` approvals by caching approvals
  based on absolute file paths in codex-core, properly wiring it through
  app-server v2, and exposing the choice in both TUI and TUI2.
  - This brings `apply_patch` calls to be at feature-parity with general
  shell commands, which also have a "Yes, and don't ask again" option.
  - This also fixes VSCE's "Allow this session" button to actually work.
  
  While we're at it, also split the app-server v2 protocol's
  `ApprovalDecision` enum so execpolicy amendments are only available for
  command execution approvals.
  
  **Key changes**
  - Core: per-session patch approval allowlist keyed by absolute file
  paths
  - Handles multi-file patches and renames/moves by recording both source
  and destination paths for `Update { move_path: Some(...) }`.
  - Extend the `Approvable` trait and `ApplyPatchRuntime` to work with
  multiple keys, because an `apply_patch` tool call can modify multiple
  files. For a request to be auto-approved, we will need to check that all
  file paths have been approved previously.
  - App-server v2: honor AcceptForSession for file changes
  - File-change approval responses now map AcceptForSession to
  ReviewDecision::ApprovedForSession (no longer downgraded to plain
  Approved).
  - Replace `ApprovalDecision` with two enums:
  `CommandExecutionApprovalDecision` and `FileChangeApprovalDecision`
  - TUI / TUI2: expose “don’t ask again for these files this session”
  - Patch approval overlays now include a third option (“Yes, and don’t
  ask again for these files this session (s)”).
      - Snapshot updates for the approval modal.
  
  **Tests added/updated**
  - Core:
  - Integration test that proves ApprovedForSession on a patch skips the
  next patch prompt for the same file
  - App-server:
  - v2 integration test verifying
  FileChangeApprovalDecision::AcceptForSession works properly
  
  **User-visible behavior**
  - When the user approves a patch “for session”, future patches touching
  only those previously approved file(s) will no longer prompt gain during
  that session (both via app-server v2 and TUI/TUI2).
  
  **Manual testing**
  Tested both TUI and TUI2 - see screenshots below.
  
  TUI:
  <img width="1082" height="355" alt="image"
  src="https://github.com/user-attachments/assets/adcf45ad-d428-498d-92fc-1a0a420878d9"
  />
  
  
  TUI2:
  <img width="1089" height="438" alt="image"
  src="https://github.com/user-attachments/assets/dd768b1a-2f5f-4bd6-98fd-e52c1d3abd9e"
  />

  Owen Lin · 2026-01-07 20:11:12 +00:00
  66450f0445
• Merge Modelfamily into modelinfo (#8763)

  - Merge ModelFamily into ModelInfo
  - Remove logic for adding instructions to apply patch
  - Add compaction limit and visible context window to `ModelInfo`

  Ahmed Ibrahim · 2026-01-07 10:35:09 -08:00
  9179c9deac
• chore: unify conversation with thread name (#8830)

  Done and verified by Codex + refactor feature of RustRover

  jif-oai · 2026-01-07 17:04:53 +00:00
  116059c3a0
• 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: add analytics config setting (#8350)
  Javi · 2026-01-06 19:04:13 +00:00
  915352b10c
• 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: honor /etc/codex/config.toml (#8461)

  This adds logic to load `/etc/codex/config.toml` and associate it with
  `ConfigLayerSource::System` on UNIX. I refactored the code so it shares
  logic with the creation of the `ConfigLayerSource::User` layer.

  Michael Bolin · 2025-12-22 19:06:04 -08:00
  e27d9bd88f
• chore: include User layer in ConfigLayerStack even if config.toml is empty (#8456)

  This is necessary so that `$CODEX_HOME/skills` and `$CODEX_HOME/rules`
  still get loaded even if `$CODEX_HOME/config.toml` does not exist. See
  #8453.
  
  For now, it is possible to omit this layer when creating a dummy
  `ConfigLayerStack` in a test. We can revisit that later, if it turns out
  to be the right thing to do.

  Michael Bolin · 2025-12-22 16:40:26 -08:00
  14dbd0610a
• feat: support in-repo .codex/config.toml entries as sources of config info (#8354)

  - We now support `.codex/config.toml` in repo (from `cwd` up to the
  first `.git` found, if any) as layers in `ConfigLayerStack`. A new
  `ConfigLayerSource::Project` variant was added to support this.
  - In doing this work, I realized that we were resolving relative paths
  in `config.toml` after merging everything into one `toml::Value`, which
  is wrong: paths should be relativized with respect to the folder
  containing the `config.toml` that was deserialized. This PR introduces a
  deserialize/re-serialize strategy to account for this in
  `resolve_config_paths()`. (This is why `Serialize` is added to so many
  types as part of this PR.)
  - Added tests to verify this new behavior.
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/8354).
  * #8359
  * __->__ #8354

  Michael Bolin · 2025-12-22 11:07:36 -08:00
  8ff16a7714
• Support admin scope skills. (#8296)

  a new scope reads from /etc/codex

  xl-openai · 2025-12-19 02:28:56 +00:00
  8120c8765b
• 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 skills shortDescription. (#8278)

  Allow SKILL.md to specify a more human-readable short description as
  skill metadata.

  xl-openai · 2025-12-18 23:13:18 +00:00
  358a5baba0
• feat(app-server): add v2 deprecation notice (#8285)

  Add a v2 event for deprecation notices so we can get rid of
  `codex/event/deprecation_notice`.

  Owen Lin · 2025-12-18 21:45:36 +00:00
  d7ae342ff4
• feat: migrate to new constraint-based loading strategy (#8251)

  This is a significant change to how layers of configuration are applied.
  In particular, the `ConfigLayerStack` now has two important fields:
  
  - `layers: Vec<ConfigLayerEntry>`
  - `requirements: ConfigRequirements`
  
  We merge `TomlValue`s across the layers, but they are subject to
  `ConfigRequirements` before creating a `Config`.
  
  How I would review this PR:
  
  - start with `codex-rs/app-server-protocol/src/protocol/v2.rs` and note
  the new variants added to the `ConfigLayerSource` enum:
  `LegacyManagedConfigTomlFromFile` and `LegacyManagedConfigTomlFromMdm`
  - note that `ConfigLayerSource` now has a `precedence()` method and
  implements `PartialOrd`
  - `codex-rs/core/src/config_loader/layer_io.rs` is responsible for
  loading "admin" preferences from `/etc/codex/managed_config.toml` and
  MDM. Because `/etc/codex/managed_config.toml` is now deprecated in favor
  of `/etc/codex/requirements.toml` and `/etc/codex/config.toml`, we now
  include some extra information on the `LoadedConfigLayers` returned in
  `layer_io.rs`.
  - `codex-rs/core/src/config_loader/mod.rs` has major changes to
  `load_config_layers_state()`, which is what produces `ConfigLayerStack`.
  The docstring has the new specification and describes the various layers
  that will be loaded and the precedence order.
  - It uses the information from `LoaderOverrides` "twice," both in the
  spirit of legacy support:
  - We use one instances to derive an instance of `ConfigRequirements`.
  Currently, the only field in `managed_config.toml` that contributes to
  `ConfigRequirements` is `approval_policy`. This PR introduces
  `Constrained::allow_only()` to support this.
  - We use a clone of `LoaderOverrides` to derive
  `ConfigLayerSource::LegacyManagedConfigTomlFromFile` and
  `ConfigLayerSource::LegacyManagedConfigTomlFromMdm` layers, as
  appropriate. As before, this ends up being a "best effort" at enterprise
  controls, but is enforcement is not guaranteed like it is for
  `ConfigRequirements`.
  - Now we only create a "user" layer if `$CODEX_HOME/config.toml` exists.
  (Previously, a user layer was always created for `ConfigLayerStack`.)
  - Similarly, we only add a "session flags" layer if there are CLI
  overrides.
  - `config_loader/state.rs` contains the updated implementation for
  `ConfigLayerStack`. Note the public API is largely the same as before,
  but the implementation is quite different. We leverage the fact that
  `ConfigLayerSource` is now `PartialOrd` to ensure layers are in the
  correct order.
  - A `Config` constructed via `ConfigBuilder.build()` will use
  `load_config_layers_state()` to create the `ConfigLayerStack` and use
  the associated `ConfigRequirements` when constructing the `Config`
  object.
  - That said, a `Config` constructed via
  `Config::load_from_base_config_with_overrides()` does _not_ yet use
  `ConfigBuilder`, so it creates a `ConfigRequirements::default()` instead
  of loading a proper `ConfigRequirements`. I will fix this in a
  subsequent PR.
  
  Then the following files are mostly test changes:
  
  ```
  codex-rs/app-server/tests/suite/v2/config_rpc.rs
  codex-rs/core/src/config/service.rs
  codex-rs/core/src/config_loader/tests.rs
  ```
  
  Again, because we do not always include "user" and "session flags"
  layers when the contents are empty, `ConfigLayerStack` sometimes has
  fewer layers than before (and the precedence order changed slightly),
  which is the main reason integration tests changed.

  Michael Bolin · 2025-12-18 10:06:05 -08:00
  b903285746
• 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
• feat: change ConfigLayerName into a disjoint union rather than a simple enum (#8095)

  This attempts to tighten up the types related to "config layers."
  Currently, `ConfigLayerEntry` is defined as follows:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/state.rs#L19-L25
  
  but the `source` field is a bit of a lie, as:
  
  - for `ConfigLayerName::Mdm`, it is
  `"com.openai.codex/config_toml_base64"`
  - for `ConfigLayerName::SessionFlags`, it is `"--config"`
  - for `ConfigLayerName::User`, it is `"config.toml"` (just the file
  name, not the path to the `config.toml` on disk that was read)
  - for `ConfigLayerName::System`, it seems like it is usually
  `/etc/codex/managed_config.toml` in practice, though on Windows, it is
  `%CODEX_HOME%/managed_config.toml`:
  
  
  https://github.com/openai/codex/blob/bef36f4ae765f471d7cd69372fcf1b92c8f0367a/codex-rs/core/src/config_loader/layer_io.rs#L84-L101
  
  All that is to say, in three out of the four `ConfigLayerName`, `source`
  is a `PathBuf` that is not an absolute path (or even a true path).
  
  This PR tries to uplevel things by eliminating `source` from
  `ConfigLayerEntry` and turning `ConfigLayerName` into a disjoint union
  named `ConfigLayerSource` that has the appropriate metadata for each
  variant, favoring the use of `AbsolutePathBuf` where appropriate:
  
  ```rust
  pub enum ConfigLayerSource {
      /// Managed preferences layer delivered by MDM (macOS only).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      Mdm { domain: String, key: String },
      /// Managed config layer from a file (usually `managed_config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      System { file: AbsolutePathBuf },
      /// Session-layer overrides supplied via `-c`/`--config`.
      SessionFlags,
      /// User config layer from a file (usually `config.toml`).
      #[serde(rename_all = "camelCase")]
      #[ts(rename_all = "camelCase")]
      User { file: AbsolutePathBuf },
  }
  ```

  Michael Bolin · 2025-12-17 08:13:59 -08:00
  de3fa03e1c
• Add public skills + improve repo skill discovery and error UX (#8098)

  1. Adds SkillScope::Public end-to-end (core + protocol) and loads skills
  from the public cache directory
  2. Improves repo skill discovery by searching upward for the nearest
  .codex/skills within a git repo
  3. Deduplicates skills by name with deterministic ordering to avoid
  duplicates across sources
  4. Fixes garbled “Skill errors” overlay rendering by preventing pending
  history lines from being injected during the modal
  5. Updates the project docs “Skills” intro wording to avoid hardcoded
  paths

  xl-openai · 2025-12-17 01:35:49 -08:00
  4897efcced
• [app-server] add new RawResponseItem v2 event (#8152)

  ``codex/event/raw_response_item` (v1) -> `rawResponseItem/completed`
  (v1).
  
  test client log:
  ````
  < {
  <   "method": "codex/event/raw_response_item",
  <   "params": {
  <     "conversationId": "019b29f7-b089-7140-a535-3fe681562c15",
  <     "id": "0",
  <     "msg": {
  <       "item": {
  <         "arguments": "{\"command\":\"sed -n '1,160p' Cargo.toml\",\"workdir\":\"/Users/celia/code/codex/codex-rs\"}",
  <         "call_id": "call_DrqbdB2jPxezPWc19YVEEt3h",
  <         "name": "shell_command",
  <         "type": "function_call"
  <       },
  <       "type": "raw_response_item"
  <     }
  <   }
  < }
  < {
  <   "method": "rawResponseItem/completed",
  <   "params": {
  <     "item": {
  <       "arguments": "{\"command\":\"sed -n '1,160p' Cargo.toml\",\"workdir\":\"/Users/celia/code/codex/codex-rs\"}",
  <       "call_id": "call_DrqbdB2jPxezPWc19YVEEt3h",
  <       "name": "shell_command",
  <       "type": "function_call"
  <     },
  <     "threadId": "019b29f7-b089-7140-a535-3fe681562c15",
  <     "turnId": "0"
  <   }
  < }
  ```

  Celia Chen · 2025-12-17 02:19:30 +00:00
  70913effc3
• chore: update listMcpServers to listMcpServerStatus (#8114)

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

  Shijie Rao · 2025-12-16 15:28:45 -08:00
  600d01b33a
• chore(app-server): remove stubbed thread/compact API (#8086)

  We want to rely on server-side auto-compaction instead of having the
  client trigger context compaction manually. This API was stubbed as a
  placeholder and never implemented.

  Owen Lin · 2025-12-16 01:11:01 +00:00
  412dd37956
• Fix: Skip Option<()> schema generation to avoid invalid Windows filenames (#7479) (#7969)

  ## Problem
  
  When generating JSON schemas on Windows, the `codex app-server
  generate-json-schema` command fails with a filename error:
  ```text
  Error: Failed to write JSON schema for Option<()>
  Caused by:
      0: Failed to write .\Option<()>.json
      1: The filename, directory name, or volume label syntax is incorrect. (os error 123)
  ```
  This occurs because Windows doesn't allow certain characters in
  filenames, specifically the angle brackets **<>** used in the
  **Option<()>** type name.
  
  ## Root Cause
  
  The schema generation process attempts to create individual JSON files
  for each schema definition, including `Option<()>`. However, the
  characters `<` and `>` are invalid in Windows filenames, causing the
  file creation to fail.
  
  ## Solution
  
  The fix extends the existing `IGNORED_DEFINITIONS` constant (which was
  already being used in the **bundle generation**) to also skip
  `Option<()>` when generating individual JSON schema files. This
  maintains consistency with the existing behavior where `Option<()>` is
  excluded from the bundled schema.
  
  ---
  
  close #7479

  Robby He · 2025-12-15 09:57:12 -08:00
  017a4a06b2
• 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