55 Commits

• feat: refactor CodexAuth so invalid state cannot be represented (#10208)

  Previously, `CodexAuth` was defined as follows:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L39-L46
  
  But if you looked at its constructors, we had creation for
  `AuthMode::ApiKey` where `storage` was built using a nonsensical path
  (`PathBuf::new()`) and `auth_dot_json` was `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L212-L220
  
  By comparison, when `AuthMode::ChatGPT` was used, `api_key` was always
  `None`:
  
  
  https://github.com/openai/codex/blob/d550fbf41afc09d7d7b5ac813aea38de07b2a73f/codex-rs/core/src/auth.rs#L665-L671
  
  https://github.com/openai/codex/pull/10012 took things further because
  it introduced a new `ChatgptAuthTokens` variant to `AuthMode`, which is
  important in when invoking `account/login/start` via the app server, but
  most logic _internal_ to the app server should just reason about two
  `AuthMode` variants: `ApiKey` and `ChatGPT`.
  
  This PR tries to clean things up as follows:
  
  - `LoginAccountParams` and `AuthMode` in `codex-rs/app-server-protocol/`
  both continue to have the `ChatgptAuthTokens` variant, though it is used
  exclusively for the on-the-wire messaging.
  - `codex-rs/core/src/auth.rs` now has its own `AuthMode` enum, which
  only has two variants: `ApiKey` and `ChatGPT`.
  - `CodexAuth` has been changed from a struct to an enum. It is a
  disjoint union where each variant (`ApiKey`, `ChatGpt`, and
  `ChatGptAuthTokens`) have only the associated fields that make sense for
  that variant.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/10208).
  * #10224
  * __->__ #10208

  Michael Bolin · 2026-01-30 09:33:23 -08:00
  377ab0c77c
• 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
• chore(app-server): document AuthMode (#10191)

  Explain what this is and what it's used for.

  Owen Lin · 2026-01-29 16:48:15 -08:00
  c6e1288ef1
• 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
• 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
• 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
• [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): thread/read API (#9569)
  Owen Lin · 2026-01-22 12:22:01 -08:00
  80240b3b67
• 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
• 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: 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
• 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: 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(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
• [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
• 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
• 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
• 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
• 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] 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
• [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
• feat[app-serve]: config management (#7241)
  jif-oai · 2025-11-25 09:29:38 +00:00
  523b40a129
• [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
• 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
• chore(app-server) world-writable windows notification (#6880)

  ## Summary
  On app-server startup, detect whether the experimental sandbox is
  enabled, and send a notification .
  
  **Note**
  New conversations will not respect the feature because we [ignore cli
  overrides in
  NewConversation](https://github.com/openai/codex/blob/a75321a64c990275ed4368bf26a5334c9ddfa0a7/codex-rs/app-server/src/codex_message_processor.rs#L1237-L1252).
  However, this should be okay, since we don't actually use config for
  this, we use a [global
  variable](https://github.com/openai/codex/blob/87cce88f4865685a863e143e0fad4cf5ea542e62/codex-rs/core/src/safety.rs#L105-L110).
  We should carefully unwind this setup at some point.
  
  
  ## Testing
  - [ ] In progress: testing locally
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Dylan Hurd · 2025-11-19 11:19:34 +00:00
  44c747837a
• fix: typos in model picker (#6859)

  # 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 · 2025-11-19 06:29:02 +00:00
  793063070b
• feat: review in app server (#6613)
  jif-oai · 2025-11-18 21:58:54 +00:00
  8ddae8cde3
• Update defaults to gpt-5.1 (#6652)

  ## Summary
  - update documentation, example configs, and automation defaults to
  reference gpt-5.1 / gpt-5.1-codex
  - bump the CLI and core configuration defaults, model presets, and error
  messaging to the new models while keeping the model-family/tool coverage
  for legacy slugs
  - refresh tests, fixtures, and TUI snapshots so they expect the upgraded
  defaults
  
  ## Testing
  - `cargo test -p codex-core
  config::tests::test_precedence_fixture_with_gpt5_profile`
  
  
  ------
  [Codex
  Task](https://chatgpt.com/codex/tasks/task_i_6916c5b3c2b08321ace04ee38604fc6b)

  Ahmed Ibrahim · 2025-11-17 17:40:11 -08:00
  ddcc60a085
• [app-server] feat: add v2 command execution approval flow (#6758)

  This PR adds the API V2 version of the command‑execution approval flow
  for the shell tool.
  
  This PR wires the new RPC (`item/commandExecution/requestApproval`, V2
  only) and related events (`item/started`, `item/completed`, and
  `item/commandExecution/delta`, 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.
  
  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 additional fields to
  `EventMsg::ExecCommandEndEvent` to capture the command's input so that
  app-server can statelessly transform these events to a
  `ThreadItem::CommandExecution` item for the `item/completed` event.
  
  Once we stabilize the API and it's complete enough for our partners, we
  can work on migrating the core to be aware of command execution items as
  a first-class concept.
  
  **Note**: We'll need followup work to make sure these APIs work for the
  unified exec tool, but will wait til that's stable and landed before
  doing a pass on app-server.
  
  Example payloads below:
  ```
  {
    "method": "item/started",
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": null,
        "exitCode": null,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "inProgress",
        "type": "commandExecution"
      }
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "method": "item/commandExecution/requestApproval",
    "params": {
      "itemId": "call_lNWWsbXl1e47qNaYjFRs0dyU",
      "parsedCmd": [
        {
          "cmd": "touch /tmp/should-trigger-approval",
          "type": "unknown"
        }
      ],
      "reason": "Need to create file in /tmp which is outside workspace sandbox",
      "risk": null,
      "threadId": "019a93e8-0a52-7fe3-9808-b6bc40c0989a",
      "turnId": "1"
    }
  }
  ```
  
  ```
  {
    "id": 0,
    "result": {
      "acceptSettings": {
        "forSession": false
      },
      "decision": "accept"
    }
  }
  ```
  
  ```
  {
    "params": {
      "item": {
        "aggregatedOutput": null,
        "command": "/bin/zsh -lc 'touch /tmp/should-trigger-approval'",
        "cwd": "/Users/owen/repos/codex/codex-rs",
        "durationMs": 224,
        "exitCode": 0,
        "id": "call_lNWWsbXl1e47qNaYjFRs0dyU",
        "parsedCmd": [
          {
            "cmd": "touch /tmp/should-trigger-approval",
            "type": "unknown"
          }
        ],
        "status": "completed",
        "type": "commandExecution"
      }
    }
  }
  ```

  Owen Lin · 2025-11-18 00:23:54 +00:00
  cecbd5b021
• [App-server] add new v2 events:item/reasoning/delta, item/agentMessage/delta & item/reasoning/summaryPartAdded (#6559)

  core event to app server event mapping:
  1. `codex/event/reasoning_content_delta` ->
  `item/reasoning/summaryTextDelta`.
  2. `codex/event/reasoning_raw_content_delta` ->
  `item/reasoning/textDelta`
  3. `codex/event/agent_message_content_delta` →
  `item/agentMessage/delta`.
  4. `codex/event/agent_reasoning_section_break` ->
  `item/reasoning/summaryPartAdded`.
  
  Also added a change in core to pass down content index, summary index
  and item id from events.
  
  Tested with the `git checkout owen/app_server_test_client && cargo run
  -p codex-app-server-test-client -- send-message-v2 "hello"` and verified
  that new events are emitted correctly.

  Celia Chen · 2025-11-14 00:25:01 +00:00
  b8ec97c0ef
• [app-server] update macro to make renaming methods less boilerplate-y (#6470)

  We already do this for notification definitions and it's really nice.
  
  Verified there are no changes to actual exported files by diff'ing
  before and after this change.

  Owen Lin · 2025-11-10 15:15:08 -08:00
  3838d6739c
• [app-server] chore: move initialize out of deprecated API section (#6468)

  Self-explanatory - `initialize` is not a deprecated API and works
  equally well with the v2 APIs.

  Owen Lin · 2025-11-10 20:24:36 +00:00
  2ac49fea58
• [App-server] Implement account/read endpoint (#6336)

  This PR does two things:
  1. add a new function in core that maps the core-internal plan type to
  the external plan type;
  2. implement account/read that get account status (v2 of
  `getAuthStatus`).

  Celia Chen · 2025-11-06 19:43:13 -08:00
  e84e39940b
• [app-server] feat: v2 Turn APIs (#6216)

  Implements:
  ```
  turn/start
  turn/interrupt
  ```
  
  along with their integration tests. These are relatively light wrappers
  around the existing core logic, and changes to core logic are minimal.
  
  However, an improvement made for developer ergonomics:
  - `turn/start` replaces both `SendUserMessage` (no turn overrides) and
  `SendUserTurn` (can override model, approval policy, etc.)

  Owen Lin · 2025-11-06 16:36:36 +00:00
  6582554926
• [App-server] Add account/login/cancel v2 endpoint (#6288)

  Add `account/login/cancel` v2 endpoint for auth. this is similar
  implementation to `cancelLoginChatgpt` v1 endpoint.

  Celia Chen · 2025-11-06 01:13:55 +00:00
  229d18f4d2