98 Commits

• 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
• 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
• 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
• 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
• 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
• Terminate stdio MCP servers on shutdown to avoid process leaks (#19753)

  ## Why
  
  Several bug reports describe thread shutdown (including subagent
  threads) leaving stdio MCP server processes behind. These reports all
  point at the same lifecycle gap: Codex launches stdio MCP servers, but
  the session-level shutdown path does not explicitly close MCP clients or
  terminate the server process tree.
  
  Fixes #12491
  Fixes #12976
  Fixes #18881
  Fixes #19469
  
  ## History
  
  This is best understood as a regression/coverage gap in MCP session
  lifecycle management, not as stdio MCP cleanup being absent all along.
  #10710 added process-group cleanup for stdio MCP servers, but that
  cleanup only runs when the `RmcpClient`/transport is dropped. The older
  reports (#12491 and #12976) came after that cleanup existed, which
  suggests the remaining problem was that some higher-level shutdown paths
  kept the MCP manager alive or replaced it without explicitly draining
  clients. The newer reports (#18881 and #19469) exposed the same family
  around manager replacement and shutdown.
  
  ## What changed
  
  - Added an explicit stdio MCP process handle in `codex-rmcp-client` so
  local MCP servers terminate their process group and executor-backed MCP
  servers call the executor process terminator.
  - Added `RmcpClient::shutdown()` and manager-level MCP shutdown draining
  so session shutdown, channel-close fallback, MCP refresh, and connector
  probing stop owned MCP clients.
  - Added regression coverage that starts a stdio MCP server, begins an
  in-flight blocking tool call, shuts down the client, and asserts the
  server process exits.
  
  ## Verification
  
  - `cargo test -p codex-rmcp-client`
  - `cargo test -p codex-mcp`
  - `just fix -p codex-rmcp-client`
  - `just fix -p codex-mcp`
  - `just fix -p codex-core`
  
  - Manual before/after validation with a temporary repro script:
  - Pre-fix binary from `HEAD^` (`fed0a8f4fa`): reproduced the leak with
  surviving MCP server and child PIDs, `survivors=[77583, 77592]`,
  `leaked=true`.
  - Post-fix binary from this branch (`67e318148b`): verified both MCP
  processes were gone after interrupting `codex exec`, `survivors=[]`,
  `leaked=false`.

  Eric Traut · 2026-04-28 09:29:57 -07:00
  4e0cf945b7
• Preserve assistant phase for replayed messages (#19832)
  friel-openai · 2026-04-28 08:46:13 -07:00
  598bbcdb58
• Stabilize memory Phase 2 input ordering (#19967)

  ## Why
  
  Phase 2 still needs to choose the most relevant stage-1 memory outputs
  by usage and recency, but exposing that ranking as the rendered
  `raw_memories.md` order creates unnecessary large diff. Usage-count or
  timestamp changes can reshuffle otherwise unchanged memories, making the
  workspace diff noisy and giving the consolidation prompt a misleading
  recency signal from file position.
  This fix will reduce token consumption
  
  ## What Changed
  
  - Keep the existing top-N Phase 2 selection ranking by `usage_count`,
  `last_usage`, `source_updated_at`, and `thread_id`.
  - Return the selected rows in stable ascending `thread_id` order before
  syncing Phase 2 filesystem inputs.
  - Update the memory README, raw memories header, and consolidation
  prompt so they describe the stable order and tell the prompt to use
  metadata and workspace diffs instead of file order as the recency
  signal.
  - Adjust the memory runtime tests to use deterministic thread IDs and
  assert the stable return order separately from the ranked selection
  semantics.
  
  ## Test Coverage
  
  - Existing memory runtime tests in
  `codex-rs/state/src/runtime/memories.rs` now cover the stable returned
  ordering for Phase 2 inputs.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 13:32:05 +02:00
  fa127be25f
• feat: fix hinting 3 (#19963)

  Fix https://github.com/openai/codex/pull/19805#discussion_r3153265562

  jif-oai · 2026-04-28 13:12:51 +02:00
  54d1401170
• feat: fix hinting 2 (#19961)

  Fix this:
  https://github.com/openai/codex/pull/19805#discussion_r3153265562

  jif-oai · 2026-04-28 13:06:41 +02:00
  b7c0f26910
• feat: split memories part 2 (#19860)

  Keep extracting memories out of core and moving the write trigger in the
  app-server
  This is temporary and it should move at the client level as a follow-up
  This makes core fully independant from `codex-memories-write`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-28 13:03:28 +02:00
  431ebeaef7
• Add MultiAgentV2 root and subagent context hints (#19805)

  ## Why
  
  MultiAgentV2 sessions need startup guidance that matches the role of the
  thread that is actually being created. Root agents and subagents have
  different responsibilities, and forked subagents can inherit parent
  rollout history. If the parent hint is carried into the child context,
  the child can see stale or conflicting developer guidance before its own
  session-specific context is added.
  
  ## What changed
  
  - Added `features.multi_agent_v2.root_agent_usage_hint_text` and
  `features.multi_agent_v2.subagent_usage_hint_text` config fields,
  including schema/config parsing support.
  - Injected the matching root or subagent hint into the initial context
  as its own developer message when `multi_agent_v2` is enabled.
  - Filtered configured MultiAgentV2 usage-hint developer messages out of
  forked parent history so a child thread receives fresh guidance for its
  own session source/config.
  - Added targeted coverage for config parsing, initial-context rendering,
  feature-config deserialization, and forked-history filtering.
  
  ## Context examples
  
  With this config:
  
  ```toml
  [features.multi_agent_v2]
  enabled = true
  root_agent_usage_hint_text = "Root guidance."
  subagent_usage_hint_text = "Subagent guidance."
  ```
  
  A root thread initial context renders the root hint as a standalone
  developer message:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Root guidance.
  ```
  
  A subagent thread initial context renders the subagent hint instead:
  
  ```text
  [developer]
  <existing developer context, when present>
  
  [developer]
  Subagent guidance.
  ```
  
  When a subagent forks parent history, any parent developer message whose
  text exactly matches the configured MultiAgentV2 root or subagent hint
  is omitted from the forked history before the child receives its fresh
  subagent hint.

  jif-oai · 2026-04-28 12:31:45 +02:00
  fd36838cf3
• permissions: derive snapshot sandbox projections (#19775)

  ## Why
  
  `ThreadConfigSnapshot` is used by app-server and thread metadata code as
  a stable view of active runtime settings. Keeping both `sandbox_policy`
  and `permission_profile` in the snapshot duplicates permission state and
  makes it possible for the legacy projection to drift from the canonical
  profile.
  
  The legacy `sandbox` value is still needed at app-server compatibility
  boundaries, so this PR derives it on demand from the snapshot profile
  and cwd instead of storing it.
  
  ## What Changed
  
  - Removes `ThreadConfigSnapshot.sandbox_policy`.
  - Adds `ThreadConfigSnapshot::sandbox_policy()` as a compatibility
  projection from `permission_profile` plus `cwd`.
  - Updates app-server response/metadata code and tests to call the
  projection only where legacy fields still exist.
  - Keeps snapshot construction profile-only so split filesystem rules,
  disabled enforcement, and external enforcement remain represented by the
  canonical profile.
  
  ## Verification
  
  - `cargo test -p codex-app-server
  thread_response_permission_profile_preserves_enforcement --lib`
  - `cargo test -p codex-core
  dispatch_reclaims_stale_global_lock_and_starts_consolidation --lib`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19775).
  * #19900
  * #19899
  * #19776
  * __->__ #19775

  Michael Bolin · 2026-04-27 22:30:47 -07:00
  fc2a69107c
• permissions: make SessionConfigured profile-only (#19774)

  ## Why
  
  `SessionConfiguredEvent` is the internal event that tells clients what
  permissions are active for a session. Emitting both `sandbox_policy` and
  `permission_profile` leaves two possible authorities and forces every
  consumer to decide which one to honor. At this point in the migration,
  the profile is expressive enough to represent managed, disabled, and
  external sandbox enforcement, so the internal event can be profile-only.
  
  The wire compatibility concern is older serialized events or rollout
  data that only contain `sandbox_policy`; those still need to
  deserialize.
  
  ## What Changed
  
  - Removes `sandbox_policy` from `SessionConfiguredEvent` and makes
  `permission_profile` required.
  - Adds custom deserialization so old payloads with only `sandbox_policy`
  are upgraded to a cwd-anchored `PermissionProfile`.
  - Updates core event emission and TUI session handling to sync
  permissions from the profile directly.
  - Updates app-server response construction to derive the legacy
  `sandbox` response field from the active thread snapshot instead of from
  `SessionConfiguredEvent`.
  - Updates yolo-mode display logic to treat both
  `PermissionProfile::Disabled` and managed unrestricted filesystem plus
  enabled network as full-access, while still preserving the distinction
  between no sandbox and external sandboxing.
  
  ## Verification
  
  - `cargo test -p codex-protocol session_configured_event --lib`
  - `cargo test -p codex-protocol serialize_event --lib`
  - `cargo test -p codex-exec session_configured --lib`
  - `cargo test -p codex-app-server
  thread_response_permission_profile_preserves_enforcement --lib`
  - `cargo test -p codex-core
  session_configured_reports_permission_profile_for_external_sandbox
  --lib`
  - `cargo test -p codex-tui session_configured --lib`
  - `cargo test -p codex-tui
  yolo_mode_includes_managed_full_access_profiles --lib`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19774).
  * #19900
  * #19899
  * #19776
  * #19775
  * __->__ #19774

  Michael Bolin · 2026-04-27 22:06:47 -07:00
  bf38def44e
• Avoid persisting ShutdownComplete after thread shutdown (#19630)

  ## Why
  
  Fixes #19475.
  
  `codex exec` can finish successfully and then emit an `ERROR` on stderr:
  
  ```text
  failed to record rollout items: thread <id> not found
  ```
  
  That happens because shutdown closes the live thread writer before
  emitting `ShutdownComplete`. The terminal event was still using the
  normal `send_event_raw` path, so it tried to append rollout items
  through a recorder that had already been removed. The answer is correct,
  but wrappers that treat stderr as failure can retry completed exec runs.
  
  This looks like a likely recent regression from
  [#18882](https://github.com/openai/codex/pull/18882), which routed live
  thread writes through `ThreadStore` and added the shutdown-time live
  writer close. I have not bisected this, so the PR treats #18882 as the
  likely source based on the affected shutdown code path rather than a
  proven first-bad commit.
  
  ## What Changed
  
  `ShutdownComplete` now bypasses rollout persistence after thread
  shutdown and is delivered directly to clients. The shutdown path still
  records the protocol event in the rollout trace before delivery,
  preserving trace visibility without attempting a post-shutdown
  thread-store append.
  
  The change also adds a regression test with the in-memory thread store
  to assert that shutdown creates and shuts down the live thread without
  appending another item after shutdown.

  Eric Traut · 2026-04-27 22:02:08 -07:00
  5ba908d179
• Remove ghost snapshots (#19481)

  ## Summary
  - Remove `ghost_snapshot` / `GhostCommit` from the Responses API surface
  and generated SDK/schema artifacts.
  - Keep legacy config loading compatible, but make undo a no-op that
  reports the feature is unavailable.
  - Clean up core history, compaction, telemetry, rollout, and tests to
  stop carrying ghost snapshot items.
  
  ## Testing
  - Unit tests passed for `codex-protocol`, `codex-core` targeted undo and
  compaction flows, `codex-rollout`, and `codex-app-server-protocol`.
  - Regenerated config and app-server schemas plus Python SDK artifacts
  and verified they match the checked-in outputs.

  pakrym-oai · 2026-04-27 18:48:57 -07:00
  4e05f3053c
• permissions: remove cwd special path (#19841)

  ## Why
  
  The experimental `PermissionProfile` API had both `:cwd` and
  `:project_roots` special filesystem paths, which made the permission
  root ambiguous. This PR removes the unstable `current_working_directory`
  special path before the permissions API is stabilized, so callers use
  `:project_roots` for symbolic project-root access.
  
  ## What changed
  
  - Removes `FileSystemSpecialPath::CurrentWorkingDirectory` from protocol
  and app-server protocol models, plus regenerated app-server
  JSON/TypeScript schemas.
  - Replaces internal `:cwd` permission entries with `:project_roots`
  entries.
  - Keeps the existing cwd-update behavior for legacy-shaped
  workspace-write profiles, while removing the deleted
  `CurrentWorkingDirectory` case from that compatibility path.
  - Keeps `PermissionProfile::workspace_write()` as the reusable symbolic
  workspace-write helper, with docs noting that `:project_roots` entries
  resolve at enforcement time.
  - Updates app-server docs/examples and approval UI labeling to stop
  advertising `:cwd` as a permission token.
  
  ## Compatibility
  
  Persisted rollout items may contain the old
  `{"kind":"current_working_directory"}` tag from earlier experimental
  `permissionProfile` snapshots. This PR keeps that tag as a
  deserialize-only alias for `ProjectRoots { subpath: None }`, while
  continuing to serialize only the new `project_roots` tag.
  
  ## Follow-up
  
  This PR intentionally does not introduce an explicit project-root set on
  `SessionConfiguration` or runtime sandbox resolution. Today, the
  resolver still uses the active cwd as the single implicit project root.
  A follow-up should model project roots separately from tool cwd so
  `:project_roots` entries can resolve against the configured project
  roots, and resolve to no entries when there are no project roots.
  
  ## Verification
  
  - `cargo test -p codex-protocol permissions:: --lib`
  - `cargo test -p codex-app-server-protocol`
  - `cargo test -p codex-sandboxing -p codex-exec-server --lib`
  - `cargo test -p codex-core session_configuration_apply_ --lib`
  - `cargo test -p codex-app-server
  command_exec_permission_profile_project_roots_use_command_cwd --test
  all`
  - `cargo test -p codex-tui
  thread_read_session_state_does_not_reuse_primary_permission_profile
  --lib`
  - `cargo test -p codex-tui
  preset_matching_accepts_workspace_write_with_extra_roots --lib`
  - `cargo test -p codex-config --lib`

  Michael Bolin · 2026-04-27 13:41:27 -07:00
  4b55979755
• [codex-analytics] remove ga flag (#19863)
  rhan-oai · 2026-04-27 19:29:19 +00:00
  215d5a8f7c
• fix: filter dynamic deferred tools from model_visible_specs (#19771)

  fixes #19486
  
  ### Problem
  Right now dynamic deferred tools are filtered at normal-turn prompt
  building time, rather than upstream while building the `ToolRouter`
  itself. This causes issues because dynamic deferred tools are then
  wrongly included in the router's `model_visible_specs`, which is what
  the compaction request-building flow relies on.
  
  ### Fix
  Move the dynamic deferred tool filtering to `ToolRouter` creation time
  to solve this problem for every request that relies on `ToolRouter` for
  `model_visible_specs`, which solves the issue generically.
  
  ### Tests
  Added unit + integration tests to ensure dynamic deferred tools are
  omitted from `model_visible_specs` and compaction request respectively.
  
  Tested against live `/compact` endpoint; raw deferred dynamic tools
  without `tool_search` returned `400` (current bug), while the filtered
  payload (this fix) returns `200`.

  sayan-oai · 2026-04-27 19:09:02 +00:00
  85c1500569
• chore: split memories part 1 (#19818)

  Extract memories into 2 different crates

  jif-oai · 2026-04-27 16:01:05 +02:00
  bb83eec825
• multi_agent_v2: move thread cap into feature config (#19792)

  ## Why
  
  `features.multi_agent_v2.max_concurrent_threads_per_session` is meant to
  be the MultiAgentV2-specific session thread cap: it counts the root
  thread and all open subagent threads. The previous implementation kept
  this surface tied to `agents.max_threads`, which made it a global
  subagent-only cap and allowed the legacy setting to coexist with
  MultiAgentV2.
  
  ## What Changed
  
  - Added `max_concurrent_threads_per_session` to
  `[features.multi_agent_v2]` with default `4`.
  - Removed the `[agents] max_concurrent_threads_per_session` alias to
  `agents.max_threads`.
  - When MultiAgentV2 is enabled, reject `agents.max_threads` and derive
  the existing internal subagent slot limit as
  `max_concurrent_threads_per_session - 1`.
  - Regenerated `core/config.schema.json` and added coverage for the new
  config semantics.
  
  ## Result
  ```
  ➜  codex git:(jif/clean-multi-agent-v2-config) codex -c features.multi_agent_v2.enabled=true -c features.multi_agent_v2.max_concurrent_threads_per_session=3
  ╭────────────────────────────────────────────────────╮
  │ >_ OpenAI Codex (v0.0.0)                           │
  │                                                    │
  │ model:     gpt-5.5 xhigh   fast   /model to change │
  │ directory: ~/code/codex                            │
  ╰────────────────────────────────────────────────────╯
  
    Tip: Update Required - This version will no longer be supported starting May 8th. Please upgrade to the latest version (https://github.com/openai/codex/releases/latest) using your preferred package manager.
  
  › Can you try to spawn 4 agents
  
  
  • I’ll try to start four lightweight agents at once and report exactly what the runtime accepts.
  
  • Spawned Russell [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 1: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Spawned Descartes [no-apps] (gpt-5.5 xhigh)
    └ Spawn probe 2: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 3: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • Agent spawn failed
    └ Spawn probe 4: reply briefly that you started, then wait for further instructions. Do not do any repo work.
  
  • The runtime accepted the first two and rejected the next two with agent thread limit reached. I’m checking whether the two accepted probes have returned cleanly, then I’ll close them if needed.
  ```
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-27 13:31:56 +02:00
  f8c527e529
• permissions: store only constrained permission profiles (#19735)
  Michael Bolin · 2026-04-26 20:59:58 -07:00
  0ccd659b4b
• Add /auto-review-denials retry approval flow (#19058)

  ## Why
  
  Auto-review can deny an action that the user later decides they want to
  retry. Today there is no TUI surface for selecting a recent denial and
  sending explicit approval context back into the session, so users have
  to restate intent manually and the retry can be reviewed without the
  original denied action context.
  
  This adds a narrow TUI-driven path for approving a recent denied action
  while still keeping the retry inside the normal auto-review flow.
  
  ## What Changed
  
  - Added `/auto-review-denials` to open a picker of recent denied
  auto-review actions.
  - Added a small in-memory TUI store for the 10 most recent denied
  auto-review events.
  - Selecting a denial sends the structured denied event back through the
  existing core/app-server op path.
  - Core now injects a developer message containing the approved action
  JSON rather than the full assessment event.
  - Auto-review transcript collection now preserves this specific approval
  developer message so follow-up review sessions can see the user approval
  context.
  - Added TUI snapshot/unit coverage for the picker and approval dispatch
  path.
  - Added core coverage for retaining the approval developer message in
  the auto-review transcript.
  
  ## Verification
  
  - `cargo test -p codex-core
  collect_guardian_transcript_entries_keeps_manual_approval_developer_message`
  - `cargo test -p codex-tui auto_review_denials`
  - `cargo test -p codex-tui
  approving_recent_denial_emits_structured_core_op_once`
  
  ## Notes
  
  This intentionally keeps retries going through auto-review. The approval
  signal is context for the exact previously denied action, not a blanket
  bypass for similar future actions.

  Won Park · 2026-04-27 03:43:53 +00:00
  8033b6a449
• permissions: centralize legacy sandbox projection (#19734)

  ## Why
  
  The remaining migration work still needs `SandboxPolicy` at a few
  compatibility boundaries, but those projections should come from one
  canonical path. Keeping ad hoc legacy projections scattered through
  app-server, CLI, and config code makes it easy for behavior to drift as
  `PermissionProfile` gains fidelity that the legacy enum cannot
  represent.
  
  ## What Changed
  
  - Adds `Permissions::legacy_sandbox_policy(cwd)` and
  `Config::legacy_sandbox_policy()` as the compatibility projection from
  the canonical `PermissionProfile`.
  - Adds `Permissions::can_set_legacy_sandbox_policy()` so legacy inputs
  are checked after they are converted into profile semantics.
  - Updates app-server command handling, Windows sandbox setup, session
  configuration, and sandbox summaries to use the centralized projection
  helper.
  - Leaves `SandboxPolicy` in place only for boundary inputs/outputs that
  still speak the legacy abstraction.
  
  ## Verification
  
  - `cargo check -p codex-config -p codex-core -p codex-sandboxing -p
  codex-app-server -p codex-cli -p codex-tui`
  - `cargo test -p codex-tui
  permissions_selection_history_snapshot_full_access_to_default --
  --nocapture`
  - `cargo test -p codex-tui
  permissions_selection_sends_approvals_reviewer_in_override_turn_context
  -- --nocapture`
  - `bazel test //codex-rs/tui:tui-unit-tests-bin
  --test_arg=permissions_selection_history_snapshot_full_access_to_default
  --test_output=errors`
  - `bazel test //codex-rs/tui:tui-unit-tests-bin
  --test_arg=permissions_selection_sends_approvals_reviewer_in_override_turn_context
  --test_output=errors`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19734).
  * #19737
  * #19736
  * #19735
  * __->__ #19734

  Michael Bolin · 2026-04-26 20:31:23 -07:00
  0d8cdc0510
• inline hostname resolution for remote sandbox config (#19739)

  # Why
  
  Requirements support host-specific
  `remote_sandbox_config.hostname_patterns`, but config loading previously
  resolved and passed the system hostname through every config-loading
  path even when no requirements layer used `remote_sandbox_config`. On
  machines where hostname lookup is slow, startup and app-server config
  reads paid for a feature that was not active.
  
  We only need the hostname when a requirements layer actually declares
  `remote_sandbox_config`, so this moves hostname resolution to the single
  requirements merge point and keeps all other config callers unaware of
  hostname matching.
  
  # What
  
  - Removed the eager `host_name` plumbing from
  `load_config_layers_state`, `load_requirements_toml`, `ConfigBuilder`,
  app-server `ConfigManager`, network proxy loading, and related call
  sites.
  - Resolve the hostname inside
  `merge_requirements_with_remote_sandbox_config` only when the incoming
  requirements contain `remote_sandbox_config`.

  Abhinav · 2026-04-27 03:18:57 +00:00
  c3e60849e5
• permissions: remove core legacy policy round trips (#19394)

  ## Why
  
  Several execution paths still converted profile-backed permissions into
  `SandboxPolicy` and then rebuilt runtime permissions from that legacy
  shape. Those round trips are unnecessary after the preceding PRs and can
  lose split filesystem semantics. Core approval and escalation should
  carry the resolved profile directly.
  
  ## What Changed
  
  - Removes `sandbox_policy` from `ResolvedPermissionProfile`; the
  resolved permission object now carries the canonical `PermissionProfile`
  directly.
  - Updates exec-policy fallback, shell/unified-exec interception,
  escalation reruns, and related tests to pass profiles instead of legacy
  policies.
  - Removes legacy additional-permission merge helpers that built an
  effective `SandboxPolicy` before rebuilding runtime permissions.
  - Keeps legacy projections only at compatibility boundaries that still
  require `SandboxPolicy`, not in core permission computation.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19394).
  * #19737
  * #19736
  * #19735
  * #19734
  * #19395
  * __->__ #19394

  Michael Bolin · 2026-04-26 17:43:32 -07:00
  2cb8746457
• Delete unused ResponseItem::Message.end_turn (#19605)

  This field is unused. Delete it.

  Andrey Mishchenko · 2026-04-26 17:18:09 -07:00
  35bc6e3d01
• permissions: migrate approval and sandbox consumers to profiles (#19393)

  ## Why
  
  Runtime decisions should not infer permissions from the lossy legacy
  sandbox projection once `PermissionProfile` is available. In particular,
  `Disabled` and `External` need to remain distinct, and managed profiles
  with split filesystem or deny-read rules should not be collapsed before
  approval, network, safety, or analytics code makes decisions.
  
  ## What Changed
  
  - Changes managed network proxy setup and network approval logic to use
  `PermissionProfile` when deciding whether a managed sandbox is active.
  - Migrates patch safety, Guardian/user-shell approval paths, Landlock
  helper setup, analytics sandbox classification, and selected
  turn/session code to profile-backed permissions.
  - Validates command-level profile overrides against the constrained
  `PermissionProfile` rather than a strict `SandboxPolicy` round trip.
  - Preserves configured deny-read restrictions when command profiles are
  narrowed.
  - Adds coverage for profile-backed trust, network proxy/approval
  behavior, patch safety, analytics classification, and command-profile
  narrowing.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19393).
  * #19395
  * #19394
  * __->__ #19393

  Michael Bolin · 2026-04-26 15:30:40 -07:00
  dda8199b73
• [codex] Move config loading into codex-config (#19487)

  ## Why
  
  Config loading had become split across crates: `codex-config` owned the
  config types and merge logic, while `codex-core` still owned the loader
  that assembled the layer stack. This change consolidates that
  responsibility in `codex-config`, so the crate that defines config
  behavior also owns how configs are discovered and loaded.
  
  To make that move possible without reintroducing the old dependency
  cycle, the shell-environment policy types and helpers that
  `codex-exec-server` needs now live in `codex-protocol` instead of
  flowing through `codex-config`.
  
  This also makes the migrated loader tests more deterministic on machines
  that already have managed or system Codex config installed by letting
  tests override the system config and requirements paths instead of
  reading the host's `/etc/codex`.
  
  ## What Changed
  
  - moved the config loader implementation from `codex-core` into
  `codex-config::loader` and deleted the old `core::config_loader` module
  instead of leaving a compatibility shim
  - moved shell-environment policy types and helpers into
  `codex-protocol`, then updated `codex-exec-server` and other downstream
  crates to import them from their new home
  - updated downstream callers to use loader/config APIs from
  `codex-config`
  - added test-only loader overrides for system config and requirements
  paths so loader-focused tests do not depend on host-managed config state
  - cleaned up now-unused dependency entries and platform-specific cfgs
  that were surfaced by post-push CI
  
  ## Testing
  
  - `cargo test -p codex-config`
  - `cargo test -p codex-core config_loader_tests::`
  - `cargo test -p codex-protocol -p codex-exec-server -p
  codex-cloud-requirements -p codex-rmcp-client --lib`
  - `cargo test --lib -p codex-app-server-client -p codex-exec`
  - `cargo test --no-run --lib -p codex-app-server`
  - `cargo test -p codex-linux-sandbox --lib`
  - `cargo shear`
  - `just bazel-lock-check`
  
  ## Notes
  
  - I did not chase unrelated full-suite failures outside the migrated
  loader surface.
  - `cargo test -p codex-core --lib` still hits unrelated proxy-sensitive
  failures on this machine, and Windows CI still shows unrelated
  long-running/timeouting test noise outside the loader migration itself.

  pakrym-oai · 2026-04-26 15:10:53 -07:00
  9c3abcd46c
• permissions: derive compatibility policies from profiles (#19392)

  ## Why
  
  After #19391, `PermissionProfile` and the split filesystem/network
  policies could still be stored in parallel. That creates drift risk: a
  profile can preserve deny globs, external enforcement, or split
  filesystem entries while a cached projection silently loses those
  details. This PR makes the profile the runtime source and derives
  compatibility views from it.
  
  ## What Changed
  
  - Removes stored filesystem/network sandbox projections from
  `Permissions` and `SessionConfiguration`; their accessors now derive
  from the canonical `PermissionProfile`.
  - Derives legacy `SandboxPolicy` snapshots from profiles only where an
  older API still needs that field.
  - Updates MCP connection and elicitation state to track
  `PermissionProfile` instead of `SandboxPolicy` for auto-approval
  decisions.
  - Adds semantic filesystem-policy comparison so cwd changes can preserve
  richer profiles while still recognizing equivalent legacy projections
  independent of entry ordering.
  - Updates config/session tests to assert profile-derived projections
  instead of parallel stored fields.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19392).
  * #19395
  * #19394
  * #19393
  * __->__ #19392

  Michael Bolin · 2026-04-26 15:06:42 -07:00
  deaa307fb2
• permissions: make runtime config profile-backed (#19606)

  ## Why
  
  This supersedes #19391. During stack repair, GitHub marked #19391 as
  merged into a temporary stack branch rather than into `main`, so the
  runtime-config change needed a fresh PR.
  
  `PermissionProfile` is now the canonical permissions shape after #19231
  because it can distinguish `Managed`, `Disabled`, and `External`
  enforcement while also carrying filesystem rules that legacy
  `SandboxPolicy` cannot represent cleanly. Core config and session state
  still needed to accept profile-backed permissions without forcing every
  profile through the strict legacy bridge, which rejected valid runtime
  profiles such as direct write roots.
  
  The unrelated CI/test hardening that previously rode along with this PR
  has been split into #19683 so this PR stays focused on the permissions
  model migration.
  
  ## What Changed
  
  - Adds `Permissions.permission_profile` and
  `SessionConfiguration.permission_profile` as constrained runtime state,
  while keeping `sandbox_policy` as a legacy compatibility projection.
  - Introduces profile setters that keep `PermissionProfile`, split
  filesystem/network policies, and legacy `SandboxPolicy` projections
  synchronized.
  - Uses a compatibility projection for requirement checks and legacy
  consumers instead of rejecting profiles that cannot round-trip through
  `SandboxPolicy` exactly.
  - Updates config loading, config overrides, session updates, turn
  context plumbing, prompt permission text, sandbox tags, and exec request
  construction to carry profile-backed runtime permissions.
  - Preserves configured deny-read entries and `glob_scan_max_depth` when
  command/session profiles are narrowed.
  - Adds `PermissionProfile::read_only()` and
  `PermissionProfile::workspace_write()` presets that match legacy
  defaults.
  
  ## Verification
  
  - `cargo test -p codex-core direct_write_roots`
  - `cargo test -p codex-core runtime_roots_to_legacy_projection`
  - `cargo test -p codex-app-server
  requested_permissions_trust_project_uses_permission_profile_intent`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19606).
  * #19395
  * #19394
  * #19393
  * #19392
  * __->__ #19606

  Michael Bolin · 2026-04-26 13:29:54 -07:00
  4d7ce3447d
• Support end_turn in response.completed (#19610)

  Some providers of Responses API forward a model-defined `end_turn`
  boolean indicating explicitly the model's indication of whether it would
  like to end the turn or to be inferenced again. In this PR, we update
  the sampling loop to use this field correctly if it's set. If the field
  is not set by the provider, we fall back to the existing sampling logic.

  Andrey Mishchenko · 2026-04-25 21:57:42 -07:00
  355c40ad7e
• Add goal core runtime (4 / 5) (#18076)

  Adds the core runtime behavior for active goals on top of the model
  tools from PR 3.
  
  ## Why
  
  A long-running goal should be a core runtime concern, not something
  every client has to implement. Core owns the turn lifecycle, tool
  completion boundaries, interruptions, resume behavior, and token usage,
  so it is the right place to account progress, enforce budgets, and
  decide when to continue work.
  
  ## What changed
  
  - Centralized goal lifecycle side effects behind
  `Session::goal_runtime_apply(GoalRuntimeEvent::...)`.
  - Starts goal continuation turns only when the session is idle; pending
  user input and mailbox work take priority.
  - Accounts token and wall-clock usage at turn, tool, mutation,
  interrupt, and resume boundaries; `get_thread_goal` remains read-only.
  - Preserves sub-second wall-clock remainder across accounting boundaries
  so long-running goals do not drift downward over time.
  - Treats token budget exhaustion as a soft stop by marking the goal
  `budget_limited` and injecting wrap-up steering instead of aborting the
  active turn.
  - Suppresses budget steering when `update_goal` marks a goal complete.
  - Pauses active goals on interrupt and auto-reactivates paused goals
  when a thread resumes outside plan mode.
  - Suppresses repeated automatic continuation when a continuation turn
  makes no tool calls.
  - Added continuation and budget-limit prompt templates.
  
  ## Verification
  
  - Added focused core coverage for continuation scheduling, accounting
  boundaries, budget-limit steering, completion accounting, interrupt
  pause behavior, resume auto-activation, and wall-clock remainder
  accounting.

  Eric Traut · 2026-04-24 21:16:00 -07:00
  4167628622
• Add goal model tools (3 / 5) (#18075)

  Adds the model-facing goal tools on top of the app-server API from PR 2.
  
  ## Why
  
  Once goals are persisted and exposed to clients, the model needs a
  small, constrained tool surface for goal workflows. The tool contract
  should let the model inspect goals, create them only when explicitly
  requested, and mark them complete without giving it broad control over
  user/runtime-owned state.
  
  ## What changed
  
  - Added `get_goal`, `create_goal`, and `update_goal` tool specs behind
  the `goals` feature flag.
  - Added core goal tool handlers that validate objectives and token
  budgets before mutating persisted state.
  - Constrained `create_goal` to create only when no goal exists, with
  optional `token_budget` only when a budget is explicitly provided.
  - Tightened the `create_goal` instructions so the model does not infer
  goals from ordinary task requests.
  - Constrained `update_goal` to expose only goal completion; pause,
  resume, clear, and budget-limited transitions remain user- or
  runtime-controlled.
  - Registered the goal tools in the tool registry and kept them out of
  review contexts where they should not appear.
  
  ## Verification
  
  - Added tool-registry coverage for feature gating and tool availability.
  - Added core session tests for create/get/update behavior, duplicate
  goal rejection, budget validation, and completion-only updates.

  Eric Traut · 2026-04-24 20:54:40 -07:00
  32ace07ac5
• Add goal app-server API (2 / 5) (#18074)

  Adds the app-server v2 goal API on top of the persisted goal state from
  PR 1.
  
  ## Why
  
  Clients need a stable app-server surface for reading and controlling
  materialized thread goals before the model tools and TUI can use them.
  Goal changes also need to be observable by app-server clients, including
  clients that resume an existing thread.
  
  ## What changed
  
  - Added v2 `thread/goal/get`, `thread/goal/set`, and `thread/goal/clear`
  RPCs for materialized threads.
  - Added `thread/goal/updated` and `thread/goal/cleared` notifications so
  clients can keep local goal state in sync.
  - Added resume/snapshot wiring so reconnecting clients see the current
  goal state for a thread.
  - Added app-server handlers that reconcile persisted rollout state
  before direct goal mutations.
  - Updated the app-server README plus generated JSON and TypeScript
  schema fixtures for the new API surface.
  
  ## Verification
  
  - Added app-server v2 coverage for goal get/set/clear behavior,
  notification emission, resume snapshots, and non-local thread-store
  interactions.

  Eric Traut · 2026-04-24 20:53:41 -07:00
  6c874f9b34
• Remove js_repl feature (#19410)
  Curtis 'Fjord' Hawthorne · 2026-04-24 17:49:29 -07:00
  8a559e7938
• permissions: remove legacy read-only access modes (#19449)

  ## Why
  
  `ReadOnlyAccess` was a transitional legacy shape on `SandboxPolicy`:
  `FullAccess` meant the historical read-only/workspace-write modes could
  read the full filesystem, while `Restricted` tried to carry partial
  readable roots. The partial-read model now belongs in
  `FileSystemSandboxPolicy` and `PermissionProfile`, so keeping it on
  `SandboxPolicy` makes every legacy projection reintroduce lossy
  read-root bookkeeping and creates unnecessary noise in the rest of the
  permissions migration.
  
  This PR makes the legacy policy model narrower and explicit:
  `SandboxPolicy::ReadOnly` and `SandboxPolicy::WorkspaceWrite` represent
  the old full-read sandbox modes only. Split readable roots, deny-read
  globs, and platform-default/minimal read behavior stay in the runtime
  permissions model.
  
  ## What changed
  
  - Removes `ReadOnlyAccess` from
  `codex_protocol::protocol::SandboxPolicy`, including the generated
  `access` and `readOnlyAccess` API fields.
  - Updates legacy policy/profile conversions so restricted filesystem
  reads are represented only by `FileSystemSandboxPolicy` /
  `PermissionProfile` entries.
  - Keeps app-server v2 compatible with legacy `fullAccess` read-access
  payloads by accepting and ignoring that no-op shape, while rejecting
  legacy `restricted` read-access payloads instead of silently widening
  them to full-read legacy policies.
  - Carries Windows sandbox platform-default read behavior with an
  explicit override flag instead of depending on
  `ReadOnlyAccess::Restricted`.
  - Refreshes generated app-server schema/types and updates tests/docs for
  the simplified legacy policy shape.
  
  ## Verification
  
  - `cargo check -p codex-app-server-protocol --tests`
  - `cargo check -p codex-windows-sandbox --tests`
  - `cargo test -p codex-app-server-protocol sandbox_policy_`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19449).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19449

  Michael Bolin · 2026-04-24 17:16:58 -07:00
  789f387982
• feat: Compress skill paths with root aliases (#19098)

  Add skill root tracking so model-visible skill lists can use short path
  aliases when absolute paths would exceed the metadata budget.

  xl-openai · 2026-04-24 15:49:07 -07:00
  1e560f33e1
• Migrate fork and resume reads to thread store (#18900)

  - Route cold thread/resume and thread/fork source loading through
  ThreadStore reads instead of direct rollout path operations
  - Keep lookups that explicitly specify a rollout-path using the local
  thread store methods but return an invalid-request error for remote
  ThreadStore configurations
  - Add some additional unit tests for code path coverage

  Tom · 2026-04-24 13:51:37 -07:00
  0a9b559c0b
• permissions: make legacy profile conversion cwd-free (#19414)

  ## Why
  
  The profile conversion path still required a `cwd` even when it was only
  translating a legacy `SandboxPolicy` into a `PermissionProfile`. That
  made profile producers invent an ambient `cwd`, which is exactly the
  anchoring we are trying to remove from permission-profile data. A legacy
  workspace-write policy can be represented symbolically instead: `:cwd =
  write` plus read-only `:project_roots` metadata subpaths.
  
  This PR creates that cwd-free base so the rest of the stack can stop
  threading cwd through profile construction. Callers that actually need a
  concrete runtime filesystem policy for a specific cwd still have an
  explicitly named cwd-bound conversion.
  
  ## What Changed
  
  - `PermissionProfile::from_legacy_sandbox_policy` now takes only
  `&SandboxPolicy`.
  - `FileSystemSandboxPolicy::from_legacy_sandbox_policy` is now the
  symbolic, cwd-free projection for profiles.
  - The old concrete projection is retained as
  `FileSystemSandboxPolicy::from_legacy_sandbox_policy_for_cwd` for
  runtime/boundary code that must materialize legacy cwd behavior.
  - Workspace-write profiles preserve `CurrentWorkingDirectory` and
  `ProjectRoots` special entries instead of materializing cwd into
  absolute paths.
  
  ## Verification
  
  - `cargo check -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-exec -p
  codex-exec-server -p codex-tui -p codex-sandboxing -p
  codex-linux-sandbox -p codex-analytics --tests`
  - `just fix -p codex-protocol -p codex-core -p codex-app-server-protocol
  -p codex-app-server -p codex-exec -p codex-exec-server -p codex-tui -p
  codex-sandboxing -p codex-linux-sandbox -p codex-analytics`
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/19414).
  * #19395
  * #19394
  * #19393
  * #19392
  * #19391
  * __->__ #19414

  Michael Bolin · 2026-04-24 13:42:05 -07:00
  13e0ec1614
• feat: surface multi-agent thread limit in spawn description (#19360)

  ## Summary
  - Thread `agent_max_threads` into `ToolsConfig` and
  `SpawnAgentToolOptions`.
  - Render the configured `max_concurrent_threads_per_session` value in
  the MultiAgentV2 `spawn_agent` description.
  - Cover the description text in `codex-tools` unit tests and
  `codex-core` tool spec tests.
  
  ## Validation
  - `just fmt`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-core spawn_agent_description`
  - `git diff --check`
  
  ## Notes
  - `cargo test -p codex-core` was also attempted, but unrelated
  environment-sensitive tests failed with the active local environment.
  Examples: approvals reviewer defaults observed `AutoReview` instead of
  `User`, request-permissions event tests did not emit events, and
  proxy-env tests saw `http://127.0.0.1:50604` from the active proxy
  environment.
  
  Co-authored-by: Codex <noreply@openai.com>

  jif-oai · 2026-04-24 15:13:54 +02:00
  deb4509302
• permissions: make profiles represent enforcement (#19231)

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

  Michael Bolin · 2026-04-23 23:02:18 -07:00
  4816b89204
• feat: let model providers own model discovery (#18950)

  ## Why
  
  `codex-models-manager` had grown to own provider-specific concerns:
  constructing OpenAI-compatible `/models` requests, resolving provider
  auth, emitting request telemetry, and deciding how provider catalogs
  should be sourced. That made the manager harder to reuse for providers
  whose model catalog is not fetched from the OpenAI `/models` endpoint,
  such as Amazon Bedrock.
  
  This change moves provider-specific model discovery behind
  provider-owned implementations, so the models manager can focus on
  refresh policy, cache behavior, picker ordering, and model metadata
  merging.
  
  ## What Changed
  
  - Introduced a `ModelsManager` trait with separate `OpenAiModelsManager`
  and `StaticModelsManager` implementations.
  - Added `ModelsEndpointClient` so OpenAI-compatible HTTP fetching lives
  outside `codex-models-manager`.
  - Moved `/models` request construction, provider auth resolution,
  timeout handling, and request telemetry into `codex-model-provider` via
  `OpenAiModelsEndpoint`.
  - Added provider-owned `models_manager(...)` construction so configured
  OpenAI-compatible providers use `OpenAiModelsManager`, while
  static/catalog-backed providers can return `StaticModelsManager`.
  - Added an Amazon Bedrock static model catalog for the GPT OSS Bedrock
  model IDs.
  - Updated core/session/thread manager code and tests to depend on
  `Arc<dyn ModelsManager>`.
  - Moved offline model test helpers into
  `codex_models_manager::test_support`.
  ## Metadata References
  
  The Bedrock catalog metadata is based on the official Amazon Bedrock
  OpenAI model documentation:
  
  - [Amazon Bedrock OpenAI
  models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-openai.html)
  lists the Bedrock model IDs, text input/output modalities, and `128,000`
  token context window for `gpt-oss-20b` and `gpt-oss-120b`.
  - [Amazon Bedrock `gpt-oss-120b` model
  card](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-oss-120b.html)
  lists the `bedrock-runtime` model ID `openai.gpt-oss-120b-1:0`, the
  `bedrock-mantle` model ID `openai.gpt-oss-120b`, text-only modalities,
  and `128K` context window.
  - [OpenAI `gpt-oss-120b` model
  docs](https://developers.openai.com/api/docs/models/gpt-oss-120b)
  document configurable reasoning effort with `low`, `medium`, and `high`,
  plus text input/output modality.
  
  The display names, default reasoning effort, and priority ordering are
  Codex-local catalog choices.
  
  ## Test Plan
  - Manually verified app-server model listing with an AWS profile:
  
  ```shell
  CODEX_HOME="$(mktemp -d)" cargo run -p codex-app-server-test-client -- \
    --codex-bin ./target/debug/codex \
    -c 'model_provider="amazon-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.profile="codex-bedrock"' \
    -c 'model_providers.amazon-bedrock.aws.region="us-west-2"' \
    model-list
  ```
  
  The response returned the Bedrock catalog with `openai.gpt-oss-120b-1:0`
  as the default model and `openai.gpt-oss-20b-1:0` as the second listed
  model, both text-only and supporting low/medium/high reasoning effort.

  Celia Chen · 2026-04-24 04:28:25 +00:00
  e8d8080818
• Add sticky environment API and thread state (#18897)

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

  starr-openai · 2026-04-23 18:57:13 -07:00
  49fb25997f
• [rollout_trace] Add debug trace reduction command (#18880)

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

  cassirer-openai · 2026-04-24 01:56:48 +00:00
  e3c8720a99
• refactor: route Codex auth through AuthProvider (#18811)

  ## Summary
  
  This PR moves Codex backend request authentication from direct
  bearer-token handling to `AuthProvider`.
  
  The new `codex-auth-provider` crate defines the shared request-auth
  trait. `CodexAuth::provider()` returns a provider that can apply all
  headers needed for the selected auth mode.
  
  This lets ChatGPT token auth and AgentIdentity auth share the same
  callsite path:
  - ChatGPT token auth applies bearer auth plus account/FedRAMP headers
  where needed.
  - AgentIdentity auth applies AgentAssertion plus account/FedRAMP headers
  where needed.
  
  Reference old stack: https://github.com/openai/codex/pull/17387/changes
  
  ## Callsite Migration
  
  | Area | Change |
  | --- | --- |
  | backend-client | accepts an `AuthProvider` instead of a raw
  token/header |
  | chatgpt client/connectors | applies auth through
  `CodexAuth::provider()` |
  | cloud tasks | keeps Codex-backend gating, applies auth through
  provider |
  | cloud requirements | uses Codex-backend auth checks and provider
  headers |
  | app-server remote control | applies provider headers for backend calls
  |
  | MCP Apps/connectors | gates on `uses_codex_backend()` and keys caches
  from generic account getters |
  | model refresh | treats AgentIdentity as Codex-backend auth |
  | OpenAI file upload path | rejects non-Codex-backend auth before
  applying headers |
  | core client setup | keeps model-provider auth flow and allows
  AgentIdentity through provider-backed OpenAI auth |
  
  ## Stack
  
  1. https://github.com/openai/codex/pull/18757: full revert
  2. https://github.com/openai/codex/pull/18871: isolated Agent Identity
  crate
  3. https://github.com/openai/codex/pull/18785: explicit AgentIdentity
  auth mode and startup task allocation
  4. This PR: migrate Codex backend auth callsites through AuthProvider
  5. https://github.com/openai/codex/pull/18904: accept AgentIdentity JWTs
  and load `CODEX_AGENT_IDENTITY`
  
  ## Testing
  
  Tests: targeted Rust checks, cargo-shear, Bazel lock check, and CI.

  efrazer-oai · 2026-04-23 17:14:02 -07:00
  5882f3f95e
• [rollout_trace] Trace tool and code-mode boundaries (#18878)

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

  cassirer-openai · 2026-04-23 12:22:11 -07:00
  6d09b6752d