107 Commits

• 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
• fix: introduce AbsolutePathBuf as part of sandbox config (#7856)

  Changes the `writable_roots` field of the `WorkspaceWrite` variant of
  the `SandboxPolicy` enum from `Vec<PathBuf>` to `Vec<AbsolutePathBuf>`.
  This is helpful because now callers can be sure the value is an absolute
  path rather than a relative one. (Though when using an absolute path in
  a Seatbelt config policy, we still have to _canonicalize_ it first.)
  
  Because `writable_roots` can be read from a config file, it is important
  that we are able to resolve relative paths properly using the parent
  folder of the config file as the base path.

  Michael Bolin · 2025-12-12 15:25:22 -08:00
  642b7566df
• [app-server] make app server not throw error when login id is not found (#7831)

  Our previous design of cancellation endpoint is not idempotent, which
  caused a bunch of flaky tests. Make app server just returned a not_found
  status instead of throwing an error if the login id is not found. Keep
  V1 endpoint behavior the same.

  Celia Chen · 2025-12-10 16:19:40 -08:00
  7cabe54fc7
• [app-server-protocol] Add types for config (#7658)

  Currently the config returned by `config/read` in untyped. Add types so
  it's easier for client to parse the config. Since currently configs are
  all defined in snake case we'll keep that instead of using camel case
  like the rest of V2.
  
  Sample output by testing using the app server test client:
  ```
  {
  <   "id": "f28449f4-b015-459b-b07b-eef06980165d",
  <   "result": {
  <     "config": {
  <       "approvalPolicy": null,
  <       "compactPrompt": null,
  <       "developerInstructions": null,
  <       "features": {
  <         "experimental_use_rmcp_client": true
  <       },
  <       "forcedChatgptWorkspaceId": null,
  <       "forcedLoginMethod": null,
  <       "instructions": null,
  <       "model": "gpt-5.1-codex-max",
  <       "modelAutoCompactTokenLimit": null,
  <       "modelContextWindow": null,
  <       "modelProvider": null,
  <       "modelReasoningEffort": null,
  <       "modelReasoningSummary": null,
  <       "modelVerbosity": null,
  <       "model_providers": {
  <         "local": {
  <           "base_url": "http://localhost:8061/api/codex",
  <           "env_http_headers": {
  <             "ChatGPT-Account-ID": "OPENAI_ACCOUNT_ID"
  <           },
  <           "env_key": "CHATGPT_TOKEN_STAGING",
  <           "name": "local",
  <           "wire_api": "responses"
  <         }
  <       },
  <       "model_reasoning_effort": "medium",
  <       "notice": {
  <         "hide_gpt-5.1-codex-max_migration_prompt": true,
  <         "hide_gpt5_1_migration_prompt": true
  <       },
  <       "profile": null,
  <       "profiles": {},
  <       "projects": {
  <         "/Users/celia/code": {
  <           "trust_level": "trusted"
  <         },
  <         "/Users/celia/code/codex": {
  <           "trust_level": "trusted"
  <         },
  <         "/Users/celia/code/openai": {
  <           "trust_level": "trusted"
  <         }
  <       },
  <       "reviewModel": null,
  <       "sandboxMode": null,
  <       "sandboxWorkspaceWrite": null,
  <       "tools": {
  <         "viewImage": null,
  <         "webSearch": null
  <       }
  <     },
  <     "origins": {
  <       "features.experimental_use_rmcp_client": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.base_url": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.env_http_headers.ChatGPT-Account-ID": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.env_key": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.name": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_providers.local.wire_api": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "model_reasoning_effort": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "notice.hide_gpt-5.1-codex-max_migration_prompt": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "notice.hide_gpt5_1_migration_prompt": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code/codex.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "projects./Users/celia/code/openai.trust_level": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       },
  <       "tools.web_search": {
  <         "name": "user",
  <         "source": "/Users/celia/.codex/config.toml",
  <         "version": "sha256:a1d8eaedb5d9db5dfdfa69f30fa9df2efec66bb4dd46aa67f149fcc67cd0711c"
  <       }
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-12-10 21:35:31 +00:00
  bfb4d5710b
• Removed experimental "command risk assessment" feature (#7799)

  This experimental feature received lukewarm reception during internal
  testing. Removing from the code base.

  Eric Traut · 2025-12-10 09:48:11 -08:00
  c4af707e09
• chore: rework unified exec events (#7775)
  jif-oai · 2025-12-10 10:30:38 +00:00
  0ad54982ae
• feat: support mcp in-session login (#7751)

  ### Summary
  * Added `mcpServer/oauthLogin` in app server for supporting in session
  MCP server login
  * Added `McpServerOauthLoginParams` and `McpServerOauthLoginResponse` to
  support above method with response returning the auth URL for consumer
  to open browser or display accordingly.
  * Added `McpServerOauthLoginCompletedNotification` which the app server
  would emit on MCP server login success or failure (i.e. timeout).
  * Refactored rmcp-client oath_login to have the ability on starting a
  auth server which the codex_message_processor uses for in-session auth.

  Shijie Rao · 2025-12-09 17:43:53 -08:00
  893f5261eb
• updating app server types to support execpoilcy amendment (#7747)

  also includes minor refactor merging `ApprovalDecision` with
  `CommandExecutionRequestAcceptSettings`

  zhao-oai · 2025-12-08 13:56:22 -08:00
  0a32acaa2d
• fix: taking plan type from usage endpoint instead of thru auth token (#7610)

  pull plan type from the usage endpoint, persist it in session state /
  tui state, and propagate through rate limit snapshots

  zhao-oai · 2025-12-04 23:34:13 -08:00
  b8eab7ce90
• fix(app-server): add will_retry to ErrorNotification (#7611)

  VSCE renders `codex/event/stream_error` (automatically retried, e.g.
  `"Reconnecting... 1/n"`) and `codex/event/error` (terminal errors)
  differently, so add `will_retry` on ErrorNotification to indicate this.

  Owen Lin · 2025-12-04 21:48:37 +00:00
  e8f6d65899
• fix(app-server): add duration_ms to McpToolCallItem (#7605)

  Seems like a nice field to have, and also VSCE does render this one.

  Owen Lin · 2025-12-04 13:45:07 -08:00
  342c084cc3
• [app-server] make file_path for config optional (#7560)

  When we are writing to config using `config/value/write` or
  `config/batchWrite`, it always require a `config/read` before it right
  now in order to get the correct file path to write to. make this
  optional so we read from the default user config file if this is not
  passed in.

  Celia Chen · 2025-12-04 03:08:18 +00:00
  3e6cd5660c
• [app-server] fix: add thread_id to turn/plan/updated (#7553)

  Realized we're missing this while migrating VSCE.

  Owen Lin · 2025-12-03 15:00:07 -08:00
  231ff19ca2
• Migrate model preset (#7542)

  - Introduce `openai_models` in `/core`
  - Move `PRESETS` under it
  - Move `ModelPreset`, `ModelUpgrade`, `ReasoningEffortPreset`,
  `ReasoningEffortPreset`, and `ReasoningEffortPreset` to `protocol`
  - Introduce `Op::ListModels` and `EventMsg::AvailableModels`
  
  Next steps:
  - migrate `app-server` and `tui` to use the introduced Operation

  Ahmed Ibrahim · 2025-12-03 20:30:43 +00:00
  71504325d3
• chore: conversation_id -> thread_id in app-server feedback/upload (#7538)

  Use `thread_id: Option<String>` instead of `conversation_id:
  Option<ConversationId>` to be consistent with the rest of app-server v2
  APIs.

  Owen Lin · 2025-12-03 18:47:35 +00:00
  3ef76ff29d
• chore: delete unused TodoList item from app-server (#7537)

  This item is sent as a turn notification instead: `turn/plan/updated`,
  similar to Turn diffs (which is `turn/diff/updated`).
  
  We treat these concepts as ephemeral compared to Items which are usually
  persisted.

  Owen Lin · 2025-12-03 18:47:12 +00:00
  844de19561
• feat: support list mcp servers in app server (#7505)

  ### Summary
  Added `mcp/servers/list` which is equivalent to `/mcp` slash command in
  CLI for response. This will be used in VSCE MCP settings to show log in
  status, available tools etc.

  Shijie Rao · 2025-12-03 09:51:46 -08:00
  4785344c9c
• fix: remove serde(flatten) annotation for TurnError (#7499)

  The problem with using `serde(flatten)` on Turn status is that it
  conditionally serializes the `error` field, which is not the pattern we
  want in API v2 where all fields on an object should always be returned.
  
  ```
  #[derive(Serialize, Deserialize, Debug, Clone, PartialEq, JsonSchema, TS)]
  #[serde(rename_all = "camelCase")]
  #[ts(export_to = "v2/")]
  pub struct Turn {
      pub id: String,
      /// Only populated on a `thread/resume` response.
      /// For all other responses and notifications returning a Turn,
      /// the items field will be an empty list.
      pub items: Vec<ThreadItem>,
      #[serde(flatten)]
      pub status: TurnStatus,
  }
  
  #[derive(Serialize, Deserialize, Debug, Clone, PartialEq, JsonSchema, TS)]
  #[serde(tag = "status", rename_all = "camelCase")]
  #[ts(tag = "status", export_to = "v2/")]
  pub enum TurnStatus {
      Completed,
      Interrupted,
      Failed { error: TurnError },
      InProgress,
  }
  ```
  
  serializes to:
  ```
  {
    "id": "turn-123",
    "items": [],
    "status": "completed"
  }
  
  {
    "id": "turn-123",
    "items": [],
    "status": "failed",
    "error": {
      "message": "Tool timeout",
      "codexErrorInfo": null
    }
  }
  ```
  
  Instead we want:
  ```
  {
    "id": "turn-123",
    "items": [],
    "status": "completed",
    "error": null
  }
  
  {
    "id": "turn-123",
    "items": [],
    "status": "failed",
    "error": {
      "message": "Tool timeout",
      "codexErrorInfo": null
    }
  }
  ```

  Owen Lin · 2025-12-02 21:39:10 +00:00
  77c457121e
• fix: add ts number annotations for app-server v2 types (#7492)

  These will be more ergonomic to work with in Typescript.

  Owen Lin · 2025-12-02 18:09:41 +00:00
  c2f8c4e9f4
• feat: add one off commands to app-server v2 (#7452)
  jif-oai · 2025-12-02 11:56:09 +00:00
  85e687c74a
• [app-server] fix: emit item/fileChange/outputDelta for file change items (#7399)
  Owen Lin · 2025-12-01 17:52:34 +00:00
  8532876ad8
• [app-server] fix: ensure thread_id and turn_id are on all events (#7408)

  This is an improvement for client-side developer ergonomics by
  simplifying the state the client needs to keep track of.

  Owen Lin · 2025-12-01 08:50:47 -08:00
  44d92675eb
• [app-server] add turn/plan/updated event (#7329)

  transform `EventMsg::PlanDate` to v2 `turn/plan/updated` event. similar
  to `turn/diff/updated`.

  Celia Chen · 2025-11-30 21:09:59 -08:00
  40006808a3
• feat: detached review (#7292)
  jif-oai · 2025-11-28 11:34:57 +00:00
  aaec8abf58
• feat: update process ID for event handling (#7261)
  jif-oai · 2025-11-25 14:21:05 -08:00
  28ff364c3a
• [app-server] add thread/tokenUsage/updated v2 event (#7268)

  the TokenEvent event message becomes `thread/tokenUsage/updated` in v2.
  before & after:
  ```
  < {
  <   "method": "codex/event/token_count",
  <   "params": {
  <     "conversationId": "019ab891-4c55-7790-9670-6c3b48c33281",
  <     "id": "1",
  <     "msg": {
  <       "info": {
  <         "last_token_usage": {
  <           "cached_input_tokens": 3072,
  <           "input_tokens": 5152,
  <           "output_tokens": 16,
  <           "reasoning_output_tokens": 0,
  <           "total_tokens": 5168
  <         },
  <         "model_context_window": 258400,
  <         "total_token_usage": {
  <           "cached_input_tokens": 3072,
  <           "input_tokens": 5152,
  <           "output_tokens": 16,
  <           "reasoning_output_tokens": 0,
  <           "total_tokens": 5168
  <         }
  <       },
  <       "rate_limits": {
  <         "credits": null,
  <         "primary": null,
  <         "secondary": null
  <       },
  <       "type": "token_count"
  <     }
  <   }
  < }
  < {
  <   "method": "thread/tokenUsage/updated",
  <   "params": {
  <     "threadId": "019ab891-4c55-7790-9670-6c3b48c33281",
  <     "tokenUsage": {
  <       "last": {
  <         "cachedInputTokens": 3072,
  <         "inputTokens": 5152,
  <         "outputTokens": 16,
  <         "reasoningOutputTokens": 0,
  <         "totalTokens": 5168
  <       },
  <       "modelContextWindow": 258400,
  <       "total": {
  <         "cachedInputTokens": 3072,
  <         "inputTokens": 5152,
  <         "outputTokens": 16,
  <         "reasoningOutputTokens": 0,
  <         "totalTokens": 5168
  <       }
  <     },
  <     "turnId": "1"
  <   }
  < }
  ```

  Celia Chen · 2025-11-25 19:56:04 +00:00
  401f94ca31
• [app-server] feat: add turn/diff/updated event (#7279)

  This is the V2 version of `EventMsg::TurnDiff`.
  
  I decided to expose this as a `turn/*` notification as opposed to an
  Item to make it more explicit that the diff is accumulated throughout a
  turn (every `apply_patch` call updates the running diff). Also, I don't
  think it's worth persisting this diff as an Item because it can always
  be recomputed from the actual `FileChange` Items.

  Owen Lin · 2025-11-25 16:21:08 +00:00
  caf2749d5b
• feat: add compaction event (#7289)
  jif-oai · 2025-11-25 16:12:14 +00:00
  9ba27cfa0a
• [app-server] feat: add thread_id and turn_id to item and error notifications (#7124)

  Add `thread_id` and `turn_id` to `item/started`, `item/completed`, and
  `error` notifications. Otherwise the client will have a hard time
  knowing which thread & turn (if multiple threads are running in
  parallel) a new item/error is for.
  
  Also add `thread_id` to `turn/started` and `turn/completed`.

  Owen Lin · 2025-11-25 08:05:47 -08:00
  157a16cefa
• feat[app-serve]: config management (#7241)
  jif-oai · 2025-11-25 09:29:38 +00:00
  523b40a129
• [app-server] feat: expose gitInfo/cwd/etc. on Thread (#7060)

  Port the new additions from https://github.com/openai/codex/pull/6337 on
  the legacy API to v2. Mainly need `gitInfo` and `cwd` for VSCE.

  Owen Lin · 2025-11-21 10:37:12 -08:00
  aa4e0d823e
• [app-server] feat: add Declined status for command exec (#7101)

  Add a `Declined` status for when we request an approval from the user
  and the user declines. This allows us to distinguish from commands that
  actually ran, but failed.
  
  This behaves similarly to apply_patch / FileChange, which does the same
  thing.

  Owen Lin · 2025-11-21 09:19:39 -08:00
  2ae1f81d84
• [app-server] update doc with codex error info (#6941)

  Document new codex error info. Also fixed the name from
  `codex_error_code` to `codex_error_info`.

  Celia Chen · 2025-11-21 01:02:37 +00:00
  7e2165f394
• [app-server & core] introduce new codex error code and v2 app-server error events (#6938)

  This PR does two things:
  1. populate a new `codex_error_code` protocol in error events sent from
  core to client;
  2. old v1 core events `codex/event/stream_error` and `codex/event/error`
  will now both become `error`. We also show codex error code for
  turncompleted -> error status.
  
  new events in app server test:
  ```
  < {
  <   "method": "codex/event/stream_error",
  <   "params": {
  <     "conversationId": "019aa34c-0c14-70e0-9706-98520a760d67",
  <     "id": "0",
  <     "msg": {
  <       "codex_error_code": {
  <         "response_stream_disconnected": {
  <           "http_status_code": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5",
  <       "type": "stream_error"
  <     }
  <   }
  < }
  
   {
  <   "method": "error",
  <   "params": {
  <     "error": {
  <       "codexErrorCode": {
  <         "responseStreamDisconnected": {
  <           "httpStatusCode": 401
  <         }
  <       },
  <       "message": "Reconnecting... 2/5"
  <     }
  <   }
  < }
  
  < {
  <   "method": "turn/completed",
  <   "params": {
  <     "turn": {
  <       "error": {
  <         "codexErrorCode": {
  <           "responseTooManyFailedAttempts": {
  <             "httpStatusCode": 401
  <           }
  <         },
  <         "message": "exceeded retry limit, last status: 401 Unauthorized, request id: 9a1b495a1a97ed3e-SJC"
  <       },
  <       "id": "0",
  <       "items": [],
  <       "status": "failed"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-20 23:06:55 +00:00
  9bce050385
• [app-server] feat: v2 apply_patch approval flow (#6760)

  This PR adds the API V2 version of the apply_patch approval flow, which
  centers around `ThreadItem::FileChange`.
  
  This PR wires the new RPC (`item/fileChange/requestApproval`, V2 only)
  and related events (`item/started`, `item/completed` for
  `ThreadItem::FileChange`, which are emitted in both V1 and V2) through
  the app-server
  protocol. The new approval RPC is only sent when the user initiates a
  turn with the new `turn/start` API so we don't break backwards
  compatibility with VSCE.
  
  Similar to https://github.com/openai/codex/pull/6758, the approach I
  took was to make as few changes to the Codex core as possible,
  leveraging existing `EventMsg` core events, and translating those in
  app-server. I did have to add a few additional fields to
  `EventMsg::PatchApplyBegin` and `EventMsg::PatchApplyEnd`, but those
  were fairly lightweight.
  
  However, the `EventMsg`s emitted by core are the following:
  ```
  1) Auto-approved (no request for approval)

  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  2) Approved by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  
  3) Declined by user
  - EventMsg::ApplyPatchApprovalRequest
  - EventMsg::PatchApplyBegin
  - EventMsg::PatchApplyEnd
  ```
  
  For a request triggering an approval, this would result in:
  ```
  item/fileChange/requestApproval
  item/started
  item/completed
  ```
  
  which is different from the `ThreadItem::CommandExecution` flow
  introduced in https://github.com/openai/codex/pull/6758, which does the
  below and is preferable:
  ```
  item/started
  item/commandExecution/requestApproval
  item/completed
  ```
  
  To fix this, we leverage `TurnSummaryStore` on codex_message_processor
  to store a little bit of state, allowing us to fire `item/started` and
  `item/fileChange/requestApproval` whenever we receive the underlying
  `EventMsg::ApplyPatchApprovalRequest`, and no-oping when we receive the
  `EventMsg::PatchApplyBegin` later.
  
  This is much less invasive than modifying the order of EventMsg within
  core (I tried).
  
  The resulting payloads:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "inProgress",
        "type": "fileChange"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/fileChange/requestApproval",
    "params": {
      "grantRoot": null,
      "itemId": "call_Nxnwj7B3YXigfV6Mwh03d686",
      "reason": null,
      "threadId": "019a9e11-8295-7883-a283-779e06502c6f",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "method": "item/completed",
    "params": {
      "item": {
        "changes": [
          {
            "diff": "Hello from Codex!\n",
            "kind": "add",
            "path": "/Users/owen/repos/codex/codex-rs/APPROVAL_DEMO.txt"
          }
        ],
        "id": "call_Nxnwj7B3YXigfV6Mwh03d686",
        "status": "completed",
        "type": "fileChange"
      }
    }
  }
  ```

  Owen Lin · 2025-11-19 20:13:31 -08:00
  d6c30ed25e
• storing credits (#6858)

  Expand the rate-limit cache/TUI: store credit snapshots alongside
  primary and secondary windows, render “Credits” when the backend reports
  they exist (unlimited vs rounded integer balances)

  zhao-oai · 2025-11-19 10:49:35 -08:00
  72af589398
• feat: arcticfox in the wild (#6906)

  <img width="485" height="600" alt="image"
  src="https://github.com/user-attachments/assets/4341740d-dd58-4a3e-b69a-33a3be0606c5"
  />
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Ahmed Ibrahim · 2025-11-19 16:31:06 +00:00
  d5dfba2509
• [app-server] populate thread>turns>items on thread/resume (#6848)

  This PR allows clients to render historical messages when resuming a
  thread via `thread/resume` by reading from the list of `EventMsg`
  payloads loaded from the rollout, and then transforming them into Turns
  and ThreadItems to be returned on the `Thread` object.
  
  This is implemented by leveraging `SessionConfiguredNotification` which
  returns this list of `EventMsg` objects when resuming a conversation,
  and then applying a stateful `ThreadHistoryBuilder` that parses from
  this EventMsg log and transforms it into Turns and ThreadItems.
  
  Note that we only persist a subset of `EventMsg`s in a rollout as
  defined in `policy.rs`, so we lose fidelity whenever we resume a thread
  compared to when we streamed the thread's turns originally. However,
  this behavior is at parity with the legacy API.

  Owen Lin · 2025-11-19 15:58:09 +00:00
  1924500250