529 Commits

• respect workspace option for disabling plugins (#18907)

  Respects the workspace setting for plugins in Codex
  
  Plugins menu disappears
  Plugins do not load
  Plugins do not load in composer
  
  no plugins loaded
  <img width="809" height="226" alt="Screenshot 2026-04-23 at 3 20 45 PM"
  src="https://github.com/user-attachments/assets/3a4dba8e-69c3-4046-a77e-f13ab77f84b4"
  />
  
  
  no plugins in menu
  <img width="293" height="204" alt="Screenshot 2026-04-23 at 3 20 35 PM"
  src="https://github.com/user-attachments/assets/5cb9bf52-ad72-488f-b90c-5eb457da09a3"
  />

  Alex Zamoshchin · 2026-04-24 17:38:45 +00:00
  bcc1caa920
• Fix hang on turn/interrupt (#18392)

  Fix a bug where the `turn/interrupt` RPC hangs when interrupting a turn
  that has already completed.
  
  Before this change, `turn/interrupt` requests were queued in app-server
  and only answered when a later TurnAborted event arrived. If the target
  turn was already complete, core treated Op::Interrupt as a no-op, so no
  abort event was emitted and the RPC could hang indefinitely.
  
  This change fixes that in two places:
  
  * Reject turn/interrupt immediately with `INVALID_REQUEST` when the
  requested turn is no longer the active turn.
  * Resolve any already-accepted pending interrupt requests when the turn
  reaches TurnComplete, covering the case where a turn finishes naturally
  after the interrupt request is accepted but before it aborts.
  
  I tested this by adding a failing test in
  707487c0634834f6741986b64f61886c2dc10108. You may view the results here:
  https://github.com/openai/codex/actions/runs/24585182419/
  
  <img width="1512" height="310" alt="CleanShot 2026-04-17 at 16 33 30@2x"
  src="https://github.com/user-attachments/assets/f4a88228-b2a4-41f4-9aaa-ec82814096af"
  />

  danwang-oai · 2026-04-24 10:47:50 -04:00
  11806faf71
• Update models.json and related fixtures (#19323)

  Supersedes #18735.
  
  The scheduled rust-release-prepare workflow force-pushed
  `bot/update-models-json` back to the generated models.json-only diff,
  which dropped the test and snapshot updates needed for CI.
  
  This PR keeps the latest generated `models.json` from #18735 and adds
  the corresponding fixture updates:
  - preserve model availability NUX in the app-server model cache fixture
  - update core/TUI expectations for the new `gpt-5.4` `xhigh` default
  reasoning
  - refresh affected TUI chatwidget snapshots for the `gpt-5.5`
  default/model copy changes
  
  Validation run locally while preparing the fix:
  - `just fmt`
  - `cargo test -p codex-app-server model_list`
  - `cargo test -p codex-core includes_no_effort_in_request`
  - `cargo test -p codex-core
  includes_default_reasoning_effort_in_request_when_defined_by_model_info`
  - `cargo test -p codex-tui --lib chatwidget::tests`
  - `cargo insta pending-snapshots`
  
  ---------
  
  Co-authored-by: aibrahim-oai <219906144+aibrahim-oai@users.noreply.github.com>

  sayan-oai · 2026-04-24 11:14:13 +02:00
  c10f95ddac
• permissions: make profiles represent enforcement (#19231)

  ## Why
  
  `PermissionProfile` is becoming the canonical permissions abstraction,
  but the old shape only carried optional filesystem and network fields.
  It could describe allowed access, but not who is responsible for
  enforcing it. That made `DangerFullAccess` and `ExternalSandbox` lossy
  when profiles were exported, cached, or round-tripped through app-server
  APIs.
  
  The important model change is that active permissions are now a disjoint
  union over the enforcement mode. Conceptually:
  
  ```rust
  pub enum PermissionProfile {
      Managed {
          file_system: FileSystemSandboxPolicy,
          network: NetworkSandboxPolicy,
      },
      Disabled,
      External {
          network: NetworkSandboxPolicy,
      },
  }
  ```
  
  This distinction matters because `Disabled` means Codex should apply no
  outer sandbox at all, while `External` means filesystem isolation is
  owned by an outside caller. Those are not equivalent to a broad managed
  sandbox. For example, macOS cannot nest Seatbelt inside Seatbelt, so an
  inner sandbox may require the outer Codex layer to use no sandbox rather
  than a permissive one.
  
  ## How Existing Modeling Maps
  
  Legacy `SandboxPolicy` remains a boundary projection, but it now maps
  into the higher-fidelity profile model:
  
  - `ReadOnly` and `WorkspaceWrite` map to `PermissionProfile::Managed`
  with restricted filesystem entries plus the corresponding network
  policy.
  - `DangerFullAccess` maps to `PermissionProfile::Disabled`, preserving
  the “no outer sandbox” intent instead of treating it as a lax managed
  sandbox.
  - `ExternalSandbox { network_access }` maps to
  `PermissionProfile::External { network }`, preserving external
  filesystem enforcement while still carrying the active network policy.
  - Split runtime policies that legacy `SandboxPolicy` cannot faithfully
  express, such as managed unrestricted filesystem plus restricted
  network, stay `Managed` instead of being collapsed into
  `ExternalSandbox`.
  - Per-command/session/turn grants remain partial overlays via
  `AdditionalPermissionProfile`; full `PermissionProfile` is reserved for
  complete active runtime permissions.
  
  ## What Changed
  
  - Change active `PermissionProfile` into a tagged union: `managed`,
  `disabled`, and `external`.
  - Keep partial permission grants separate with
  `AdditionalPermissionProfile` for command/session/turn overlays.
  - Represent managed filesystem permissions as either `restricted`
  entries or `unrestricted`; `glob_scan_max_depth` is non-zero when
  present.
  - Preserve old rollout compatibility by accepting the pre-tagged `{
  network, file_system }` profile shape during deserialization.
  - Preserve fidelity for important edge cases: `DangerFullAccess`
  round-trips as `disabled`, `ExternalSandbox` round-trips as `external`,
  and managed unrestricted filesystem + restricted network stays managed
  instead of being mistaken for external enforcement.
  - Preserve configured deny-read entries and bounded glob scan depth when
  full profiles are projected back into runtime policies, including
  unrestricted replacements that now become `:root = write` plus deny
  entries.
  - Regenerate the experimental app-server v2 JSON/TypeScript schema and
  update the `command/exec` README example for the tagged
  `permissionProfile` shape.
  
  ## Compatibility
  
  Legacy `SandboxPolicy` remains available at config/API boundaries as the
  compatibility projection. Existing rollout lines with the old
  `PermissionProfile` shape continue to load. The app-server
  `permissionProfile` field is experimental, so its v2 wire shape is
  intentionally updated to match the higher-fidelity model.
  
  ## Verification
  
  - `just write-app-server-schema`
  - `cargo check --tests`
  - `cargo test -p codex-protocol permission_profile`
  - `cargo test -p codex-protocol
  preserving_deny_entries_keeps_unrestricted_policy_enforceable`
  - `cargo test -p codex-app-server-protocol
  permission_profile_file_system_permissions`
  - `cargo test -p codex-app-server-protocol serialize_client_response`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox`
  - `just fix`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• [codex] Support remote plugin install writes (#18917)

  ## Summary
  - Add a remote plugin install write call that POSTs the selected remote
  plugin to the ChatGPT cloud plugin API.
  - Align remote install with the latest remote read contract:
  `pluginName` carries the backend remote plugin id directly, for example
  `plugins~Plugin_linear`, and install no longer synthesizes
  `<name>@<marketplace>` ids.
  - Validate remote install ids with the same character rules as remote
  read, return the same install response shape as local installs, and
  include mocked app-server coverage for the write path.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-app-server --test all plugin_install`
  - `cargo test -p codex-core-plugins`
  - `just fix -p codex-app-server`
  - `just fix -p codex-core-plugins`

  xli-oai · 2026-04-23 22:10:15 -07:00
  33cc135cc3
• Add sticky environment API and thread state (#18897)

  ## Summary
  - add sticky environment selections to app-server v2 thread/start and
  turn/start request flow
  - carry thread-level selections through core session/thread state
  - add app-server coverage for sticky selections and turn overrides
  
  ## Stack
  1. This PR: API and thread persistence
  2. #18898: config.toml named environment loading
  3. #18899: downstream tool/runtime consumers
  
  ## Validation
  - Not run locally; split only.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• feat: expose AWS account state from account/read (#19048)

  ## Why
  
  AWS/Bedrock mode currently reports `account: null` with
  `requiresOpenaiAuth: false` from `account/read`. That suppresses the
  OpenAI-auth requirement, but it does not let app clients distinguish AWS
  auth from any other non-OpenAI custom provider. For the prototype AWS
  provider UX, clients need a simple provider-derived signal so they can
  suppress ChatGPT/API-key login and token-refresh paths without
  hardcoding Bedrock checks.
  
  ## What changed
  
  - Adds an `aws` variant to the v2 `Account` protocol union.
  - Adds `ProviderAccountKind` to `codex-model-provider` so the runtime
  provider owns the app-visible account classification.
  - Makes Amazon Bedrock return `ProviderAccountKind::Aws` from the
  model-provider layer.
  - Updates app-server `account/read` to map `ProviderAccountKind` to the
  existing `GetAccountResponse` wire shape.
  - Preserves the existing `account: null, requiresOpenaiAuth: false`
  behavior for other non-OpenAI providers.
  - Regenerates the app-server protocol schema fixtures.
  - Adds coverage for provider account classification and for the Amazon
  Bedrock `account/read` response.
  
  ## Testing
  
  - `cargo test -p codex-model-provider`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server get_account_with_aws_provider`
  
  ## Notes
  
  I attempted `just bazel-lock-update` and `just bazel-lock-check`, but
  both are blocked in my local environment because `bazel` is not
  installed.

  Celia Chen · 2026-04-24 01:53:13 +00:00
  432771c5fd
• Add app-server marketplace upgrade RPC (#19074)

  ## Summary
  - add a v2 `marketplace/upgrade` app-server RPC that mirrors the
  existing configured Git marketplace upgrade path
  - expose typed request/response/error payloads and regenerate
  JSON/TypeScript schema fixtures
  - add app-server integration coverage for all, named, already
  up-to-date, and invalid marketplace upgrade requests
  
  ## Tests
  - `just write-app-server-schema`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-app-server marketplace_upgrade`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fmt`

  xli-oai · 2026-04-23 13:00:46 -07:00
  0d6a90cd6b
• Move marketplace add/remove and startup sync out of core. (#19099)

  Move more things to core-plugins.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  xl-openai · 2026-04-23 11:27:17 -07:00
  198eddd25d
• Respect explicit untrusted project config (#18626)

  ## Why
  
  Fixes #18475. A `-c` override such as `projects.<cwd>.trust_level =
  "untrusted"` is meant to be a runtime config override, but app-server
  thread startup treated any non-trusted project as eligible for automatic
  trust persistence when a permissive sandbox/cwd was requested. That
  meant an explicit `untrusted` session override could still cause
  `config.toml` to be updated with `trusted`.
  
  ## What changed
  
  The app-server auto-trust path now runs only when the active project
  trust level is unknown. Explicit `trusted` and explicit `untrusted`
  values are both respected, regardless of whether they came from
  persisted config or session flags.
  
  A focused `thread/start` test now covers the explicit `untrusted` case
  with a permissive sandbox request.
  
  ## Verification
  
  - `cargo test -p codex-app-server`
  - `just fix -p codex-app-server`

  Eric Traut · 2026-04-23 10:51:17 -07:00
  c2423f42d1
• Add excludeTurns parameter to thread/resume and thread/fork (#19014)

  For callers who expect to be paginating the results for the UI, they can
  now call thread/resume or thread/fork with excludeturns:true so it will
  not fetch any pages of turns, and instead only set up the subscription.
  That call can be immediately followed by pagination requests to
  thread/turns/list to fetch pages of turns according to the UI's current
  interactions.

  David de Regt · 2026-04-23 10:07:59 -07:00
  3d3028a5a9
• 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
• 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
• 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
• 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: 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
• 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
• feat: add explicit AgentIdentity auth mode (#18785)

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

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

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

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

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

  starr-openai · 2026-04-21 17:48:33 -07:00
  1d4cc494c9
• 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
• 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
• 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
• [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
• 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
• 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
• 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
• Stabilize marketplace/remove installedRoot test (#17721)

  ## Why
  
  This addresses the review comment from #17751 about `marketplace/remove`
  app-server test portability:
  https://github.com/openai/codex/pull/17751#discussion_r3104378613
  
  The API returns the removed installed root using the app-server's
  effective `CODEX_HOME`. On macOS, temporary directory paths can appear
  as either `/var/...` or `/private/var/...`, so comparing one raw path
  against another can fail even when `marketplace/remove` behaves
  correctly.
  
  ## What changed
  
  - Removed the direct whole-response equality assertion for the installed
  root path.
  - Asserted the stable response field, `marketplace_name`, directly.
  - Compared the expected and returned installed-root paths after
  canonicalizing their existing parent directories, which avoids requiring
  the removed leaf directory to still exist.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  marketplace_remove_deletes_config_and_installed_root`
  - `cargo test -p codex-app-server marketplace_remove`

  xli-oai · 2026-04-20 03:11:45 -07:00
  2a17b32dfa
• [codex] Add marketplace/remove app-server RPC (#17751)

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

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

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

  Adrian · 2026-04-19 15:45:28 -07:00
  e5b52a3caa
• Update image outputs to default to high detail (#18386)

  Do not assume the default `detail`.

  pakrym-oai · 2026-04-18 11:01:12 -07:00
  53b1570367
• Add max context window model metadata (#18382)

  Adds max_context_window to model metadata and routes core context-window
  reads through resolved model info. Config model_context_window overrides
  are clamped to max_context_window when present; without an override, the
  model context_window is used.

  Ahmed Ibrahim · 2026-04-17 21:48:14 -07:00
  5bb193aa88
• [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
• [codex] Describe uninstalled cross-repo plugin reads (#18449)

  ## Summary
  - Populate `PluginDetail.description` in core for uninstalled cross-repo
  plugins when detailed fields are unavailable until install.
  - Include the source Git URL plus optional path/ref/sha details in that
  fallback description.
  - Keep `details_unavailable_reason` as the structured signal while
  app-server forwards the description normally.
  - Add plugin-read coverage proving the response does not clone the
  remote source just to show the message.
  
  ## Why
  Uninstalled cross-repo plugins intentionally return sparse detail data
  so listing/reading does not clone the plugin source. Without a
  description, Desktop and TUI detail pages look like an ordinary empty
  plugin. This gives users a concrete explanation and source pointer while
  keeping the existing structured reason available for callers.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-core
  read_plugin_for_config_uninstalled_git_source_requires_install_without_cloning`
  - `cargo test -p codex-app-server plugin_read --test all`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`
  
  Note: `cargo test -p codex-app-server` was also attempted before the
  latest refactor and failed broadly in unrelated v2
  thread/realtime/review/skills suites; the new plugin-read test passed in
  that run as well.

  xli-oai · 2026-04-17 20:31:13 -07:00
  def6467d2b
• 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
• fix: trust-gate project hooks and exec policies (#14718)

  ## Summary
  - trust-gate project `.codex` layers consistently, including repos that
  have `.codex/hooks.json` or `.codex/execpolicy/*.rules` but no
  `.codex/config.toml`
  - keep disabled project layers in the config stack so nested trusted
  project layers still resolve correctly, while preventing hooks and exec
  policies from loading until the project is trusted
  - update app-server/TUI onboarding copy to make the trust boundary
  explicit and add regressions for loader, hooks, exec-policy, and
  onboarding coverage
  
  ## Security
  Before this change, an untrusted repo could auto-load project hooks or
  exec policies from `.codex/` as long as `config.toml` was absent. This
  makes trust the single gate for project-local config, hooks, and exec
  policies.
  
  ## Stack
  - Parent of #15936
  
  ## Test
  - cargo test -p codex-core without_config_toml
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 17:56:58 -07:00
  370bed4bf4