2460 Commits

• chore: refactor network permissions to use explicit domain and unix socket rule maps (#15120)

  ## Summary
  
  This PR replaces the legacy network allow/deny list model with explicit
  rule maps for domains and unix sockets across managed requirements,
  permissions profiles, the network proxy config, and the app server
  protocol.
  
  Concretely, it:
  
  - introduces typed domain (`allow` / `deny`) and unix socket permission
  (`allow` / `none`) entries instead of separate `allowed_domains`,
  `denied_domains`, and `allow_unix_sockets` lists
  - updates config loading, managed requirements merging, and exec-policy
  overlays to read and upsert rule entries consistently
  - exposes the new shape through protocol/schema outputs, debug surfaces,
  and app-server config APIs
  - rejects the legacy list-based keys and updates docs/tests to reflect
  the new config format
  
  ## Why
  
  The previous representation split related network policy across multiple
  parallel lists, which made merging and overriding rules harder to reason
  about. Moving to explicit keyed permission maps gives us a single source
  of truth per host/socket entry, makes allow/deny precedence clearer, and
  gives protocol consumers access to the full rule state instead of
  derived projections only.
  
  ## Backward Compatibility
  
  ### Backward compatible
  
  - Managed requirements still accept the legacy
  `experimental_network.allowed_domains`,
  `experimental_network.denied_domains`, and
  `experimental_network.allow_unix_sockets` fields. They are normalized
  into the new canonical `domains` and `unix_sockets` maps internally.
  - App-server v2 still deserializes legacy `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` payloads, so older clients can
  continue reading managed network requirements.
  - App-server v2 responses still populate `allowedDomains`,
  `deniedDomains`, and `allowUnixSockets` as legacy compatibility views
  derived from the canonical maps.
  - `managed_allowed_domains_only` keeps the same behavior after
  normalization. Legacy managed allowlists still participate in the same
  enforcement path as canonical `domains` entries.
  
  ### Not backward compatible
  
  - Permissions profiles under `[permissions.<profile>.network]` no longer
  accept the legacy list-based keys. Those configs must use the canonical
  `[domains]` and `[unix_sockets]` tables instead of `allowed_domains`,
  `denied_domains`, or `allow_unix_sockets`.
  - Managed `experimental_network` config cannot mix canonical and legacy
  forms in the same block. For example, `domains` cannot be combined with
  `allowed_domains` or `denied_domains`, and `unix_sockets` cannot be
  combined with `allow_unix_sockets`.
  - The canonical format can express explicit `"none"` entries for unix
  sockets, but those entries do not round-trip through the legacy
  compatibility fields because the legacy fields only represent allow/deny
  lists.
  ## Testing
  `/target/debug/codex sandbox macos --log-denials /bin/zsh -c 'curl
  https://www.example.com' ` gives 200 with config
  ```
  [permissions.workspace.network.domains]
  "www.example.com" = "allow"
  ```
  and fails when set to deny: `curl: (56) CONNECT tunnel failed, response
  403`.
  
  Also tested backward compatibility path by verifying that adding the
  following to `/etc/codex/requirements.toml` works:
  ```
  [experimental_network]
  allowed_domains = ["www.example.com"]
  ```

  Celia Chen · 2026-03-27 06:17:59 +00:00
  dd30c8eedd
• codex-tools: extract MCP schema adapters (#15928)

  ## Why
  
  `codex-tools` already owns the shared tool input schema model and parser
  from the first extraction step, but `core/src/tools/spec.rs` still owned
  the MCP-specific adapter that normalizes `rmcp::model::Tool` schemas and
  wraps `structuredContent` into the call result output schema.
  
  Keeping that adapter in `codex-core` means the reusable MCP schema path
  is still split across crates, and the unit tests for that logic stay
  anchored in `codex-core` even though the runtime orchestration does not
  need to move yet.
  
  This change takes the next small step by moving the reusable MCP schema
  adapter into `codex-tools` while leaving `ResponsesApiTool` assembly in
  `codex-core`.
  
  ## What changed
  
  - added `tools/src/mcp_tool.rs` and sibling
  `tools/src/mcp_tool_tests.rs`
  - introduced `ParsedMcpTool`, `parse_mcp_tool()`, and
  `mcp_call_tool_result_output_schema()` in `codex-tools`
  - updated `core/src/tools/spec.rs` to consume parsed MCP tool parts from
  `codex-tools`
  - removed the now-redundant MCP schema unit tests from
  `core/src/tools/spec_tests.rs`
  - expanded `codex-rs/tools/README.md` to describe this second migration
  step
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib tools::spec::`

  Michael Bolin · 2026-03-26 19:57:26 -07:00
  be5afc65d3
• feat(windows-sandbox): add network proxy support (#12220)

  ## Summary
  
  This PR makes Windows sandbox proxying enforceable by routing proxy-only
  runs through the existing `offline` sandbox user and reserving direct
  network access for the existing `online` sandbox user.
  
  In brief:
  
  - if a Windows sandbox run should be proxy-enforced, we run it as the
  `offline` user
  - the `offline` user gets firewall rules that block direct outbound
  traffic and only permit the configured localhost proxy path
  - if a Windows sandbox run should have true direct network access, we
  run it as the `online` user
  - no new sandbox identity is introduced
  
  This brings Windows in line with the intended model: proxy use is not
  just env-based, it is backed by OS-level egress controls. Windows
  already has two sandbox identities:
  
  - `offline`: intended to have no direct network egress
  - `online`: intended to have full network access
  
  This PR makes proxy-enforced runs use that model directly.
  
  ### Proxy-enforced runs
  
  When proxy enforcement is active:
  
  - the run is assigned to the `offline` identity
  - setup extracts the loopback proxy ports from the sandbox env
  - Windows setup programs firewall rules for the `offline` user that:
    - block all non-loopback outbound traffic
    - block loopback UDP
    - block loopback TCP except for the configured proxy ports
  - optionally allow broader localhost access when `allow_local_binding=1`
  
  So the sandboxed process can only talk to the local proxy. It cannot
  open direct outbound sockets or do local UDP-based DNS on its own.The
  proxy then performs the real outbound network access outside that
  restricted sandbox identity.
  
  ### Direct-network runs
  
  When proxy enforcement is not active and full network access is allowed:
  
  - the run is assigned to the `online` identity
  - no proxy-only firewall restrictions are applied
  - the process gets normal direct network access
  
  ### Unelevated vs elevated
  
  The restricted-token / unelevated path cannot enforce per-identity
  firewall policy by itself.
  
  So for Windows proxy-enforced runs, we transparently use the logon-user
  sandbox path under the hood, even if the caller started from the
  unelevated mode. That keeps enforcement real instead of best-effort.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-03-26 17:27:38 -07:00
  81fa04783a
• permissions: remove macOS seatbelt extension profiles (#15918)

  ## Why
  
  `PermissionProfile` should only describe the per-command permissions we
  still want to grant dynamically. Keeping
  `MacOsSeatbeltProfileExtensions` in that surface forced extra macOS-only
  approval, protocol, schema, and TUI branches for a capability we no
  longer want to expose.
  
  ## What changed
  
  - Removed the macOS-specific permission-profile types from
  `codex-protocol`, the app-server v2 API, and the generated
  schema/TypeScript artifacts.
  - Deleted the core and sandboxing plumbing that threaded
  `MacOsSeatbeltProfileExtensions` through execution requests and seatbelt
  construction.
  - Simplified macOS seatbelt generation so it always includes the fixed
  read-only preferences allowlist instead of carrying a configurable
  profile extension.
  - Removed the macOS additional-permissions UI/docs/test coverage and
  deleted the obsolete macOS permission modules.
  - Tightened `request_permissions` intersection handling so explicitly
  empty requested read lists are preserved only when that field was
  actually granted, avoiding zero-grant responses being stored as active
  permissions.

  Michael Bolin · 2026-03-26 17:12:45 -07:00
  e6e2999209
• codex-tools: extract shared tool schema parsing (#15923)

  ## Why
  
  `parse_tool_input_schema` and the supporting `JsonSchema` model were
  living in `core/src/tools/spec.rs`, but they already serve callers
  outside `codex-core`.
  
  Keeping that shared schema parsing logic inside `codex-core` makes the
  crate boundary harder to reason about and works against the guidance in
  `AGENTS.md` to avoid growing `codex-core` when reusable code can live
  elsewhere.
  
  This change takes the first extraction step by moving the schema parsing
  primitive into its own crate while keeping the rest of the tool-spec
  assembly in `codex-core`.
  
  ## What changed
  
  - added a new `codex-tools` crate under `codex-rs/tools`
  - moved the shared tool input schema model and sanitizer/parser into
  `tools/src/json_schema.rs`
  - kept `tools/src/lib.rs` exports-only, with the module-level unit tests
  split into `json_schema_tests.rs`
  - updated `codex-core` to use `codex-tools::JsonSchema` and re-export
  `parse_tool_input_schema`
  - updated `codex-app-server` dynamic tool validation to depend on
  `codex-tools` directly instead of reaching through `codex-core`
  - wired the new crate into the Cargo workspace and Bazel build graph

  Michael Bolin · 2026-03-27 00:03:35 +00:00
  44d28f500f
• chore: remove skill metadata from command approval payloads (#15906)

  ## Why
  
  This is effectively a follow-up to
  [#15812](https://github.com/openai/codex/pull/15812). That change
  removed the special skill-script exec path, but `skill_metadata` was
  still being threaded through command-approval payloads even though the
  approval flow no longer uses it to render prompts or resolve decisions.
  
  Keeping it around added extra protocol, schema, and client surface area
  without changing behavior.
  
  Removing it keeps the command-approval contract smaller and avoids
  carrying a dead field through app-server, TUI, and MCP boundaries.
  
  ## What changed
  
  - removed `ExecApprovalRequestSkillMetadata` and the corresponding
  `skillMetadata` field from core approval events and the v2 app-server
  protocol
  - removed the generated JSON and TypeScript schema output for that field
  - updated app-server, MCP server, TUI, and TUI app-server approval
  plumbing to stop forwarding the field
  - cleaned up tests that previously constructed or asserted
  `skillMetadata`
  
  ## Testing
  
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-app-server-test-client`
  - `cargo test -p codex-mcp-server`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-26 15:32:03 -07:00
  5906c6a658
• chore: move bwrap config helpers into dedicated module (#15898)

  ## Summary
  - move the bwrap PATH lookup and warning helpers out of config/mod.rs
  - move the related tests into a dedicated bwrap_tests.rs file
  
  ## Validation
  - git diff --check
  - skipped heavier local tests per request
  
  Follow-up to #15791.

  viyatb-oai · 2026-03-26 15:15:59 -07:00
  b52abff279
• sandboxing: use OsString for SandboxCommand.program (#15897)

  ## Why
  
  `SandboxCommand.program` represents an executable path, but keeping it
  as `String` forced path-backed callers to run `to_string_lossy()` before
  the sandbox layer ever touched the command. That loses fidelity earlier
  than necessary and adds avoidable conversions in runtimes that already
  have a `PathBuf`.
  
  ## What changed
  
  - Changed `SandboxCommand.program` to `OsString`.
  - Updated `SandboxManager::transform` to keep the program and argv in
  `OsString` form until the `SandboxExecRequest` conversion boundary.
  - Switched the path-backed `apply_patch` and `js_repl` runtimes to pass
  `into_os_string()` instead of `to_string_lossy()`.
  - Updated the remaining string-backed builders and tests to match the
  new type while preserving the existing Linux helper `arg0` behavior.
  
  ## Verification
  
  - `cargo test -p codex-sandboxing`
  - `just argument-comment-lint -p codex-core -p codex-sandboxing`
  - `cargo test -p codex-core` currently fails in unrelated existing
  config tests: `config::tests::approvals_reviewer_*` and
  `config::tests::smart_approvals_alias_*`

  Michael Bolin · 2026-03-26 20:38:33 +00:00
  dfb36573cd
• [codex] import token_data from codex-login directly (#15903)

  ## Why
  `token_data` is owned by `codex-login`, but `codex-core` was still
  re-exporting it. That let callers pull auth token types through
  `codex-core`, which keeps otherwise unrelated crates coupled to
  `codex-core` and makes `codex-core` more of a build-graph bottleneck.
  
  ## What changed
  - remove the `codex-core` re-export of `codex_login::token_data`
  - update the remaining `codex-core` internals that used
  `crate::token_data` to import `codex_login::token_data` directly
  - update downstream callers in `codex-rs/chatgpt`,
  `codex-rs/tui_app_server`, `codex-rs/app-server/tests/common`, and
  `codex-rs/core/tests` to import `codex_login::token_data` directly
  - add explicit `codex-login` workspace dependencies and refresh lock
  metadata for crates that now depend on it directly
  
  ## Validation
  - `cargo test -p codex-chatgpt --locked`
  - `just argument-comment-lint`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ## Notes
  - attempted `cargo test -p codex-core --locked` and `cargo test -p
  codex-core auth_refresh --locked`, but both ran out of disk while
  linking `codex-core` test binaries in the local environment

  Michael Bolin · 2026-03-26 13:34:02 -07:00
  b23789b770
• Protect first-time project .codex creation across Linux and macOS sandboxes (#15067)

  ## Problem
  
  Codex already treated an existing top-level project `./.codex` directory
  as protected, but there was a gap on first creation.
  
  If `./.codex` did not exist yet, a turn could create files under it,
  such as `./.codex/config.toml`, without going through the same approval
  path as later modifications. That meant the initial write could bypass
  the intended protection for project-local Codex state.
  
  ## What this changes
  
  This PR closes that first-creation gap in the Unix enforcement layers:
  
  - `codex-protocol`
  - treat the top-level project `./.codex` path as a protected carveout
  even when it does not exist yet
  - avoid injecting the default carveout when the user already has an
  explicit rule for that exact path
  - macOS Seatbelt
  - deny writes to both the exact protected path and anything beneath it,
  so creating `./.codex` itself is blocked in addition to writes inside it
  - Linux bubblewrap
  - preserve the same protected-path behavior for first-time creation
  under `./.codex`
  - tests
  - add protocol regressions for missing `./.codex` and explicit-rule
  collisions
  - add Unix sandbox coverage for blocking first-time `./.codex` creation
    - tighten Seatbelt policy assertions around excluded subpaths
  
  ## Scope
  
  This change is intentionally scoped to protecting the top-level project
  `.codex` subtree from agent writes.
  
  It does not make `.codex` unreadable, and it does not change the product
  behavior around loading project skills from `.codex` when project config
  is untrusted.
  
  ## Why this shape
  
  The fix is pointed rather than broad:
  - it preserves the current model of “project `.codex` is protected from
  writes”
  - it closes the security-relevant first-write hole
  - it avoids folding a larger permissions-model redesign into this PR
  
  ## Validation
  
  - `cargo test -p codex-protocol`
  - `cargo test -p codex-sandboxing seatbelt`
  - `cargo test -p codex-exec --test all
  sandbox_blocks_first_time_dot_codex_creation -- --nocapture`
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  rreichel3-oai · 2026-03-26 16:06:53 -04:00
  86764af684
• skills: remove unused skill permission metadata (#15900)

  ## Why
  
  Skill metadata accepted a `permissions` block and stored the result on
  `SkillMetadata`, but that data was never consumed by runtime behavior.
  Leaving the dead parsing path in place makes it look like skills can
  widen or otherwise influence execution permissions when, in practice,
  declared skill permissions are ignored.
  
  This change removes that misleading surface area so the skill metadata
  model matches what the system actually uses.
  
  ## What changed
  
  - removed `permission_profile` and `managed_network_override` from
  `core-skills::SkillMetadata`
  - stopped parsing `permissions` from skill metadata in
  `core-skills/src/loader.rs`
  - deleted the loader tests that only exercised the removed permissions
  parsing path
  - cleaned up dependent `SkillMetadata` constructors in tests and TUI
  code that were only carrying `None` for those fields
  
  ## Testing
  
  - `cargo test -p codex-core-skills`
  - `cargo test -p codex-tui
  submission_prefers_selected_duplicate_skill_path`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-26 19:33:23 +00:00
  b3e069e8cb
• fix: resolve bwrap from trusted PATH entry (#15791)

  ## Summary
  - resolve system bwrap from PATH instead of hardcoding /usr/bin/bwrap
  - skip PATH entries that resolve inside the current workspace before
  launching the sandbox helper
  - keep the vendored bubblewrap fallback when no trusted system bwrap is
  found
  
  ## Validation
  - cargo test -p codex-core bwrap --lib
  - cargo test -p codex-linux-sandbox
  - just fix -p codex-core
  - just fix -p codex-linux-sandbox
  - just fmt
  - just argument-comment-lint
  - cargo clean

  viyatb-oai · 2026-03-26 12:13:51 -07:00
  b6050b42ae
• [plugins] Polish tool suggest prompts. (#15891)

  - [x] Polish tool suggest prompts to distinguish between missing
  connectors and discoverable plugins, and be very precise about the
  triggering conditions.

  Matthew Zeng · 2026-03-26 18:52:59 +00:00
  3360f128f4
• [mcp] Fix legacy_tools (#15885)

  - [x] Fix legacy_tools

  Matthew Zeng · 2026-03-26 11:08:49 -07:00
  25134b592c
• fix: root as std agent (#15881)
  jif-oai · 2026-03-26 18:57:34 +01:00
  970386e8b2
• fix: box apply_patch test harness futures (#15835)

  ## Why
  
  `#[large_stack_test]` made the `apply_patch_cli` tests pass by giving
  them more stack, but it did not address why those tests needed the extra
  stack in the first place.
  
  The real problem is the async state built by the `apply_patch_cli`
  harness path. Those tests await three helper boundaries directly:
  harness construction, turn submission, and apply-patch output
  collection. If those helpers inline their full child futures, the test
  future grows to include the whole harness startup and request/response
  path.
  
  This change replaces the workaround from #12768 with the same basic
  approach used in #13429, but keeps the fix narrower: only the helper
  boundaries awaited directly by `apply_patch_cli` stay boxed.
  
  ## What Changed
  
  - removed `#[large_stack_test]` from
  `core/tests/suite/apply_patch_cli.rs`
  - restored ordinary `#[tokio::test(flavor = "multi_thread",
  worker_threads = 2)]` annotations in that suite
  - deleted the now-unused `codex-test-macros` crate and removed its
  workspace wiring
  - boxed only the three helper boundaries that the suite awaits directly:
    - `apply_patch_harness_with(...)`
    - `TestCodexHarness::submit(...)`
    - `TestCodexHarness::apply_patch_output(...)`
  - added comments at those boxed boundaries explaining why they remain
  boxed
  
  ## Testing
  
  - `cargo test -p codex-core --test all suite::apply_patch_cli --
  --nocapture`
  
  ## References
  
  - #12768
  - #13429

  Michael Bolin · 2026-03-26 17:32:04 +00:00
  e36ebaa3da
• Add MCP connector metrics (#15805)

  ## Summary
  - enrich `codex.mcp.call` with `tool`, `connector_id`, and sanitized
  `connector_name` for actual MCP executions
  - record `codex.mcp.call.duration_ms` for actual MCP executions so
  connector-level latency is visible in metrics
  - keep skipped, blocked, declined, and cancelled paths on the plain
  status-only `codex.mcp.call` counter
  
  ## Included Changes
  - `codex-rs/core/src/mcp_tool_call.rs`: add connector-sliced MCP count
  and duration metrics only for executed tool calls, while leaving
  non-executed outcomes as status-only counts
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: cover metric tag shaping,
  connector-name sanitization, and the new duration metric tags
  
  ## Testing
  - `cargo test -p codex-core`
  - `just fix -p codex-core`
  - `just fmt`
  
  ## Notes
  - `cargo test -p codex-core` still hits existing unrelated failures in
  approvals-reviewer config tests and the sandboxed JS REPL `mktemp` test
  - full workspace `cargo test` was not run
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  nicholasclark-openai · 2026-03-26 17:08:02 +00:00
  8d479f741c
• fix: max depth agent still has v2 tools (#15880)
  jif-oai · 2026-03-26 17:36:12 +01:00
  352f37db03
• [plugins] Update the suggestable plugins list. (#15829)

  - [x] Update the suggestable plugins list to be featured plugins.

  Matthew Zeng · 2026-03-26 15:53:22 +00:00
  c9214192c5
• feat: use ProcessId in exec-server (#15866)

  Use a full struct for the ProcessId to increase readability and make it
  easier in the future to make it evolve if needed

  jif-oai · 2026-03-26 16:45:36 +01:00
  6d2f4aaafc
• fix: flaky (#15869)
  jif-oai · 2026-03-26 16:07:32 +01:00
  26c66f3ee1
• core: remove special execve handling for skill scripts (#15812)
  Michael Bolin · 2026-03-26 07:46:04 -07:00
  01fa4f0212
• feat: exec-server prep for unified exec (#15691)

  This PR partially rebase `unified_exec` on the `exec-server` and adapt
  the `exec-server` accordingly.
  
  ## What changed in `exec-server`
  
  1. Replaced the old "broadcast-driven; process-global" event model with
  process-scoped session events. The goal is to be able to have dedicated
  handler for each process.
  2. Add to protocol contract to support explicit lifecycle status and
  stream ordering:
  - `WriteResponse` now returns `WriteStatus` (Accepted, UnknownProcess,
  StdinClosed, Starting) instead of a bool.
    - Added seq fields to output/exited notifications.
    - Added terminal process/closed notification.
  3. Demultiplexed remote notifications into per-process channels. Same as
  for the event sys
  4. Local and remote backends now both implement ExecBackend.
  5. Local backend wraps internal process ID/operations into per-process
  ExecProcess objects.
  6. Remote backend registers a session channel before launch and
  unregisters on failed launch.
  
  ## What changed in `unified_exec`
  
  1. Added unified process-state model and backend-neutral process
  wrapper. This will probably disappear in the future, but it makes it
  easier to keep the work flowing on both side.
  - `UnifiedExecProcess` now handles both local PTY sessions and remote
  exec-server processes through a shared `ProcessHandle`.
  - Added `ProcessState` to track has_exited, exit_code, and terminal
  failure message consistently across backends.
  2. Routed write and lifecycle handling through process-level methods.
  
  ## Some rationals
  
  1. The change centralizes execution transport in exec-server while
  preserving policy and orchestration ownership in core, avoiding
  duplicated launch approval logic. This comes from internal discussion.
  2. Session-scoped events remove coupling/cross-talk between processes
  and make stream ordering and terminal state explicit (seq, closed,
  failed).
  3. The failure-path surfacing (remote launch failures, write failures,
  transport disconnects) makes command tool output and cleanup behavior
  deterministic
  
  ## Follow-ups:
  * Unify the concept of thread ID behind an obfuscated struct
  * FD handling
  * Full zsh-fork compatibility
  * Full network sandboxing compatibility
  * Handle ws disconnection

  jif-oai · 2026-03-26 15:22:34 +01:00
  7dac332c93
• feat: clean spawn v1 (#15861)

  Avoid the usage of path in the v1 spawn

  jif-oai · 2026-03-26 15:01:00 +01:00
  4a5635b5a0
• feat: drop artifact tool and feature (#15851)
  jif-oai · 2026-03-26 13:21:24 +01:00
  b00a05c785
• feat: replace askama by custom lib (#15784)

  Finalise the drop of `askama` to use our internal lib instead

  jif-oai · 2026-03-26 10:33:25 +01:00
  7ef3cfe63e
• fix: fix old system bubblewrap compatibility without falling back to vendored bwrap (#15693)

  Fixes #15283.
  
  ## Summary
  Older system bubblewrap builds reject `--argv0`, which makes our Linux
  sandbox fail before the helper can re-exec. This PR keeps using system
  `/usr/bin/bwrap` whenever it exists and only falls back to vendored
  bwrap when the system binary is missing. That matters on stricter
  AppArmor hosts, where the distro bwrap package also provides the policy
  setup needed for user namespaces.
  
  For old system bwrap, we avoid `--argv0` instead of switching binaries:
  - pass the sandbox helper a full-path `argv0`,
  - keep the existing `current_exe() + --argv0` path when the selected
  launcher supports it,
  - otherwise omit `--argv0` and re-exec through the helper's own
  `argv[0]` path, whose basename still dispatches as
  `codex-linux-sandbox`.
  
  Also updates the launcher/warning tests and docs so they match the new
  behavior: present-but-old system bwrap uses the compatibility path, and
  only absent system bwrap falls back to vendored.
  
  ### Validation
  
  1. Install Ubuntu 20.04 in a VM
  2. Compile codex and run without bubblewrap installed - see a warning
  about falling back to the vendored bwrap
  3. Install bwrap and verify version is 0.4.0 without `argv0` support
  4. run codex and use apply_patch tool without errors
  
  <img width="802" height="631" alt="Screenshot 2026-03-25 at 11 48 36 PM"
  src="https://github.com/user-attachments/assets/77248a29-aa38-4d7c-9833-496ec6a458b8"
  />
  <img width="807" height="634" alt="Screenshot 2026-03-25 at 11 47 32 PM"
  src="https://github.com/user-attachments/assets/5af8b850-a466-489b-95a6-455b76b5050f"
  />
  <img width="812" height="635" alt="Screenshot 2026-03-25 at 11 45 45 PM"
  src="https://github.com/user-attachments/assets/438074f0-8435-4274-a667-332efdd5cb57"
  />
  <img width="801" height="623" alt="Screenshot 2026-03-25 at 11 43 56 PM"
  src="https://github.com/user-attachments/assets/0dc8d3f5-e8cf-4218-b4b4-a4f7d9bf02e3"
  />
  
  ---------
  
  Co-authored-by: Michael Bolin <mbolin@openai.com>

  viyatb-oai · 2026-03-25 23:51:39 -07:00
  937cb5081d
• [hooks] add non-streaming (non-stdin style) shell-only PostToolUse support (#15531)

  CHAINED PR - note that base is eternal/hooks-pretooluse-bash, not main
  -- so the following PR should be first
  
  Matching post-tool hook to the pre-tool functionality here:
  https://github.com/openai/codex/pull/15211
  
  So, PreToolUse calls for plain shell calls, allows blocking. This
  PostToolUse call runs after the command executed
  
  example run:
  
  ```
  › as a test, run in parallel the following commands:
    - echo 'one'
    - echo '[block-pre-tool-use]'
    - echo '[block-post-tool-use]'
  
  
  ⚠ MCP startup incomplete (failed: notion, linear)
  
  • Cruising through those three commands in parallel now, and I’ll share the exact outputs right after
    they land.
  
  • Running PreToolUse hook: checking the observatory runes
  
  • Running PreToolUse hook: checking the observatory runes
  
  • Running PreToolUse hook: checking the observatory runes
  
  PreToolUse hook (blocked)
    warning: wizard-tower PreToolUse demo blocked a Bash command on purpose.
    feedback: PreToolUse demo blocked the command. Remove [block-pre-tool-use] to continue.
  
  PreToolUse hook (completed)
    warning: wizard-tower PreToolUse demo inspected Bash: echo 'one'
  
  PreToolUse hook (completed)
    warning: wizard-tower PreToolUse demo inspected Bash: echo '[block-post-tool-use]'
  
  • Ran echo '[block-post-tool-use]'
    └ [block-post-tool-use]
  
  • Ran echo 'one'
    └ one
  
  • Running PostToolUse hook: reading the observatory aftermath
  
  • Running PostToolUse hook: reading the observatory aftermath
  
  PostToolUse hook (blocked)
    warning: wizard-tower PostToolUse demo blocked the Bash follow-through on purpose.
    feedback: PostToolUse demo blocked the result after execution. Remove [block-post-tool-use] to
  continue.
  
  PostToolUse hook (completed)
    warning: wizard-tower PostToolUse demo inspected Bash: echo 'one'
    hook context: PostToolUse demo saw the Bash result. Response preview: one
  
  ──────────────────────────────────────────────────────────────────────────────────────────────────────
  
  • Ran them in parallel. Little wave report:
  
    - echo 'one' completed and returned one.
    - echo '[block-pre-tool-use]' was blocked before execution by the PreToolUse hook.
    - echo '[block-post-tool-use]' ran, but its result was blocked afterward by the PostToolUse hook.
  
    The hook messages were:
  
    - PreToolUse demo blocked the command. Remove [block-pre-tool-use] to continue.
    - PostToolUse demo blocked the result after execution. Remove [block-post-tool-use] to continue.
  
  
  › for the blocked messages (correctly blocked in this test) did the tool output land back into
    context?
  
  
  • Yeah, from this run:
  
    - PreToolUse block: the command itself did not execute, so no command output landed in context. Only
      the block message did.
    - PostToolUse block: the command did execute, but the actual stdout did not come back into context.
      Only the post-tool block message did.
  
    So the blocked notifications landed in context, but the blocked command payloads themselves did not.
    Nice clean guardrail, aloha.
  ```

  Andrei Eternal · 2026-03-25 19:18:03 -07:00
  c4d9887f9a
• [mcp] Improve custom MCP elicitation (#15800)

  - [x] Support don't ask again for custom MCP tool calls.
  - [x] Don't run arc in yolo mode.
  - [x] Run arc for custom MCP tools in always allow mode.

  Matthew Zeng · 2026-03-26 01:02:37 +00:00
  78799c1bcf
• Add cached environment manager for exec server URL (#15785)

  Add environment manager that is a singleton and is created early in
  app-server (before skill manager, before config loading).
  
  Use an environment variable to point to a running exec server.

  pakrym-oai · 2026-03-25 16:14:36 -07:00
  8fa88fa8ca
• TUI plugin menu polish (#15802)

  - Add "OpenAI Curated" display name for `openai-curated` marketplace
  - Hide /apps menu
  - Change app install phase display text

  canvrno-oai · 2026-03-25 16:09:19 -07:00
  f24c55f0d5
• Add MCP tool call spans (#15659)

  ## Summary
  - add an explicit `mcp.tools.call` span around MCP tool execution in
  core
  - keep MCP span validation local to `mcp_tool_call_tests` instead of
  broadening the integration test suite
  - inline the turn/session correlation fields directly in the span
  initializer
  
  ## Included Changes
  - `codex-rs/core/src/mcp_tool_call.rs`: wrap the existing MCP tool call
  in `mcp.tools.call` and inline `conversation.id`, `session.id`, and
  `turn.id` in the span initializer
  - `codex-rs/core/src/mcp_tool_call_tests.rs`: assert the MCP span
  records the expected correlation and server fields
  
  ## Testing
  - `cargo test -p codex-core`
  - `just fmt`
  
  ## Notes
  - `cargo test -p codex-core` still hits existing unrelated failures in
  guardian-config tests and the sandboxed JS REPL `mktemp` test
  - metric work moved to stacked PR #15792
  - transport-level RMCP spans and trace propagation remain in stacked PR
  #15792
  - full workspace `cargo test` was not run
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  nicholasclark-openai · 2026-03-25 22:13:02 +00:00
  b6524514c1
• Extract codex-core-skills crate (#15749)

  ## Summary
  - move skill loading and management into codex-core-skills
  - leave codex-core with the thin integration layer and shared wiring
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 12:57:42 -07:00
  9dbe098349
• [apps][tool_suggest] Remove tool_suggest's dependency on tool search. (#14856)

  - [x] Remove tool_suggest's dependency on tool search.

  Matthew Zeng · 2026-03-25 12:26:02 -07:00
  91337399fe
• Clarify codex_home base for MDM path resolution (#15707)

  ## Summary
  
  Add the follow up code comment Michael asked for at the MDM
  `managed_config_from_mdm` - a follow up from
  https://github.com/openai/codex/pull/15351.
  
  ## Validation
  
  1. `cargo fmt --all --check`
  2. `cargo test -p codex-core
  managed_preferences_expand_home_directory_in_workspace_write_roots --
  --nocapture`
  3. `cargo test -p codex-core
  write_value_succeeds_when_managed_preferences_expand_home_directory_paths
  -- --nocapture`
  4. `./tools/argument-comment-lint/run-prebuilt-linter.sh -p codex-core`

  evawong-oai · 2026-03-25 18:40:43 +00:00
  6566ab7e02
• Extract codex-analytics crate (#15748)

  ## Summary
  - move the analytics events client into codex-analytics
  - update codex-core and app-server callsites to use the new crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:08:05 -07:00
  d273efc0f3
• Extract codex-plugin crate (#15747)

  ## Summary
  - extract plugin identifiers and load-outcome types into codex-plugin
  - update codex-core to consume the new plugin crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:07:31 -07:00
  2bb1027e37
• Extract codex-utils-plugins crate (#15746)

  ## Summary
  - extract shared plugin path and manifest helpers into
  codex-utils-plugins
  - update codex-core to consume the utility crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 11:05:35 -07:00
  ad74543a6f
• Extract codex-instructions crate (#15744)

  ## Summary
  - extract instruction fragment and user-instruction types into
  codex-instructions
  - update codex-core to consume the new crate
  
  ## Testing
  - CI
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Ahmed Ibrahim · 2026-03-25 10:43:49 -07:00
  fba3c79885
• chore: remove read_file handler (#15773)

  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-03-25 16:27:32 +00:00
  14c35a16a8
• Use AbsolutePathBuf for cwd state (#15710)

  Migrate `cwd` and related session/config state to `AbsolutePathBuf` so
  downstream consumers consistently see absolute working directories.
  
  Add test-only `.abs()` helpers for `Path`, `PathBuf`, and `TempDir`, and
  update branch-local tests to use them instead of
  `AbsolutePathBuf::try_from(...)`.
  
  For the remaining TUI/app-server snapshot coverage that renders absolute
  cwd values, keep the snapshots unchanged and skip the Windows-only cases
  where the platform-specific absolute path layout differs.

  pakrym-oai · 2026-03-25 16:02:22 +00:00
  504aeb0e09
• chore: remove grep_files handler (#15775)

  # External (non-OpenAI) Pull Request Requirements
  
  Before opening this Pull Request, please read the dedicated
  "Contributing" markdown file or your PR may be closed:
  https://github.com/openai/codex/blob/main/docs/contributing.md
  
  If your PR conforms to our contribution guidelines, replace this text
  with a detailed and high quality description of your changes.
  
  Include a link to a bug report or enhancement request.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-03-25 16:01:45 +00:00
  178c3b15b4
• fix(core): default approval behavior for mcp missing annotations (#15519)

  - Changed `requires_mcp_tool_approval` to apply MCP spec defaults when
  annotations are missing.
  - Unannotated tools now default to:
    - `readOnlyHint = false`
    - `destructiveHint = true`
    - `openWorldHint = true`
  - This means unannotated MCP tools now go through approval/ARC
  monitoring instead of silently bypassing it.
  - Explicitly read-only tools still skip approval unless they are also
  explicitly marked destructive.
  
  **Previous behavior**
  Failed open for missing annotations, which was unsafe for custom MCP
  tools that omitted or forgot annotations.
  
  ---------
  
  Co-authored-by: colby-oai <228809017+colby-oai@users.noreply.github.com>

  Fouad Matin · 2026-03-25 07:55:41 -07:00
  32c4993c8a
• chore: tty metric (#15766)
  jif-oai · 2026-03-25 13:34:43 +00:00
  047ea642d2
• [plugins] Add a flag for tool search. (#15722)

  - [x] Add a flag for tool search.

  Matthew Zeng · 2026-03-25 07:00:25 +00:00
  e590fad50b
• fix: support split carveouts in windows restricted-token sandbox (#14172)

  ## Summary
  - keep legacy Windows restricted-token sandboxing as the supported
  baseline
  - support the split-policy subset that restricted-token can enforce
  directly today
  - support full-disk read, the same writable root set as legacy
  `WorkspaceWrite`, and extra read-only carveouts under those writable
  roots via additional deny-write ACLs
  - continue to fail closed for unsupported split-only shapes, including
  explicit unreadable (`none`) carveouts, reopened writable descendants
  under read-only carveouts, and writable root sets that do not match the
  legacy workspace roots
  
  ## Example
  Given a filesystem policy like:
  
  ```toml
  ":root" = "read"
  ":cwd" = "write"
  "./docs" = "read"
  ```
  
  the restricted-token backend can keep the workspace writable while
  denying writes under `docs` by layering an extra deny-write carveout on
  top of the legacy workspace-write roots.
  
  A policy like:
  
  ```toml
  "/workspace" = "write"
  "/workspace/docs" = "read"
  "/workspace/docs/tmp" = "write"
  ```
  
  still fails closed, because the unelevated backend cannot reopen the
  nested writable descendant safely.
  
  ## Stack
  -> fix: support split carveouts in windows restricted-token sandbox
  #14172
  fix: support split carveouts in windows elevated sandbox #14568

  viyatb-oai · 2026-03-24 22:54:18 -07:00
  95ba762620
• [plugins] Flip on additional flags. (#15719)

  - [x] Flip on additional flags.

  Matthew Zeng · 2026-03-24 21:52:11 -07:00
  8c62829a2b
• [plugins] Flip the flags. (#15713)

  - [x] Flip the `plugins` and `apps` flags.

  Matthew Zeng · 2026-03-25 03:31:21 +00:00
  0bff38c54a
• [codex] Defer fork context injection until first turn (#15699)

  ## Summary
  - remove the fork-startup `build_initial_context` injection
  - keep the reconstructed `reference_context_item` as the fork baseline
  until the first real turn
  - update fork-history tests and the request snapshot, and add a
  `TODO(ccunningham)` for remaining nondiffable initial-context inputs
  
  ## Why
  Fork startup was appending current-session initial context immediately
  after reconstructing the parent rollout, then the first real turn could
  emit context updates again. That duplicated model-visible context in the
  child rollout.
  
  ## Impact
  Forked sessions now behave like resume for context seeding: startup
  reconstructs history and preserves the prior baseline, and the first
  real turn handles any current-session context emission.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-24 18:34:44 -07:00
  d72fa2a209
• Extract rollout into its own crate (#15548)
  Ahmed Ibrahim · 2026-03-24 18:10:53 -07:00
  2e03d8b4d2