83 Commits

• 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
• better name for windows sandbox features (#8077)

  `--enable enable...` is a bad look

  iceweasel-oai · 2025-12-15 10:15:40 -08:00
  b4635ccc07
• 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
• feat: clean config loading and config api (#7924)

  Check the README of the `config_loader` for details

  jif-oai · 2025-12-12 12:01:24 -08:00
  92098d36e8
• feat: use latest disk value for mcp servers status (#7907)

  ### Summary
  Instead of stale in memory config value for listing mcp server statuses,
  we pull the latest disk value.

  Shijie Rao · 2025-12-11 18:56:55 -08:00
  163a7e317e
• [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
• fix: thread/list returning fewer than the requested amount due to filtering CXA-293 (#7509)

  This caused some conversations to not appear when they otherwise should.
  
  Prior to this change, `thread/list`/`list_conversations_common` would:
  - Fetch N conversations from `RolloutRecorder::list_conversations`
  - Then it would filter those (like by the provided `model_providers`)
  - This would make it potentially return less than N items.
  
  With this change:
  - `list_conversations_common` now continues fetching more conversations
  from `RolloutRecorder::list_conversations` until it "fills up" the
  `requested_page_size`.
  - Ultimately this means that clients can rely on getting eg 20
  conversations if they request 20 conversations.

  Javi · 2025-12-10 23:06:32 +00:00
  e2559ab28d
• make model optional in config (#7769)

  - Make Config.model optional and centralize default-selection logic in
  ModelsManager, including a default_model helper (with
  codex-auto-balanced when available) so sessions now carry an explicit
  chosen model separate from the base config.
  - Resolve `model` once in `core` and `tui` from config. Then store the
  state of it on other structs.
  - Move refreshing models to be before resolving the default model

  Ahmed Ibrahim · 2025-12-10 11:19:00 -08:00
  cb9a189857
• refactoring with_escalated_permissions to use SandboxPermissions instead (#7750)

  helpful in the future if we want more granularity for requesting
  escalated permissions:
  e.g when running in readonly sandbox, model can request to escalate to a
  sandbox that allows writes

  zhao-oai · 2025-12-10 17:18:48 +00:00
  e0fb3ca1db
• 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
• Introduce ModelsManager and migrate app-server to use it. (#7552)
  Ahmed Ibrahim · 2025-12-03 17:17:56 -08:00
  00cc00ead8
• 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
• 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
• chore: review everywhere (#7444)
  jif-oai · 2025-12-02 11:26:27 +00:00
  4b78e2ab09
• feat: detached review (#7292)
  jif-oai · 2025-11-28 11:34:57 +00:00
  aaec8abf58
• [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
• [feedback] Add source info into feedback metadata. (#7140)

  Verified the source info is correctly attached based on whether it's cli
  or vscode.

  Matthew Zeng · 2025-11-24 19:05:37 +00:00
  c31663d745
• refactor: inline sandbox type lookup in process_exec_tool_call (#7122)

  `process_exec_tool_call()` was taking `SandboxType` as a param, but in
  practice, the only place it was constructed was in
  `codex_message_processor.rs` where it was derived from the other
  `sandbox_policy` param, so this PR inlines the logic that decides the
  `SandboxType` into `process_exec_tool_call()`.
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/7122).
  * #7112
  * __->__ #7122

  Michael Bolin · 2025-11-21 22:53:05 +00:00
  67975ed33a
• [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
• fix(app-server) remove www warning (#7046)

  ### Summary
  After #7022, we no longer need this warning. We should also clean up the
  schema for the notification, but this is a quick fix to just stop the
  behavior in the VSCE
  
  ## Testing
  - [x] Ran locally

  Dylan Hurd · 2025-11-20 19:18:39 -08:00
  3f73e2c892
• feat: update process_exec_tool_call() to take a cancellation token (#6972)

  This updates `ExecParams` so that instead of taking `timeout_ms:
  Option<u64>`, it now takes a more general cancellation mechanism,
  `ExecExpiration`, which is an enum that includes a
  `Cancellation(tokio_util::sync::CancellationToken)` variant.
  
  If the cancellation token is fired, then `process_exec_tool_call()`
  returns in the same way as if a timeout was exceeded.
  
  This is necessary so that in #6973, we can manage the timeout logic
  external to the `process_exec_tool_call()` because we want to "suspend"
  the timeout when an elicitation from a human user is pending.
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/6972).
  * #7005
  * #6973
  * __->__ #6972

  Michael Bolin · 2025-11-20 16:29:57 -08:00
  f56d1dc8fc
• [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
• fix(app-server) move windows world writable warning (#6916)

  ## Summary
  Move the app-server warning into the process_new_conversation
  
  ## Testing
  - [x] Tested locally

  Dylan Hurd · 2025-11-19 11:24:49 -08:00
  20982d5c6a
• [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
• 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: add more fields to ThreadStartResponse and ThreadResumeResponse (#6847)

  This adds the following fields to `ThreadStartResponse` and
  `ThreadResumeResponse`:
  
  ```rust
      pub model: String,
      pub model_provider: String,
      pub cwd: PathBuf,
      pub approval_policy: AskForApproval,
      pub sandbox: SandboxPolicy,
      pub reasoning_effort: Option<ReasoningEffort>,
  ```
  
  This is important because these fields are optional in
  `ThreadStartParams` and `ThreadResumeParams`, so the caller needs to be
  able to determine what values were ultimately used to start/resume the
  conversation. (Though note that any of these could be changed later
  between turns in the conversation.)
  
  Though to get this information reliably, it must be read from the
  internal `SessionConfiguredEvent` that is created in response to the
  start of a conversation. Because `SessionConfiguredEvent` (as defined in
  `codex-rs/protocol/src/protocol.rs`) did not have all of these fields, a
  number of them had to be added as part of this PR.
  
  Because `SessionConfiguredEvent` is referenced in many tests, test
  instances of `SessionConfiguredEvent` had to be updated, as well, which
  is why this PR touches so many files.

  Michael Bolin · 2025-11-18 21:18:43 -08:00
  a75321a64c
• [app-server] introduce turn/completed v2 event (#6800)

  similar to logic in
  `codex/codex-rs/exec/src/event_processor_with_jsonl_output.rs`.
  translation of v1 -> v2 events:
  `codex/event/task_complete` -> `turn/completed`
  `codex/event/turn_aborted` -> `turn/completed` with `interrupted` status
  `codex/event/error` -> `turn/completed` with `error` status
  
  this PR also makes `items` field in `Turn` optional. For now, we only
  populate it when we resume a thread, and leave it as None for all other
  places until we properly rewrite core to keep track of items.
  
  tested using the codex app server client. example new event:
  ```
  < {
  <   "method": "turn/completed",
  <   "params": {
  <     "turn": {
  <       "id": "0",
  <       "items": [],
  <       "status": "interrupted"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-19 01:55:24 +00:00
  b395dc1be6
• feat: review in app server (#6613)
  jif-oai · 2025-11-18 21:58:54 +00:00
  8ddae8cde3
• nit: app server (#6830)
  jif-oai · 2025-11-18 16:34:13 +00:00
  0eb2e6f9ee
• [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 mcp tool call item started/completed events (#6642)

  this PR does two things:
  1. refactor `apply_bespoke_event_handling` into a separate file as it's
  getting kind of long;
  2. add mcp tool call `item/started` and `item/completed` events. To roll
  out app server events asap we didn't properly migrate mcp core events to
  use TurnItem for mcp tool calls - this will be a follow-up PR.
  
  real events generated in log:
  ```
  {
    "method": "codex/event/mcp_tool_call_end",
    "params": {
      "conversationId": "019a8021-26af-7c20-83db-21ca81e44d68",
      "id": "0",
      "msg": {
        "call_id": "call_7EjRQkD9HnfyMWf7tGrT9FKA",
        "duration": {
          "nanos": 92708,
          "secs": 0
        },
        "invocation": {
          "arguments": {
            "server": ""
          },
          "server": "codex",
          "tool": "list_mcp_resources"
        },
        "result": {
          "Ok": {
            "content": [
              {
                "text": "{\"resources\":[]}",
                "type": "text"
              }
            ],
            "isError": false
          }
        },
        "type": "mcp_tool_call_end"
      }
    }
  }
  
  {
    "method": "item/completed",
    "params": {
      "item": {
        "arguments": {
          "server": ""
        },
        "error": null,
        "id": "call_7EjRQkD9HnfyMWf7tGrT9FKA",
        "result": {
          "content": [
            {
              "text": "{\"resources\":[]}",
              "type": "text"
            }
          ],
          "structuredContent": null
        },
        "server": "codex",
        "status": "completed",
        "tool": "list_mcp_resources",
        "type": "mcpToolCall"
      }
    }
  }
  ```

  Celia Chen · 2025-11-14 08:08:43 -08:00
  526777c9b4
• [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] feat: thread/resume supports history, path, and overrides (#6483)

  This updates `thread/resume` to be at parity with v1's
  `ResumeConversationParams`. Turns out history is useful for codex cloud
  and path is useful for the VSCode extension. And config overrides are
  always useful.

  Owen Lin · 2025-11-12 22:02:43 +00:00
  964220ac94
• [app-server] add item started/completed events for turn items (#6517)

  This one should be quite straightforward, as it's just a translation of
  TurnItem events we already emit to ThreadItem that app-server exposes to
  customers.
  
  To test, cp my change to owen/app_server_test_client and do the
  following:
  ```
  cargo build -p codex-cli
  RUST_LOG=codex_app_server=info CODEX_BIN=target/debug/codex cargo run -p codex-app-server-test-client -- send-message-v2 "hello"
  ```
  
  example event before (still kept there for backward compatibility):
  ```
  {
  <   "method": "codex/event/item_completed",
  <   "params": {
  <     "conversationId": "019a74cc-fad9-7ab3-83a3-f42827b7b074",
  <     "id": "0",
  <     "msg": {
  <       "item": {
  <         "Reasoning": {
  <           "id": "rs_03d183492e07e20a016913a936eb8c81a1a7671a103fee8afc",
  <           "raw_content": [],
  <           "summary_text": [
  <             "Hey! What would you like to work on? I can explore the repo, run specific tests, or implement a change. Let's keep it short and straightforward. There's no need for a lengthy introduction or elaborate planning, just a friendly greeting and an open offer to help. I want to make sure the user feels welcomed and understood right from the start. It's all about keeping the tone friendly and concise!"
  <           ]
  <         }
  <       },
  <       "thread_id": "019a74cc-fad9-7ab3-83a3-f42827b7b074",
  <       "turn_id": "0",
  <       "type": "item_completed"
  <     }
  <   }
  < }
  ```
  
  after (v2):
  ```
  < {
  <   "method": "item/completed",
  <   "params": {
  <     "item": {
  <       "id": "rs_03d183492e07e20a016913a936eb8c81a1a7671a103fee8afc",
  <       "text": "Hey! What would you like to work on? I can explore the repo, run specific tests, or implement a change. Let's keep it short and straightforward. There's no need for a lengthy introduction or elaborate planning, just a friendly greeting and an open offer to help. I want to make sure the user feels welcomed and understood right from the start. It's all about keeping the tone friendly and concise!",
  <       "type": "reasoning"
  <     }
  <   }
  < }
  ```

  Celia Chen · 2025-11-11 22:43:24 +00:00
  e357fc723d
• [hygiene][app-server] have a helper function for duplicate code in turn APIs (#6488)

  turn_start and turn_interrupt have some logic that can be shared. have a
  helper function for it.

  Celia Chen · 2025-11-11 02:44:47 +00:00
  6951872776
• [app-server] feat: expose additional fields on Thread (#6338)

  Add the following fields to Thread:
  
  ```
      pub preview: String,
      pub model_provider: String,
      pub created_at: i64,
  ```
  
  Will prob need another PR once this lands:
  https://github.com/openai/codex/pull/6337

  Owen Lin · 2025-11-07 04:08:45 +00:00
  2030b28083
• [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] Add more session metadata to listConversations (#6337)

  This unlocks a few new product experience for app server consumers

  Gabriel Peal · 2025-11-06 17:13:24 -05:00
  1b8cc8b625
• [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
• feat: support models with single reasoning effort (#6300)
  Thibault Sottiaux · 2025-11-05 23:06:45 -08:00
  667e841d3e
• [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
• [App-server] Implement v2 for account/login/start and account/login/completed (#6183)

  This PR implements `account/login/start` and `account/login/completed`.
  Instead of having separate endpoints for login with chatgpt and api, we
  have a single enum handling different login methods. For sync auth
  methods like sign in with api key, we still send a `completed`
  notification back to be compatible with the async login flow.

  Celia Chen · 2025-11-05 13:52:50 -08:00
  05f0b4f590
• [app-server] feat: v2 Thread APIs (#6214)

  Implements:
  ```
  thread/list
  thread/start
  thread/resume
  thread/archive
  ```
  
  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:
  - `thread/start` and `thread/resume` automatically attaches a
  conversation listener internally, so clients don't have to make a
  separate `AddConversationListener` call like they do today.
  
  For consistency, also updated `model/list` and `feedback/upload` (naming
  conventions, list API params).

  Owen Lin · 2025-11-05 20:28:43 +00:00
  2ab1650d4d
• [app-server] feat: export.rs supports a v2 namespace, initial v2 notifications (#6212)

  **Typescript and JSON schema exports**
  While working on Thread/Turn/Items type definitions, I realize we will
  run into name conflicts between v1 and v2 APIs (e.g. `RateLimitWindow`
  which won't be reusable since v1 uses `RateLimitWindow` from `protocol/`
  which uses snake_case, but we want to expose camelCase everywhere, so
  we'll define a V2 version of that struct that serializes as camelCase).
  
  To set us up for a clean and isolated v2 API, generate types into a
  `v2/` namespace for both typescript and JSON schema.
  - TypeScript: v2 types emit under `out_dir/v2/*.ts`, and root index.ts
  now re-exports them via `export * as v2 from "./v2"`;.
  - JSON Schemas: v2 definitions bundle under `#/definitions/v2/*` rather
  than the root.
  
  The location for the original types (v1 and types pulled from
  `protocol/` and other core crates) haven't changed and are still at the
  root. This is for backwards compatibility: no breaking changes to
  existing usages of v1 APIs and types.
  
  **Notifications**
  While working on export.rs, I:
  - refactored server/client notifications with macros (like we already do
  for methods) so they also get exported (I noticed they weren't being
  exported at all).
  - removed the hardcoded list of types to export as JSON schema by
  leveraging the existing macros instead
  - and took a stab at API V2 notifications. These aren't wired up yet,
  and I expect to iterate on these this week.

  Owen Lin · 2025-11-05 01:02:39 +00:00
  edf4c3f627
• [App-server] v2 for account/updated and account/logout (#6175)

  V2 for `account/updated` and `account/logout` for app server. correspond
  to old `authStatusChange` and `LogoutChatGpt` respectively. Followup PRs
  will make other v2 endpoints call `account/updated` instead of
  `authStatusChange` too.

  Celia Chen · 2025-11-03 22:01:33 -08:00
  d3187dbc17