393 Commits

• 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
• Use model metadata for Fast Mode status (#16949)

  Fast Mode status was still tied to one model name in the TUI and
  model-list plumbing. This changes the model metadata shape so a model
  can advertise additional speed tiers, carries that field through the
  app-server model list, and uses it to decide when to show Fast Mode
  status.
  
  For people using Codex, the behavior is intended to stay the same for
  existing models. Fast Mode still requires the existing signed-in /
  feature-gated path; the difference is that the UI can now recognize any
  model the model list marks as Fast-capable, instead of requiring a new
  client-side slug check.

  pash-openai · 2026-04-07 17:55:40 -07:00
  80ebc80be5
• Add WebRTC transport to realtime start (#16960)

  Adds WebRTC startup to the experimental app-server
  `thread/realtime/start` method with an optional transport enum. The
  websocket path remains the default; WebRTC offers create the realtime
  session through the shared start flow and emit the answer SDP via
  `thread/realtime/sdp`.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-04-07 15:43:38 -07:00
  fb3dcfde1d
• fix(app-server) revert null instructions changes (#17047)
  Dylan Hurd · 2026-04-07 15:18:34 -07:00
  6c36e7d688
• [app-server-protocol] introduce generic ServerResponse for app-server-protocol (#17044)

  - introduces `ServerResponse` as the symmetrical typed response union to
  `ServerRequest` for app-server-protocol
  - enables scalable event stream ingestion for use cases such as
  analytics, particularly for tools/approvals
  - no runtime behavior changes, protocol/schema plumbing only
  - mirrors #15921

  rhan-oai · 2026-04-07 14:50:27 -07:00
  f480b98984
• app-server: Move watch_id to request of fs/watch (#17026)

  It's easier for clients to maintain watchers if they define the watch
  id, so move it into the request.
  It's not used yet, so should be a safe change.

  Ruslan Nigmatullin · 2026-04-07 11:22:28 -07:00
  8a13f82204
• [mcp] Support MCP Apps part 2 - Add meta to mcp tool call result. (#16465)

  - [x] Add meta to mcp tool call result.

  Matthew Zeng · 2026-04-07 11:10:21 -07:00
  252d79f5eb
• Honor null thread instructions (#16964)

  - Treat explicit null thread instructions as a blank-slate override
  while preserving omitted-field fallback behavior.
  - Preserve null through rollout resume/fork and keep explicit empty
  strings distinct.
  - Add app-server v2 start/fork coverage for the tri-state instruction
  params.

  Ahmed Ibrahim · 2026-04-07 04:10:19 +00:00
  24c598e8a9
• [codex] Add danger-full-access denylist-only network mode (#16946)

  ## Summary
  
  This adds `experimental_network.danger_full_access_denylist_only` for
  orgs that want yolo / danger-full-access sessions to keep full network
  access while still enforcing centrally managed deny rules.
  
  When the flag is true and the session sandbox is `danger-full-access`,
  the network proxy starts with:
  
  - domain allowlist set to `*`
  - managed domain `deny` entries enforced
  - upstream proxy use allowed
  - all Unix sockets allowed
  - local/private binding allowed
  
  Caveat: the denylist is best effort only. In yolo / danger-full-access
  mode, Codex or the model can use an allowed socket or other
  local/private network path to bypass the proxy denylist, so this should
  not be treated as a hard security boundary.
  
  The flag is intentionally scoped to `SandboxPolicy::DangerFullAccess`.
  Read-only and workspace-write modes keep the existing managed/user
  allowlist, denylist, Unix socket, and local-binding behavior. This does
  not enable the non-loopback proxy listener setting; that still requires
  its own explicit config.
  
  This also threads the new field through config requirements parsing,
  app-server protocol/schema output, config API mapping, and the TUI debug
  config output.
  
  ## How to use
  
  Add the flag under `[experimental_network]` in the network policy config
  that is delivered to Codex. The setting is not under `[permissions]`.
  
  ```toml
  [experimental_network]
  enabled = true
  danger_full_access_denylist_only = true
  
  [experimental_network.domains]
  "blocked.example.com" = "deny"
  "*.blocked.example.com" = "deny"
  ```
  
  With that configuration, yolo / danger-full-access sessions get broad
  network access except for the managed denied domains above. The denylist
  remains a best-effort proxy policy because the session may still use
  allowed sockets to bypass it. Other sandbox modes do not get the
  wildcard domain allowlist or the socket/local-binding relaxations from
  this flag.
  
  ## Verification
  
  - `cargo test -p codex-config network_requirements`
  - `cargo test -p codex-core network_proxy_spec`
  - `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 write-app-server-schema`
  - `just fmt`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-tui`
  - `just fix -p codex-core -p codex-config`
  - `git diff --check`
  - `cargo clean`

  viyatb-oai · 2026-04-06 19:38:51 -07:00
  9d13d29acd
• [mcp] Support MCP Apps part 1. (#16082)

  - [x] Add `mcpResource/read` method to read mcp resource.

  Matthew Zeng · 2026-04-06 19:17:14 -07:00
  5fe9ef06ce
• Speed up /mcp inventory listing (#16831)

  Addresses #16244
  
  This was a performance regression introduced when we moved the TUI on
  top of the app server API.
  
  Problem: `/mcp` rebuilt a full MCP inventory through
  `mcpServerStatus/list`, including resources and resource templates that
  made the TUI wait on slow inventory probes.
  
  Solution: add a lightweight `detail` mode to `mcpServerStatus/list`,
  have `/mcp` request tools-and-auth only, and cover the fast path with
  app-server and TUI tests.
  
  Testing: Confirmed slow (multi-second) response prior to change and
  immediate response after change.
  
  I considered two options:
  1. Change the existing `mcpServerStatus/list` API to accept an optional
  "details" parameter so callers can request only a subset of the
  information.
  2. Add a separate `mcpServer/list` API that returns only the servers,
  tools, and auth but omits the resources.
  
  I chose option 1, but option 2 is also a reasonable approach.

  Eric Traut · 2026-04-06 16:27:02 -07:00
  9f737c28dd
• [codex-analytics] add protocol-native turn timestamps (#16638)

  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16638).
  * #16870
  * #16706
  * #16659
  * #16641
  * #16640
  * __->__ #16638

  rhan-oai · 2026-04-06 16:22:59 -07:00
  756c45ec61
• fix(guardian): fix ordering of guardian events (#16462)

  Guardian events were emitted a bit out of order for CommandExecution
  items. This would make it hard for the frontend to render a guardian
  auto-review, which has this payload:
  ```
  pub struct ItemGuardianApprovalReviewStartedNotification {
      pub thread_id: String,
      pub turn_id: String,
      pub target_item_id: String,
      pub review: GuardianApprovalReview,
      // FYI this is no longer a json blob
      pub action: Option<JsonValue>,
  }
  ```
  
  There is a `target_item_id` the auto-approval review is referring to,
  but the actual item had not been emitted yet.
  
  Before this PR:
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`, and if approved...
  - `item/started`
  - `item/completed`
  
  After this PR:
  - `item/started`
  - `item/autoApprovalReview/started`
  - `item/autoApprovalReview/completed`
  - `item/completed`
  
  This lines up much better with existing patterns (i.e. human review in
  `Default mode`, where app-server would send a server request to prompt
  for user approval after `item/started`), and makes it easier for clients
  to render what guardian is actually reviewing.
  
  We do this following a similar pattern as `FileChange` (aka apply patch)
  items, where we create a FileChange item and emit `item/started` if we
  see the apply patch approval request, before the actual apply patch call
  runs.

  Owen Lin · 2026-04-06 19:14:27 +00:00
  bd30bad96f
• feat(requirements): support allowed_approval_reviewers (#16701)

  ## Description
  
  Add requirements.toml support for `allowed_approvals_reviewers =
  ["user", "guardian_subagent"]`, so admins can now restrict the use of
  guardian mode.
  
  Note: If a user sets a reviewer that isn’t allowed by requirements.toml,
  config loading falls back to the first allowed reviewer and emits a
  startup warning.
  
  The table below describes the possible admin controls.
  | Admin intent | `requirements.toml` | User `config.toml` | End result |
  |---|---|---|---|
  | Leave Guardian optional | omit `allowed_approvals_reviewers` or set
  `["user", "guardian_subagent"]` | user chooses `approvals_reviewer =
  "user"` or `"guardian_subagent"` | Guardian off for `user`, on for
  `guardian_subagent` + `approval_policy = "on-request"` |
  | Force Guardian off | `allowed_approvals_reviewers = ["user"]` | any
  user value | Effective reviewer is `user`; Guardian off |
  | Force Guardian on | `allowed_approvals_reviewers =
  ["guardian_subagent"]` and usually `allowed_approval_policies =
  ["on-request"]` | any user reviewer value; user should also have
  `approval_policy = "on-request"` unless policy is forced | Effective
  reviewer is `guardian_subagent`; Guardian on when effective approval
  policy is `on-request` |
  | Allow both, but default to manual if user does nothing |
  `allowed_approvals_reviewers = ["user", "guardian_subagent"]` | omit
  `approvals_reviewer` | Effective reviewer is `user`; Guardian off |
  | Allow both, and user explicitly opts into Guardian |
  `allowed_approvals_reviewers = ["user", "guardian_subagent"]` |
  `approvals_reviewer = "guardian_subagent"` and `approval_policy =
  "on-request"` | Guardian on |
  | Invalid admin config | `allowed_approvals_reviewers = []` | anything |
  Config load error |

  Owen Lin · 2026-04-06 11:11:44 -07:00
  ded559680d
• Fix fork source display in /status (expose forked_from_id in app server) (#16596)

  Addresses #16560
  
  Problem: `/status` stopped showing the source thread id in forked TUI
  sessions after the app-server migration.
  
  Solution: Carry fork source ids through app-server v2 thread data and
  the TUI session adapter, and update TUI fixtures so `/status` matches
  the old TUI behavior.

  Eric Traut · 2026-04-02 14:05:29 -07:00
  9bb7f0a694