3055 Commits

• Add hooks/list app-server RPC (#19778)

  ## Why
  
  We need a way to list the available hooks to expose via the TUI and App
  so users can view and manage their hooks
  
  ## What
  
  - Adds `hooks/list` for one or more `cwd` values that returns discovered
  hook metadata
  
  ## Stack
  
  1. openai/codex#19705
  2. This PR - openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Review Notes
  
  The generated schema files account for most of the raw diff, these files
  have the core change:
  
  - `hooks/src/engine/discovery.rs` builds the inventory entries during
  hook discovery while leaving runtime handlers focused on execution.
  - `app-server/src/codex_message_processor.rs` wires `hooks/list` into
  the app-server flow for each requested `cwd`.
  - `app-server-protocol/src/protocol/v2.rs` defines the new v2
  request/response payloads exposed on the wire.
  
  ### Core Changes
  
  `core/src/plugins/manager.rs` adds `plugins_for_layer_stack(...)` so
  `skills/list` and `hooks/list`can resolve plugin state for each
  requested `cwd`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-29 23:39:57 +00:00
  8774229a89
• stop blocking unified_exec on Windows (#19435)

  ## Summary
  - remove the Windows-specific unified-exec environment block from tool
  selection
  - keep `unified_exec` default-off on Windows unless the feature is
  explicitly enabled
  - normalize model-provided `shell_type = unified_exec` to
  `shell_command` when the feature is disabled
  - drop obsolete tests tied to the removed environment gate and keep the
  feature-flag regression coverage
  
  ## Why
  Now that the session/long-lived process backend is implemented for the
  Windows sandbox, we don't need to hard disable it anymore. We will be
  rolling out slowly using a feature gate.
  
  ## Impact
  This allows manual Windows opt-in in CLI and app-backed flows while
  preserving the existing default-off behavior for Windows users.
  
  ---------
  
  Co-authored-by: canvrno-oai <kbond@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  iceweasel-oai · 2026-04-29 16:06:33 -07:00
  13dbcda28f
• Add codex-core public API listing (#20243)

  Summary:
  - Add a checked-in codex-core public API listing generated by
  cargo-public-api.
  - Add scripts/regen-public-api.sh with an embedded crate list,
  auto-install for cargo-public-api 0.51.0, pinned nightly, and --check
  mode.
  - Add Rust CI jobs on the codex Linux x64 runner pool to verify the
  listing stays up to date.
  
  Testing:
  - bash -n scripts/regen-public-api.sh
  - just regen-public-api --check
  - yq '.' .github/workflows/rust-ci.yml
  .github/workflows/rust-ci-full.yml
  - git diff --check

  pakrym-oai · 2026-04-29 22:58:08 +00:00
  8de2a7a16d
• [mcp] Fix plugin MCP approval policy. (#19537)

  Plugin MCP servers are loaded from plugin manifests rather than
  top-level `[mcp_servers]`, so their tool approval preferences need to be
  stored and applied through the owning plugin config. Without this,
  choosing "Always allow" for a plugin MCP tool could write a preference
  that was not reliably used on later tool calls.
  
  ## Summary
  - Add plugin-scoped MCP policy config under
  `plugins.<plugin>.mcp_servers`, including server enablement, tool
  allow/deny lists, server defaults, and per-tool approval modes.
  - Overlay plugin MCP policy onto manifest-provided server configs when
  plugins are loaded.
  - Route persistent "Always allow" writes for plugin MCP tools back to
  the owning `plugins.<plugin>.mcp_servers.<server>.tools.<tool>` config
  entry.
  - Reload user config after persisting an approval and make the plugin
  load cache config-aware so stale plugin MCP policy is not reused after
  `config.toml` changes.
  - Regenerate the config schema and add coverage for plugin MCP policy
  loading, approval lookup, persistence, and stale-cache prevention.
  
  ## Testing
  - `cargo test -p codex-config`
  - `cargo test -p codex-core-plugins`
  - `cargo test -p codex-core --lib plugin_mcp`

  Matthew Zeng · 2026-04-29 15:40:03 -07:00
  e20391e567
• Escape turn metadata headers as ASCII JSON (#19620)

  ## Why
  
  `x-codex-turn-metadata` is sent as an HTTP/WebSocket header, but Codex
  was serializing the metadata JSON with raw UTF-8 string contents. When a
  workspace path contains non-ASCII characters, common HTTP stacks can
  reject or corrupt that header before the request reaches the provider.
  
  Fixes #17468. Also addresses the duplicate WebSocket report in #19581.
  
  ## What changed
  
  - Added `codex_utils_string::to_ascii_json_string`, a shared helper that
  serializes JSON normally while escaping non-ASCII string content as
  `\uXXXX`.
  - Switched turn metadata header serialization, including merged
  Responses API client metadata, to use the ASCII-safe JSON helper.
  - Added coverage for non-ASCII workspace paths and non-ASCII client
  metadata while preserving the same parsed JSON values.
  
  ## Verification
  
  - `cargo test -p codex-utils-string`
  - `cargo test -p codex-core turn_metadata`
  - `just bazel-lock-check`

  Eric Traut · 2026-04-29 15:35:33 -07:00
  4241df4d79
• [apps] Add apps MCP path override (#20231)

  Summary
  
  - Add `[features.apps_mcp_path_override]` config with a `path` field for
  overriding only the built-in apps MCP path.
  - Keep existing host/base URL derivation unchanged and append the
  configured path after that base.
  - Regenerate the config schema with the custom feature-config case.
  
  Test Plan
  
  - Not run for latest revision; only `just fmt` and `just
  write-config-schema` were run.
  - Earlier revision: `cargo test -p codex-features`
  - Earlier revision: `cargo test -p codex-mcp`

  Alex Daley · 2026-04-29 18:08:06 -04:00
  f63b19bedd
• [tool_suggest] Improve tool_suggest triggering conditions. (#20091)

  ## Summary
  - Tighten `tool_suggest` guidance so it prefers explicit plugin install
  requests, while still allowing a connector install when the relevant
  plugin is already installed and a needed connector from that plugin is
  missing.
  - Tell the model not to call `tool_suggest` in parallel with other
  tools.
  
  ## Testing
  - `cargo test -p codex-tools tool_suggest`
  - `cargo test -p codex-core tool_suggest`

  Matthew Zeng · 2026-04-29 13:41:12 -07:00
  8ce48f9968
• fix: handle deferred network proxy denials (#19184)

  ## Why
  
  This bug is exposed by Guardian/auto-review approvals. With the managed
  network proxy enabled, a blocked network request can be reported back
  through the network approval service as an approval denial after the
  command has already started. Before this change, the shell and unified
  exec runtimes registered those network approval calls, but did not have
  a way to observe an async proxy denial as a cancellation/failure signal
  for the running process.
  
  The result was confusing: Guardian/auto-review could correctly deny
  network access, but the command path could keep running or unregister
  the approval without surfacing the denial as the command failure.
  
  ## What Changed
  
  - `NetworkApprovalService` now attaches a cancellation token to active
  and deferred network approvals.
  - Proxy-denial outcomes are recorded only for active registrations,
  cancel the owning token, and are consumed when the approval is
  finalized.
  - The shell runtime combines the normal command timeout with the
  network-denial cancellation token.
  - Unified exec stores the deferred network approval object, terminates
  tracked processes when the proxy denial arrives, and returns the denial
  as a process failure while polling or completing the process.
  - Tool orchestration passes the active network approval cancellation
  token into the sandbox attempt and preserves deferred approval errors
  instead of silently unregistering them.
  - App-server `command/exec` now handles the combined
  timeout-or-cancellation expiration variant used by the runtime.
  
  ## Verification
  
  - `cargo test -p codex-core network_approval --lib`
  - `cargo clippy -p codex-app-server --all-targets -- -D warnings`
  - `cargo clippy -p codex-core --all-targets -- -D warnings`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  viyatb-oai · 2026-04-29 19:13:57 +00:00
  07c8b8c77c
• feat: Use remote installed plugin cache for skills and MCP (#20096)

  - Fetches and caches remote /installed plugin state
  - Lets skills/list load skills from remote-installed cached plugins
  without requiring a local marketplace entry
  - Routes plugin list/startup/install/uninstall changes through async
  plugin cache invalidation and MCP refresh

  xl-openai · 2026-04-29 12:09:49 -07:00
  73cd831952
• Include auto-review rollout in feedback uploads (#20064)

  ## Summary
  
  - include the live auto-review trunk rollout when `/feedback` uploads
  logs
  - upload that attachment as
  `auto-review-rollout-<parent-thread-id>.jsonl` so it is distinguishable
  from the parent rollout
  - show the same auto-review attachment name in the TUI consent popup
  
  ## Scope
  
  - this only covers the live cached auto-review trunk for the current
  parent thread
  - it does not add durable historical parent->auto-review lookup
  - it does not add persisted rollout support for ephemeral parallel
  review forks
  
  ## UI 
  
  <img width="599" height="185" alt="Screenshot 2026-04-28 at 1 17 18 PM"
  src="https://github.com/user-attachments/assets/6a0e79c2-5d21-4702-8a89-f765778bc9e9"
  />
  
  ## Validation
  
  - `cargo test -p codex-core
  cached_guardian_subagent_exposes_its_rollout_path`
  - `cargo test -p codex-feedback`
  - `cargo test -p codex-app-server`
  - `cargo test -p codex-tui feedback_upload_consent_popup_snapshot`
  - `cargo test -p codex-tui
  feedback_good_result_consent_popup_includes_connectivity_diagnostics_filename`
  
  ## Known unrelated local failures
  
  - `cargo test -p codex-core` currently fails in the pre-existing proxy
  env snapshot test
  `tools::runtimes::tests::maybe_wrap_shell_lc_with_snapshot_keeps_user_proxy_env_when_proxy_inactive`
  - `cargo test -p codex-tui` currently hits pre-existing `status::*`
  snapshot drift unrelated to this change
  
  ## Follow-Up 
  - persist parallel auto-review fork sessions so /feedback can include
  their rollout history too
  - attach each persisted fork as its own clearly named file, for example
  auto-review-rollout-<parent-thread-id>-fork <n>.jsonl, instead of
  merging multiple Guardian sessions into one attachment
  - keep the same live-session-only scope initially; durable historical
  parent -> auto-review lookup can remain a separate decision if we later
  need feedback from resumed sessions

  Won Park · 2026-04-29 11:44:55 -07:00
  5cf0adba93
• Add ThreadManager sample crate (#20141)

  Summary:
  - Add codex-thread-manager-sample, a one-shot binary that starts a
  ThreadManager thread, submits a prompt, and prints the final assistant
  output.
  - Pass ThreadStore into ThreadManager::new and expose
  thread_store_from_config for existing callsites.
  - Build the sample Config directly with only --model and prompt inputs.
  
  Verification:
  - just fmt
  - cargo check -p codex-thread-manager-sample -p codex-app-server -p
  codex-mcp-server
  - git diff --check
  
  Tests: Not run per request.

  pakrym-oai · 2026-04-29 11:21:06 -07:00
  8356806fc9
• Make multi-agent v2 ignore agents.max_depth (#20180)

  ## Why
  
  `agents.max_depth` is a legacy multi-agent v1 guard. Multi-agent v2 uses
  task-path routing and its own session/thread limits, so v2 should not
  reject nested `spawn_agent` calls just because the thread-spawn depth
  has reached the v1 maximum.
  
  Keeping the v1 depth guard active in v2 prevents deeper task trees even
  though the v2 path still needs the depth value only for lineage and
  task-path metadata.
  
  ## What Changed
  
  - Removed the depth-limit rejection from the multi-agent v2
  `spawn_agent` handler while still computing child depth for lineage/path
  metadata.
  - Made the depth-based disabling of legacy `SpawnCsv`/`Collab` tools
  apply only when `Feature::MultiAgentV2` is disabled.
  - Added `multi_agent_v2_spawn_agent_ignores_configured_max_depth` to
  cover a v2 child spawning another agent when `agent_max_depth = 1`,
  while the existing v1 depth-limit tests continue to enforce the legacy
  behavior.
  
  ## Verification
  
  - `cargo test -p codex-core
  multi_agent_v2_spawn_agent_ignores_configured_max_depth -- --nocapture`
  - `cargo test -p codex-core depth_limit -- --nocapture`
  - `cargo test -p codex-core tools::handlers::multi_agents::tests --
  --nocapture`

  jif-oai · 2026-04-29 12:23:00 +02:00
  70ac0f123c
• nit: drop old memories things (#20186)

  Drop legacy code

  jif-oai · 2026-04-29 12:19:50 +02:00
  c41b74c453
• feat(cli): add sandbox profile config controls (#20118)

  ## Why
  
  The explicit profile path from #20117 is meant for standalone testing,
  but it still inherited the
  shell cwd and all managed requirements implicitly. The pre-existing
  launcher path even called out
  that it did not support a separate cwd yet in
  
  [`debug_sandbox.rs`](https://github.com/openai/codex/blob/509453f688a30929432be866402d1ea46aa12169/codex-rs/cli/src/debug_sandbox.rs#L174-L179).
  
  For a standalone command, the useful default is to let the caller choose
  the project directory being
  tested and to avoid administrator-provided constraints unless the caller
  explicitly wants to test
  those too.
  
  ## What changed
  
  - Add explicit-profile-only `-C/--cd DIR`, and use that cwd for both
  profile resolution and command
    execution.
  - Add explicit-profile-only `--include-managed-config`.
  - Make explicit profile mode skip managed requirement sources by
  default, including cloud
  requirements, MDM requirements, `/etc/codex/requirements.toml`, and the
  legacy managed-config
    requirements projection.
  - Preserve all existing invocations outside the explicit-profile path.
  
  ## Stack
  
  1. #20117 `sandbox-ui-profile`
  2. #20118 `sandbox-ui-config` --> this PR
  
  Both PRs are additive. Replay JSON is intentionally deferred to a
  follow-up design pass.
  
  ## Tests ran
  
  - `cargo test -p codex-cli debug_sandbox`
  - `cargo test -p codex-cli sandbox_macos_`
  - `cargo test -p codex-core
  load_config_layers_can_ignore_managed_requirements`
  - `cargo test -p codex-core
  load_config_layers_includes_cloud_requirements`
  - macOS branch-binary smoke on the rebased top of stack: `-C` changed
  execution cwd, explicit
  profile mode omitted managed proxy env under `env -i`, and
  `--include-managed-config` restored it.
  - Linux devbox branch-binary smoke on the rebased top of stack: `-C`
  changed execution cwd for
    built-in and user-defined explicit profiles.

  viyatb-oai · 2026-04-29 06:55:51 +00:00
  5597925155
• Delete multi_agent_v2 followup_task interrupt parameter (#20139)

  Messages sent with `followup_task` already arrive at their target
  recipient promptly (at message boundaries while sampling, or after the
  pending tool call completes) -- having `interrupt` is not worth the
  added complexity.

  Andrey Mishchenko · 2026-04-28 23:19:48 -07:00
  857146b328
• feat(cli): add explicit sandbox permission profiles (#20117)

  ## Why
  
  `codex sandbox` is useful for exercising sandbox behavior directly, but
  before this stack the CLI
  only picked up permission profiles indirectly from the active config.
  The existing debug-sandbox path
  already compiled `[permissions]` profiles through normal config loading,
  as covered by the existing
  profile tests in
  [`debug_sandbox.rs`](https://github.com/openai/codex/blob/de2ccf94735a3d8a2a7077e6a5292026413867cf/codex-rs/cli/src/debug_sandbox.rs#L715-L760).
  
  This adds the smallest stable entry point first: an explicit profile
  selector that reuses the same
  config machinery as normal Codex config, so standalone testing becomes
  possible without changing
  current no-selector behavior.
  
  ## What changed
  
  - Add additive `--permissions-profile NAME` support to `codex sandbox
  macos|linux|windows`.
  - Resolve built-in and user-defined profile names by feeding
  `default_permissions` through the
  existing config compilation path instead of inventing a sandbox-only
  parser.
  - Make an explicit selector win over an ambient active profile's legacy
  `sandbox_mode`.
  - Keep the existing no-selector behavior unchanged.
  
  ## Stack
  
  1. #20117 `sandbox-ui-profile` --> this PR
  2. #20118 `sandbox-ui-config`
  
  Both PRs are additive. Replay JSON is intentionally deferred to a
  follow-up design pass.
  
  ## Tests ran
  
  - `cargo test -p codex-cli debug_sandbox`
  - `cargo test -p codex-cli sandbox_macos_parses_permissions_profile`
  - `cargo test -p codex-core
  cli_override_takes_precedence_over_profile_sandbox_mode`
  - macOS branch-binary smoke on the rebased top of stack: built-in
  `:workspace` and user-defined
    profiles both executed successfully through `--permissions-profile`.
  - Linux devbox branch-binary smoke on the rebased top of stack: built-in
  `:workspace` and
  user-defined profiles both executed successfully through
  `--permissions-profile`.

  viyatb-oai · 2026-04-29 06:18:16 +00:00
  6ed0440611
• Add environment provider snapshot (#20058)

  ## Summary
  - Change `EnvironmentProvider` to return concrete `Environment`
  instances instead of `EnvironmentConfigurations`.
  - Make `DefaultEnvironmentProvider` provide the provider-visible `local`
  environment plus optional `remote` environment from
  `CODEX_EXEC_SERVER_URL`.
  - Keep `EnvironmentManager` as the concrete cache while exposing its own
  explicit local environment for `local_environment()` fallback paths.
  
  ## Validation
  - `just fmt`
  - `git diff --check`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  starr-openai · 2026-04-28 20:05:18 -07:00
  e1ec9e63a0
• Soften skill description budget warnings (#20112)

  Updates skill description budget messaging to be less alarming

  xl-openai · 2026-04-28 19:56:25 -07:00
  6f328d5e02
• linux-sandbox: switch helper plumbing to PermissionProfile (#20106)

  ## Why
  
  `PermissionProfile` is the canonical runtime permission model in the
  Rust workspace, but the Linux sandbox helper still accepted a legacy
  `SandboxPolicy` plus separate filesystem and network policy flags. That
  translation layer made the helper interface harder to reason about and
  left `linux-sandbox`-specific callers and tests coupled to the legacy
  policy representation.
  
  This change moves the helper onto `PermissionProfile` directly so the
  Linux sandbox plumbing matches the rest of the permission stack.
  
  ## What changed
  
  - changed `codex-linux-sandbox` to accept `--permission-profile` and
  derive the runtime filesystem and network policies internally
  - updated the in-process seccomp and legacy Landlock path in
  `codex-rs/linux-sandbox` to operate on `PermissionProfile`
  - updated Linux sandbox argv construction in `codex-rs/sandboxing`,
  `codex-rs/core`, and the CLI debug sandbox path to pass the canonical
  profile instead of serializing compatibility policy projections
  - simplified the Linux sandbox tests to build the exact permission
  profile under test, including the managed-proxy path and
  direct-runtime-enforcement carveout coverage
  - removed helper-local `SandboxPolicy` usage from `bwrap` tests where
  `FileSystemSandboxPolicy` is already the value being exercised
  
  ## Testing
  
  - `cargo test -p codex-sandboxing`
  - `cargo test -p codex-linux-sandbox` (on this macOS host, the crate
  compiled cleanly and its Linux-only tests were cfg-gated)
  - `cargo test -p codex-core --no-run`
  - `cargo test -p codex-cli --no-run`

  Michael Bolin · 2026-04-28 19:43:44 -07:00
  e6db1a9442
• fix: restore live event submit path for apply patch tests (#20108)

  ## Summary
  
  This fixes the CI regression introduced by
  [#20040](https://github.com/openai/codex/pull/20040).
  
  That PR migrated several `apply_patch_cli` tests from direct
  `codex.submit(Op::UserTurn { ... })` calls to `harness.submit(...)`.
  `harness.submit()` waits for `TurnComplete` before returning, which
  drains the same event stream that these tests use to assert `TurnDiff`,
  `PatchApplyUpdated`, and related live events. The regressed tests then
  timed out waiting for events that had already been consumed.
  
  This change restores a no-wait submit path for the event-observing
  `apply_patch_cli` tests so they can watch the turn stream directly
  again.
  
  ## What Changed
  
  - added a local `submit_without_wait(...)` helper in
  `codex-rs/core/tests/suite/apply_patch_cli.rs`
  - switched the `apply_patch_cli` tests that assert live turn events back
  to that helper
  - left the profile-backed `harness.submit(...)` migration in place for
  tests that only care about final filesystem or tool output state
  
  ## Why macOS Looked Green
  
  In the failing run
  [25084487331](https://github.com/openai/codex/actions/runs/25084487331),
  `//codex-rs/core:core-all-test` was cached on macOS, so the regressed
  tests were not rerun there. The Linux GNU, Linux MUSL, and Windows Bazel
  jobs reran the target and exposed the failure.
  
  ## Verification
  
  - `cargo test -p codex-core apply_patch_ -- --nocapture`
  - previously failing local cases now pass again:
    - `apply_patch_cli_move_without_content_change_has_no_turn_diff`
    - `apply_patch_turn_diff_for_rename_with_content_change`
    - `apply_patch_aggregates_diff_across_multiple_tool_calls`

  Michael Bolin · 2026-04-28 18:09:20 -07:00
  c9f7c88f3d
• feat: disable capabilities by model provider (#19442)

  ## Why
  
  Unsupported features must fail closed and Codex must not expose
  OpenAI-hosted fallback paths when the active provider cannot support
  them. In practice, Bedrock should not surface app connectors, MCP
  servers, tool search/suggestions, image generation, web search, or JS
  REPL until those paths are explicitly supported for that provider.
  
  This PR moves that decision into provider-owned capability metadata
  instead of scattering Bedrock-specific checks across callers.
  
  ## What changed
  
  - Adds `ProviderCapabilities` to `codex-model-provider`, with default
  support for existing providers and a Bedrock override that disables
  unsupported launch surfaces.
  - Adds `ToolCapabilityBounds` to `codex-tools` so provider capability
  limits can clamp otherwise-enabled tool config.
  - Applies capability bounds when building session and review-thread tool
  config.
  - Routes MCP/app connector configuration through
  `McpManager::mcp_config`, which filters configured MCP servers and app
  connectors based on the active provider.
  - Updates app-server MCP list/read paths to use the filtered MCP config.
  - Adds coverage for default provider capabilities, Bedrock disabled
  capabilities, and optional tool-surface clamping.
  
  ## Testing
  
  built locally and verified that bedrock responses api now return without
  errors calling unsupported tools.

  Celia Chen · 2026-04-28 17:51:30 -07:00
  f8fe96d548
• Support disabling tool suggest for specific tools. (#20072)

  ## Summary
  - Add `disable_tool_suggest` to app and plugin config, schema, and
  TypeScript output
  - Exclude disabled connectors and plugins from tool suggestion discovery
  - Persist "never show again" tool-suggestion choices back into
  `config.toml`
  - Update config docs and add coverage for connector and plugin
  suppression
  
  ## Testing
  - Added and updated unit tests for config persistence and tool-suggest
  filtering
  - Not run (not requested)

  Matthew Zeng · 2026-04-29 00:19:34 +00:00
  ebdf3a878c
• core tests: migrate hook turns to profiles (#20041)

  ## Summary
  - Removes `SandboxPolicy` from the hooks test suite.
  - Submits hook-related turns with explicit `PermissionProfile` values
  for disabled, read-only, and workspace-write cases.
  - Preserves the managed-network hook test by configuring and submitting
  a workspace-write profile with enabled network, allowing the existing
  requirements-backed proxy path to remain covered.
  
  ## Verification
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:18:45 -07:00
  1211a90a35
• core tests: migrate apply patch turns to profiles (#20040)

  ## Summary
  - Removes `SandboxPolicy` from the apply-patch CLI test suite.
  - Uses the harness' profile-backed submit helper for danger/no-sandbox
  turns instead of constructing `Op::UserTurn` manually with legacy
  fields.
  - Converts the workspace-write traversal cases to submit
  `PermissionProfile::workspace_write_with(...)` directly.
  
  ## Verification
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:18:19 -07:00
  1fed948c66
• core tests: migrate rmcp turns to profiles (#20037)

  ## Summary
  - Removes `SandboxPolicy` from the RMCP client test suite.
  - Adds shared read-only user-turn helpers that submit
  `PermissionProfile::read_only()` plus the legacy compatibility
  projection required by the current `Op::UserTurn` shape.
  - Keeps sandbox metadata assertions intact by deriving the expected
  legacy `sandboxPolicy` value from the same read-only profile used for
  the turn.
  
  ## Verification
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:17:47 -07:00
  1dae5788e1
• core tests: migrate compact turns to profiles (#20035)

  ## Summary
  - Removes the remaining `SandboxPolicy` usage from the compaction test
  suite.
  - Adds a small local helper for direct `Op::UserTurn` construction so
  these tests send `PermissionProfile::Disabled` plus the legacy
  compatibility projection required by the protocol field.
  - Keeps the existing danger/full-access behavior while exercising the
  canonical permission profile path.
  
  ## Verification
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:17:12 -07:00
  6662c0f312
• core tests: migrate zsh-fork permissions to profiles (#20034)

  ## Summary
  - Updates the zsh-fork test helper to configure `PermissionProfile`
  directly instead of constructing a legacy `SandboxPolicy`.
  - Sends permission-profile-backed turns from the skill approval zsh-fork
  tests so the runtime and request path exercise the canonical permissions
  model.
  - Leaves the broader approvals suite on legacy policies for now, except
  for the zsh-fork test that shares this helper.
  
  ## Verification
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:15:58 -07:00
  026df712cc
• core tests: migrate request permissions tool turns to profiles (#20033)

  ## Summary
  
  This migrates the macOS request-permissions tool tests from legacy
  `SandboxPolicy` setup to `PermissionProfile` setup. The tests still
  exercise the same workspace-write baseline and request-permission
  grants, but the canonical permissions value is now the profile.
  
  ## Changes
  
  - Replaces the `workspace_write_excluding_tmp()` helper with a
  `PermissionProfile::workspace_write_with()` helper.
  - Applies test config through `Permissions::set_permission_profile()`.
  - Uses `turn_permission_fields()` for `Op::UserTurn` compatibility
  fields.
  - Removes the `SandboxPolicy` import from `request_permissions_tool.rs`.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:15:13 -07:00
  1ea90410e1
• core tests: migrate prompt caching turns to profiles (#20032)

  ## Summary
  
  This removes the explicit `SandboxPolicy` constructors from
  `core/tests/suite/prompt_caching.rs`. The tests still exercise the same
  prompt-cache invariants across permission and turn-context changes, but
  the permission source is now `PermissionProfile`.
  
  ## Changes
  
  - Uses `PermissionProfile::workspace_write_with()` for workspace-write
  override scenarios.
  - Uses `PermissionProfile::Disabled` for the no-sandbox per-turn
  override.
  - Projects profiles through `turn_permission_fields()` or
  `to_legacy_sandbox_policy()` only to populate compatibility fields on
  existing ops.
  - Removes the `SandboxPolicy` import from `prompt_caching.rs`.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:13:53 -07:00
  af39e488bc
• core tests: migrate exec policy turns to profiles (#20030)

  ## Summary
  
  This migrates `core/tests/suite/exec_policy.rs` away from legacy
  `SandboxPolicy` turn construction. These tests all use no-sandbox turns
  to exercise exec-policy behavior, so `PermissionProfile::Disabled` is
  the canonical representation.
  
  ## Changes
  
  - Replaces direct `SandboxPolicy::DangerFullAccess` turn fields with
  `PermissionProfile::Disabled`.
  - Uses `turn_permission_fields()` to populate the compatibility
  `sandbox_policy` field required by `Op::UserTurn`.
  - Removes the `SandboxPolicy` import from `exec_policy.rs`.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:12:48 -07:00
  5d08315c00
• core tests: migrate permissions message tests to profiles (#20028)

  ## Summary
  
  This removes another test-only `SandboxPolicy` dependency by configuring
  `permissions_messages.rs` with a `PermissionProfile` directly. The test
  still verifies the rendered compatibility permissions text, but now
  obtains the legacy projection from the loaded `Config` rather than using
  `SandboxPolicy` as the source of truth.
  
  ## Changes
  
  - Builds the workspace-write test setup with
  `PermissionProfile::workspace_write_with()`.
  - Applies that profile through `Permissions::set_permission_profile()`.
  - Uses `Config::legacy_sandbox_policy()` only for the expected
  `PermissionsInstructions` compatibility rendering.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:12:10 -07:00
  b599849d86
• core tests: migrate tools tests to permission profiles (#20027)

  ## Summary
  
  This continues the test-side migration away from `SandboxPolicy` by
  removing the remaining legacy policy setup in
  `core/tests/suite/tools.rs`. The affected test was already modeling a
  profile-backed filesystem policy with a deny-read glob, so configuring
  the test through `Permissions::set_permission_profile()` is a better
  match for the behavior being exercised.
  
  ## Changes
  
  - Drops the `SandboxPolicy` import from `core/tests/suite/tools.rs`.
  - Configures the glob deny-read shell test directly with a
  `PermissionProfile` instead of creating a legacy read-only policy first.
  - Submits the test turn with the session permission profile so the
  deny-read glob remains active for the command under test.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:11:43 -07:00
  3ef09c71d3
• core tests: migrate plan item turns to profiles (#20026)

  ## Why
  
  The core item tests still had a cluster of plan-mode `Op::UserTurn`
  literals that used `SandboxPolicy::DangerFullAccess` and omitted
  `permission_profile`. These tests are validating emitted item lifecycle
  events, so keeping them on the legacy sandbox-only turn shape adds noise
  to the broader permissions migration without testing legacy behavior.
  
  ## What Changed
  
  - Adds a local `disabled_plan_turn()` helper that preserves the existing
  `std::env::current_dir()` turn cwd behavior.
  - Uses `turn_permission_fields(PermissionProfile::Disabled, cwd)` to
  populate both the compatibility `sandbox_policy` and canonical
  `permission_profile` fields.
  - Replaces the plan-mode hand-built turns in
  `codex-rs/core/tests/suite/items.rs`, removing all `SandboxPolicy`
  references from that file and reducing remaining `codex-rs/core/tests`
  `SandboxPolicy` files from 16 to 15.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:11:17 -07:00
  8d3992d830
• core tests: migrate safety check turns to profiles (#20024)

  ## Why
  
  This stack is retiring direct `SandboxPolicy` construction from tests so
  core coverage exercises the same `PermissionProfile` turn path used by
  runtime code. `safety_check_downgrade.rs` still submitted each test turn
  as `SandboxPolicy::DangerFullAccess` with no permission profile, even
  though the tests are about model verification/reroute behavior rather
  than legacy sandbox conversion.
  
  ## What Changed
  
  - Adds a local `disabled_text_turn()` helper that derives both the
  compatibility `sandbox_policy` and canonical `permission_profile` from
  `PermissionProfile::Disabled`.
  - Replaces repeated hand-built `Op::UserTurn` literals in
  `codex-rs/core/tests/suite/safety_check_downgrade.rs` with that helper.
  - Removes all `SandboxPolicy` references from the safety-check suite,
  reducing the remaining `codex-rs/core/tests` files that mention
  `SandboxPolicy` from 17 to 16.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:10:42 -07:00
  162f4e3183
• core tests: migrate view image turns to profiles (#20021)

  ## Why
  
  This stack is removing direct `SandboxPolicy` usage from test code so
  new tests exercise the same `PermissionProfile` path that runtime code
  now treats as canonical. `view_image.rs` still built `Op::UserTurn`
  requests with `SandboxPolicy::DangerFullAccess` and no permission
  profile, which kept another core test module on the legacy turn shape.
  
  ## What Changed
  
  - Adds a small `disabled_user_turn()` helper for the view-image suite
  that derives the compatibility `sandbox_policy` and canonical
  `permission_profile` from `PermissionProfile::Disabled`.
  - Replaces repeated direct `Op::UserTurn` literals in
  `codex-rs/core/tests/suite/view_image.rs` with that helper.
  - Removes all `SandboxPolicy` references from `view_image.rs`, reducing
  the remaining `codex-rs/core/tests` files that mention `SandboxPolicy`
  from 18 to 17.
  
  ## Verification
  
  - `cargo check -p codex-core --tests`

  Michael Bolin · 2026-04-28 17:09:48 -07:00
  2a8ce9b319
• core tests: migrate model/personality turns to profiles (#20018)

  ## Summary
  
  - Migrates `model_switching.rs` and `personality.rs` direct
  `Op::UserTurn` construction from legacy `SandboxPolicy` literals to
  `PermissionProfile`-backed turn fields.
  - Adds small local helpers in each file so tests keep asserting
  model/personality behavior without repeating permission plumbing.
  - Reduces `rg -l '\bSandboxPolicy\b' codex-rs/core/tests` from 20 files
  to 18; `codex-rs/tui` remains at zero `SandboxPolicy` references.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:09:12 -07:00
  d77d23da2e
• core tests: send model turns with permission profiles (#20016)

  ## Summary
  - Migrate direct `Op::UserTurn` construction in remote-model tests from
  legacy `SandboxPolicy::DangerFullAccess` to
  `PermissionProfile::Disabled` via `turn_permission_fields()`.
  - Migrate the Responses API proxy header helper from an inline
  workspace-write `SandboxPolicy` to
  `PermissionProfile::workspace_write()`.
  - Reduce `SandboxPolicy` references in `codex-rs/core/tests` from 22
  files after #20015 to 20 files.
  
  ## Testing
  - `cargo check -p codex-core --tests`
  - `just fmt`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/20016).
  * #20041
  * #20040
  * #20037
  * #20035
  * #20034
  * #20033
  * #20032
  * #20030
  * #20028
  * #20027
  * #20026
  * #20024
  * #20021
  * #20018
  * __->__ #20016

  Michael Bolin · 2026-04-28 17:08:04 -07:00
  d6d79ffcc7
• core tests: configure profiles directly (#20015)

  ## Summary
  - Replace legacy sandbox config setup in delegate and telemetry tests
  with direct `PermissionProfile` configuration.
  - Move no-sandbox and read-only test turns in `tools.rs`,
  `code_mode.rs`, `user_shell_cmd.rs`, and `model_visible_layout.rs` from
  legacy `SandboxPolicy` values to `PermissionProfile` helpers, while
  leaving the deny-glob read-only compatibility case for a later targeted
  cleanup.
  - Use `PermissionProfile::read_only()` where tests need managed
  read-only behavior and `PermissionProfile::Disabled` where they
  intentionally need no sandbox.
  - Reduce `SandboxPolicy` references in `codex-rs/core/tests` from 27
  files after #20013 to 22 files.
  
  ## Testing
  - `cargo check -p codex-core --tests`
  - `just fmt`

  Michael Bolin · 2026-04-28 17:06:59 -07:00
  158b2a4201
• core tests: migrate more turns to permission profiles (#20013)

  ## Summary
  - Migrate another batch of direct `Op::UserTurn` test construction from
  legacy `SandboxPolicy` values to `PermissionProfile` inputs via
  `turn_permission_fields()`.
  - Replace a one-off read-only `SandboxPolicy` bridge in the macOS exec
  test with `PermissionProfile::read_only()`.
  - Reduce `SandboxPolicy` references in `codex-rs/core/tests` from 32
  files at the start of the cleanup stack to 27 files.
  
  ## Testing
  - `cargo check -p codex-core --tests`
  - `just fmt`
  - `just fix -p codex-core`

  Michael Bolin · 2026-04-28 17:05:53 -07:00
  52e79ee49a
• core tests: build user turns from permission profiles (#20011)

  ## Summary
  - Add `turn_permission_fields()` so tests that construct `Op::UserTurn`
  directly can provide a canonical `PermissionProfile` while still filling
  the required legacy `sandbox_policy` compatibility field.
  - Migrate direct user-turn construction in core integration tests from
  `SandboxPolicy::DangerFullAccess` to `PermissionProfile::Disabled`.
  - Continue reducing direct `SandboxPolicy` usage in
  `codex-rs/core/tests`, from 41 files after #20010 to 32 files in this
  PR.
  
  ## Testing
  - `cargo check -p codex-core --tests`
  - `just fmt`
  - `just fix -p core_test_support`
  - `just fix -p codex-core`

  Michael Bolin · 2026-04-28 17:03:20 -07:00
  7d15936e69
• core tests: submit turns with permission profiles (#20010)

  ## Summary
  
  - Add `PermissionProfile`-based turn submission helpers to
  `core_test_support`, while keeping the legacy `SandboxPolicy` helper for
  tests that intentionally exercise legacy fallback behavior.
  - Switch the default `TestCodex::submit_turn()` path to send a real
  `PermissionProfile` plus the required legacy compatibility projection in
  `Op::UserTurn`.
  - Migrate straightforward app/search/shell/truncation tests from
  `SandboxPolicy::{DangerFullAccess, ReadOnly}` to
  `PermissionProfile::{Disabled, read_only}`.
  - Add a TUI compatibility projection helper for legacy app-server fields
  so non-legacy writable roots are preserved instead of being downgraded
  to read-only.
  - Fix remote start/resume/fork sandbox-mode projection to classify any
  managed profile with writable roots as workspace-write, not only
  profiles that can write `cwd`.
  - Reduce `SandboxPolicy` references in `codex-rs/core/tests` from 47
  files to 41 files without changing production behavior.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`
  - `cargo test -p codex-tui
  compatibility_profile_preserves_unbridgeable_write_roots`
  - `cargo test -p codex-tui
  sandbox_mode_preserves_non_cwd_write_roots_for_remote_sessions`
  - `just fmt`
  - `just fix -p core_test_support`
  - `just fix -p codex-core`

  Michael Bolin · 2026-04-28 23:01:40 +00:00
  891722849d
• Discover hooks bundled with plugins (#19705)

  ## Why
  
  Plugins can bundle lifecycle hooks, but Codex previously only discovered
  hooks from user, project, and managed config layers. This adds the
  plugin discovery and runtime plumbing needed for plugin-bundled hooks
  while keeping execution behind the `plugin_hooks` feature flag.
  
  ## What
  
  - Discovers plugin hook sources from each plugin's default
  `hooks/hooks.json`.
  - Supports `plugin.json` manifest `hooks` entries as either relative
  paths or inline hook objects.
  - Plumbs discovered plugin hook sources through plugin loading into the
  hook runtime when `plugin_hooks` is enabled.
  - Marks plugin-originated hook runs as `HookSource::Plugin`.
  - Injects `PLUGIN_ROOT` and `CLAUDE_PLUGIN_ROOT` into plugin hook
  command environments.
  - Updates generated schemas and hook source metadata for the plugin hook
  source.
  
  ## Stack
  
  1. This PR - openai/codex#19705
  2. openai/codex#19778
  3. openai/codex#19840
  4. openai/codex#19882
  
  ## Reviewer Notes
  
  - Core logic is in `codex-rs/core-plugins/src/loader.rs` and
  `codex-rs/hooks/src/engine/discovery.rs`
  - Moved existing / adding new tests to
  `codex-rs/core-plugins/src/loader_tests.rs` hence the large diff there
  - Otherwise mostly plumbing and minor schema updates
  
  ### Core Changes
  
  The `codex-rs/core` changes are limited to wiring plugin hook support
  into existing core flows:
  
  - `core/src/session/session.rs` conditionally pulls effective plugin
  hook sources and plugin hook load warnings from `PluginsManager` when
  `plugin_hooks` is enabled, then passes them into `HooksConfig`.
  - `core/src/hook_runtime.rs` adds the `plugin` metric tag for
  `HookSource::Plugin`.
  - `core/config.schema.json` picks up the new `plugin_hooks` feature
  flag, and `core/src/plugins/manager_tests.rs` updates fixtures for the
  added plugin hook fields.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Abhinav · 2026-04-28 14:17:18 -07:00
  c6e7d564c3
• [rollout-trace] Include x-request-id in rollout trace. (#20066)

  ## Why
  
  Rollout traces need an identifier that can be used to correlate a Codex
  inference with upstream Responses API, proxy, and engine logs. The
  reduced trace model already exposed `upstream_request_id`, but it was
  being populated from the Responses API `response.id`. That value is
  useful for `previous_response_id` chaining, but it is not the transport
  request id that upstream systems key on.
  
  This PR separates those concepts so trace consumers can reliably answer
  both questions:
  
  - which Responses API response did this inference produce?
  - which upstream request handled it?
  
  ## Structure
  
  The change keeps the upstream request id at the same lifecycle level as
  the provider stream:
  
  - `codex-api` captures the `x-request-id` HTTP response header when the
  SSE stream is created and exposes it on `ResponseStream`. Fixture and
  websocket streams set the field to `None` because they do not have that
  HTTP response header.
  - `codex-core` carries that stream-level id into `InferenceTraceAttempt`
  when recording terminal stream outcomes. Completed, failed, cancelled,
  dropped-stream, and pre-response error paths all record the id when it
  is available.
  - `rollout-trace` now records both identifiers in raw terminal inference
  events and response payloads: `response_id` for the Responses API
  `response.id`, and `upstream_request_id` for `x-request-id`.
  - The reducer stores both fields on `InferenceCall`. It also uses
  `response_id` for `previous_response_id` conversation linking, which
  removes the old accidental dependency on the misnamed
  `upstream_request_id` field.
  - Terminal inference reduction now consumes the full terminal payload
  (`InferenceCompleted`, `InferenceFailed`, or `InferenceCancelled`) in
  one place. That keeps status, partial payloads, response ids, and
  upstream request ids consistent across success, failure, cancellation,
  and late stream-mapper events.
  
  ## Why This Shape
  
  `x-request-id` is a property of the HTTP/provider response envelope, not
  an SSE event. Capturing it once in `codex-api` and plumbing it through
  terminal trace recording avoids trying to infer the value from stream
  contents, and it preserves the id even when the stream fails or is
  cancelled after only partial output.
  
  Keeping `response_id` separate from `upstream_request_id` also makes the
  reduced trace model less surprising: `response_id` remains the
  conversation-continuation id, while `upstream_request_id` is the
  operational correlation id for upstream debugging.
  
  ## Validation
  
  The PR updates trace and reducer coverage for:
  
  - reading `x-request-id` from SSE response headers;
  - storing the true upstream request id on completed inference calls;
  - preserving upstream request ids for cancelled and late-cancelled
  inference streams;
  - keeping `previous_response_id` reconstruction tied to `response_id`
  rather than transport request ids.

  cassirer-openai · 2026-04-28 21:11:17 +00:00
  89698ad1c3
• Make MultiAgentV2 wait minimum configurable (#20052)

  ## Why
  
  MultiAgentV2 `wait_agent` currently clamps short waits to a fixed 10
  second minimum. That default is still useful for preventing tight
  polling loops, but it is too rigid for environments that need faster
  mailbox wake-up checks or a larger minimum to discourage frequent
  polling.
  
  This PR makes the minimum wait timeout configurable from the existing
  MultiAgentV2 feature config section, so operators can tune the behavior
  without changing the legacy multi-agent tool surface.
  
  ## What Changed
  
  - Added `features.multi_agent_v2.min_wait_timeout_ms`.
  - Defaulted the new setting to the existing 10 second floor.
  - Validated the configured value as `1..=3600000`, matching the existing
  one hour maximum wait bound.
  - Applied the configured minimum to MultiAgentV2 `wait_agent` runtime
  clamping.
  - Plumbed the configured minimum into the `wait_agent` tool schema,
  including the effective default when the minimum is above the normal 30
  second default.
  - Regenerated `core/config.schema.json`.
  
  ## Verification
  
  - `cargo test -p codex-features`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core --lib multi_agent_v2`
  - `just fix -p codex-core`

  jif-oai · 2026-04-28 22:36:44 +02:00
  34d71d43eb
• [codex] Add token usage to turn tracing spans (#19432)

  ## Why
  
  Slow Codex turns are easier to debug when token usage is visible in the
  trace itself, without joining against separate analytics. This adds
  token usage to existing turn-handling spans for regular user turns only.
  
  [Example
  turn](https://openai.datadoghq.com/apm/trace/9d353efa2cb5de1f4c5b93dc33c3df04?colorBy=service&graphType=flamegraph&shouldShowLegend=true&sort=time&spanID=3555541504891512675&spanViewType=metadata&traceQuery=)
  <img width="1447" height="967" alt="Screenshot 2026-04-24 at 3 03 07 PM"
  src="https://github.com/user-attachments/assets/ab7bb187-e7fc-41f0-a366-6c44610b2b2c"
  />
  
  ## What Changed
  
  Added response-level token fields on completed handle_responses spans:
  
  gen_ai.usage.input_tokens
  gen_ai.usage.cache_read.input_tokens
  gen_ai.usage.output_tokens
  codex.usage.reasoning_output_tokens
  codex.usage.total_tokens
  Added aggregate token fields on regular turn spans:
  
  codex.turn.token_usage.*
  Added an explicit regular-turn opt-in via
  SessionTask::records_turn_token_usage_on_span() so this is not coupled
  to span-name strings.
  
  ## Testing
  
  - `cargo test -p codex-otel`
  - `cargo test -p codex-core
  turn_and_completed_response_spans_record_token_usage`
  - `just fmt`
  - `just fix -p codex-core`
  - `just fix -p codex-otel`
  - Manual local Electron/app-server smoke test: regular user turn emits
  the new span fields
  
  Known status: `cargo test -p codex-core` was attempted and failed in
  unrelated existing areas: config approvals, request-permissions,
  git-info ordering, and subagent metadata persistence.

  charley-openai · 2026-04-28 11:41:32 -07:00
  de2ccf9473
• permissions: add built-in default profiles (#19900)

  ## Why
  
  The migration away from `SandboxPolicy` needs new configs to start from
  permissions profiles instead of deriving profiles from legacy sandbox
  modes. Existing users can have empty `config.toml` files, and we should
  not rewrite user-owned config files that may live in shared
  repositories.
  
  This PR introduces built-in profile names so an empty config can resolve
  to a canonical `PermissionProfile`, while explicit named `[permissions]`
  profiles still behave predictably.
  
  ## What changed
  
  - Adds built-in `default_permissions` profile names:
    - `:read-only` maps to `PermissionProfile::read_only()`.
  - `:workspace` maps to the workspace-write profile, including
  project-root metadata carveouts.
  - `:danger-no-sandbox` maps to `PermissionProfile::Disabled`, preserving
  the distinction between no sandbox and a broad managed sandbox.
  - Reserves the `:` prefix for built-in profiles so user-defined
  `[permissions]` profiles cannot collide with future built-ins.
  - Allows `default_permissions` to reference a built-in profile without
  requiring a `[permissions]` table.
  - Makes an otherwise empty config choose a built-in profile by
  trust/platform context: trusted or untrusted project roots use
  `:workspace` when the platform supports that sandbox, while roots
  without a trust decision use `:read-only`.
  - Keeps legacy `sandbox_mode` configs on the legacy path, and still
  rejects user-defined `[permissions]` profiles that omit
  `default_permissions` so we do not silently guess among custom profiles.
  - Preserves compatibility behavior for implicit defaults: bare
  `network.enabled = true` allows runtime network without starting the
  managed proxy, explicit profile proxy policy still starts the proxy, and
  implicit workspace/add-dir roots keep legacy metadata carveouts.
  
  ## Verification
  
  - `cargo test -p codex-core builtin --lib`
  - `cargo test -p codex-core profile_network_proxy_config`
  - `cargo test -p codex-core
  implicit_builtin_workspace_profile_preserves_add_dir_metadata_carveouts`
  - `cargo test -p codex-core
  permissions_profiles_network_enabled_allows_runtime_network_without_proxy`
  - `cargo test -p codex-core
  permissions_profiles_proxy_policy_starts_managed_network_proxy`
  
  ## Documentation
  
  Public Codex config docs should mention these built-in names when the
  `[permissions]` config format is ready to document as stable.
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19900).
  * #20041
  * #20040
  * #20037
  * #20035
  * #20034
  * #20033
  * #20032
  * #20030
  * #20028
  * #20027
  * #20026
  * #20024
  * #20021
  * #20018
  * #20016
  * #20015
  * #20013
  * #20011
  * #20010
  * #20008
  * __->__ #19900

  Michael Bolin · 2026-04-28 11:21:39 -07:00
  9e26613657
• Clarify network approval auto-review prompts (#19907)

  ## Why
  
  Network access approval prompts were showing the generic retry reason,
  which made auto-review focus on the blocked connection instead of the
  command that caused it. This makes network approvals easier to assess by
  telling the reviewer to evaluate whether the triggering command was
  authorised by the user and within policy, and to treat the network call
  as acceptable when it is a reasonable consequence of that command.
  
  ## What changed
  
  - Split guardian approval request prompt rendering so `NetworkAccess`
  has a dedicated branch.
  - For network requests, show `Network approval context` and `Network
  access JSON` instead of `Retry reason` / `Planned action JSON`.
  - Added regression coverage for the network approval prompt wording and
  for omitting retry reason in this case.
  
  ## Verification
  
  - `cargo test -p codex-core
  guardian::tests::build_guardian_prompt_items_explains_network_access_review_scope`

  maja-openai · 2026-04-28 10:25:37 -07:00
  273c2e21a9
• Record MCP result telemetry on mcp.tools.call spans (#19509)

  ## Why
  - Without change: MCP tool call spans include request-side details such
  as server, tool, call ID, connector, session, and turn.
  - Issue: Some useful telemetry is only known by the MCP server after it
  handles the tool call, such as target identity or whether the call
  triggered a user-facing flow.
  
  ## What Changed
  - With change: Codex reads allowlisted telemetry from
  `_meta["codex/telemetry"]["span"]` and records it on the
  `mcp.tools.call` span.
  - Adds span fields for `codex.mcp.target.id` and
  `codex.mcp.user_flow.triggered`, with strict type checks and bounded
  target ID length.
  
  
  ## Verification
  `codex-rs/core/src/mcp_tool_call_tests.rs`

  mchen-oai · 2026-04-28 17:20:38 +00:00
  01de13b7e6
• feat: verify agent identity JWTs with JWKS (#19764)
  efrazer-oai · 2026-04-28 09:56:20 -07:00
  f6797c3ac6
• Add turn start timestamp to turn metadata (#19473)

  ## Why
  - Without change: MCP tool calls receive
  `_meta["x-codex-turn-metadata"]` with `session_id` and `turn_id`.
  - Issue: MCP servers may want the turn start timestamp to measure
  internal latency relative to turn start.
  
  ## What Changed
  - With change: turn metadata now includes `turn_started_at_unix_ms`,
  which is propagated to MCP tool calls in
  `_meta["x-codex-turn-metadata"]`.
  
  ## Verification
  - `codex-rs/core/src/mcp_tool_call_tests.rs`
  - `codex-rs/core/src/turn_metadata_tests.rs`
  - `codex-rs/core/src/turn_timing_tests.rs`
  - `codex-rs/core/tests/responses_headers.rs`
  - `codex-rs/core/tests/suite/search_tool.rs`

  mchen-oai · 2026-04-28 16:36:59 +00:00
  ccec84b148