18 Commits

• Chore: add cmd related info to exec approval request (#9659)

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

  Shijie Rao · 2026-01-21 23:58:53 -08:00
  a4cb97ba5a
• Persist text elements through TUI input and history (#9393)

  Continuation of breaking up this PR
  https://github.com/openai/codex/pull/9116
  
  ## Summary
  - Thread user text element ranges through TUI/TUI2 input, submission,
  queueing, and history so placeholders survive resume/edit flows.
  - Preserve local image attachments alongside text elements and rehydrate
  placeholders when restoring drafts.
  - Keep model-facing content shapes clean by attaching UI metadata only
  to user input/events (no API content changes).
  
  ## Key Changes
  - TUI/TUI2 composer now captures text element ranges, trims them with
  text edits, and restores them when submission is suppressed.
  - User history cells render styled spans for text elements and keep
  local image paths for future rehydration.
  - Initial chat widget bootstraps accept empty `initial_text_elements` to
  keep initialization uniform.
  - Protocol/core helpers updated to tolerate the new InputText field
  shape without changing payloads sent to the API.

  charley-oai · 2026-01-19 23:49:34 -08:00
  eb90e20c0b
• Add text element metadata to protocol, app server, and core (#9331)

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

  charley-oai · 2026-01-15 17:26:41 -08:00
  1fa8350ae7
• Add text element metadata to types (#9235)

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

  charley-oai · 2026-01-14 16:41:50 -08:00
  4a9c2bcc5a
• renaming: task to turn (#8963)
  jif-oai · 2026-01-09 17:31:17 +00:00
  1aed01e99f
• fix: implement 'Allow this session' for apply_patch approvals (#8451)

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

  Owen Lin · 2026-01-07 20:11:12 +00:00
  66450f0445
• 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
• [app-server] fix config loading for conversations (#8765)

  Currently we don't load config properly for app server conversations.
  see:
  https://linear.app/openai/issue/CODEX-3956/config-flags-not-respected-in-codex-app-server.
  This PR fixes that by respecting the config passed in.
  
  Tested by running `cargo build -p codex-cli &&
  RUST_LOG=codex_app_server=debug CODEX_BIN=target/debug/codex cargo run
  -p codex-app-server-test-client -- \
  --config
  model_providers.mock_provider.base_url=\"http://localhost:4010/v2\" \
      --config model_provider=\"mock_provider\" \
      --config model_providers.mock_provider.name="hello" \
      send-message-v2 "hello"`
  and verified that the mock_provider is called instead of default
  provider.
  
  #closes
  https://linear.app/openai/issue/CODEX-3956/config-flags-not-respected-in-codex-app-server
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Celia Chen · 2026-01-06 22:02:17 +00:00
  11d4f3f45e
• chore: add model/list call to app-server-test-client (#8331)

  Allows us to run `cargo run -p codex-app-server-test-client --
  model-list` to return the list of models over app-server.

  Owen Lin · 2026-01-06 17:50:17 +00:00
  cab7136fb3
• 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
• 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: 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
• [app-server-test-client] add send-followup-v2 (#7271)

  Add a new endpoint that allows us to test multi-turn behavior.
  
  Tested with running:
  ```
  RUST_LOG=codex_app_server=debug CODEX_BIN=target/debug/codex \
        cargo run -p codex-app-server-test-client -- \
        send-follow-up-v2 "hello" "and now a follow-up question"
  ```

  Celia Chen · 2025-11-25 08:04:27 +00:00
  0dd822264a
• [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
• [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
• [app-server-test-client] feat: auto approve command (#6852)
  Owen Lin · 2025-11-18 15:25:02 -08:00
  b3a824ae3c
• feat: add app-server-test-client crate for internal use (#5391)

  For app-server development it's been helpful to be able to trigger some
  test flows end-to-end and print the JSON-RPC messages sent between
  client and server.

  Owen Lin · 2025-11-14 12:39:58 -08:00
  c3951e505d