870 Commits

• Support MCP tools in hooks (#18385)

  ## Summary
  
  Lifecycle hooks currently treat `PreToolUse`, `PostToolUse`, and
  `PermissionRequest` as Bash-only flows
  - hook schema constrains `tool_name` to `Bash`
  - hook input assumes a command-shaped `tool_input`
  - core hook dispatch path passes only shell command strings
  
  That means hooks cannot target MCP tools even though MCP tool names are
  model-visible and stable
  
  This change generalizes those hook paths so they can match and receive
  payloads for MCP tools while preserving the existing Bash behavior.
  
  ## Reviewer Notes
  
  I think these are the key files
  - `codex-rs/core/src/tools/handlers/mcp.rs`
  - `codex-rs/core/src/mcp_tool_call.rs`
  
  Otherwise the changes across apply_patch, shell, and unified_exec are
  mainly to rewire everything to be `tool_input` based instead of just
  `command` so that it'll make sense for MCP tools.
  
  ## Changes
  
  - Allow `PreToolUse`, `PostToolUse`, and `PermissionRequest` hook inputs
  to carry arbitrary `tool_name` and `tool_input` values instead of
  hard-coding `Bash` and command-only payloads.
  - Add MCP hook payload support through `McpHandler`, using the
  model-visible tool name from `ToolInvocation` and the raw MCP arguments
  as `tool_input`.
  - Include MCP tool responses in `PostToolUse` by serializing
  `McpToolOutput` into the hook response payload.
  - Run `PermissionRequest` hooks for MCP approval requests after
  remembered approval checks and before falling back to user-facing MCP
  elicitation.
  - Preserve exact matching for literal hook matchers like `Bash` and
  `mcp__memory__create_entities`, while keeping regex matcher support for
  patterns like `mcp__memory__.*` and `mcp__.*__write.*`.
  
  ---------
  
  Co-authored-by: Andrei Eternal <eternal@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-23 07:33:57 +00:00
  305825abd9
• app-server: include filesystem entries in permission requests (#19086)

  ## Why
  
  `item/permissions/requestApproval` sends a requested permission profile
  to app-server clients. The core profile already stores filesystem
  permissions as `entries`, but the v2 compatibility conversion used the
  legacy `read`/`write` projection whenever possible and left `entries`
  unset.
  
  That made the request ambiguous for clients that consume the canonical
  v2 shape: `permissions.fileSystem.entries` was missing even though
  filesystem access was being requested. A client that rendered or echoed
  grants from `entries` could treat the request as having no filesystem
  permission entries, then return an empty or incomplete grant. The
  app-server intersects responses with the original request, so omitted
  filesystem permissions are denied.
  
  ## What Changed
  
  - Populate `AdditionalFileSystemPermissions.entries` when converting
  legacy read/write roots for request permission payloads, while
  preserving `read` and `write` for compatibility.
  - Mark `read` and `write` as transitional schema fields in the generated
  app-server schema.
  - Add regression coverage for the v2 conversion, the app-server
  `item/permissions/requestApproval` round trip, and TUI app-server
  approval conversion expectations.
  - Refresh generated JSON and TypeScript schema fixtures.
  
  ## Verification
  
  - `just fmt`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server request_permissions_round_trip`
  - `cargo test -p codex-tui
  converts_request_permissions_into_granted_permissions`
  - `cargo test -p codex-tui
  resolves_permissions_and_user_input_through_app_server_request_id`

  Michael Bolin · 2026-04-23 00:21:59 -07:00
  8bc667b07b
• Clarify cloud requirements error messages (#19078)

  ## Why
  The current cloud-requirements failures say `workspace-managed config`,
  which is ambiguous and can read like it refers to local managed config
  such as `managed_config.toml`.
  
  This code path only applies to cloud requirements, so the user-facing
  message should name that source directly.
  
  ## What changed
  - Updated the load failure in
  [`codex-rs/cloud-requirements/src/lib.rs`](https://github.com/openai/codex/blob/46e704d1f93054daa9a3b5a9100333c540c81d50/codex-rs/cloud-requirements/src/lib.rs)
  to say `failed to load cloud requirements (workspace-managed policies)`.
  - Updated the parse failure in the same file to use the same `cloud
  requirements (workspace-managed policies)` terminology.
  - Kept `workspace-managed` hyphenated because it is used as a compound
  modifier.
  - Updated the matching assertion in
  [`codex-rs/app-server/src/codex_message_processor.rs`](https://github.com/openai/codex/blob/46e704d1f93054daa9a3b5a9100333c540c81d50/codex-rs/app-server/src/codex_message_processor.rs).
  - Reused `CLOUD_REQUIREMENTS_LOAD_FAILED_MESSAGE` in the
  `codex-cloud-requirements` test where the test is asserting that
  crate-local contract directly.
  
  ## Testing
  `cargo test -p codex-cloud-requirements`

  Gav Verma · 2026-04-22 23:07:08 -07:00
  2ef2d675d6
• Use remote plugin IDs for detail reads and enlarge list pages (#19079)

  1. For remote plugin use plugin id (plugin name) directly for read
  plugin details;
  2. Request up to 200 remote plugins per directory list page.

  xl-openai · 2026-04-22 22:50:20 -07:00
  fb6308cf64
• app-server: accept command permission profiles (#18283)

  ## Why
  
  `command/exec` is another app-server entry point that can run under
  caller-provided permissions. It needs to accept `PermissionProfile`
  directly so command execution is not left behind on `SandboxPolicy`
  while thread APIs move forward.
  
  Command-level profiles also need to preserve the semantics clients
  expect from profile-relative paths. `:cwd` and cwd-relative deny globs
  should be anchored to the resolved command cwd for a command-specific
  profile, while configured deny-read restrictions such as `**/*.env =
  none` still need to be enforced because they can come from config or
  requirements rather than the command override itself.
  
  ## What Changed
  
  This adds `permissionProfile` to `CommandExecParams`, rejects requests
  that combine it with `sandboxPolicy`, and converts accepted profiles
  into the runtime filesystem/network permissions used for command
  execution.
  
  When a command supplies a profile, the app-server resolves that profile
  against the command cwd instead of the thread/server cwd. It also
  preserves configured deny-read entries and `globScanMaxDepth` on the
  effective filesystem policy so one-off command overrides cannot drop
  those read protections. The PR also updates app-server docs/schema
  fixtures and adds command-exec coverage for accepted, rejected,
  cwd-scoped, and deny-read-preserving profile paths.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  command_exec_permission_profile_cwd_uses_command_cwd`
  - `cargo test -p codex-app-server
  command_profile_preserves_configured_deny_read_restrictions`
  - `cargo test -p codex-app-server
  command_exec_accepts_permission_profile`
  - `cargo test -p codex-app-server
  command_exec_rejects_sandbox_policy_with_permission_profile`
  - `just fix -p codex-app-server`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18283).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * __->__ #18283

  Michael Bolin · 2026-04-22 22:33:16 -07:00
  9d824cf4b4
• Add safety check notification and error handling (#19055)

  Adds a new app-server notification that fires when a user account has
  been flagged for potential safety reasons.

  Eric Traut · 2026-04-22 22:24:12 -07:00
  bbff4ee61a
• codex: support hooks in config.toml and requirements.toml (#18893)

  ## Summary
  
  Support the existing hooks schema in inline TOML so hooks can be
  configured from both `config.toml` and enterprise-managed
  `requirements.toml` without requiring a separate `hooks.json` payload.
  
  This gives enterprise admins a way to ship managed hook policy through
  the existing requirements channel while still leaving script delivery to
  MDM or other device-management tooling, and it keeps `hooks.json`
  working unchanged for existing users.
  
  This also lays the groundwork for follow-on managed filtering work such
  as #15937, while continuing to respect project trust gating from #14718.
  It does **not** implement `allow_managed_hooks_only` itself.
  
  NOTE: yes, it's a bit unfortunate that the toml isn't formatted as
  closely as normal to our default styling. This is because we're trying
  to stay compatible with the spec for plugins/hooks that we'll need to
  support & the main usecase here is embedding into requirements.toml
  
  ## What changed
  
  - moved the shared hook serde model out of `codex-rs/hooks` into
  `codex-rs/config` so the same schema can power `hooks.json`, inline
  `config.toml` hooks, and managed `requirements.toml` hooks
  - added `hooks` support to both `ConfigToml` and
  `ConfigRequirementsToml`, including requirements-side `managed_dir` /
  `windows_managed_dir`
  - treated requirements-managed hooks as one constrained value via
  `Constrained`, so managed hook policy is merged atomically and cannot
  drift across requirement sources
  - updated hook discovery to load requirements-managed hooks first, then
  per-layer `hooks.json`, then per-layer inline TOML hooks, with a warning
  when a single layer defines both representations
  - threaded managed hook metadata through discovered handlers and exposed
  requirements hooks in app-server responses, generated schemas, and
  `/debug-config`
  - added hook/config coverage in `codex-rs/config`, `codex-rs/hooks`,
  `codex-rs/core/src/config_loader/tests.rs`, and
  `codex-rs/core/tests/suite/hooks.rs`
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-app-server config_api`
  
  ## Documentation
  
  Companion updates are needed in the developers website repo for:
  
  - the hooks guide
  - the config reference, sample, basic, and advanced pages
  - the enterprise managed configuration guide
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  Andrei Eternal · 2026-04-22 21:20:09 -07:00
  2b2de3f38b
• feat(request-permissions) approve with strict review (#19050)

  ## Summary
  Allow the user to approve a request_permissions_tool request with the
  condition that all commands in the rest of the turn are reviewed by
  guardian, regardless of sandbox status.
  
  ## Testing
  - [x] Added unit tests
  - [x] Ran locally

  Dylan Hurd · 2026-04-23 01:56:32 +00:00
  5e71da1424
• Fix relative stdio MCP cwd fallback (#19031)
  Matthew Zeng · 2026-04-22 17:52:17 -07:00
  8f0a92c1e5
• Rename approvals reviewer variant to auto-review (#19056)

  ## Why
  
  `approvals_reviewer` now uses `auto_review` as the canonical config/API
  value after #18504, but the Rust enum variant and nearby helper/test
  names still used `GuardianSubagent` / guardian approval wording. That
  made follow-up code and reviews confusing even though the external value
  had already moved to Auto-review.
  
  ## What changed
  
  - Renamed `ApprovalsReviewer::GuardianSubagent` to
  `ApprovalsReviewer::AutoReview`.
  - Updated protocol, app-server, config, core, TUI, exec, and analytics
  test callsites.
  - Renamed nearby helper/test names from guardian approval wording to
  Auto-review wording where they refer to the approvals reviewer mode.
  - Preserved wire compatibility:
    - `auto_review` remains the canonical serialized value.
    - `guardian_subagent` remains accepted as a legacy alias.
  
  This intentionally does not rename the `[features].guardian_approval`
  key, `Feature::GuardianApproval`, `core/src/guardian`, analytics event
  names, or app-server Guardian review event types.
  
  ## Verification
  
  - `cargo test -p codex-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-app-server-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent`
  - `cargo test -p codex-config approvals_reviewer`
  - `cargo test -p codex-tui update_feature_flags`
  - `cargo test -p codex-core permissions_instructions`
  - `cargo test -p codex-tui permissions_selection`

  Won Park · 2026-04-22 17:22:35 -07:00
  83ec1eb5d6
• Rebrand approvals reviewer config to auto-review (#18504)

  ### Why
  
  Auto-review is the user-facing name for the approvals reviewer, but the
  config/API value still exposed the old `guardian_subagent` name. That
  made new configs and generated schemas point users at Guardian
  terminology even though the intended product surface is Auto-review.
  
  This PR updates the external `approvals_reviewer` value while preserving
  compatibility for existing configs and clients.
  
  ### What changed
  
  - Makes `auto_review` the canonical serialized value for
  `approvals_reviewer`.
  - Keeps `guardian_subagent` accepted as a legacy alias.
  - Keeps `user` accepted and serialized as `user`.
  - Updates generated config and app-server schemas so
  `approvals_reviewer` includes:
    - `user`
    - `auto_review`
    - `guardian_subagent`
  - Updates app-server README docs for the reviewer value.
  - Updates analytics and config requirements tests for the canonical
  auto_review value.
  
  
  ### Compatibility
  
  Existing configs and API payloads using:
  
  ```toml
  approvals_reviewer = "guardian_subagent"
  ```
  
  continue to load and map to the Auto-review reviewer behavior. 
  
  New serialization emits: 
  ```toml
  approvals_reviewer = "auto_review" 
  ```
  
  This PR intentionally does not rename the [features].guardian_approval
  key or broad internal Guardian symbols. Those are split out for a
  follow-up PR to keep this migration small and avoid touching large
  TUI/internal surfaces.
  
  **Verification**
  cargo test -p codex-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent
  cargo test -p codex-app-server-protocol
  approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent

  Won Park · 2026-04-22 15:45:35 -07:00
  46142c3cb0
• app-server: accept permission profile overrides (#18279)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions shape shared
  by core and app-server. After app-server responses expose the active
  profile, clients need to be able to send that same shape back when
  starting, resuming, forking, or overriding a turn instead of translating
  through the legacy `sandbox`/`sandboxPolicy` shorthands.
  
  This still needs to preserve the existing requirements/platform
  enforcement model. A profile-shaped request can be downgraded or
  rejected by constraints, but the server should keep the user's
  elevated-access intent for project trust decisions. Turn-level profile
  overrides also need to retain existing read protections, including
  deny-read entries and bounded glob-scan metadata, so a permission
  override cannot accidentally drop configured protections such as
  `**/*.env = deny`.
  
  ## What changed
  
  - Adds optional `permissionProfile` request fields to `thread/start`,
  `thread/resume`, `thread/fork`, and `turn/start`.
  - Rejects ambiguous requests that specify both `permissionProfile` and
  the legacy `sandbox`/`sandboxPolicy` fields, including running-thread
  resume requests.
  - Converts profile-shaped overrides into core runtime filesystem/network
  permissions while continuing to derive the constrained legacy sandbox
  projection used by existing execution paths.
  - Preserves project-trust intent for profile overrides that are
  equivalent to workspace-write or full-access sandbox requests.
  - Preserves existing deny-read entries and `globScanMaxDepth` when
  applying turn-level `permissionProfile` overrides.
  - Updates app-server docs plus generated JSON/TypeScript schema fixtures
  and regression coverage.
  
  ## Verification
  
  - `cargo test -p codex-app-server-protocol schema_fixtures`
  - `cargo test -p codex-core
  session_configuration_apply_permission_profile_preserves_existing_deny_read_entries`
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18279).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * __->__ #18279

  Michael Bolin · 2026-04-22 13:34:33 -07:00
  18a26d7bbc
• feat(auto-review) short-circuit (#18890)

  ## Summary
  Short circuit the convo if auto-review hits too many denials
  
  ## Testing
  - [x] Added unit tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Dylan Hurd · 2026-04-22 20:34:15 +00:00
  ed4def8286
• feat: Fairly trim skill descriptions within context budget (#18925)

  Preserve skill name/path entries whenever possible and trim descriptions
  first, using round-robin character allocation so short descriptions do
  not waste budget.

  xl-openai · 2026-04-22 12:33:29 -07:00
  b77791c228
• Add plumbing to approve stored Auto-Review denials (#18955)

  ## Summary
  
  This adds the structural plumbing needed for an app-server client to
  approve a previously denied Guardian review and carry that approval
  context into the next model turn.
  
  This PR does not add the actual `/auto-review-denials` tool 
  
  ## What Changed
  
  - Added app-server v2 RPC `thread/approveGuardianDeniedAction`.
  - Added generated JSON schema and TypeScript fixtures for
  `ThreadApproveGuardianDeniedAction*`.
  - Added core `Op::ApproveGuardianDeniedAction`.
  - Added a core handler that validates the event is a denied Guardian
  assessment and injects a developer message containing the stored denial
  event JSON.
  - Queues the approval context for the next turn if there is no active
  turn yet.
  - Added the TUI app-server bridge so `Op::ApproveGuardianDeniedAction {
  event }` is routed to the app-server request.
  
  ## What This Does Not Do
  
  - Does not add `/auto-review-denials`.
  - Does not add chat widget recent-denial state.
  - Does not add popup/list UI.
  - Does not add a product-facing denial lookup/store.
  - Does not change where Guardian denials are originally emitted or
  persisted.
  
  ## Verification
  
  - `cargo test -p codex-tui thread_approve_guardian_denied_action`

  Won Park · 2026-04-22 10:38:19 -07:00
  11e5af53c4
• chore: prep memories for AB (#18973)
  jif-oai · 2026-04-22 11:46:15 +01:00
  65420737e8
• Support multiple cwd filters for thread list (#18502)

  ## Summary
  
  - Teach app-server `thread/list` to accept either a single `cwd` or an
  array of cwd filters, returning threads whose recorded session cwd
  matches any requested path
  - Add `useStateDbOnly` as an explicit opt-in fast path for callers that
  want to answer `thread/list` from SQLite without scanning JSONL rollout
  files
  - Preserve backwards compatibility: by default, `thread/list` still
  scans JSONL rollouts and repairs SQLite state
  - Wire the new cwd array and SQLite-only options through app-server,
  local/remote thread-store, rollout listing, generated TypeScript/schema
  fixtures, proto output, and docs
  
  ## Test Plan
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-rollout`
  - `cargo test -p codex-thread-store`
  - `cargo test -p codex-app-server thread_list`
  - `just fmt`
  - `just fix -p codex-app-server-protocol -p codex-rollout -p
  codex-thread-store -p codex-app-server`
  - `cargo build -p codex-cli --bin codex`

  acrognale-oai · 2026-04-22 06:10:09 -04:00
  4f8c58f737
• [codex-analytics] guardian review TTFT plumbing and emission (#17696)

  ## Why
  
  Guardian analytics includes time-to-first-token, but the Guardian
  reviewer runs as a normal Codex session and `TurnCompleteEvent` did not
  expose TTFT. The timing needs to flow through the standard
  turn-completion protocol so Guardian review analytics can consume the
  same value as the rest of the session machinery.
  
  ## What changed
  
  Adds optional `time_to_first_token_ms` to `TurnCompleteEvent` and
  populates it from `TurnTiming`. The value is carried through app-server
  thread history, rollout reconstruction, TUI/app-server adapters, and
  Guardian review session handling.
  
  Guardian review analytics now captures TTFT from the reviewer
  turn-complete event when available. Existing tests and fixtures are
  updated to set the new optional field to `None` where TTFT is not
  relevant.
  
  ## Verification
  
  - `cargo clippy -p codex-tui --tests -- -D warnings`
  - `cargo clippy -p codex-core --lib --tests -- -D warnings`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17696).
  * __->__ #17696
  * #17695
  * #17693
  * #18278
  * #18953

  rhan-oai · 2026-04-22 01:52:48 -07:00
  213b17b7a3
• 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
• core: derive active permission profiles (#18277)

  ## Why
  
  `Permissions` should not store a separate `PermissionProfile` that can
  drift from the constrained `SandboxPolicy` and network settings. The
  active profile needs to be derived from the same constrained values that
  already honor `requirements.toml`.
  
  ## What changed
  
  This adds derivation of the active `PermissionProfile` from the
  constrained runtime permission settings and exposes that derived value
  through config snapshots and thread state. The app-server can then
  report the active profile without introducing a second source of truth.
  
  ## Verification
  
  - `cargo test -p codex-core --test all permissions_messages --
  --nocapture`
  - `cargo test -p codex-core --test all request_permissions --
  --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18277).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * #18279
  * #18278
  * __->__ #18277

  Michael Bolin · 2026-04-21 22:11:40 -07:00
  0fef35dc3a
• 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
• Support multiple managed environments (#18401)

  ## Summary
  - refactor EnvironmentManager to own keyed environments with
  default/local lookup helpers
  - keep remote exec-server client creation lazy until exec/fs use
  - preserve disabled agent environment access separately from internal
  local environment access
  
  ## Validation
  - not run (per Codex worktree instruction to avoid tests/builds unless
  requested)
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-21 15:29:35 -07:00
  ddbe2536be
• Preserve Cloudfare HTTP cookies in codex (#17783)

  ## Summary
  - Adds a process-local, in-memory cookie store for ChatGPT HTTP clients.
  - Limits cookie storage and replay to a shared ChatGPT host allowlist.
  - Wires the shared store into the default Codex reqwest client and
  backend client.
  - Shares the ChatGPT host allowlist with remote-control URL validation
  to avoid drift.
  - Enables reqwest cookie support and updates lockfiles.

  Shijie Rao · 2026-04-21 14:40:15 -07:00
  c5e9c6f71f
• 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
• app-server: implement device key v2 methods (#18430)

  ## Why
  
  The device-key protocol needs an app-server implementation that keeps
  local key operations behind the same request-processing boundary as
  other v2 APIs.
  
  app-server owns request dispatch, transport policy, documentation, and
  JSON-RPC error shaping. `codex-device-key` owns key binding, validation,
  platform provider selection, and signing mechanics. Keeping the adapter
  thin makes the boundary easier to review and avoids moving local
  key-management details into thread orchestration code.
  
  ## What changed
  
  - Added `DeviceKeyApi` as the app-server adapter around
  `DeviceKeyStore`.
  - Converted protocol protection policies, payload variants, algorithms,
  and protection classes to and from the device-key crate types.
  - Encoded SPKI public keys and DER signatures as base64 protocol fields.
  - Routed `device/key/create`, `device/key/public`, and `device/key/sign`
  through `MessageProcessor`.
  - Rejected remote transports before provider access while allowing local
  `stdio` and in-process callers to reach the device-key API.
  - Added stdio, in-process, and websocket tests for device-key validation
  and transport policy.
  - Documented the device-key methods in the app-server v2 method list.
  
  ## Test coverage
  
  - `device_key_create_rejects_empty_account_user_id`
  - `in_process_allows_device_key_requests_to_reach_device_key_api`
  - `device_key_methods_are_rejected_over_websocket`
  
  ## Stack
  
  This is PR 3 of 4 in the device-key app-server stack. It is stacked on
  #18429.
  
  ## Validation
  
  - `cargo test -p codex-app-server device_key`
  - `just fix -p codex-app-server`

  Ruslan Nigmatullin · 2026-04-21 14:07:08 -07:00
  69c3d12274
• Load app-server config through ConfigManager (#18870)

  ## Summary
  - Load app-server startup config through `ConfigManager` instead of
  direct `ConfigBuilder` calls.
  - Move `ConfigManager` constructor-owned state (`cli_overrides`, runtime
  feature map, cloud requirements loader) behind internal manager fields.
  - Pass `ConfigManager` into `MessageProcessor` directly instead of
  reconstructing it from raw args.
  
  ## Tests
  - `cargo check -p codex-app-server`
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server`
  - `just fmt`

  pakrym-oai · 2026-04-21 14:01:02 -07:00
  ffa6944587
• app-server: fix Bazel clippy in tracing tests (#18872)

  ## Why
  
  PR #18431 exposed a Bazel clippy failure in the app-server unit-test
  target across Linux, macOS, and Windows. The failing lint was
  `clippy::await_holding_invalid_type`: two tracing tests serialized
  access to global tracing state by holding a `tokio::sync::MutexGuard`
  across awaited test work.
  
  That serialization is still needed because the tests share
  process-global tracing setup and exporter state, but it should not
  require holding an async mutex guard through the whole test body.
  
  ## What changed
  
  - Replaced the bespoke async `tracing_test_guard` helper with
  `serial_test` on the two tracing tests that need global tracing
  serialization.
  - Removed the `#[expect(clippy::await_holding_invalid_type)]`
  annotations and the lock guard callsites that Bazel clippy rejected.
  
  ## Validation
  
  - `cargo test -p codex-app-server jsonrpc_span`
  - `just fix -p codex-app-server`
  - `git diff --check`
  
  I also attempted the exact failing Bazel clippy target locally with
  BuildBuddy disabled: `bazel --noexperimental_remote_repo_contents_cache
  build --config=clippy --bes_backend= --remote_cache=
  --experimental_remote_downloader= --
  //codex-rs/app-server:app-server-unit-tests-bin`. That run did not reach
  clippy because Bazel timed out downloading `libcap-2.27.tar.gz` from
  `kernel.org`.

  Ruslan Nigmatullin · 2026-04-21 13:10:36 -07:00
  56375712e3
• 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
• Refactor app-server config loading into ConfigManager (#18442)

  Localize app-server configuration loading in one place.

  pakrym-oai · 2026-04-21 10:22:26 -07:00
  5fe767e8e1
• Propagate thread id in MCP tool metadata (#18093)

  ## Summary
  - attach the authoritative Codex thread id to MCP tool request
  `_meta.threadId` for model-initiated tool calls
  - attach the same thread id for manual `mcpServer/tool/call` requests
  before invoking the MCP server
  - cover both metadata helper behavior and the manual app-server MCP path
  in tests
  
  
  needed because the Rust app-server is the last place that still has
  authoritative knowledge of “this model-generated MCP tool call belongs
  to conversation/thread X” before the request leaves Codex and reaches
  Hoopa. It adds threadId to MCP request metadata in the model-generated
  tool-call path, using sess.conversation_id, and also does the same for
  the manual mcpServer/tool/call path.
  
  ## Test plan
  - `cargo test -p codex-core
  mcp_tool_call_thread_id_meta_is_added_to_request_meta --lib`
  - `cargo test -p codex-app-server
  mcp_server_tool_call_returns_tool_result`
  
  Paired Hoopa consumer PR: https://github.com/openai/openai/pull/833263

  Rennie · 2026-04-21 10:09:46 -07:00
  3a9df58d06
• 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
• Move external agent config out of core (#18850)

  ## Summary
  - Move external agent config migration logic and tests from `codex-core`
  into `app-server/src/config`.
  - Keep the migration service crate-private to app-server and update the
  API adapter imports.
  - Remove stale core re-exports and expose only the needed marketplace
  source helper.
  
  ## Testing
  - `cargo test -p codex-app-server config::external_agent_config`
  - `just fmt`
  - `just fix -p codex-app-server`
  - `just fix -p codex-core`
  - `git diff --check`

  pakrym-oai · 2026-04-21 08:33:58 -07:00
  833212115e
• [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
• chore: document intentional await-holding cases (#18423)

  ## Why
  
  This PR prepares the stack to enable Clippy await-holding lints that
  were left disabled in #18178. The mechanical lock-scope cleanup is
  handled separately; this PR is the documentation/configuration layer for
  the remaining await-across-guard sites.
  
  Without explicit annotations, reviewers and future maintainers cannot
  tell whether an await-holding warning is a real concurrency smell or an
  intentional serialization boundary.
  
  ## What changed
  
  - Configures `clippy.toml` so `await_holding_invalid_type` also covers
  `tokio::sync::{MutexGuard,RwLockReadGuard,RwLockWriteGuard}`.
  - Adds targeted `#[expect(clippy::await_holding_invalid_type, reason =
  ...)]` annotations for intentional async guard lifetimes.
  - Documents the main categories of intentional cases: active-turn state
  transitions that must remain atomic, session-owned MCP manager accesses,
  remote-control websocket serialization, JS REPL kernel/process
  serialization, OAuth persistence, external bearer token refresh
  serialization, and tests that intentionally serialize shared global or
  session-owned state.
  - For external bearer token refresh, documents the existing
  serialization boundary: holding `cached_token` across the provider
  command prevents concurrent cache misses from starting duplicate refresh
  commands, and the current behavior is small enough that an explicit
  expectation is easier to maintain than adding another synchronization
  primitive.
  
  ## Verification
  
  - `cargo clippy -p codex-login --all-targets`
  - `cargo clippy -p codex-connectors --all-targets`
  - `cargo clippy -p codex-core --all-targets`
  - The follow-up PR #18698 enables `await_holding_invalid_type` and
  `await_holding_lock` as workspace `deny` lints, so any undocumented
  remaining offender will fail Clippy.
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18423).
  * #18698
  * __->__ #18423

  Michael Bolin · 2026-04-20 22:41:54 -07:00
  d62421d322
• Add remote_sandbox_config to our config requirements (#18763)

  ## Why
  
  Customers need finer-grained control over allowed sandbox modes based on
  the host Codex is running on. For example, they may want stricter
  sandbox limits on devboxes while keeping a different default elsewhere.
  
  Our current cloud requirements can target user/account groups, but they
  cannot vary sandbox requirements by host. That makes remote development
  environments awkward because the same top-level `allowed_sandbox_modes`
  has to apply everywhere.
  
  ## What
  
  Adds a new `remote_sandbox_config` section to `requirements.toml`:
  
  ```toml
  allowed_sandbox_modes = ["read-only"]
  
  [[remote_sandbox_config]]
  hostname_patterns = ["*.org"]
  allowed_sandbox_modes = ["read-only", "workspace-write"]
  
  [[remote_sandbox_config]]
  hostname_patterns = ["*.sh", "runner-*.ci"]
  allowed_sandbox_modes = ["read-only", "danger-full-access"]
  ```
  
  During requirements resolution, Codex resolves the local host name once,
  preferring the machine FQDN when available and falling back to the
  cleaned kernel hostname. This host classification is best effort rather
  than authenticated device proof.
  
  Each requirements source applies its first matching
  `remote_sandbox_config` entry before it is merged with other sources.
  The shared merge helper keeps that `apply_remote_sandbox_config` step
  paired with requirements merging so new requirements sources do not have
  to remember the extra call.
  
  That preserves source precedence: a lower-precedence requirements file
  with a matching `remote_sandbox_config` cannot override a
  higher-precedence source that already set `allowed_sandbox_modes`.
  
  This also wires the hostname-aware resolution through app-server,
  CLI/TUI config loading, config API reads, and config layer metadata so
  they all evaluate remote sandbox requirements consistently.
  
  ## Verification
  
  - `cargo test -p codex-config remote_sandbox_config`
  - `cargo test -p codex-config host_name`
  - `cargo test -p codex-core
  load_config_layers_applies_matching_remote_sandbox_config`
  - `cargo test -p codex-core
  system_remote_sandbox_config_keeps_cloud_sandbox_modes`
  - `cargo test -p codex-config`
  - `cargo test -p codex-core` unit tests passed; `tests/all.rs`
  integration matrix was intentionally stopped after the relevant focused
  tests passed
  - `just fix -p codex-config`
  - `just fix -p codex-core`
  - `cargo check -p codex-app-server`

  Abhinav · 2026-04-21 05:05:02 +00:00
  ab26554a3a
• 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
• feat: add a built-in Amazon Bedrock model provider (#18744)

  ## Why
  
  Codex needs a first-class `amazon-bedrock` model provider so users can
  select Bedrock without copying a full provider definition into
  `config.toml`. The provider has Codex-owned defaults for the pieces that
  should stay consistent across users: the display `name`, Bedrock
  `base_url`, and `wire_api`.
  
  At the same time, users still need a way to choose the AWS credential
  profile used by their local environment. This change makes
  `amazon-bedrock` a partially modifiable built-in provider: code owns the
  provider identity and endpoint defaults, while user config can set
  `model_providers.amazon-bedrock.aws.profile`.
  
  For example:
  
  ```toml
  model_provider = "amazon-bedrock"
  
  [model_providers.amazon-bedrock.aws]
  profile = "codex-bedrock"
  ```
  
  ## What Changed
  
  - Added `amazon-bedrock` to the built-in model provider map with:
    - `name = "Amazon Bedrock"`
    - `base_url = "https://bedrock-mantle.us-east-1.api.aws/v1"`
    - `wire_api = "responses"`
  - Added AWS provider auth config with a profile-only shape:
  `model_providers.<id>.aws.profile`.
  - Kept AWS auth config restricted to `amazon-bedrock`; custom providers
  that set `aws` are rejected.
  - Allowed `model_providers.amazon-bedrock` through reserved-provider
  validation so it can act as a partial override.
  - During config loading, only `aws.profile` is copied from the
  user-provided `amazon-bedrock` entry onto the built-in provider. Other
  Bedrock provider fields remain hard-coded by the built-in definition.
  - Updated the generated config schema for the new provider AWS profile
  config.

  Celia Chen · 2026-04-21 00:54:05 +00:00
  cefcfe43b9
• Add session config loader interface (#18208)

  ## Why
  
  Cloud-hosted sessions need a way for the service that starts or manages
  a thread to provide session-owned config without treating all config as
  if it came from the same user/project/workspace TOML stack.
  
  The important boundary is ownership: some values should be controlled by
  the session/orchestrator, some by the authenticated user, and later some
  may come from the executor. The earlier broad config-store shape made
  that boundary too fuzzy and overlapped heavily with the existing
  filesystem-backed config loader. This PR starts with the smaller piece
  we need now: a typed session config loader that can feed the existing
  config layer stack while preserving the normal precedence and merge
  behavior.
  
  ## What Changed
  
  - Added `ThreadConfigLoader` and related typed payloads in
  `codex-config`.
  - `SessionThreadConfig` currently supports `model_provider`,
  `model_providers`, and feature flags.
  - `UserThreadConfig` is present as an ownership boundary, but does not
  yet add TOML-backed fields.
  - `NoopThreadConfigLoader` preserves existing behavior when no external
  loader is configured.
    - `StaticThreadConfigLoader` supports tests and simple callers.
  
  - Taught thread config sources to produce ordinary `ConfigLayerEntry`
  values so the existing `ConfigLayerStack` remains the place where
  precedence and merging happen.
  
  - Wired the loader through `ConfigBuilder`, the config loader, and
  app-server startup paths so app-server can provide session-owned config
  before deriving a thread config.
  
  - Added coverage for:
    - translating typed thread config into config layers,
  - inserting thread config layers into the stack at the right precedence,
  - applying session-provided model provider and feature settings when
  app-server derives config from thread params.
  
  ## Follow-Ups
  
  This intentionally stops short of adding the remote/service transport.
  The next pieces are expected to be:
  
  1. Define the proto/API shape for this interface.
  2. Add a client implementation that can source session config from the
  service side.
  
  ## Verification
  
  - Added unit coverage in `codex-config` for the loader and layer
  conversion.
  - Added `codex-core` config loader coverage for thread config layer
  precedence.
  - Added app-server coverage that verifies session thread config wins
  over request-provided config for model provider and feature settings.

  Rasmus Rygaard · 2026-04-20 23:05:49 +00:00
  7b994100b3
• Add realtime silence tool (#18635)

  ## Summary
  
  Adds a second realtime v2 function tool, `remain_silent`, so the
  realtime model has an explicit non-speaking action when the
  collaboration mode or latest context says it should not answer aloud.
  This is stacked on #18597.
  
  ## Design
  
  - Advertise `remain_silent` alongside `background_agent` in realtime v2
  conversational sessions.
  - Parse `remain_silent` function calls into a typed
  `RealtimeEvent::NoopRequested` event.
  - Have core answer that function call with an empty
  `function_call_output` and deliberately avoid `response.create`, so no
  follow-up realtime response is requested.
  - Keep the event hidden from app-server/TUI surfaces; it is operational
  plumbing, not user-visible conversation content.

  guinness-oai · 2026-04-20 15:43:20 -07:00
  1029742cf7
• Read conversation summaries through thread store (#18716)

  Migrate the conversation summary App Server methods to ThreadStore
  
  Because this app server api allows explicitly fetching the thread by
  rollout path, intercept that case in the app server code and (a) route
  directly to underlying local thread store methods if we're using a local
  thread store, or (b) throw an unsupported error if we're using a remote
  thread store. This keeps the thread store API clean and all filesystem
  operations inside of the local thread store, which pushing the
  "fundamental incompatibility" check as early as possible.

  Tom · 2026-04-20 22:39:10 +00:00
  a718b6fd47
• feat: cascade thread archive (#18112)

  Cascade the thread archive endpoint to all the sub-agents in the agent
  tree
  
  Fix: https://github.com/openai/codex/issues/17867
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-20 23:38:18 +01:00
  660153b6de
• Add experimental remote thread store config (#18714)

  Add experimental config to use remote thread store rather than local
  thread store implementation in app server

  Tom · 2026-04-20 22:20:39 +00:00
  46e5814f77
• Update realtime handoff transcript handling (#18597)

  ## Summary
  
  This PR aims to improve integration between the realtime model and the
  codex agent by sharing more context with each other. In particular, we
  now share full realtime conversation transcript deltas in addition to
  the delegation message.
  
  realtime_conversation.rs now turns a handoff into:
  ```
  <realtime_delegation>
    <input>...</input>
    <transcript_delta>...</transcript_delta>
  </realtime_delegation>
  ```
  
  ## Implementation notes
  
  The transcript is accumulated in the realtime websocket layer as parsed
  realtime events arrive. When a background-agent handoff is requested,
  the current transcript snapshot is copied onto the handoff event and
  then serialized by `realtime_conversation.rs` into the hidden realtime
  delegation envelope that Codex receives as user-turn context.
  
  For Realtime V2, the session now explicitly enables input audio
  transcription, and the parser handles the relevant input/output
  transcript completion events so the snapshot includes both user speech
  and realtime model responses. The delegation `<input>` remains the
  actual handoff request, while `<transcript_delta>` carries the
  surrounding conversation history for context.
  
  Reviewers should note that the transcript payload is intended for Codex
  context sharing, not UI rendering. The realtime delegation envelope
  should stay hidden from the user-facing transcript surface, while still
  being included in the background-agent turn so Codex can answer with the
  same conversational context the realtime model had.

  guinness-oai · 2026-04-20 14:04:09 -07:00
  126bd6e7a8
• 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
• Update models.json (#18586)

  - Replace the active models-manager catalog with the deleted core
  catalog contents.
  - Replace stale hardcoded test model slugs with current bundled model
  slugs.
  - Keep this as a stacked change on top of the cleanup PR.

  Ahmed Ibrahim · 2026-04-20 10:27:01 -07:00
  316cf0e90b
• 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: move unloaded thread writes into store (#18361)

  - Migrates unloaded `thread/name/set` and `thread/memoryModeSet`
  app-server writes behind the generic
  `ThreadStore::update_thread_metadata` API rather than adding one-off
  store methods for setting thread name or memory mode.
  - Implements the local ThreadStore metadata patch path for thread name
  and memory mode, including rollout append, legacy name index updates,
  SessionMeta validation/update, SQLite reconciliation, and re-reading the
  stored thread.
  - Adds focused local thread-store unit coverage plus app-server
  integration coverage for the migrated unloaded write paths.

  Tom · 2026-04-20 09:50:01 -07:00
  ac7c9a685f