635 Commits

• chore: apply truncation policy to unified_exec (#19247)

  we were not respecting turn's `truncation_policy` to clamp output tokens
  for `unified_exec` and `write_stdin`.
  
  this meant truncation was only being applied by `ContextManager` before
  the output was stored in-memory (so it _was_ being truncated from
  model-visible context), but the full output was persisted to rollout on
  disk.
  
  now we respect that `truncation_policy` and `ContextManager`-level
  truncation remains a backup.
  
  ### Tests
  added tests, tested locally.

  sayan-oai · 2026-04-24 00:17:39 -07:00
  e083b6c757
• Reject unsupported js_repl image MIME types (#19292)

  ## Summary
  
  `codex.emitImage` accepted arbitrary image MIME types for byte payloads
  and data URLs. That allowed a value like `image/rgba` to be wrapped as
  an `input_image`, even though it is not a supported encoded image
  format, so the invalid image could reach the model-input path and
  trigger output sanitization.
  
  This results in a panic in debug builds because the output sanitization
  is meant as a final safety net, not a primary means of rejecting invalid
  image types. I've hit this case multiple times when executing certain
  long-running tasks.
  
  This PR rejects unsupported image MIME types before they are emitted
  from `js_repl`.
  
  ## Changes
  
  - Validate `codex.emitImage({ bytes, mimeType })` in the JS kernel so
  only encoded PNG, JPEG, WebP, or GIF payloads are accepted.
  - Apply the same MIME allowlist to direct image data URLs, including the
  Rust host-side validation path.
  - Clarify the JS REPL instructions so agents know byte payloads must
  already be encoded as PNG/JPEG/WebP/GIF.

  Eric Traut · 2026-04-24 00:14:51 -07:00
  ac8c9fc49c
• 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
• 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
• [rollout_trace] Add debug trace reduction command (#18880)

  ## Summary
  
  Adds the debug CLI entry point for reducing recorded rollout traces.
  This gives developers a direct way to inspect whether the emitted trace
  stream reduces into the expected conversation/runtime model.
  
  ## Stack
  
  This is PR 5/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is intentionally last: it depends on the trace crate, core
  recorder, runtime/tool events, and session/agent edge data all existing.
  The command should remain a debug/developer tool and avoid adding new
  runtime behavior.
  
  The useful review question is whether the CLI exposes the reducer in the
  smallest practical way for local inspection without turning the debug
  command into a supported user-facing workflow.

  cassirer-openai · 2026-04-24 01:56:48 +00:00
  e3c8720a99
• shell-escalation: carry resolved permission profiles (#18287)

  ## Why
  
  Shell escalation still has adapter code that expects a legacy sandbox
  policy, but command approvals should carry the resolved
  `PermissionProfile` so callers can reason about the granted permissions
  canonically.
  
  ## What changed
  
  This introduces profile-shaped resolved escalation permissions while
  retaining the derived legacy sandbox policy for the Unix escalation
  adapter. It updates approval types, the escalation server protocol, and
  tests that inspect escalated command permissions.
  
  ## Verification
  
  - `cargo test -p codex-core --test all handle_container_exec_ --
  --nocapture`
  - `cargo test -p codex-core --test all handle_sandbox_ -- --nocapture`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18287).
  * #18288
  * __->__ #18287

  Michael Bolin · 2026-04-23 12:46:19 -07:00
  9c0eced391
• [rollout_trace] Trace tool and code-mode boundaries (#18878)

  ## Summary
  
  Extends rollout tracing across tool dispatch and code-mode runtime
  boundaries. This records canonical tool-call lifecycle events and links
  code-mode execution/wait operations back to the model-visible calls that
  caused them.
  
  ## Stack
  
  This is PR 3/5 in the rollout trace stack.
  
  - [#18876](https://github.com/openai/codex/pull/18876): Add rollout
  trace crate
  - [#18877](https://github.com/openai/codex/pull/18877): Record core
  session rollout traces
  - [#18878](https://github.com/openai/codex/pull/18878): Trace tool and
  code-mode boundaries
  - [#18879](https://github.com/openai/codex/pull/18879): Trace sessions
  and multi-agent edges
  - [#18880](https://github.com/openai/codex/pull/18880): Add debug trace
  reduction command
  
  ## Review Notes
  
  This PR is about attribution. Reviewers should focus on whether direct
  tool calls, code-mode-originated tool calls, waits, outputs, and
  cancellation boundaries are recorded with enough source information for
  deterministic reduction without coupling the reducer to live runtime
  internals.
  
  The stack remains valid after this layer: tool and code-mode traces
  reduce through the existing crate model, while the broader session and
  multi-agent relationships are added in the next PR.

  cassirer-openai · 2026-04-23 12:22:11 -07:00
  6d09b6752d
• 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
• feat: drop spawned-agent context instructions (#19127)

  ## Why
  
  MultiAgentV2 children should not receive an extra model-visible
  developer fragment just because they were spawned. The parent/configured
  developer instructions should carry through normally, but the dedicated
  `<spawned_agent_context>` block is no longer desired.
  
  ## What changed
  
  - Removed the `SpawnAgentInstructions` context fragment and its
  `<spawned_agent_context>` wrapper.
  - Stopped appending spawned-agent instructions in
  `codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs`.
  - Updated subagent notification coverage to assert inherited parent
  developer instructions without expecting the spawned-agent wrapper.
  
  ## Verification
  
  - `cargo test -p codex-core --test all
  spawned_multi_agent_v2_child_inherits_parent_developer_context --
  --nocapture`
  - `cargo test -p codex-core --test all
  skills_toggle_skips_instructions_for_parent_and_spawned_child --
  --nocapture`
  - `cargo test -p codex-core --test all subagent_notifications --
  --nocapture`

  jif-oai · 2026-04-23 18:54:45 +02:00
  a2f868c9d6
• 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
• 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
• core: box multi-agent wrapper futures (#19059)

  ## Why
  
  While debugging the Windows stack overflows we saw in
  [#13429](https://github.com/openai/codex/pull/13429) and then again in
  [#18893](https://github.com/openai/codex/pull/18893), I hit another
  overflow in
  `tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed`.
  
  That test drives the legacy multi-agent spawn / close / resume path. The
  behavior was fine, but several thin async wrappers were still inlining
  much larger `AgentControl` futures into their callers, which was enough
  to overflow the default Windows stack.
  
  ## What
  
  - Box the thin `AgentControl` wrappers around `spawn_agent_internal`,
  `resume_single_agent_from_rollout`, and `shutdown_agent_tree`.
  - Box the corresponding legacy `multi_agents` handler calls in `spawn`,
  `resume_agent`, and `close_agent`.
  - Keep behavior unchanged while reducing future size on this call path
  so the Windows test no longer overflows its stack.
  
  ## Testing
  
  - `cargo test -p codex-core --lib
  tools::handlers::multi_agents::tests::tool_handlers_cascade_close_and_resume_and_keep_explicitly_closed_subtrees_closed
  -- --exact --nocapture`
  - `cargo test -p codex-core` (this still hit unrelated local
  integration-test failures because `codex.exe` / `test_stdio_server.exe`
  were not present in this shell; the relevant unit tests passed)

  Michael Bolin · 2026-04-22 17:48:13 -07:00
  3cc3763e6c
• hooks: emit Bash PostToolUse when exec_command completes via write_stdin (#18888)

  Fixes #16246.
  
  ## Why
  
  `exec_command` already emits `PreToolUse`, but long-running unified exec
  commands that finish on a later `write_stdin` poll could miss the
  matching `PostToolUse`. That left the Bash hook lifecycle inconsistent,
  broke expectations around `tool_use_id` and `tool_input.command`, and
  meant `PostToolUse` block/replacement feedback could fail to replace the
  final session output before it reached model context.
  
  This keeps the fix scoped to the `exec_command` / `write_stdin`
  lifecycle. Broader non-Bash hook expansion is still out of scope here
  and remains tracked separately in #16732.
  
  ## What changed
  
  - Compute and store `PostToolUsePayload` while handlers still have
  access to their concrete output type, and carry `tool_use_id` through
  that payload.
  - Preserve the original hook-facing `exec_command` string through
  unified exec state (`ExecCommandRequest`, `ProcessEntry`,
  `PreparedProcessHandles`, and `ExecCommandToolOutput`) via
  `hook_command`, and remove the now-unused `session_command` output
  metadata.
  - Emit exactly one Bash `PostToolUse` for long-running `exec_command`
  sessions when a later `write_stdin` poll observes final completion,
  using the original `exec_command` call id and hook-facing command.
  - Keep one-shot `exec_command` behavior aligned with the same payload
  construction, including interactive completions that return a final
  result directly.
  - Apply `PostToolUse` block/replacement feedback before the final
  `write_stdin` completion output is sent back to the model.
  - Keep `write_stdin` itself out of `PreToolUse` matching so it continues
  to act as transport/polling for the original Bash tool call.
  - Restore plain matcher behavior for tool-name matchers such as `Bash`
  and `Edit|Write`, while still treating patterns with regex characters
  (for example `mcp__.*`) as regexes.
  - Add unit coverage for unified exec payload construction and parallel
  session separation, plus a core integration regression that verifies a
  blocked `PostToolUse` replaces the final `write_stdin` output in model
  context.
  
  ## Testing
  
  - `cargo test -p codex-hooks`
  - `cargo test -p codex-core post_tool_use_payload`
  - `cargo test -p codex-core
  post_tool_use_blocks_when_exec_session_completes_via_write_stdin`

  Andrei Eternal · 2026-04-22 17:14:22 -07:00
  eed0e07825
• feat: add guardian network approval trigger context (#18197)

  ## Summary
  
  Give guardian network-access reviews the command context that triggered
  a managed-network approval. The prompt JSON now includes the originating
  tool call id, tool name, command argv, cwd, sandbox permissions,
  additional permissions, justification, and tty state when a single
  active tool call can be attributed.
  
  The implementation keeps the trigger shape canonical by serializing
  `GuardianNetworkAccessTrigger` directly and lets each runtime build that
  trigger from its `ToolCtx`. Non-guardian approval prompts avoid cloning
  the full trigger payload.
  
  ## UX changes
  
  Guardian network-access reviews now include a `trigger` object that
  explains what command caused the network approval. Instead of seeing
  only the requested host, the guardian reviewer can also see the
  originating tool call, argv, working directory, sandbox mode,
  justification, and tty state.
  
  Example payload the guardian reviewer can see:
  
  ```json
  {
    "tool": "network_access",
    "target": "https://api.github.com:443",
    "host": "api.github.com",
    "protocol": "https",
    "port": 443,
    "trigger": {
      "callId": "call_abc123",
      "toolName": "shell",
      "command": ["gh", "api", "/repos/openai/codex/pulls/18197"],
      "cwd": "/workspace/codex",
      "sandboxPermissions": "require_escalated",
      "justification": "Fetch PR metadata from GitHub.",
      "tty": false
    }
  }
  ```
  
  The network review itself remains scoped to the network decision:
  `target_item_id` stays `null`. `trigger.callId` is attribution context
  only, so clients can still distinguish network reviews from
  item-targeted command reviews.
  
  ## Verification
  
  - Added coverage for serializing network trigger context in guardian
  approval JSON.
  - Added regression coverage that network guardian reviews do not reuse
  `trigger.callId` as `target_item_id`.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-22 14:00:53 -07:00
  2d73bac45f
• fix: wait_agent timeout for queued mailbox mail (#18968)

  ## Why
  
  `wait_agent` can be called while mailbox mail is already pending. The
  previous implementation subscribed for future mailbox sequence changes
  and then waited for the next notification. If the mail was queued before
  that wait started, no new notification arrived, so the tool could sit
  until `timeout_ms` even though mail was ready to deliver.
  
  ## What Changed
  
  - Added `Session::has_pending_mailbox_items()` for checking pending
  mailbox mail through the session API.
  - Updated `multi_agents_v2::wait` to return immediately when pending
  mailbox mail already exists before sleeping on a new mailbox sequence
  update.
  - Reworked the regression coverage in `multi_agents_tests.rs` so already
  queued mailbox mail must wake `wait_agent` promptly.
  
  Relevant code:
  - [`wait_agent` pending-mail
  check](https://github.com/openai/codex/blob/aa8ca06e83cf2a3dc22f86f37caec6cc2d9533ea/codex-rs/core/src/tools/handlers/multi_agents_v2/wait.rs#L55-L60)
  -
  [`Session::has_pending_mailbox_items`](https://github.com/openai/codex/blob/aa8ca06e83cf2a3dc22f86f37caec6cc2d9533ea/codex-rs/core/src/session/mod.rs#L2979-L2981)
  -
  [`multi_agent_v2_wait_agent_returns_for_already_queued_mail`](https://github.com/openai/codex/blob/aa8ca06e83cf2a3dc22f86f37caec6cc2d9533ea/codex-rs/core/src/tools/handlers/multi_agents_tests.rs#L2854)
  
  ## Verification
  
  - `cargo test -p codex-core
  multi_agent_v2_wait_agent_returns_for_already_queued_mail`

  jif-oai · 2026-04-22 11:16:17 +01:00
  639382609f
• [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
• exec-server: carry filesystem sandbox profiles (#18276)

  ## Why
  
  The exec-server still needs platform sandbox inputs, but the migration
  should preserve the `PermissionProfile` that produced them. Keeping only
  the derived legacy sandbox map would keep `SandboxPolicy` as the
  effective abstraction and would make full-disk vs. restricted profiles
  harder to preserve as the permissions stack starts round-tripping
  profiles.
  
  `PermissionProfile` entries can also be cwd-sensitive (`:cwd`,
  `:project_roots`, relative globs), so the exec-server must carry the
  request sandbox cwd instead of resolving those entries against the
  long-lived exec-server process cwd.
  
  ## What changed
  
  `FileSystemSandboxContext` now carries `permissions: PermissionProfile`
  plus an optional `cwd`:
  
  - removed `sandboxPolicy`, `sandboxPolicyCwd`,
  `fileSystemSandboxPolicy`, and `additionalPermissions`
  - added `permissions` and `cwd`
  - kept the platform knobs `windowsSandboxLevel`,
  `windowsSandboxPrivateDesktop`, and `useLegacyLandlock`
  
  Core turn and apply-patch paths populate the context from the active
  runtime permissions and request cwd. Exec-server derives platform
  `SandboxPolicy`/`FileSystemSandboxPolicy` at the filesystem boundary,
  adds helper runtime reads there, and rejects cwd-dependent profiles that
  arrive without a cwd.
  
  The legacy `FileSystemSandboxContext::new(SandboxPolicy)` constructor
  now preserves the old workspace-write conversion semantics for
  compatibility tests/callers.
  
  ## Verification
  
  - `cargo test -p codex-exec-server`
  - `cargo test -p codex-exec-server sandbox_cwd -- --nocapture`
  - `cargo test -p codex-exec-server
  sandbox_context_new_preserves_legacy_workspace_write_read_only_subpaths
  -- --nocapture`
  - `cargo test -p codex-core --lib
  file_system_sandbox_context_uses_active_attempt -- --nocapture`

  Michael Bolin · 2026-04-21 20:22:28 -07:00
  36f8bb4ffa
• fix(core): emit hooks for apply_patch edits (#18391)

  Fixes https://github.com/openai/codex/issues/16732.
  
  ## Why
  
  `apply_patch` is Codex's primary file edit path, but it was not emitting
  `PreToolUse` or `PostToolUse` hook events. That meant hook-based policy,
  auditing, and write coordination could observe shell commands while
  missing the actual file mutation performed by `apply_patch`.
  
  The issue also exposed that the hook runtime serialized command hook
  payloads with `tool_name: "Bash"` unconditionally. Even if `apply_patch`
  supplied hook payloads, hooks would either fail to match it directly or
  receive misleading stdin that identified the edit as a Bash tool call.
  
  ## What Changed
  
  - Added `PreToolUse` and `PostToolUse` payload support to
  `ApplyPatchHandler`.
  - Exposed the raw patch body as `tool_input.command` for both
  JSON/function and freeform `apply_patch` calls.
  - Taught tool hook payloads to carry a handler-supplied hook-facing
  `tool_name`.
  - Preserved existing shell compatibility by continuing to emit `Bash`
  for shell-like tools.
  - Serialized the selected hook `tool_name` into hook stdin instead of
  hardcoding `Bash`.
  - Relaxed the generated hook command input schema so `tool_name` can
  represent tools other than `Bash`.
  
  ## Verification
  
  Added focused handler coverage for:
  
  - JSON/function `apply_patch` calls producing a `PreToolUse` payload.
  - Freeform `apply_patch` calls producing a `PreToolUse` payload.
  - Successful `apply_patch` output producing a `PostToolUse` payload.
  - Shell and `exec_command` handlers continuing to expose `Bash`.
  
  Added end-to-end hook coverage for:
  
  - A `PreToolUse` hook matching `^apply_patch$` blocking the patch before
  the target file is created.
  - A `PostToolUse` hook matching `^apply_patch$` receiving the patch
  input and tool response, then adding context to the follow-up model
  request.
  - Non-participating tools such as the plan tool continuing not to emit
  `PreToolUse`/`PostToolUse` hook events.
  
  Also validated manually with a live `codex exec` smoke test using an
  isolated temp workspace and temp `CODEX_HOME`. The smoke test confirmed
  that a real `apply_patch` edit emits `PreToolUse`/`PostToolUse` with
  `tool_name: "apply_patch"`, a shell command still emits `tool_name:
  "Bash"`, and a denying `PreToolUse` hook prevents the blocked patch file
  from being created.

  Felipe Coury · 2026-04-21 22:00:40 -03:00
  09ebc34f17
• 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
• sandboxing: materialize cwd-relative permission globs (#18867)

  ## Why
  
  #18275 anchors session-scoped `:cwd` and `:project_roots` grants to the
  request cwd before recording them for reuse. Relative deny glob entries
  need the same treatment. Without anchoring, a stored session permission
  can keep a pattern such as `**/*.env` relative, then reinterpret that
  deny against a later turn cwd. That makes the persisted profile depend
  on the cwd at reuse time instead of the cwd that was reviewed and
  approved.
  
  ## What changed
  
  `intersect_permission_profiles` now materializes retained
  `FileSystemPath::GlobPattern` entries against the request cwd, matching
  the existing materialization for cwd-sensitive special paths.
  
  Materialized accepted grants are now deduplicated before deny retention
  runs. This keeps the sticky-grant preapproval shape stable when a
  repeated request is merged with the stored grant and both `:cwd = write`
  and the materialized absolute cwd write are present.
  
  The preapproval check compares against the same materialized form, so a
  later request for the same cwd-relative deny glob still matches the
  stored anchored grant instead of re-prompting or rejecting.
  
  Tests cover both the storage path and the preapproval path: a
  session-scoped `:cwd = write` grant with `**/*.env = none` is stored
  with both the cwd write and deny glob anchored to the original request
  cwd, cannot be reused from a later cwd, and remains preapproved when
  re-requested from the original cwd after merging with the stored grant.
  
  ## Verification
  
  - `cargo test -p codex-sandboxing policy_transforms`
  - `cargo test -p codex-core --lib
  relative_deny_glob_grants_remain_preapproved_after_materialization`
  - `cargo clippy -p codex-sandboxing --tests -- -D
  clippy::redundant_clone`
  - `cargo clippy -p codex-core --lib -- -D clippy::redundant_clone`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/18867).
  * #18288
  * #18287
  * #18286
  * #18285
  * #18284
  * #18283
  * #18282
  * #18281
  * #18280
  * #18279
  * #18278
  * #18277
  * #18276
  * __->__ #18867

  Michael Bolin · 2026-04-21 17:28:58 -07:00
  799e50412e
• chore: default multi-agent v2 fork to all (#18873)

  Default sub-agents v2 to `all` for the fork mode

  jif-oai · 2026-04-21 21:54:58 +01:00
  15b8cde2a4
• Add Windows sandbox unified exec runtime support (#15578)

  ## Summary
  
  This is the runtime/foundation half of the Windows sandbox unified-exec
  work.
  
  - add Windows sandbox `unified_exec` session support in
  `windows-sandbox-rs` for both:
    - the legacy restricted-token backend
    - the elevated runner backend
  - extend the PTY/process runtime so driver-backed sessions can support:
    - stdin streaming
    - stdout/stderr separation
    - exit propagation
    - PTY resize hooks
  - add Windows sandbox runtime coverage in `codex-windows-sandbox` /
  `codex-utils-pty`
  
  This PR does **not** enable Windows sandbox `UnifiedExec` for product
  callers yet because hooking this up to app-server comes in the next PR.
  
  Windows sandbox advertising is intentionally kept aligned with `main`,
  so sandboxed Windows callers still fall back to `ShellCommand`.
  
  This PR isolates the runtime/session layer so it can be reviewed
  independently from product-surface enablement.
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  iceweasel-oai · 2026-04-21 10:44:49 -07:00
  8612714aa6
• 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
• Split DeveloperInstructions into individual fragments. (#18813)

  Split DeveloperInstructions into individual fragments.

  pakrym-oai · 2026-04-21 10:22:36 -07:00
  2a226096f6
• [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
• feat(auto-review) Handle request_permissions calls (#18393)

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

  Dylan Hurd · 2026-04-20 21:48:57 -07:00
  86535c9901
• fix: fix stale proxy env restoration after shell snapshots (#17271)

  ## Summary
  
  This fixes a stale-environment path in shell snapshot restoration. A
  sandboxed command can source a shell snapshot that was captured while an
  older proxy process was running. If that proxy has died and come back on
  a different port, the snapshot can otherwise put old proxy values back
  into the command environment, which is how tools like `pip` end up
  talking to a dead proxy.
  
  The wrapper now captures the live process environment before sourcing
  the snapshot and then restores or clears every proxy env var from the
  proxy crate's canonical list. That makes proxy state after shell
  snapshot restoration match the current command environment, rather than
  whatever proxy values happened to be present in the snapshot. On macOS,
  the Codex-generated `GIT_SSH_COMMAND` is refreshed when the SOCKS
  listener changes, while custom SSH wrappers are still left alone.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-20 16:39:17 -07:00
  33fa952426
• [codex] prefer inherited spawn agent model (#18701)

  This updates the spawn-agent tool contract so subagents are presented as
  inheriting the parent model by default. The visible model list is now
  framed as optional overrides, the model parameter tells callers to leave
  it unset and the delegation guidance no longer nudges models toward
  picking a smaller/mini override.
  
  Fixes reports that 5.4 would occasionally pick 5.2 or lower as
  sub-agents.

  Thibault Sottiaux · 2026-04-20 22:34:08 +00:00
  54bd07d28c
• 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
• 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
• fix: fix fs sandbox helper for apply_patch (#18296)

  ## Summary
  
  - pass split filesystem sandbox policy/cwd through apply_patch contexts,
  while omitting legacy-equivalent policies to keep payloads small
  - keep the fs helper compatible with legacy Landlock by avoiding helper
  read-root permission expansion in that mode and disabling helper network
  access
  
  ## Root Cause
  
  `d626dc38950fb40a1a5ad0a8ffab2485e3348c53` routed exec-server filesystem
  operations through a sandboxed helper. That path forwarded legacy
  Landlock into a helper policy shape that could require direct
  split-policy enforcement. Sandboxed `apply_patch` hit that edge through
  the filesystem abstraction.
  
  The same 0.121 edit-regression path is consistent with #18354: normal
  writes route through the `apply_patch` filesystem helper, fail under
  sandbox, and then surface the generic retry-without-sandbox prompt.
  
  Fixes #18069
  Fixes #18354
  
  ## Validation
  
  - `cd codex-rs && just fmt`
  - earlier branch validation before merging current `origin/main` and
  dropping the now-separate PATH fix:
    - `cd codex-rs && cargo test -p codex-exec-server`
  - `cd codex-rs && cargo test -p codex-core file_system_sandbox_context`
    - `cd codex-rs && just fix -p codex-exec-server`
    - `cd codex-rs && just fix -p codex-core`
    - `git diff --check`
    - `cd codex-rs && cargo clean`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-17 15:39:07 -07:00
  f705f42ba8
• refactor: narrow async lock guard lifetimes (#18211)

  Follow-up to https://github.com/openai/codex/pull/18178, where we called
  out enabling the await-holding lint as a follow-up.
  
  The long-term goal is to enable Clippy coverage for async guards held
  across awaits. This PR is intentionally only the first, low-risk cleanup
  pass: it narrows obvious lock guard lifetimes and leaves
  `codex-rs/Cargo.toml` unchanged so the lint is not enabled until the
  remaining cases are fixed or explicitly justified. It intentionally
  leaves the active-turn/turn-state locking pattern alone because those
  checks and mutations need to stay atomic.
  
  ## Common fixes used here
  
  These are the main patterns reviewers should expect in this PR, and they
  are also the patterns to reach for when fixing future `await_holding_*`
  findings:
  
  - **Scope the guard to the synchronous work.** If the code only needs
  data from a locked value, move the lock into a small block, clone or
  compute the needed values, and do the later `.await` after the block.
  - **Use direct one-line mutations when there is no later await.** Cases
  like `map.lock().await.remove(&id)` are acceptable when the guard is
  only needed for that single mutation and the statement ends before any
  async work.
  - **Drain or clone work out of the lock before notifying or awaiting.**
  For example, the JS REPL drains pending exec senders into a local vector
  and the websocket writer clones buffered envelopes before it serializes
  or sends them.
  - **Use a `Semaphore` only when serialization is intentional across
  async work.** The test serialization guards intentionally span awaited
  setup or execution, so using a semaphore communicates "one at a time"
  without holding a mutex guard.
  - **Remove the mutex when there is only one owner.** The PTY stdin
  writer task owns `stdin` directly; the old `Arc<Mutex<_>>` did not
  protect shared access because nothing else had access to the writer.
  - **Do not split locks that protect an atomic invariant.** This PR
  deliberately leaves active-turn/turn-state paths alone because those
  checks and mutations need to stay atomic. Those cases should be fixed
  separately with a design change or documented with `#[expect]`.
  
  ## What changed
  
  - Narrow scoped async mutex guards in app-server, JS REPL, network
  approval, remote-control websocket, and the RMCP test server.
  - Replace test-only async mutex serialization guards with semaphores
  where the guard intentionally lives across async work.
  - Let the PTY pipe writer task own stdin directly instead of wrapping it
  in an async mutex.
  
  ## Verification
  
  - `just fix -p codex-core -p codex-app-server -p codex-rmcp-client -p
  codex-shell-escalation -p codex-utils-pty -p codex-utils-readiness`
  - `just clippy -p codex-core`
  - `cargo test -p codex-core -p codex-app-server -p codex-rmcp-client -p
  codex-shell-escalation -p codex-utils-pty -p codex-utils-readiness` was
  run; the app-server suite passed, and `codex-core` failed in the local
  sandbox on six otel approval tests plus
  `suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var`,
  which appear to depend on local command approval/default rules and
  `CODEX_SANDBOX_NETWORK_DISABLED=1` in this environment.

  Michael Bolin · 2026-04-17 14:06:50 -07:00
  1265df0ec2
• enable tool search over dynamic tools (#18263)

  ## Summary
  
  - Normalize deferred MCP and dynamic tools into `ToolSearchEntry` values
  before constructing `ToolSearchHandler`.
  - Move the tool-search entry adapter out of `tools/handlers` and into
  `tools/tool_search_entry.rs` so the handlers directory stays focused on
  handlers.
  - Keep `ToolSearchHandler` operating over one generic entry list for
  BM25 search, namespace grouping, and per-bucket default limits.
  
  ## Why
  
  Follow-up cleanup for #17849. The dynamic tool-search support made the
  handler juggle source-specific MCP and dynamic tool lists, index
  arithmetic, output conversion, and namespace emission. This keeps source
  adaptation outside the handler so the search loop itself is smaller and
  source-agnostic.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-core tools::handlers::tool_search::tests`
  - `git diff --check`
  - `cargo test -p codex-core` currently fails in unrelated
  `plugins::manager::tests::list_marketplaces_ignores_installed_roots_missing_from_config`;
  rerunning that single test fails the same way at
  `core/src/plugins/manager_tests.rs:1692`.
  
  ---------
  
  Co-authored-by: pash <pash@openai.com>

  sayan-oai · 2026-04-18 02:07:59 +08:00
  6991be7ead
• Move codex module under session (#18249)

  ## Summary
  - rename the core codex module root to session/mod.rs without using
  #[path]
  - move the codex module directory and tests under core/src/session
  - remove session/mod.rs reexports so call sites use explicit child
  module paths
  
  ## Testing
  - cargo test -p codex-core --lib
  - cargo check -p codex-core --tests
  - just fmt
  - just fix -p codex-core
  - git diff --check

  pakrym-oai · 2026-04-17 16:18:53 +00:00
  71e4c6fa17
• Add PermissionRequest hooks support (#17563)

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

  Abhinav · 2026-04-17 14:45:47 +00:00
  8494e5bd7b
• feat: add opt-in provider runtime abstraction (#17713)

  ## Summary
  
  - Add `codex-model-provider` as the runtime home for model-provider
  behavior that does not belong in `codex-core`, `codex-login`, or
  `codex-api`.
  - The new crate wraps configured `ModelProviderInfo` in a
  `ModelProvider` trait object that can resolve the API provider config,
  provider-scoped auth manager, and request auth provider for each call.
  - This centralizes provider auth behavior in one place today, and gives
  us an extension point for future provider-specific auth, model listing,
  request setup, and related runtime behavior.
  
  ## Tests
  Ran tests manually to make sure that provider auth under different
  configs still work as expected.
  
  ---------
  
  Co-authored-by: pakrym-oai <pakrym@openai.com>

  Celia Chen · 2026-04-17 02:27:45 +00:00
  a803790a10
• Stream apply_patch changes (#17862)

  Adds new events for streaming apply_patch changes from responses api.
  This is to enable clients to show progress during file writes.
  
  Caveat: This does not work with apply_patch in function call mode, since
  that required adding streaming json parsing.

  Akshay Nathan · 2026-04-16 18:12:19 -07:00
  7995c66032
• feat(sandbox): add glob deny-read platform enforcement (#18096)

  ## Summary
  - adds macOS Seatbelt deny rules for unreadable glob patterns
  - expands unreadable glob matches on Linux and masks them in bwrap,
  including canonical symlink targets
  - keeps Linux glob expansion robust when `rg` is unavailable in minimal
  or Bazel test environments
  - adds sandbox integration coverage that runs `shell` and `exec_command`
  with a `**/*.env = none` policy and verifies the secret contents do not
  reach the model
  
  ## Linux glob expansion
  
  ```text
  Prefer:   rg --files --hidden --no-ignore --glob <pattern> -- <search-root>
  Fallback: internal globset walker when rg is not installed
  Failure:  any other rg failure aborts sandbox construction
  ```
  
  ```
  [permissions.workspace.filesystem]
  glob_scan_max_depth = 2
  
  [permissions.workspace.filesystem.":project_roots"]
  "**/*.env" = "none"
  ```
  
  
  This keeps the common path fast without making sandbox construction
  depend on an ambient `rg` binary. If `rg` is present but fails for
  another reason, the sandbox setup fails closed instead of silently
  omitting deny-read masks.
  
  ## Platform support
  - macOS: subprocess sandbox enforcement is handled by Seatbelt regex
  deny rules
  - Linux: subprocess sandbox enforcement is handled by expanding existing
  glob matches and masking them in bwrap
  - Windows: policy/config/direct-tool glob support is already on `main`
  from #15979; Windows subprocess sandbox paths continue to fail closed
  when unreadable split filesystem carveouts require runtime enforcement,
  rather than silently running unsandboxed
  
  ## Stack
  1. #15979 - merged: cross-platform glob deny-read
  policy/config/direct-tool support for macOS, Linux, and Windows
  2. This PR - macOS/Linux subprocess sandbox enforcement plus Windows
  fail-closed clarification
  3. #17740 - managed deny-read requirements
  
  ## Verification
  - Added integration coverage for `shell` and `exec_command` glob
  deny-read enforcement
  - `cargo check -p codex-sandboxing -p codex-linux-sandbox --tests`
  - `cargo check -p codex-core --test all`
  - `cargo clippy -p codex-linux-sandbox -p codex-sandboxing --tests`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-16 17:35:16 -07:00
  0d0abe839a
• feat(permissions): add glob deny-read policy support (#15979)

  ## Summary
  - adds first-class filesystem policy entries for deny-read glob patterns
  - parses config such as :project_roots { "**/*.env" = "none" } into
  pattern entries
  - enforces deny-read patterns in direct read/list helpers
  - fails closed for sandbox execution until platform backends enforce
  glob patterns in #18096
  - preserves split filesystem policy in turn context only when it cannot
  be reconstructed from legacy sandbox policy
  
  ## Stack
  1. This PR - glob deny-read policy/config/direct-tool support
  2. #18096 - macOS and Linux sandbox enforcement
  3. #17740 - managed deny-read requirements
  
  ## Verification
  - just fmt
  - cargo check -p codex-core -p codex-sandboxing --tests
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-16 10:31:51 -07:00
  6862b9c745
• Make yolo skip managed-network tool enforcement (#18042)

  ## Summary
  
  This makes `DangerFullAccess` / yolo tool execution fully opt out of
  managed-network enforcement.
  
  Previously, yolo turns could have `turn.network` stripped while tool
  orchestration still derived `enforce_managed_network=true` from
  `requirements.toml.network`. That created an inconsistent state where
  the turn had no managed proxy attached, but tool execution still behaved
  like managed networking was active.
  
  This updates the tool orchestration and JS REPL paths to treat managed
  networking as active only when the current turn actually has
  `turn.network`.
  
  ## Behavior
  
  - Yolo / `DangerFullAccess`: no managed proxy, no managed-network
  enforcement.
  - Guardian / workspace-write with managed proxy: managed-network
  enforcement still applies.
  - Avoids the half-state where yolo has no proxy but still gets
  managed-network sandbox behavior.
  
  ## Tests
  
  - `just fmt`
  - `cargo test -p codex-core
  danger_full_access_tool_attempts_do_not_enforce_managed_network --
  --nocapture`
  - `cargo test -p codex-core danger_full_access -- --nocapture`
  - `just fix -p codex-core`
  
  Co-authored-by: jgershen-oai <jgershen@openai.com>

  Won Park · 2026-04-16 09:06:10 -07:00
  3a4fa77ad7
• Launch image generation by default (#17153)

  ## Summary
  - Promote `image_generation` from under-development to stable
  - Enable image generation by default in the feature registry
  - Update feature coverage for the new launch-state expectation
  - Add the missing image-generation auth fixture field in a tool registry
  test
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools` currently fails:
  `test_full_toolset_specs_for_gpt5_codex_unified_exec_web_search` needs
  its expected default tool list updated for `image_generation`

  Won Park · 2026-04-16 09:05:38 -07:00
  85203d8872
• [codex][mcp] Add resource uri meta to tool call item. (#17831)

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

  Matthew Zeng · 2026-04-16 05:09:17 +00:00
  224dad41ac
• Async config loading (#18022)

  Parts of config will come from executor. Prepare for that by making
  config loading methods async.

  pakrym-oai · 2026-04-15 19:18:38 -07:00
  bd61737e8a
• [mcp] Add dummy tools for previously called but currently missing tools. (#17853)

  - [x] Add dummy tools for previously called but currently missing tools.
  Currently supporting MCP tools only.

  Matthew Zeng · 2026-04-15 21:48:05 +00:00
  28b76d13fe
• Support original-detail metadata on MCP image outputs (#17714)

  ## Summary
  - honor `_meta["codex/imageDetail"] == "original"` on MCP image content
  and map it to `detail: "original"` where supported
  - strip that detail back out when the active model does not support
  original-detail image inputs
  - update code-mode `image(...)` to accept individual MCP image blocks
  - teach `js_repl` / `codex.emitImage(...)` to preserve the same hint
  from raw MCP image outputs
  - document the new `_meta` contract and add generic RMCP-backed coverage
  across protocol, core, code-mode, and js_repl paths

  Curtis 'Fjord' Hawthorne · 2026-04-15 14:43:33 -07:00
  9e2fc31854
• register all mcp tools with namespace (#17404)

  stacked on #17402.
  
  MCP tools returned by `tool_search` (deferred tools) get registered in
  our `ToolRegistry` with a different format than directly available
  tools. this leads to two different ways of accessing MCP tools from our
  tool catalog, only one of which works for each. fix this by registering
  all MCP tools with the namespace format, since this info is already
  available.
  
  also, direct MCP tools are registered to responsesapi without a
  namespace, while deferred MCP tools have a namespace. this means we can
  receive MCP `FunctionCall`s in both formats from namespaces. fix this by
  always registering MCP tools with namespace, regardless of deferral
  status.
  
  make code mode track `ToolName` provenance of tools so it can map the
  literal JS function name string to the correct `ToolName` for
  invocation, rather than supporting both in core.
  
  this lets us unify to a single canonical `ToolName` representation for
  each MCP tool and force everywhere to use that one, without supporting
  fallbacks.

  sayan-oai · 2026-04-15 21:02:59 +08:00
  0df7e9a820
• nit: stable test (#17924)
  jif-oai · 2026-04-15 12:05:50 +01:00
  544b4e39e3