407 Commits

• app-server: expose thread permission profiles (#18278)

  ## Why
  
  The `PermissionProfile` migration needs app-server clients to see the
  same constrained permission model that core is using at runtime. Before
  this PR, thread lifecycle responses only exposed the legacy
  `SandboxPolicy` shape, so clients still had to infer active permissions
  from sandbox fields. That makes downstream resume, fork, and override
  flows harder to make `PermissionProfile`-first.
  
  External sandbox policies are intentionally excluded from this canonical
  view. External enforcement cannot be round-tripped as a
  `PermissionProfile`, and exposing a lossy root-write profile would let
  clients accidentally change sandbox semantics if they echo the profile
  back later.
  
  ## What changed
  
  - Adds the app-server v2 `PermissionProfile` wire shape, including
  filesystem permissions and glob scan depth metadata.
  - Adds `PermissionProfileNetworkPermissions` so the profile response
  does not expose active network state through the older
  additional-permissions naming.
  - Returns `permissionProfile` from thread start, resume, and fork
  responses when the active sandbox can be represented as a
  `PermissionProfile`.
  - Keeps legacy `sandbox` in those responses for compatibility and
  documents `permissionProfile` as canonical when present.
  - Makes lifecycle `permissionProfile` nullable and returns `null` for
  `ExternalSandbox` to avoid exposing a lossy profile.
  - Regenerates the app-server JSON schema and TypeScript fixtures.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server
  thread_response_permission_profile_omits_external_sandbox --
  --nocapture`
  - `cargo check --tests -p codex-analytics -p codex-exec -p codex-tui`
  - `just fix -p codex-app-server-protocol -p codex-app-server -p
  codex-analytics -p codex-exec -p codex-tui`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18278).
  * #18279
  * __->__ #18278

  Michael Bolin · 2026-04-21 23:52:56 -07:00
  5eab9ff8ca
• feat: add explicit AgentIdentity auth mode (#18785)

  ## Summary
  
  This PR adds `CodexAuth::AgentIdentity` as an explicit auth mode.
  
  An AgentIdentity auth record is a standalone `auth.json` mode. When
  `AuthManager::auth().await` loads that mode, it registers one
  process-scoped task and stores it in runtime-only state on the auth
  value. Header creation stays synchronous after that because the task is
  initialized before callers receive the auth object.
  
  This PR also removes the old feature flag path. AgentIdentity is
  selected by explicit auth mode, not by a hidden flag or lazy mutation of
  ChatGPT auth records.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Design Decisions
  
  - AgentIdentity is a real auth enum variant because it can be the only
  credential in `auth.json`.
  - The process task is ephemeral runtime state. It is not serialized and
  is not stored in rollout/session data.
  - Account/user metadata needed by existing Codex backend checks lives on
  the AgentIdentity record for now.
  - `is_chatgpt_auth()` remains token-specific.
  - `uses_codex_backend()` is the broader predicate for ChatGPT-token auth
  and AgentIdentity auth.
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. This PR: explicit AgentIdentity auth mode and startup task allocation
  4. https://github.com/openai/codex/pull/18811: migrate Codex backend
  auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-21 22:33:24 -07:00
  69c8913e24
• feat: Support remote plugin list/read. (#18452)

  Add a temporary internal remote_plugin feature flag that merges remote
  marketplaces into plugin/list and routes plugin/read through the remote
  APIs when needed, while keeping pure local marketplaces working as
  before.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-21 18:39:07 -07:00
  a978e411f6
• Add turn-scoped environment selections (#18416)

  ## Summary
  - add experimental turn/start.environments params for per-turn
  environment id + cwd selections
  - pass selections through core protocol ops and resolve them with
  EnvironmentManager before TurnContext creation
  - treat omitted selections as default behavior, empty selections as no
  environment, and non-empty selections as first environment/cwd as the
  turn primary
  
  ## Testing
  - ran `just fmt`
  - ran `just write-app-server-schema`
  - not run: unit tests for this stacked PR
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 17:48:33 -07:00
  1d4cc494c9
• fix: fully revert agent identity runtime wiring (#18757)

  ## Summary
  
  This PR fully reverts the previously merged Agent Identity runtime
  integration from the old stack:
  https://github.com/openai/codex/pull/17387/changes
  
  It removes the Codex-side task lifecycle wiring, rollout/session
  persistence, feature flag plumbing, lazy `auth.json` mutation,
  background task auth paths, and request callsite changes introduced by
  that stack.
  
  This leaves the repo in a clean pre-AgentIdentity integration state so
  the follow-up PRs can reintroduce the pieces in smaller reviewable
  layers.
  
  ## Stack
  
  1. This PR: full revert
  2. https://github.com/openai/codex/pull/18871: move Agent Identity
  business logic into a crate
  3. https://github.com/openai/codex/pull/18785: add explicit
  AgentIdentity auth mode and startup task allocation
  4. https://github.com/openai/codex/pull/18811: migrate auth callsites
  through AuthProvider
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-21 14:30:55 -07:00
  be75785504
• sandboxing: intersect permission profiles semantically (#18275)

  ## Why
  
  Permission approval responses must not be able to grant more access than
  the tool requested. Moving this flow to `PermissionProfile` means the
  comparison must be profile-shaped instead of `SandboxPolicy`-shaped, and
  cwd-relative special paths such as `:cwd` and `:project_roots` must stay
  anchored to the turn that produced the request.
  
  ## What changed
  
  This implements semantic `PermissionProfile` intersection in
  `codex-sandboxing` for file-system and network permissions. The
  intersection accepts narrower path grants, rejects broader grants,
  preserves deny-read carve-outs and glob scan depth, and materializes
  cwd-dependent special-path grants to absolute paths before they can be
  recorded for reuse.
  
  The request-permissions response paths now use that intersection
  consistently. App-server captures the request turn cwd before waiting
  for the client response, includes that cwd in the v2 approval params,
  and core stores the requested profile plus cwd for direct TUI/client
  responses and Guardian decisions before recording turn- or
  session-scoped grants. The TUI app-server bridge now preserves the
  app-server request cwd when converting permission approval params into
  core events.
  
  ## Verification
  
  - `cargo test -p codex-sandboxing intersect_permission_profiles --
  --nocapture`
  - `cargo test -p codex-app-server request_permissions_response --
  --nocapture`
  - `cargo test -p codex-core
  request_permissions_response_materializes_session_cwd_grants_before_recording
  -- --nocapture`
  - `cargo check -p codex-tui --tests`
  - `cargo check --tests`
  - `cargo test -p codex-tui
  app_server_request_permissions_preserves_file_system_permissions`

  Michael Bolin · 2026-04-21 10:23:01 -07:00
  f8562bd47b
• app-server: define device key v2 protocol (#18428)

  ## Why
  
  Clients need a stable app-server protocol surface for enrolling a local
  device key, retrieving its public key, and producing a device-bound
  proof.
  
  The protocol reports `protectionClass` explicitly so clients can
  distinguish hardware-backed keys from an explicitly allowed OS-protected
  fallback. Signing uses a tagged `DeviceKeySignPayload` enum rather than
  arbitrary bytes so each signed statement is auditable at the API
  boundary.
  
  ## What changed
  
  - Added v2 JSON-RPC methods for `device/key/create`,
  `device/key/public`, and `device/key/sign`.
  - Added request/response types for device-key metadata, SPKI public
  keys, protection classes, and ECDSA signatures.
  - Added `DeviceKeyProtectionPolicy` with hardware-only default behavior
  and an explicit `allow_os_protected_nonextractable` option.
  - Added the initial `remoteControlClientConnection` signing payload
  variant.
  - Regenerated JSON Schema and TypeScript fixtures for app-server
  clients.
  
  ## Stack
  
  This is PR 1 of 4 in the device-key app-server stack.
  
  ## Validation
  
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`

  Ruslan Nigmatullin · 2026-04-21 10:08:42 -07:00
  48f82ca7c5
• [tool search] support namespaced deferred dynamic tools (#18413)

  Deferred dynamic tools need to round-trip a namespace so a tool returned
  by `tool_search` can be called through the same registry key that core
  uses for dispatch.
  
  This change adds namespace support for dynamic tool specs/calls,
  persists it through app-server thread state, and routes dynamic tool
  calls by full `ToolName` while still sending the app the leaf tool name.
  Deferred dynamic tools must provide a namespace; non-deferred dynamic
  tools may remain top-level.
  
  It also introduces `LoadableToolSpec` as the shared
  function-or-namespace Responses shape used by both `tool_search` output
  and dynamic tool registration, so dynamic tools use the same wrapping
  logic in both paths.
  
  Validation:
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core tool_search`
  
  ---------
  
  Co-authored-by: Sayan Sisodiya <sayan@openai.com>

  pash-openai · 2026-04-21 14:13:08 +08:00
  dc1a8f2190
• feat(auto-review) Handle request_permissions calls (#18393)

  ## Summary
  When auto-review is enabled, it should handle request_permissions tool.
  We'll need to clean up the UX but I'm planning to do that in a separate
  pass
  
  ## Testing
  - [x] Ran locally
  <img width="893" height="396" alt="Screenshot 2026-04-17 at 1 16 13 PM"
  src="https://github.com/user-attachments/assets/4c045c5f-1138-4c6c-ac6e-2cb6be4514d8"
  />
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-04-20 21:48:57 -07:00
  86535c9901
• Make MCP resource read threadless (#18292)

  ## Summary
  
  Making thread id optional so that we can better cache resources for MCPs
  for connectors since their resource templates is universal and not
  particular to projects.
  
  - Make `mcpServer/resource/read` accept an optional `threadId`
  - Read resources from the current MCP config when no thread is supplied
  - Keep the existing thread-scoped path when `threadId` is present
  - Update the generated schemas, README, and integration coverage
  
  ## Testing
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-mcp`
  - `cargo test -p codex-app-server --test all mcp_resource`
  - `just fix -p codex-mcp`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`

  Matthew Zeng · 2026-04-20 19:59:36 -07:00
  1132ef887c
• protocol: preserve glob scan depth in permission profiles (#18713)

  ## Why
  
  #18274 made `PermissionProfile` the canonical file-system permissions
  shape, but the round-trip from `FileSystemSandboxPolicy` to
  `PermissionProfile` still dropped one piece of policy metadata:
  `glob_scan_max_depth`.
  
  That field is security-relevant for deny-read globs such as `**/*.env`.
  On Linux, bubblewrap sandbox construction uses it to bound unreadable
  glob expansion. If a profile copied from active runtime permissions
  loses this value and is submitted back as an override, the resulting
  `FileSystemSandboxPolicy` can behave differently even though the visible
  permission entries look equivalent.
  
  ## What changed
  
  - Add `glob_scan_max_depth` to protocol `FileSystemPermissions` and
  preserve it when converting to/from `FileSystemSandboxPolicy`.
  - Keep legacy `read`/`write` JSON for simple path-only permissions, but
  force canonical JSON when glob scan depth is present so the metadata is
  not silently dropped.
  - Carry `globScanMaxDepth` through app-server
  `AdditionalFileSystemPermissions`, generated JSON/TypeScript schemas,
  and app-server/TUI conversion call sites.
  - Preserve the metadata through sandboxing permission normalization,
  merging, and intersection.
  - Carry the merged scan depth into the effective
  `FileSystemSandboxPolicy` used for command execution, so bounded
  deny-read globs reach Linux bubblewrap materialization.
  
  ## Verification
  
  - `cargo test -p codex-sandboxing glob_scan -- --nocapture`
  - `cargo test -p codex-sandboxing policy_transforms -- --nocapture`
  - `just fix -p codex-sandboxing`
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18713).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * #18279
  * #18278
  * #18277
  * #18276
  * #18275
  * __->__ #18713

  Michael Bolin · 2026-04-20 19:42:45 -07:00
  3d2f123895
• Wire the PatchUpdated events through app_server (#18289)

  Wires patch_updated events through app_server. These events are parsed
  and streamed while apply_patch is being written by the model. Also adds 500ms of buffering to the patch_updated events in the diff_consumer.
  
  The eventual goal is to use this to display better progress indicators in
  the codex app.

  Akshay Nathan · 2026-04-20 10:44:03 -07:00
  34a3e85fcd
• protocol: canonicalize file system permissions (#18274)

  ## Why
  
  `PermissionProfile` needs stable, canonical file-system semantics before
  it can become the primary runtime permissions abstraction. Without a
  canonical form, callers have to keep re-deriving legacy sandbox maps and
  profile comparisons remain lossy or order-dependent.
  
  ## What changed
  
  This adds canonicalization helpers for `FileSystemPermissions` and
  `PermissionProfile`, expands special paths into explicit sandbox
  entries, and updates permission request/conversion paths to consume
  those canonical entries. It also tightens the legacy bridge so root-wide
  write profiles with narrower carveouts are not silently projected as
  full-disk legacy access.
  
  ## Verification
  
  - `cargo test -p codex-protocol
  root_write_with_read_only_child_is_not_full_disk_write -- --nocapture`
  - `cargo test -p codex-sandboxing permission -- --nocapture`
  - `cargo test -p codex-tui permissions -- --nocapture`

  Michael Bolin · 2026-04-20 09:57:03 -07:00
  dcec516313
• [codex] Add marketplace/remove app-server RPC (#17751)

  ## Summary
  
  Add a new app-server `marketplace/remove` RPC on top of the shared
  marketplace-remove implementation.
  
  This change:
  - adds `MarketplaceRemoveParams` / `MarketplaceRemoveResponse` to the
  app-server protocol
  - wires the new request through `codex_message_processor`
  - reuses the shared core marketplace-remove flow from the stacked
  refactor PR
  - updates generated schema files and adds focused app-server coverage
  
  ## Validation
  
  - `just write-app-server-schema`
  - `just fmt`
  - heavy compile/test coverage deferred to GitHub CI per request

  xli-oai · 2026-04-19 23:22:49 -07:00
  1dc3535e17
• Persist and prewarm agent tasks per thread (#17978)

  ## Summary
  - persist registered agent tasks in the session state update stream so
  the thread can reuse them
  - prewarm task registration once identity registration succeeds, while
  keeping startup failures best-effort
  - isolate the session-side task lifecycle into a dedicated module so
  AgentIdentityManager and RegisteredAgentTask do not leak across as many
  core layers
  
  ## Testing
  - cargo test -p codex-core startup_agent_task_prewarm
  - cargo test -p codex-core
  cached_agent_task_for_current_identity_clears_stale_task
  - cargo test -p codex-core record_initial_history_

  Adrian · 2026-04-19 15:45:28 -07:00
  e5b52a3caa
• [codex] Add owner nudge app-server API (#18220)

  ## Summary
  
  Second PR in the split from #17956. Stacked on #18227.
  
  - adds app-server v2 protocol/schema support for
  `account/sendAddCreditsNudgeEmail`
  - adds the backend-client `send_add_credits_nudge_email` request and
  request body mapping
  - handles the app-server request with auth checks, backend call, and
  cooldown mapping
  - adds the disabled `workspace_owner_usage_nudge` feature flag and
  focused app-server/backend tests
  
  ## Validation
  
  - `cargo test -p codex-backend-client`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server rate_limits`
  - `cargo test -p codex-tui workspace_`
  - `cargo test -p codex-tui status_`
  - `just fmt`
  - `just fix -p codex-backend-client`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`

  richardopenai · 2026-04-17 21:41:57 -07:00
  6b39d0c657
• feat: Budget skill metadata and surface trimming as a warning (#18298)

  Cap the model-visible skills section to a small share of the context
  window, with a fallback character budget, and keep only as many implicit
  skills as fit within that budget.
  
  Emit a non-fatal warning when enabled skills are omitted, and add a new
  app-server warning notification
  
  Record thread-start skill metrics for total enabled skills, kept skills,
  and whether truncation happened
  
  ---------
  
  Co-authored-by: Matthew Zeng <mzeng@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-17 18:11:47 -07:00
  3f7222ec76
• feat: Add remote plugin fields to plugin API (#17277)

  ## Summary
  Update the plugin API for the new remote plugin model.
  
  The mental model is no longer “keep local plugin state in sync with
  remote.” Instead, local and remote plugins are becoming separate
  sources. Remote catalog entries can be shown directly from the remote
  API before installation; after installation they are still downloaded
  into the local cache for execution, but remote installed state will come
  from the API and be held in memory rather than being read from config.
  
  • ## API changes
  - Remove `forceRemoteSync` from `plugin/list`, `plugin/install`, and
  `plugin/uninstall`.
    - Remove `remoteSyncError` from `plugin/list`.
    - Add remote-capable metadata to `plugin/list` / `plugin/read`:
      - nullable `marketplaces[].path`
      - `source: { type: "remote", downloadUrl }`
      - URL asset fields alongside local path fields:
    `composerIconUrl`, `logoUrl`, `screenshotUrls`
    - Make `plugin/read` and `plugin/install` source-compatible:
      - `marketplacePath?: AbsolutePathBuf | null`
      - `remoteMarketplaceName?: string | null`
      - exactly one source is required at runtime

  xl-openai · 2026-04-17 16:47:58 -07:00
  26d9894a27
• [codex] Add cross-repo plugin sources to marketplace manifests (#18017)

  ## Summary
  - add first-class marketplace support for git-backed plugin sources
  - keep the newer marketplace parsing behavior from `main`, including
  alternate manifest locations and string local sources
  - materialize remote plugin sources during install, detail reads, and
  non-curated cache refresh
  - expose git plugin source metadata through the app-server protocol
  
  ## Details
  This teaches the marketplace parser to accept all of the following:
  - local string sources such as `"source": "./plugins/foo"`
  - local object sources such as
  `{"source":"local","path":"./plugins/foo"}`
  - remote repo-root sources such as
  `{"source":"url","url":"https://github.com/org/repo.git"}`
  - remote subdir sources such as
  `{"source":"git-subdir","url":"owner/repo","path":"plugins/foo","ref":"main","sha":"..."}`
  
  It also preserves the newer tolerant behavior from `main`: invalid or
  unsupported plugin entries are skipped instead of breaking the whole
  marketplace.
  
  ## Validation
  - `cargo test -p codex-core plugins::marketplace::tests`
  - `just fix -p codex-core`
  - `just fmt`
  
  ## Notes
  - A full `cargo test -p codex-core` run still hit unrelated existing
  failures in agent and multi-agent tests during this session; the
  marketplace-focused suite passed after the rebase resolution.

  xli-oai · 2026-04-17 15:11:42 -07:00
  0e111e08d0
• [codex] Propagate rate limit reached type (#18227)

  ## Summary
  
  First PR in the split from #17956.
  
  - adds the core/app-server `RateLimitReachedType` shape
  - maps backend `rate_limit_reached_type` into Codex rate-limit snapshots
  - carries the field through app-server notifications/responses and
  generated schemas
  - updates existing constructors/tests for the new optional field
  
  ## Validation
  
  - `cargo test -p codex-backend-client`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server rate_limits`
  - `cargo test -p codex-tui workspace_`
  - `cargo test -p codex-tui status_`
  - `just fmt`
  - `just fix -p codex-backend-client`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`

  richardopenai · 2026-04-17 13:37:25 -07:00
  139fa8b8f2
• Add sorting/backwardsCursor to thread/list and new thread/turns/list api (#17305)

  To improve performance of UI loads from the app, add two main
  improvements:
  1. The `thread/list` api now gets a `sortDirection` request field and a
  `backwardsCursor` to the response, which lets you paginate forwards and
  backwards from a window. This lets you fetch the first few items to
  display immediately while you paginate to fill in history, then can
  paginate "backwards" on future loads to catch up with any changes since
  the last UI load without a full reload of the entire data set.
  2. Added a new `thread/turns/list` api which also has sortDirection and
  backwardsCursor for the same behavior as `thread/list`, allowing you the
  same small-fetch for immediate display followed by background fill-in
  and resync catchup.

  David de Regt · 2026-04-17 11:49:02 -07:00
  eaf78e43f2
• Guardian -> Auto-Review (#18021)

  This PR is a user-facing change for our rebranding of guardian to
  auto-review.

  Won Park · 2026-04-17 09:56:24 -07:00
  af7b8d551c
• Add PermissionRequest hooks support (#17563)

  ## Why
  
  We need `PermissionRequest` hook support!
  
  Also addresses:
  - https://github.com/openai/codex/issues/16301
  - run a script on Hook to do things like play a sound to draw attention
  but actually no-op so user can still approve
  - can omit the `decision` object from output or just have the script
  exit 0 and print nothing
  - https://github.com/openai/codex/issues/15311
    - let the script approve/deny on its own
    - external UI what will run on Hook and relay decision back to codex
  
  
  ## Reviewer Note
  
  There's a lot of plumbing for the new hook, key files to review are:
  - New hook added in `codex-rs/hooks/src/events/permission_request.rs`
  - Wiring for network approvals
  `codex-rs/core/src/tools/network_approval.rs`
  - Wiring for tool orchestrator `codex-rs/core/src/tools/orchestrator.rs`
  - Wiring for execve
  `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs`
  
  ## What
  
  - Wires shell, unified exec, and network approval prompts into the
  `PermissionRequest` hook flow.
  - Lets hooks allow or deny approval prompts; quiet or invalid hooks fall
  back to the normal approval path.
  - Uses `tool_input.description` for user-facing context when it helps:
    - shell / `exec_command`: the request justification, when present
    - network approvals: `network-access <domain>`
  - Uses `tool_name: Bash` for shell, unified exec, and network approval
  permission-request hooks.
  - For network approvals, passes the originating command in
  `tool_input.command` when there is a single owning call; otherwise falls
  back to the synthetic `network-access ...` command.
  
  <details>
  <summary>Example `PermissionRequest` hook input for a shell
  approval</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "rm -f /tmp/example"
    }
  }
  ```
  
  </details>
  
  <details>
  <summary>Example `PermissionRequest` hook input for an escalated
  `exec_command` request</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "cp /tmp/source.json /Users/alice/export/source.json",
      "description": "Need to copy a generated file outside the workspace"
    }
  }
  ```
  
  </details>
  
  <details>
  <summary>Example `PermissionRequest` hook input for a network
  approval</summary>
  
  ```json
  {
    "session_id": "<session-id>",
    "turn_id": "<turn-id>",
    "transcript_path": "/path/to/transcript.jsonl",
    "cwd": "/path/to/cwd",
    "hook_event_name": "PermissionRequest",
    "model": "gpt-5",
    "permission_mode": "default",
    "tool_name": "Bash",
    "tool_input": {
      "command": "curl http://codex-network-test.invalid",
      "description": "network-access http://codex-network-test.invalid"
    }
  }
  ```
  
  </details>
  
  ## Follow-ups
  
  - Implement the `PermissionRequest` semantics for `updatedInput`,
  `updatedPermissions`, `interrupt`, and suggestions /
  `permission_suggestions`
  - Add `PermissionRequest` support for the `request_permissions` tool
  path
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-17 14:45:47 +00:00
  8494e5bd7b
• Sync local plugin imports, async remote imports, refresh caches after… (#18246)

  … import
  
  ## Why
  
  `externalAgentConfig/import` used to spawn plugin imports in the
  background and return immediately. That meant local marketplace imports
  could still be in flight when the caller refreshed plugin state, so
  newly imported plugins would not show up right away.
  
  This change makes local marketplace imports complete before the RPC
  returns, while keeping remote marketplace imports asynchronous so we do
  not block on remote fetches.
  
  ## What changed
  
  - split plugin migration details into local and remote marketplace
  imports based on the external config source
  - import local marketplaces synchronously during
  `externalAgentConfig/import`
  - return pending remote plugin imports to the app-server so it can
  finish them in the background
  - clear the plugin and skills caches before responding to plugin
  imports, and again after background remote imports complete, so the next
  `plugin/list` reloads fresh state
  - keep marketplace source parsing encapsulated behind
  `is_local_marketplace_source(...)` instead of re-exporting the internal
  enum
  - add core and app-server coverage for the synchronous local import path
  and the pending remote import path
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-core` (currently fails an existing unrelated
  test:
  `config_loader::tests::cli_override_can_update_project_local_mcp_server_when_project_is_trusted`)
  - `cargo test` (currently fails existing `codex-app-server` integration
  tests in MCP/skills/thread-start areas, plus the unrelated `codex-core`
  failure above)

  alexsong-oai · 2026-04-17 09:34:55 +00:00
  20b4b80426
• Refactor config loading to use filesystem abstraction (#18209)

  Initial pass propagating FileSystem through config loading.

  pakrym-oai · 2026-04-17 00:51:21 +00:00
  9effa0509f
• fix(app-server): replay token usage after resume and fork (#18023)

  ## Problem
  
  When a user resumed or forked a session, the TUI could render the
  restored thread history immediately, but it did not receive token usage
  until a later model turn emitted a fresh usage event. That left the
  context/status UI blank or stale during the exact window where the user
  expects resumed state to look complete. Core already reconstructed token
  usage from the rollout; the missing behavior was app-server lifecycle
  replay to the client that just attached.
  
  ## Mental model
  
  Token usage has two representations. The rollout is the durable source
  of historical `TokenCount` events, and the core session cache is the
  in-memory snapshot reconstructed from that rollout on resume or fork.
  App-server v2 clients do not read core state directly; they learn about
  usage through `thread/tokenUsage/updated`. The fix keeps those roles
  separate: core exposes the restored `TokenUsageInfo`, and app-server
  sends one targeted notification after a successful `thread/resume` or
  `thread/fork` response when that restored snapshot exists.
  
  This notification is not a new model event. It is a replay of
  already-persisted state for the client that just attached. That
  distinction matters because using the normal core event path here would
  risk duplicating `TokenCount` entries in the rollout and making future
  resumes count historical usage twice.
  
  ## Non-goals
  
  This change does not add a new protocol method or payload shape. It
  reuses the existing v2 `thread/tokenUsage/updated` notification and the
  TUI’s existing handler for that notification.
  
  This change does not alter how token usage is computed, accumulated,
  compacted, or written during turns. It only exposes the token usage that
  resume and fork reconstruction already restored.
  
  This change does not broadcast historical usage replay to every
  subscribed client. The replay is intentionally scoped to the connection
  that requested resume or fork so already-attached clients are not
  surprised by an old usage update while they may be rendering live
  activity.
  
  ## Tradeoffs
  
  Sending the usage notification after the JSON-RPC response preserves a
  clear lifecycle order: the client first receives the thread object, then
  receives restored usage for that thread. The tradeoff is that usage is
  still a notification rather than part of the `thread/resume` or
  `thread/fork` response. That keeps the protocol shape stable and avoids
  duplicating usage fields across response types, but clients must
  continue listening for notifications after receiving the response.
  
  The helper selects the latest non-in-progress turn id for the replayed
  usage notification. This is conservative because restored usage belongs
  to completed persisted accounting, not to newly attached in-flight work.
  The fallback to the last turn preserves a stable wire payload for
  unusual histories, but histories with no meaningful completed turn still
  have a weak attribution story.
  
  ## Architecture
  
  Core already seeds `Session` token state from the last persisted rollout
  `TokenCount` during `InitialHistory::Resumed` and
  `InitialHistory::Forked`. The new core accessor exposes the complete
  `TokenUsageInfo` through `CodexThread` without giving app-server direct
  session mutation authority.
  
  App-server calls that accessor from three lifecycle paths: cold
  `thread/resume`, running-thread resume/rejoin, and `thread/fork`. In
  each path, the server sends the normal response first, then calls a
  shared helper that converts core usage into
  `ThreadTokenUsageUpdatedNotification` and sends it only to the
  requesting connection.
  
  The tests build fake rollouts with a user turn plus a persisted token
  usage event. They then exercise `thread/resume` and `thread/fork`
  without starting another model turn, proving that restored usage arrives
  before any next-turn token event could be produced.
  
  ## Observability
  
  The primary debug path is the app-server JSON-RPC stream. After
  `thread/resume` or `thread/fork`, a client should see the response
  followed by `thread/tokenUsage/updated` when the source rollout includes
  token usage. If the notification is absent, check whether the rollout
  contains an `event_msg` payload of type `token_count`, whether core
  reconstruction seeded `Session::token_usage_info`, and whether the
  connection stayed attached long enough to receive the targeted
  notification.
  
  The notification is sent through the existing
  `OutgoingMessageSender::send_server_notification_to_connections` path,
  so existing app-server tracing around server notifications still
  applies. Because this is a replay, not a model turn event, debugging
  should start at the resume/fork handlers rather than the turn event
  translation in `bespoke_event_handling`.
  
  ## Tests
  
  The focused regression coverage is `cargo test -p codex-app-server
  emits_restored_token_usage`, which covers both resume and fork. The core
  reconstruction guard is `cargo test -p codex-core
  record_initial_history_seeds_token_info_from_rollout`.
  
  Formatting and lint/fix passes were run with `just fmt`, `just fix -p
  codex-core`, and `just fix -p codex-app-server`. Full crate test runs
  surfaced pre-existing unrelated failures in command execution and plugin
  marketplace tests; the new token usage tests passed in focused runs and
  within the app-server suite before the unrelated command execution
  failure.

  Felipe Coury · 2026-04-16 17:29:34 -03:00
  ec8d4bfc77
• Add codex_hook_run analytics event (#17996)

  # Why
  Add product analytics for hook handler executions so we can understand
  which hooks are running, where they came from, and whether they
  completed, failed, stopped, or blocked work.
  
  # What
  - add the new `codex_hook_run` analytics event and payload plumbing in
  `codex-rs/analytics`
  - emit hook-run analytics from the shared hook completion path in
  `codex-rs/core`
  - classify hook source from the loaded hook path as `system`, `user`,
  `project`, or `unknown`
  
  ```
  {
    "event_type": "codex_hook_run",
    "event_params": {
      "thread_id": "string",
      "turn_id": "string",
      "model_slug": "string",
      "hook_name": "string, // any HookEventName
      "hook_source": "system | user | project | unknown",
      "status": "completed | failed | stopped | blocked"
    }
  }
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-16 19:43:16 +00:00
  8720b7bdce
• [codex][mcp] Add resource uri meta to tool call item. (#17831)

  - [x] Add resource uri meta to tool call item so that the app-server
  client can start prefetching resources immediately without loading mcp
  server status.

  Matthew Zeng · 2026-04-16 05:09:17 +00:00
  224dad41ac
• feat: add endpoint to delete memories (#17913)
  jif-oai · 2026-04-15 10:35:06 +01:00
  7579d5ad75
• support plugins in external agent config migration (#17855)
  alexsong-oai · 2026-04-14 19:39:10 -07:00
  ca650561d6
• Spread AbsolutePathBuf (#17792)

  Mechanical change to promote absolute paths through code.

  pakrym-oai · 2026-04-14 14:26:10 -07:00
  dd1321d11b
• fix: Revert danger-full-access denylist-only mode (#17732)

  ## Summary
  
  - Reverts openai/codex#16946 and removes the danger-full-access
  denylist-only network mode.
  - Removes the corresponding config requirements, app-server
  protocol/schema, config API, TUI debug output, and network proxy
  behavior.
  - Drops stale tests that depended on the reverted mode while preserving
  newer managed allowlist-only coverage.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `just fmt`
  - `cargo test -p codex-config network_requirements`
  - `cargo test -p codex-core network_proxy_spec`
  - `cargo test -p codex-core
  managed_network_proxy_decider_survives_full_access_start`
  - `cargo test -p codex-app-server map_requirements_toml_to_api`
  - `cargo test -p codex-tui debug_config_output`
  - `cargo test -p codex-app-server-protocol`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-tui`
  - `git diff --cached --check`
  
  Not run: full workspace `cargo test` (repo instructions ask for
  confirmation before that broader run).

  viyatb-oai · 2026-04-14 09:50:14 -07:00
  81c0bcc921
• Add realtime output modality and transcript events (#17701)

  - Add outputModality to thread/realtime/start and wire text/audio output
  selection through app-server, core, API, and TUI.\n- Rename the realtime
  transcript delta notification and add a separate transcript done
  notification that forwards final text from item done without correlating
  it with deltas.

  Ahmed Ibrahim · 2026-04-14 00:13:13 -07:00
  2f6fc7c137
• [codex] Refactor marketplace add into shared core flow (#17717)

  ## Summary
  
  Move `codex marketplace add` onto a shared core implementation so the
  CLI and app-server path can use one source of truth.
  
  This change:
  - adds shared marketplace-add orchestration in `codex-core`
  - switches the CLI command to call that shared implementation
  - removes duplicated CLI-only marketplace add helpers
  - preserves focused parser and add-path coverage while moving the shared
  behavior into core tests
  
  ## Why
  
  The new `marketplace/add` RPC should reuse the same underlying
  marketplace-add flow as the CLI. This refactor lands that consolidation
  first so the follow-up app-server PR can be mostly protocol and handler
  wiring.
  
  ## Validation
  
  - `cargo test -p codex-core marketplace_add`
  - `cargo test -p codex-cli marketplace_cmd`
  - `just fix -p codex-core`
  - `just fix -p codex-cli`
  - `just fmt`

  xli-oai · 2026-04-13 20:37:11 -07:00
  ff584c5a4b
• [codex] Add symlink flag to fs metadata (#17719)

  Add `is_symlink` to FsMetadata struct.

  pakrym-oai · 2026-04-13 17:46:56 -07:00
  f3cbe3d385
• Add turn item injection API (#17703)

  ## Summary
  - Add `turn/inject_items` app-server v2 request support for appending
  raw Responses API items to a loaded thread history without starting a
  turn.
  - Generate JSON schema and TypeScript protocol artifacts for the new
  params and empty response.
  - Document the new endpoint and include a request/response example.
  - Preserve compatibility with the typo alias `turn/injet_items` while
  returning the canonical method name.
  
  ## Testing
  - Not run (not requested)

  pakrym-oai · 2026-04-13 16:11:05 -07:00
  d4be06adea
• feat: disable memory endpoint (#17626)
  jif-oai · 2026-04-13 18:29:49 +01:00
  46a266cd6a
• Use AbsolutePathBuf in skill loading and codex_home (#17407)

  Helps with FS migration later

  pakrym-oai · 2026-04-13 10:26:51 -07:00
  ac82443d07
• Expose instruction sources (AGENTS.md) via app server (#17506)

  Addresses #17498
  
  Problem: The TUI derived /status instruction source paths from the local
  client environment, which could show stale <none> output or incorrect
  paths when connected to a remote app server.
  
  Solution: Add an app-server v2 instructionSources snapshot to thread
  start/resume/fork responses, default it to an empty list when older
  servers omit it, and render TUI /status from that server-provided
  session data.
  
  Additional context: The app-server field is intentionally named
  instructionSources rather than AGENTS.md-specific terminology because
  the loaded instruction sources can include global instructions, project
  AGENTS.md files, AGENTS.override.md, user-defined instruction files, and
  future dynamic sources.

  Eric Traut · 2026-04-12 15:50:12 -07:00
  46ab9974dc
• Pass turn id with feedback uploads (#17314)

  ## Summary
  - Add an optional `tags` dictionary to feedback upload params.
  - Capture the active app-server turn id in the TUI and submit it as
  `tags.turn_id` with `/feedback` uploads.
  - Merge client-provided feedback tags into Sentry feedback tags while
  preserving reserved system fields like `thread_id`, `classification`,
  `cli_version`, `session_source`, and `reason`.
  
  ## Behavior / impact
  Existing feedback upload callers remain compatible because `tags` is
  optional and nullable. The wire shape is still a normal JSON object /
  TypeScript dictionary, so adding future feedback metadata will not
  require a new top-level protocol field each time. This change only adds
  feedback metadata for Codex CLI/TUI uploads; it does not affect existing
  pipelines, DAGs, exports, or downstream consumers unless they choose to
  read the new `turn_id` feedback tag.
  
  ## Tests
  - `cargo fmt -- --config imports_granularity=Item` passed; stable
  rustfmt warned that `imports_granularity` is nightly-only.
  - `cargo run -p codex-app-server-protocol --bin write_schema_fixtures`
  - `cargo test -p codex-feedback
  upload_tags_include_client_tags_and_preserve_reserved_fields`
  - `cargo test -p codex-app-server-protocol
  schema_fixtures_match_generated`
  - `cargo test -p codex-tui build_feedback_upload_params`
  - `cargo test -p codex-tui
  live_app_server_turn_started_sets_feedback_turn_id`
  - `cargo check -p codex-app-server --tests`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  ningyi-oai · 2026-04-11 00:23:50 -07:00
  be13f03c39
• [mcp] Support MCP Apps part 3 - Add mcp tool call support. (#17364)

  - [x] Add a new app-server method so that MCP Apps can call their own
  MCP server directly.

  Matthew Zeng · 2026-04-11 04:39:19 +00:00
  b7139a7e8f
• representing guardian review timeouts in protocol types (#17381)

  ## Summary
  
  - Add `TimedOut` to Guardian/review carrier types:
    - `ReviewDecision::TimedOut`
    - `GuardianAssessmentStatus::TimedOut`
    - app-server v2 `GuardianApprovalReviewStatus::TimedOut`
  - Regenerate app-server JSON/TypeScript schemas for the new wire shape.
  - Wire the new status through core/app-server/TUI mappings with
  conservative fail-closed handling.
  - Keep `TimedOut` non-user-selectable in the approval UI.
  
  **Does not change runtime behavior yet; emitting `TimeOut` and
  parent-model timeout messaging will come in followup PRs**

  Won Park · 2026-04-10 20:02:33 -07:00
  37aac89a6d
• Revert "Option to Notify Workspace Owner When Usage Limit is Reached" (#17391)

  Reverts openai/codex#16969
  
  #sev3-2026-04-10-accountscheckversion-500s-for-openai-workspace-7300

  Shijie Rao · 2026-04-10 23:33:13 +00:00
  930e5adb7e
• fix(guardian, app-server): introduce guardian review ids (#17298)

  ## Description
  
  This PR introduces `review_id` as the stable identifier for guardian
  reviews and exposes it in app-server `item/autoApprovalReview/started`
  and `item/autoApprovalReview/completed` events.
  
  Internally, guardian rejection state is now keyed by `review_id` instead
  of the reviewed tool item ID. `target_item_id` is still included when a
  review maps to a concrete thread item, but it is no longer overloaded as
  the review lifecycle identifier.
  
  ## Motivation
  
  We'd like to give users the ability to preempt a guardian review while
  it's running (approve or decline).
  
  However, we can't implement the API that allows the user to override a
  running guardian review because we didn't have a unique `review_id` per
  guardian review. Using `target_item_id` is not correct since:
  - with execve reviews, there can be multiple execve calls (and therefore
  guardian reviews) per shell command
  - with network policy reviews, there is no target item ID
  
  The PR that actually implements user overrides will use `review_id` as
  the stable identifier.

  Owen Lin · 2026-04-10 16:21:02 -07:00
  a3be74143a
• Support clear SessionStart source (#17073)

  ## Motivation
  
  The `SessionStart` hook already receives `startup` and `resume` sources,
  but sessions created from `/clear` previously looked like normal startup
  sessions. This makes it impossible for hook authors to distinguish
  between these with the matcher.
  
  ## Summary
  
  - Add `InitialHistory::Cleared` so `/clear`-created sessions can be
  distinguished from ordinary startup sessions.
  - Add `SessionStartSource::Clear` and wire it through core, app-server
  thread start params, and TUI clear-session flow.
  - Update app-server protocol schemas, generated TypeScript, docs, and
  related tests.
  
  
  https://github.com/user-attachments/assets/9cae3cb4-41c7-4d06-b34f-966252442e5c

  Abhinav · 2026-04-10 16:05:21 -07:00
  7999b0f60f
• Option to Notify Workspace Owner When Usage Limit is Reached (#16969)

  ## Summary
  - Replace the manual `/notify-owner` flow with an inline confirmation
  prompt when a usage-based workspace member hits a credits-depleted
  limit.
  - Fetch the current workspace role from the live ChatGPT
  `accounts/check/v4-2023-04-27` endpoint so owner/member behavior matches
  the desktop and web clients.
  - Keep owner, member, and spend-cap messaging distinct so we only offer
  the owner nudge when the workspace is actually out of credits.
  
  ## What Changed
  - `backend-client`
  - Added a typed fetch for the current account role from
  `accounts/check`.
    - Mapped backend role values into a Rust workspace-role enum.
  - `app-server` and protocol
    - Added `workspaceRole` to `account/read` and `account/updated`.
  - Derived `isWorkspaceOwner` from the live role, with a fallback to the
  cached token claim when the role fetch is unavailable.
  - `tui`
    - Removed the explicit `/notify-owner` slash command.
  - When a member is blocked because the workspace is out of credits, the
  error now prompts:
  - `Your workspace is out of credits. Request more from your workspace
  owner? [y/N]`
    - Choosing `y` sends the existing owner-notification request.
  - Choosing `n`, pressing `Esc`, or accepting the default selection
  dismisses the prompt without sending anything.
  - Selection popups now honor explicit item shortcuts, which is how the
  `y` / `n` interaction is wired.
  
  ## Reviewer Notes
  - The main behavior change is scoped to usage-based workspace members
  whose workspace credits are depleted.
  - Spend-cap reached should not show the owner-notification prompt.
  - Owners and admins should continue to see `/usage` guidance instead of
  the member prompt.
  - The live role fetch is best-effort; if it fails, we fall back to the
  existing token-derived ownership signal.
  
  ## Testing
  - Manual verification
    - Workspace owner does not see the member prompt.
  - Workspace member with depleted credits sees the confirmation prompt
  and can send the nudge with `y`.
  - Workspace member with spend cap reached does not see the
  owner-notification prompt.
  
  ### Workspace member out of usage
  
  https://github.com/user-attachments/assets/341ac396-eff4-4a7f-bf0c-60660becbea1
  
  ### Workspace owner
  <img width="1728" height="1086" alt="Screenshot 2026-04-09 at 11 48
  22 AM"
  src="https://github.com/user-attachments/assets/06262a45-e3fc-4cc4-8326-1cbedad46ed6"
  />

  richardopenai · 2026-04-09 21:15:17 -07:00
  9f2a585153
• Forward app-server turn clientMetadata to Responses (#16009)

  ## Summary
  App-server v2 already receives turn-scoped `clientMetadata`, but the
  Rust app-server was dropping it before the outbound Responses request.
  This change keeps the fix lightweight by threading that metadata through
  the existing turn-metadata path rather than inventing a new transport.
  
  ## What we're trying to do and why
  We want turn-scoped metadata from the app-server protocol layer,
  especially fields like Hermes/GAAS run IDs, to survive all the way to
  the actual Responses API request so it is visible in downstream
  websocket request logging and analytics.
  
  The specific bug was:
  - app-server protocol uses camelCase `clientMetadata`
  - Responses transport already has an existing turn metadata carrier:
  `x-codex-turn-metadata`
  - websocket transport already rewrites that header into
  `request.request_body.client_metadata["x-codex-turn-metadata"]`
  - but the Rust app-server never parsed or stored `clientMetadata`, so
  nothing from the app-server request was making it into that existing
  path
  
  This PR fixes that without adding a new header or a second metadata
  channel.
  
  ## How we did it
  ### Protocol surface
  - Add optional `clientMetadata` to v2 `TurnStartParams` and
  `TurnSteerParams`
  - Regenerate the JSON schema / TypeScript fixtures
  - Update app-server docs to describe the field and its behavior
  
  ### Runtime plumbing
  - Add a dedicated core op for app-server user input carrying turn-scoped
  metadata: `Op::UserInputWithClientMetadata`
  - Wire `turn/start` and `turn/steer` through that op / signature path
  instead of dropping the metadata at the message-processor boundary
  - Store the metadata in `TurnMetadataState`
  
  ### Transport behavior
  - Reuse the existing serialized `x-codex-turn-metadata` payload
  - Merge the new app-server `clientMetadata` into that JSON additively
  - Do **not** replace built-in reserved fields already present in the
  turn metadata payload
  - Keep websocket behavior unchanged at the outer shape level: it still
  sends only `client_metadata["x-codex-turn-metadata"]`, but that JSON
  string now contains the merged fields
  - Keep HTTP fallback behavior unchanged except that the existing
  `x-codex-turn-metadata` header now includes the merged fields too
  
  ### Request shape before / after
  Before, a websocket `response.create` looked like:
  ```json
  {
    "type": "response.create",
    "client_metadata": {
      "x-codex-turn-metadata": "{\"session_id\":\"...\",\"turn_id\":\"...\"}"
    }
  }
  ```
  Even if the app-server caller supplied `clientMetadata`, it was not
  represented there.
  
  After, the same request shape is preserved, but the serialized payload
  now includes the new turn-scoped fields:
  ```json
  {
    "type": "response.create",
    "client_metadata": {
      "x-codex-turn-metadata": "{\"session_id\":\"...\",\"turn_id\":\"...\",\"fiber_run_id\":\"fiber-start-123\",\"origin\":\"gaas\"}"
    }
  }
  ```
  
  ## Validation
  ### Targeted tests added / updated
  - protocol round-trip coverage for `clientMetadata` on `turn/start` and
  `turn/steer`
  - protocol round-trip coverage for `Op::UserInputWithClientMetadata`
  - `TurnMetadataState` merge test proving client metadata is added
  without overwriting reserved built-in fields
  - websocket request-shape test proving outbound `response.create`
  contains merged metadata inside
  `client_metadata["x-codex-turn-metadata"]`
  - app-server integration tests proving:
  - `turn/start` forwards `clientMetadata` into the outbound Responses
  request path
    - websocket warmup + real turn request both behave correctly
    - `turn/steer` updates the follow-up request metadata
  
  ### Commands run
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-core
  turn_metadata_state_merges_client_metadata_without_replacing_reserved_fields
  --lib`
  - `cargo test -p codex-core --test all
  responses_websocket_preserves_custom_turn_metadata_fields`
  - `cargo test -p codex-app-server --test all client_metadata`
  - `cargo test -p codex-app-server --test all
  turn_start_forwards_client_metadata_to_responses_websocket_request_body_v2
  -- --nocapture`
  - `just fmt`
  - `just fix -p codex-core -p codex-protocol -p codex-app-server-protocol
  -p codex-app-server`
  - `just fix -p codex-exec -p codex-tui-app-server`
  - `just argument-comment-lint`
  
  ### Full suite note
  `cargo test` in `codex-rs` still fails in:
  -
  `suite::v2::turn_interrupt::turn_interrupt_resolves_pending_command_approval_request`
  
  I verified that same failure on a clean detached `HEAD` worktree with an
  isolated `CARGO_TARGET_DIR`, so it is not caused by this patch.

  neil-oai · 2026-04-09 11:52:37 -07:00
  a92a5085bd
• Add realtime voice selection (#17176)

  - Add realtime voice selection for realtime/start.
  - Expose the supported v1/v2 voice lists and cover explicit, configured,
  default, and invalid voice paths.

  Ahmed Ibrahim · 2026-04-08 20:19:15 -07:00
  2f9090be62
• Move default realtime prompt into core (#17165)

  - Adds a core-owned realtime backend prompt template and preparation
  path.
  - Makes omitted realtime start prompts use the core default, while null
  or empty prompts intentionally send empty instructions.
  - Covers the core realtime path and app-server v2 path with integration
  coverage.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-08 19:34:40 -07:00
  4c2a1ae31b
• Update guardian output schema (#17061)

  ## Summary
  - Update guardian output schema to separate risk, authorization,
  outcome, and rationale.
  - Feed guardian rationale into rejection messages.
  - Split the guardian policy into template and tenant-config sections.
  
  ## Validation
  - `cargo test -p codex-core mcp_tool_call`
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED INSTA_UPDATE=always cargo test
  -p codex-core guardian::`
  
  ---------
  
  Co-authored-by: Owen Lin <owen@openai.com>

  maja-openai · 2026-04-08 15:47:29 -07:00
  dcbc91fd39