3534 Commits

• Expose local image paths to models (#25944)

  ## Why
  
  Local image attachments include image bytes, but the adjacent
  model-visible label omits the source path. Exposing the path lets
  model-selected workflows refer back to the intended local image
  explicitly.
  
  ## What changed
  
  - Include an escaped `path` attribute in model-visible local image
  opening tags.
  - Reuse the path-aware marker generator in rollout coverage.
  - Update protocol, replay, and rollout coverage for the new request
  shape.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-protocol`
  - `just test -p codex-core skips_local_image_label_text`
  - `just test -p codex-core
  copy_paste_local_image_persists_rollout_request_shape`
  - `git diff --check`

  Won Park · 2026-06-03 19:49:58 +00:00
  57ab4c89e0
• core: stop threading SandboxPolicy through exec (#25700)

  ## Why
  
  #25450 attempts a broad `SandboxPolicy` removal across several unrelated
  surfaces, which makes it hard to review and still leaves new helper code
  moving legacy policies around. This PR is a narrower alternative:
  migrate only the exec-side Windows sandbox plumbing so the review can
  focus on one production path and one compatibility boundary.
  
  The goal is to stop threading `SandboxPolicy` through exec code without
  expanding the migration into app-server, protocol, telemetry, config, or
  session behavior.
  
  ## What changed
  
  - Removed `ExecRequest::compatibility_sandbox_policy()`.
  - Changed the Windows restricted-token and elevated filesystem override
  helpers to accept `PermissionProfile` plus the split filesystem/network
  policies instead of a `SandboxPolicy`.
  - Kept the remaining legacy projection local to the writable-root
  comparison that still needs to compare split policy behavior against the
  legacy Windows backend model.
  - Rejected restricted split filesystem policies that still grant
  full-disk writes before using the Windows restricted-token backend,
  preserving the previous clear-failure behavior for profiles that project
  to `ExternalSandbox`.
  - Updated the Windows sandbox override tests to exercise the new call
  shape and cover the full-write split-profile regression.
  
  ## Verification
  
  - `just test -p codex-core windows_restricted_token`
  - `just test -p codex-core windows_elevated`

  Michael Bolin · 2026-06-03 10:41:41 -07:00
  52b359b249
• feat: guard git enrichment (#26175)

  Skip turn git metadata enrichment when a turn has remote or multiple
  executors, so we do not report the orchestrator checkout as executor
  workspace metadata.
  
  Test: `just test -p codex-core` (blocked by existing
  `Session::conversation_id` compile error in `close_agent.rs`).

  jif · 2026-06-03 18:36:10 +02:00
  8030c36970
• nit: small prompt update for MAv2 (#26179)

  Simple prompt change for MAv2 because of OOD compared to CBv9

  jif · 2026-06-03 18:34:32 +02:00
  99c9be1d30
• fix: main (#26176)
  jif · 2026-06-03 16:47:34 +02:00
  4417e4c193
• chore: mechanical rename (#26156)

  Rename `Session::conversation_id` to `Session::thread_id` with an auto
  refactor in RustRover

  jif · 2026-06-03 15:38:30 +02:00
  c9ae0f48a1
• skills: resolve per-turn catalogs from turn input context (#26106)

  ## Why
  
  The skills extension needs the resolved turn environments to build a
  real per-turn `SkillListQuery`. The previous `TurnLifecycleContributor`
  hook only had a turn id, so it could only seed a placeholder query and
  never carry the executor authorities that executor-scoped skill routing
  will need.
  
  Moving catalog resolution onto `TurnInputContributor` puts the skills
  extension on the same turn-preparation path that already has the
  environment ids and working directories for the submitted turn, while
  keeping the actual prompt injection work for follow-up changes.
  
  ## What changed
  
  - switch `ext/skills` from `TurnLifecycleContributor` to
  `TurnInputContributor`
  - build `executor_authorities` from `TurnInputContext.environments` and
  pass them through `SkillListQuery`
  - keep storing the resolved catalog in `SkillsTurnState`, but drop the
  placeholder query helper that no longer matches the real data flow
  - update the extension TODOs to reflect that per-turn catalog resolution
  now happens in the turn-input contributor, and that prompt/context
  injection still needs to move later
  
  ## Testing
  
  - Not run locally.

  jif · 2026-06-03 13:32:55 +02:00
  3389fa554e
• Reject MAv2 close_agent self-targets (#26144)

  ## Why
  
  `close_agent` is a parent-owned coordination tool: a worker should
  return its result, then let its parent decide when to close it. Before
  this change, if an MAv2 worker targeted itself, the resolved target
  could flow through the normal close path and ask the agent control layer
  to close the current conversation.
  
  ## What changed
  
  - Reject `close_agent` when the resolved target is the current session's
  `conversation_id`, returning a model-visible error that tells the worker
  to return its result instead.
  - Keep the guard after target resolution so it covers both thread-id
  targets and task-path targets.
  - Add coverage for self-targeting by thread id and by task name in
  `multi_agents_tests.rs`.
  
  Relevant code:
  
  -
  [`handle_close_agent`](https://github.com/openai/codex/blob/7c24e6641b693a3eed933dd376ce8f424ab6ea5f/codex-rs/core/src/tools/handlers/multi_agents_v2/close_agent.rs#L39-L57)
  - [`multi_agent_v2_close_agent_rejects_self_target_by_id` /
  `multi_agent_v2_close_agent_rejects_self_target_by_task_name`](https://github.com/openai/codex/blob/7c24e6641b693a3eed933dd376ce8f424ab6ea5f/codex-rs/core/src/tools/handlers/multi_agents_tests.rs#L3936-L4070)
  
  ## Testing
  
  Not run locally.

  jif · 2026-06-03 13:30:04 +02:00
  51493157cd
• chore: extract context fragments into dedicated crate (#26122)

  ## Why
  
  `codex-core` currently owns the generic contextual-fragment trait and
  several reusable fragment implementations. That makes it harder for
  other crates to share the same host-owned model-input abstraction
  without depending on all of `codex-core`.
  
  This change extracts the reusable fragment machinery into a small
  `codex-context-fragments` crate so future extension and skills work can
  depend on the fragment abstraction directly.
  
  ## What Changed
  
  - Added the `codex-context-fragments` crate with:
    - `ContextualUserFragment`
    - `FragmentRegistration` / `FragmentRegistrationProxy`
    - additional-context fragment types
  - Moved `SkillInstructions` into `codex-core-skills`, since
  skill-specific rendering belongs with skills rather than generic core
  context machinery.
  - Kept `codex-core` re-exporting the fragment types it still uses
  internally, so existing call sites keep the same shape.
  - Updated Cargo and Bazel workspace metadata for the new crate.
  
  ## Verification
  
  - `cargo metadata --locked --format-version 1 --no-deps`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  jif · 2026-06-03 12:25:21 +02:00
  ac67905fc4
• feat: default hide_spawn_agent_metadata to true (#26114)

  For MAv2 CBv9

  jif · 2026-06-03 12:22:23 +02:00
  668703c23f
• feat: add extension turn-input contributors (#25959)

  ## Disclaimer
  Do not use for now
  
  ## Why
  
  Extensions can already contribute prompt fragments and request same-turn
  item injection, but there was no host-owned hook for contributing
  structured `ResponseItem`s while Codex is assembling a new turn's
  initial model input. This change adds that seam so extensions can attach
  turn-local input that depends on the submitted user input and resolved
  turn environments without routing through prompt text or late injection.
  
  ## What changed
  
  - add `TurnInputContributor` to `codex_extension_api` and export the new
  `TurnInputContext` / `TurnInputEnvironment` types it receives
  - teach `ExtensionRegistry` to register and expose turn-input
  contributors alongside the existing extension hooks
  - call registered turn-input contributors from
  `core/src/session/turn.rs` while building the initial injected input for
  a turn, then append their returned `ResponseItem`s after the skill and
  plugin injections

  jif · 2026-06-03 01:33:31 +02:00
  271d5cecf2
• config: express implicit sandbox defaults as permission profiles (#25926)

  ## Why
  
  `PermissionProfile` is becoming the default way to represent Codex
  permissions, but the implicit default behavior should stay the same for
  now:
  
  - trusted projects use `:workspace`
  - untrusted projects also use `:workspace`
  - roots without a trust decision use `:read-only`
  - unsandboxed Windows falls back to `:read-only`
  
  This keeps the existing sandbox semantics while making silent config
  defaults observable as built-in permission profiles instead of treating
  the legacy `SandboxPolicy` projection as the primary shape.
  
  ## What Changed
  
  - Refactored legacy sandbox derivation to resolve the configured sandbox
  mode once, then apply the implicit project fallback only when no sandbox
  mode was configured.
  - Preserved the existing trust-decision fallback: trusted and untrusted
  projects default to workspace-write where supported.
  - Added empty-config coverage asserting that an untrusted project
  resolves to the built-in active permission profile (`:workspace` outside
  unsandboxed Windows).
  
  ## Verification
  
  - `just fmt`
  - `just test -p codex-core 'config::'`
  - `just test -p codex-config`
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25926).
  * __->__ #25926

  Michael Bolin · 2026-06-02 16:26:36 -07:00
  a28b32a835
• config: remove dead profile sandbox fallback (#25943)

  ## Why
  
  `profile_sandbox_mode` was left over from the old selected legacy
  profile path. Production now always derives permissions without that
  value, and legacy profile contents are ignored, so keeping a parameter
  that is always `None` makes `derive_permission_profile` look like it
  still supports a fallback that no longer exists.
  
  ## What Changed
  
  - Removed the `profile_sandbox_mode` argument from
  `ConfigToml::derive_permission_profile`.
  - Updated the production caller and legacy sandbox-policy test helper to
  match.
  - Dropped the stale unselected legacy-profile sandbox test that only
  protected the removed fallback shape.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-core 'config::'`
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/25943).
  * #25926
  * __->__ #25943

  Michael Bolin · 2026-06-02 22:05:04 +00:00
  c6d76750e8
• Add remote request permissions integration coverage (#25867)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. This PR (#25867) - Add remote request permissions integration
  coverage: verifies the selected remote environment across request,
  approval, grant reuse, and exec.
  
  This PR is stacked on #25862 and should be reviewed after #25850,
  #25858, and #25862.
  
  ## Why
  
  The environment-scoped permission stack needs one end-to-end check that
  exercises the CCA-shaped path, not only unit-level parsing. This
  verifies that a model-sent `environmentId` on `request_permissions`
  reaches the approval event, stores the grant under the selected
  environment, and is reused by a later tool call in that same
  environment.
  
  ## What Changed
  
  - Adds a remote executor integration test for `request_permissions` with
  `environmentId: remote` and a relative write root.
  - Asserts the permission event reports the remote environment and cwd,
  and that the normalized grant resolves under the remote cwd.
  - Approves the grant, then runs a remote `exec_command` without explicit
  per-call permissions and verifies it completes without another exec
  approval and writes only in the remote filesystem.
  
  ## Verification
  
  - Not run locally per instruction.
  - `git diff --check`

  jif · 2026-06-02 23:55:08 +02:00
  d55e5a9bde
• [codex] Keep hosted tools visible in code-only mode (#25890)

  ## Why
  
  `code_mode_only` moved ordinary runtime tools behind `exec`, but it also
  hid hosted Responses tools. Hosted `web_search` and `image_generation`
  do not have a nested `exec` runtime path, so code-only sessions lost
  those capabilities entirely even when their existing provider, auth,
  model, and configuration gates passed.
  
  ## What changed
  
  - Keep hosted Responses tools top-level in `code_mode_only` sessions
  after their existing gates pass.
  - Preserve the existing nested-tool behavior for ordinary runtimes and
  the direct-only behavior for multi-agent v2 tools.
  - Add planner coverage for `code_mode_only` with default multi-agent v2
  settings, hosted live web search, and hosted image generation.
  
  ## Verification
  
  - Added focused regression coverage in
  `codex-rs/core/src/tools/spec_plan_tests.rs`.
  - Left execution to CI per repository workflow.

  Ahmed Ibrahim · 2026-06-02 14:50:16 -07:00
  68e2c8ed69
• core: stop passing legacy SandboxPolicy to guardian reviews (#25911)

  ## Why
  
  Guardian review turns already submit a read-only `PermissionProfile`,
  which is the permissions model the runtime should honor. Passing the
  equivalent legacy `SandboxPolicy` through `ThreadSettingsOverrides`
  keeps two representations of the same read-only constraint alive on this
  path and makes the guardian flow depend on compatibility plumbing that
  is being phased out.
  
  ## What Changed
  
  - Set `sandbox_policy` to `None` when the guardian review session
  submits its child `Op::UserInput`.
  - Keep `permission_profile: Some(PermissionProfile::read_only())` and
  `approval_policy: Some(AskForApproval::Never)`, so the guardian review
  remains read-only and cannot request approvals.
  - Remove the now-unused `SandboxPolicy` import and redundant comment
  from `codex-rs/core/src/guardian/review_session.rs`.
  
  ## Verification
  
  Not run locally; this is a narrow cleanup of redundant thread-settings
  override state.

  Michael Bolin · 2026-06-02 14:16:12 -07:00
  f6d64bd6ab
• Switch runtime to cloud config bundle (#24622)

  ## Summary
  
  - Adapts the moved `codex-cloud-config` crate from the legacy cloud
  requirements endpoint to the new config bundle endpoint.
  - Switches runtime consumers from `CloudRequirementsLoader` to
  `CloudConfigBundleLoader` so one shared bundle supplies cloud-delivered
  config and requirements.
  - Removes the legacy cloud requirements domain loader path.
  
  ## Details
  
  This intentionally keeps `codex-cloud-config` monolithic for review
  lineage: the previous PR establishes the crate move, and this PR shows
  the behavior change against that moved implementation. A follow-up PR
  splits the module back into focused files.
  
  The new bundle path preserves the important cloud requirements loader
  semantics where intended: account-scoped signed cache, 30 minute TTL, 5
  minute refresh cadence, retry/backoff, auth recovery, and fail-closed
  startup loading. The cached payload changes from a single requirements
  TOML string to the backend-delivered bundle, and validation rejects
  malformed config or requirements fragments before cache write/use.

  joeflorencio-openai · 2026-06-02 13:18:59 -07:00
  d45cd26248
• Populate workspace kind on Codex turn events (#25135)

  ## Summary
  - carry `workspace_kind` from Responses API client metadata into the
  turn resolved analytics fact
  - serialize the optional value on `codex_turn_event`
  - cover both the turn metadata source and turn event serialization
  
  The `workspace_kind` tells us whether a thread had a project attached vs
  projectless. this is an indicator for who is adopting Codex for
  knowledge work outside of coding
  
  ## Testing
  - `env UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just fmt`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-analytics`
  - `env PATH=/private/tmp/cargo-tools/bin:$PATH
  CARGO_HOME=/private/tmp/cargo-home UV_CACHE_DIR=/private/tmp/uv-cache
  /private/tmp/cargo-tools/bin/just test -p codex-core turn_metadata`
  
  Paired with openai/openai#970661, which keeps forwarding the same
  metadata key through Responses API headers.

  knittel-openai · 2026-06-02 12:46:14 -07:00
  b794182ea7
• Propagate permission approval environment id (#25862)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. This PR (#25862) - Propagate permission approval environment id:
  carries the selected environment id through approval events, app-server
  requests, TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  This PR is stacked on #25858, and #25867 is stacked on this PR.
  
  ## Why
  
  PR2 lets the model bind a `request_permissions` call to a selected
  environment, but the approval event and client-facing request still
  needed to carry that binding. For CCA, the user-facing prompt and
  delegated approval path should know which environment the grant applies
  to instead of relying on cwd alone.
  
  ## What Changed
  
  - Added optional `environmentId` to `RequestPermissionsEvent`.
  - Emit the selected environment id from core permission approval events.
  - Preserve the environment id through delegate forwarding, including
  cwd-based delegated requests.
  - Added `environmentId` to app-server permission approval params,
  generated schema/TypeScript artifacts, and README examples.
  - Preserve and display the environment id in TUI permission approval
  prompts.
  - Updated focused core, app-server protocol, and TUI conversion
  coverage.
  
  ## Testing
  
  Not run locally per instruction. Performed read-only `git diff --check`.

  jif · 2026-06-02 21:09:34 +02:00
  9de568372d
• Route standalone image generation through host finalization md (#25176)

  ## Why
  
  Standalone image-generation extensions emitted turn items through the
  low-level event path, bypassing host-owned finalization such as image
  persistence and contributor processing. At the same time, the
  generated-image save-path hint must remain visible to the model through
  the extension tool's `FunctionCallOutput`, rather than the legacy
  built-in developer-message path.
  
  ## What changed
  
  - Extended `ExtensionTurnItem` to support image-generation items while
  keeping the extension-facing emitter API limited to `emit_started` and
  `emit_completed`.
  - Routed extension completion through core `finalize_turn_item`, so
  standalone image-generation items receive host-owned processing and
  persisted `saved_path` values before publication.
  - Kept legacy built-in image generation on its existing
  developer-message hint path, while standalone image generation returns
  its deterministic saved-path hint in `FunctionCallOutput`.
  - Shared the image artifact path and output-hint formatting used by core
  and the image-generation extension.
  - Passed thread identity through extension tool calls so standalone
  image generation can construct the same intended artifact path as core.
  - Added an app-server integration test covering real standalone image
  generation, saved artifact publication, model-visible output hint
  wiring, and absence of the legacy developer-message hint.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-goal-extension`
  - `just test -p codex-memories-extension`
  - Targeted `codex-core` tests for image save history, extension
  completion finalization, and contributor execution
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just fix -p codex-core`
  - `just fix -p codex-image-generation-extension`
  - `just bazel-lock-update`
  - `just bazel-lock-check`

  Won Park · 2026-06-02 12:00:04 -07:00
  57f337a8e9
• Add environmentId to request_permissions (#25858)

  ## Stack
  
  1. #25850 - Key request-permission grants by environment: stores and
  applies sticky permission grants per environment id.
  2. This PR (#25858) - Add `environmentId` to `request_permissions`: lets
  the model target a selected environment and resolves relative permission
  paths against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  This PR is stacked on #25850; #25862 and #25867 are stacked on this PR.
  
  ## Why
  
  PR1 made request-permission grants internally environment-keyed, but the
  model-facing `request_permissions` tool could still only target the
  primary environment. For CCA and multi-environment turns, the tool needs
  an explicit way to bind a permission request to a selected attached
  environment before resolving relative paths.
  
  ## What Changed
  
  - Added optional `environmentId` to `RequestPermissionsArgs`, with
  `environment_id` accepted as an alias.
  - Exposed `environmentId` in the `request_permissions` tool schema and
  description.
  - Resolve the selected environment before parsing filesystem permission
  paths, so relative paths bind to the selected environment cwd.
  - Route validated tool calls through
  `request_permissions_for_environment` directly instead of duplicating
  environment lookup in `Session::request_permissions`.
  - Reject unknown environment ids with a model-facing error.
  - Updated focused request-permissions and Guardian call sites for the
  new optional field.
  
  ## Testing
  
  Not run locally per instruction.

  jif · 2026-06-02 20:51:25 +02:00
  e29071e4c9
• [codex-analytics] Track CodexErr details in turn analytics (#25707)

  ## Summary
  - add analytics-only `CodexErr` telemetry to `codex_turn_event` while
  leaving existing `turn_error` unchanged
  - record terminal `CodexErr` facts from core immediately before the
  existing turn error event is sent
  - emit source-truth `codex_error_*` fields for downstream analytics,
  including the raw `CodexErr::InvalidRequest(String)` message as
  `codex_error_subreason`
  
  ## Validation
  - `just test -p codex-analytics`
  - attempted `just test -p codex-core`, but the local run timed out
  across unrelated integration suites in this environment and is not being
  used as validation

  rhan-oai · 2026-06-02 11:40:35 -07:00
  8e4b92d294
• Key request-permission grants by environment (#25850)

  ## Stack
  
  1. This PR (#25850) - Key request-permission grants by environment:
  stores and applies sticky permission grants per environment id.
  2. #25858 - Add `environmentId` to `request_permissions`: lets the model
  target a selected environment and resolves relative permission paths
  against it.
  3. #25862 - Propagate permission approval environment id: carries the
  selected environment id through approval events, app-server requests,
  TUI prompts, and delegate forwarding.
  4. #25867 - Add remote request permissions integration coverage:
  verifies the selected remote environment across request, approval, grant
  reuse, and exec.
  
  #25858, #25862, and #25867 are stacked on this PR and should be reviewed
  after it.
  
  ## Why
  
  Multi-environment CCA turns can attach both local and remote executors,
  but request-permission grants were still effectively cwd-only. Pending
  permission requests tracked a cwd, while stored turn/session grants had
  no environment identity, so sticky grants could be reused through the
  wrong executor context.
  
  This makes the first permission-grant step environment-aware without
  changing the external `request_permissions` payload shape: omitted
  environment targeting remains bound to the primary turn environment.
  
  ## What Changed
  
  - Store turn- and session-scoped request-permission grants by
  `environment_id`.
  - Keep the selected `TurnEnvironmentSelection` with pending
  `request_permissions` calls so approval responses normalize and record
  grants against the same environment.
  - Resolve relative `request_permissions` file paths against the primary
  turn environment cwd instead of deprecated `turn.cwd`.
  - Apply sticky grants in `shell`, `exec_command`, and `apply_patch` by
  selected environment id while still using the actual tool cwd for
  cwd-relative permission materialization.
  - Update Guardian and request-permissions coverage for the
  environment-keyed grant behavior.
  
  ## Testing
  
  Not run locally. Added or updated focused coverage for:
  
  - `request_permission_grants_are_environment_keyed`
  -
  `request_permissions_tool_resolves_relative_paths_against_primary_environment`
  - related Guardian/request-permissions sticky grant tests

  jif · 2026-06-02 20:16:57 +02:00
  503ec190a8
• core: derive built-in permission profiles from raw policies (#25739)

  ## Why
  
  Permission profiles that extend a built-in profile should behave like
  other TOML inheritance: parent entries provide defaults, and child keys
  override matching fields before the profile is compiled.
  
  That was not true for `:workspace`. Previously, a profile with `extends
  = ":workspace"` seeded the compiled runtime
  `PermissionProfile::workspace_write()` policy and then appended child
  filesystem entries. A child override such as `":tmpdir" = "read"`
  therefore left the inherited `":tmpdir" = "write"` entry in the final
  policy. Since same-target `write` wins over `read` during runtime
  resolution, the child override was ineffective.
  
  This also needs a clear source of truth for the built-in profiles. The
  protocol-level sandbox policy constructors now define the raw built-in
  filesystem entries, and both `PermissionProfile` presets and
  config-profile inheritance derive from those same values.
  
  ## What Changed
  
  - Add a canonical `FileSystemSandboxPolicy::read_only()` constructor
  while keeping the read-only and workspace-write raw filesystem entries
  explicit and independent.
  - Derive `PermissionProfile::read_only()` from
  `FileSystemSandboxPolicy::read_only()`;
  `PermissionProfile::workspace_write()` continues to derive from
  `FileSystemSandboxPolicy::workspace_write()`.
  - Build extensible `:read-only` and `:workspace` parent profiles by
  projecting those canonical sandbox policies into
  `PermissionProfileToml`, then merge user overrides at the TOML layer
  before compilation.
  - Add config parsing support for `:slash_tmp` so the built-in
  `:workspace` parent can be expressed in the same TOML-shaped filesystem
  table as user profiles.
  - Document that `PermissionsToml::resolve_profile()` returns an
  already-merged `PermissionProfileToml`, and return that profile directly
  after removing the resolved-profile wrapper.
  - Extend the config test for `extends = ":workspace"` to assert that
  inherited `":slash_tmp" = "write"` is preserved and that a child
  `":tmpdir" = "read"` entry replaces the inherited `write` entry.
  
  ## Verification
  
  - `just test -p codex-config`
  - `just test -p codex-protocol`
  - `just test -p codex-core
  permissions_profiles_resolve_extends_parent_first_with_child_overrides`
  - `just test -p codex-core
  default_permissions_profile_can_extend_builtin_workspace`
  - `just test -p codex-core`
    - Result: 2596 passed, 4 failed, 1 timed out.
  - The failures were existing sandbox/environment-sensitive tests
  unrelated to this permissions change:
  
  `suite::user_shell_cmd::user_shell_command_does_not_set_network_sandbox_env_var`,
  
  `suite::user_shell_cmd::user_shell_command_history_is_persisted_and_shared_with_model`,
  
  `suite::abort_tasks::interrupt_persists_turn_aborted_marker_in_next_request`,
      `suite::abort_tasks::interrupt_tool_records_history_entries`, and
  
  `thread_manager::tests::start_thread_uses_all_default_environments_from_codex_home`.

  Michael Bolin · 2026-06-02 10:57:35 -07:00
  593df8773d
• Skip startup prewarm when websockets are disabled (#25868)

  ## Summary
  - skip startup websocket prewarm setup when the model client has
  Responses-over-WebSocket disabled
  - avoid making HTTP-only sessions build prewarm prompt/tool state that
  cannot produce a reusable websocket session
  
  ## Why
  Recent macOS timing flakes were timing out while waiting for first-turn
  events in HTTP-only core tests. Startup prewarm is only useful for
  websocket-capable providers, but it was scheduled for every session. For
  HTTP-only test providers this added unnecessary async startup work
  before the regular turn could reach the mocked response flow.
  
  ## Testing
  - bazel test //codex-rs/core:core-all-test
  --test_filter=suite::auto_review::remote_model_override_uses_catalog_model_for_strict_auto_review
  --test_output=errors
  - bazel test //codex-rs/core:core-all-test
  --test_filter=suite::request_permissions_tool::approved_folder_write_request_permissions_unblocks_later_apply_patch
  --test_output=errors

  jif · 2026-06-02 17:27:30 +02:00
  859dbe2761
• [app-server][core] Add connector-level Guardian reviewer overrides (#25167)

  Context: https://openai.slack.com/archives/C0B4JAF0Q2C/p1779912328647229
  
  ```
  approvals_reviewer = "auto_review"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "user"
  default_tools_approval_mode = "prompt"
  ```
  
  <img width="230" height="84" alt="Screenshot 2026-05-31 at 11 56 34 AM"
  src="https://github.com/user-attachments/assets/e319f8f7-0983-42a7-98cd-3302732fa406"
  />
  
  <img width="841" height="233" alt="Screenshot 2026-05-31 at 11 52 42 AM"
  src="https://github.com/user-attachments/assets/7ac76645-4e90-4d00-8242-f031146a22a5"
  />
  
  -------
  
  ```
  approvals_reviewer = "user"
  
  [apps.connector_5f3c8c41a1e54ad7a76272c89e2554fa]
  enabled = true
  approvals_reviewer = "auto_review"
  default_tools_approval_mode = "prompt"
  ```
  <img width="195" height="83" alt="Screenshot 2026-05-31 at 12 02 27 PM"
  src="https://github.com/user-attachments/assets/3d374dc8-8aa2-466f-a13f-e4ed8567aa2e"
  />
  <img width="771" height="207" alt="Screenshot 2026-05-31 at 12 05 42 PM"
  src="https://github.com/user-attachments/assets/105c2575-68d6-4ca6-8e69-dc8c82da36a2"
  />
  
  
  
  ## Summary
  - add `apps.<connector_id>.approvals_reviewer` to override Guardian or
  user review routing per connected app
  - apply overrides across direct app MCP calls, delegated MCP prompts,
  and app-server MCP elicitation review while preserving global behavior
  for non-app MCP servers
  - expose and document the config through app-server v2 and generated
  schemas, while honoring global managed reviewer requirements
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Alex Zamoshchin · 2026-06-02 17:04:11 +02:00
  4d80d808b4
• flake: Keep plugin test homes alive (#25857)

  ## Summary
  
  Keep the full `TestCodex` harness alive in plugin integration tests
  instead of returning only the `CodexThread`.
  
  ## Why
  
  The helper was moving a temporary `codex_home` into `TestCodex`, then
  immediately dropping the harness and returning only the thread. For
  plugin MCP tests, the MCP server cwd is inside that temporary home. If
  the temp directory is removed while MCP startup is still racing, the
  server launch can fail with `No such file or directory`.
  
  Keeping the harness in scope keeps the temp home alive for the test
  duration and removes the lifetime race behind the recent
  `explicit_plugin_mentions_inject_plugin_guidance` flake.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core
  explicit_plugin_mentions_inject_plugin_guidance`

  jif · 2026-06-02 16:21:22 +02:00
  b9af5d1234
• Reduce stack pressure in session startup and config rebuilds (#25844)

  ## Why
  
  `/clear` starts a fresh thread with `InitialHistory::Cleared`, which
  re-enters the thread/session startup path. That path now builds large
  async futures through `ThreadManagerState::spawn_thread_with_source`,
  `Codex::spawn`, and `Session::new`. Separately, TUI config rebuilds for
  cwd and permission-profile changes build a similarly heavy
  `ConfigBuilder::build()` future inside the app task. In debug and Bazel
  runs, those call chains can put enough state on the caller stack to
  abort before startup or config refresh completes.
  
  This change keeps the behavior the same while moving the heaviest future
  frames off the caller stack.
  
  ## What changed
  
  - Box `Codex::spawn(...)` in `codex-rs/core/src/thread_manager.rs`
  before awaiting it from `spawn_thread_with_source`.
  - Box `Session::new(...)` in `codex-rs/core/src/session/mod.rs` before
  awaiting it from `Codex::spawn_internal`.
  - Route `ConfigBuilder::build()` through a small `tokio::spawn` helper
  in `codex-rs/tui/src/app/config_persistence.rs` so cwd and
  permission-profile config rebuilds run on a runtime worker stack while
  preserving error context.
  
  ## Verification
  
  CI is running on the PR.
  
  No new targeted tests were added. This is a mechanical stack-pressure
  reduction that keeps the existing behavior and error propagation intact.

  jif-oai · 2026-06-02 15:42:47 +02:00
  1dd731305a
• Test runtime selector before first turn (#25724)

  Stack split from #25708. Original PR intentionally left open. This fifth
  PR adds coverage that a remotely selected multi-agent runtime is applied
  when the model is selected before the first turn.

  jif-oai · 2026-06-02 15:01:10 +02:00
  33273e4258
• Test remote multi-agent runtime selector override (#25723)

  Stack split from #25708. Original PR intentionally left open. This
  fourth PR adds coverage that remote model multi-agent runtime selectors
  override local feature flag defaults.

  jif-oai · 2026-06-02 14:48:13 +02:00
  66991c949f
• fix: main oops (#25840)

  Fix main, comment is self-explainatory

  jif-oai · 2026-06-02 14:48:04 +02:00
  06e9a33d09
• session: keep startup prewarm aligned with resolved multi-agent runtime (#25841)

  ## Why
  
  Follow-up to #25722. Startup prewarm builds a preview `TurnContext`
  before the first real turn so it can precompute the initial prompt and
  tool surface. After the per-thread runtime work landed, that preview
  path still recomputed multi-agent mode from `model_info` and feature
  defaults instead of reusing the runtime the session had already resolved
  from persisted metadata or inheritance.
  
  That could leave the prewarmed session primed for a different
  multi-agent mode than the first real turn, which is especially risky
  because collaboration tool exposure depends on
  `turn_context.multi_agent_version`.
  
  ## What changed
  
  - In the `TurnMultiAgentRuntime::Preview` path, prefer
  `Session::multi_agent_version()` when it is already known.
  - Only fall back to `model_info.multi_agent_version` and feature
  defaults when the session has not resolved a runtime yet.
  - Keep preview mode read-only: this still avoids storing a runtime
  during startup prewarm.
  
  ## Testing
  
  - Not run (small runtime-selection follow-up)

  jif-oai · 2026-06-02 14:35:26 +02:00
  3cf6f08da5
• Resolve per-thread multi-agent runtime (#25722)

  Stack split from #25708. Original PR intentionally left open. This third
  PR resolves the effective per-thread multi-agent runtime from persisted
  metadata, inherited runtime, and current model selection.

  jif-oai · 2026-06-02 14:31:00 +02:00
  bf9fd885b2
• Persist multi-agent runtime metadata (#25721)

  Stack split from #25708. Original PR intentionally left open. This
  second PR persists multi-agent runtime metadata through thread creation,
  rollout recording, and thread storage.

  jif-oai · 2026-06-02 13:05:20 +02:00
  0c5ccd18ab
• Add multi-agent runtime metadata types (#25720)

  Stack split from #25708. Original PR intentionally left open. This first
  PR adds the multi-agent runtime metadata types and catalog plumbing used
  by the rest of the stack.

  jif-oai · 2026-06-02 12:10:14 +02:00
  3f1fb7ed8b
• [codex] Move plugin discoverable logic into core-plugins (#25783)

  ## Summary
  - Move plugin discoverable recommendation filtering from `codex-core`
  into `codex-core-plugins` behind `ToolSuggestPluginDiscoveryInput`.
  - Keep `codex-core` as a thin adapter from `Config` to the core-plugins
  API and back to `DiscoverablePluginInfo`.
  - Keep the existing discoverable allowlist private to the core-plugins
  implementation.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-core list_tool_suggest_discoverable_plugins`
  - `git diff --check`
  - Read-only subagent review: no findings

  xl-openai · 2026-06-01 23:25:37 -07:00
  07f04cc3c7
• [codex] Cache remote plugin catalog for suggestions (#25457)

  ## Summary
  - cache the global remote plugin catalog when remote plugin listing runs
  and warm it during startup
  - use the cached remote catalog in plugin install recommendations with
  canonical `plugin@openai-curated-remote` ids
  - reuse the session `PluginsManager` for plugin recommendations so
  remote cache state is visible on the recommend path
  - skip core installed-state verification for remote plugin install
  suggestions while leaving local plugin and connector verification
  unchanged
  
  ## Testing
  - `just fmt`
  - `git diff --check`
  - `cargo test -p codex-core
  list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins`
  - `cargo test -p codex-core
  remote_plugin_install_suggestions_skip_core_installed_verification`
  - `cargo test -p codex-app-server
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`
  
  Earlier focused checks during the same branch: codex-tools TUI filter
  test, request_plugin_install tests, and codex-app-server build.

  xl-openai · 2026-06-01 22:10:52 -07:00
  f2b725102b
• feat: show enterprise monthly credit limits in status (#24812)

  ## Summary
  
  Enterprise users can have an effective monthly credit limit, but Codex
  `/status` currently drops that metadata from the account-usage response.
  
  This change adds the optional `spend_control.individual_limit`
  projection to the existing rate-limit snapshot flow. The backend client
  reads the monthly limit, app-server exposes it as `individualLimit`, and
  the TUI renders a `Monthly credit limit` row through the existing
  progress-bar renderer.
  
  When the backend does not return an effective monthly limit, existing
  rate-limit behavior is unchanged.
  
  ## Existing backend state
  
  The account-usage backend already returns the effective monthly limit
  and current usage together:
  
  ```json
  {
    "spend_control": {
      "reached": false,
      "individual_limit": {
        "limit": "25000",
        "used": "8000",
        "remaining": "17000",
        "used_percent": 32,
        "remaining_percent": 68,
        "reset_after_seconds": 86400,
        "reset_at": 1778137680
      }
    }
  }
  ```
  
  Before this change, Codex projected rolling `primary` and `secondary`
  windows plus `credits`. It ignored `spend_control.individual_limit`, so
  app-server clients and `/status` could not render the monthly cap.
  
  The updated flow is:
  
  ```text
  account usage backend
    -> backend-client reads spend_control.individual_limit
    -> existing rate-limit snapshot carries optional individual_limit
    -> app-server exposes optional individualLimit
    -> TUI renders Monthly credit limit
  ```
  
  ## App-server contract
  
  `account/rateLimits/read` and sparse `account/rateLimits/updated`
  notifications now include an additive nullable
  `rateLimits.individualLimit` field:
  
  ```json
  {
    "individualLimit": {
      "limit": "25000",
      "used": "8000",
      "remainingPercent": 68,
      "resetsAt": 1778137680
    }
  }
  ```
  
  In an `account/rateLimits/read` response, `null` means no monthly limit
  is available. `account/rateLimits/updated` remains a sparse rolling
  notification: clients merge available values into their most recent
  `account/rateLimits/read` snapshot or refetch. Nullable account metadata
  in a rolling notification does not clear a previously observed value.
  
  ## Design decisions
  
  - Extend the existing rate-limit snapshot instead of introducing a
  separate request or wire-level update protocol.
  - Keep the Codex projection narrow: `/status` needs the effective limit,
  current usage, remaining percentage, and reset timestamp.
  - Render the monthly row through the existing progress-bar renderer,
  with one optional detail line for `8,000 of 25,000 credits used`.
  - Keep the backend response optional so existing accounts and older
  usage states preserve their current behavior.
  - Preserve cached monthly metadata when sparse rolling notifications
  omit it. Live account-usage reads remain authoritative and can clear a
  removed limit.
  
  ## Visual evidence
  
  ```text
   Monthly credit limit:   [██████████████░░░░░░] 68% left (resets 07:08 on 7 May)
                           8,000 of 25,000 credits used
  ```
  
  Snapshot:
  `codex-rs/tui/src/status/snapshots/codex_tui__status__tests__status_snapshot_includes_enterprise_monthly_credit_limit.snap`
  
  ## Testing
  
  Tests: generated app-server schema verification, protocol tests,
  backend-client tests, app-server integration coverage, TUI snapshot
  coverage, formatting, and workspace lint cleanup.

  efrazer-oai · 2026-06-01 21:25:42 -07:00
  c8e5db16c9
• app-server: remove experimental persist_extended_history bool flag (#25712)

  ## Summary
  
  Remove the dead experimental `persistExtendedHistory` app-server flag
  and collapse rollout persistence to the single policy app-server already
  used.
  
  ## What Changed
  
  - Removed `persistExtendedHistory` from v2 thread start/resume/fork
  params and deleted its deprecation notice path.
  - Removed the persistence-mode enums and plumbing through core, rollout,
  and thread-store.
  - Made rollout filtering mode-free, keeping the existing limited
  persisted-history behavior.
  
  ## Test Plan
  
  - `just write-app-server-schema`
  - `cargo nextest run --no-fail-fast -p codex-app-server-protocol
  schema_fixtures`
  - `cargo nextest run --no-fail-fast -p codex-app-server
  thread_shell_command_history_responses_exclude_persisted_command_executions`
  - `cargo nextest run --no-fail-fast -p codex-rollout -p
  codex-thread-store`
  - final `rg` for removed flag/type names

  Owen Lin · 2026-06-01 23:33:42 +00:00
  11e0f3d3ae
• Wire managed MITM CA trust into child env (#22668)

  ## Stack
  1. Parent PR: #18240 uses named MITM permissions config.
  2. This PR wires managed MITM CA trust into spawned child processes.
  
  ## Why
  When Codex terminates HTTPS for limited mode or MITM hooks, child HTTPS
  clients need to trust Codex's managed MITM CA. Exporting proxy URLs
  alone is not enough, but blindly replacing user CA settings would be
  wrong: it can break custom enterprise/test roots, leak unreadable CA
  files into generated bundles, or make the child env disagree with its
  sandbox policy.
  
  ## Summary
  1. Build immutable managed CA bundles under `$CODEX_HOME/proxy` that
  include native roots, the managed MITM CA, and only inherited or
  command-scoped CA bundles the child is allowed to read.
  2. Export curated CA env vars alongside managed proxy env vars while
  preserving user CA override semantics, including nested Codex
  `SSL_CERT_FILE` precedence.
  3. Thread generated CA bundle paths into child sandbox readable roots,
  including debug sandbox execution, so the exported env vars work inside
  sandboxed commands.
  4. Remove only Codex-generated MITM CA bundle env when a child
  intentionally drops managed proxying for escalation or no-proxy retry.
  5. Document the managed CA bundle behavior and cover env injection,
  per-child bundle generation, sandbox readable roots, and no-proxy
  cleanup in tests.
  
  ## Validation
  1. Ran `just test -p codex-network-proxy`.
  2. Ran `just test -p codex-protocol`.
  3. Ran `just fix -p codex-network-proxy -p codex-protocol`.
  4. Tried focused `codex-core` validation, but the crate currently fails
  to compile in `core/tests/suite/guardian_review.rs` because an existing
  `Op::UserInput` initializer is missing `additional_context`.
  
  ---------
  
  Co-authored-by: Eva Wong <evawong@openai.com>

  Winston Howes · 2026-06-01 23:23:59 +00:00
  bca18cba40
• Move tool search metadata onto ToolExecutor (#25684)

  Deferred tools need to be searchable even when they are not implemented
  inside `codex-core`. Extension-provided tools can be registered for
  later discovery, but the search metadata path was still owned by
  core-specific runtime hooks, which meant the shared `ToolExecutor`
  abstraction could not describe how a deferred extension tool should
  appear in `tool_search`.
  
  ## Changes
  
  - Move `ToolSearchEntry` and `ToolSearchInfo` into `codex-tools` and
  re-export them from the shared tools crate.
  - Add a default `ToolExecutor::search_info` implementation that derives
  loadable tool-search metadata from function and namespace specs.
  - Forward search metadata through extension adapters and exposure
  overrides while keeping custom search text/source metadata for dynamic,
  MCP, and multi-agent tools.
  - Remove the old core-local `tool_search_entry` module now that search
  metadata lives with the shared executor APIs.
  
  ## Testing
  
  - Added `deferred_extension_tools_are_discoverable_with_tool_search`
  coverage in `core/src/tools/spec_plan_tests.rs`.

  jif-oai · 2026-06-02 00:24:41 +02:00
  8d720feb69
• refactor: hide shell override for zsh fork unified exec (#24980)

  ## Why
  
  When unified exec is configured to launch through the zsh fork, local
  commands should not let the model override the shell binary with the
  `shell` parameter. The configured zsh fork is the mechanism that makes
  `execv(2)` interception reliable, so exposing `shell` for local zsh-fork
  execution would create a confusing API surface and undermine the
  composition.
  
  Remote environments are different: zsh-fork interception is local-only,
  so remote unified-exec calls must keep direct unified-exec behavior and
  still expose `shell` when a remote environment can be selected.
  
  ## What Changed
  
  - Taught the `exec_command` schema builder to omit the `shell` parameter
  when requested.
  - Hid `shell` from the unified-exec tool schema only when zsh-fork
  unified exec applies to all selectable environments.
  - Kept `shell` visible when any remote environment can be targeted,
  because those calls run through direct unified exec.
  - Made unified exec choose the effective shell mode per selected
  environment: local environments keep zsh-fork mode, remote environments
  use direct mode.
  - Left direct unified-exec behavior unchanged, including support for
  model-specified shells there.
  
  ## Verification
  
  - Added schema coverage showing `exec_command` can hide `shell`.
  - Added planner coverage showing zsh-fork unified exec hides `shell` for
  local-only execution while direct unified exec still exposes it.
  - Added planner coverage showing `shell` remains visible when a remote
  environment is available.
  - Added handler coverage showing remote environments use direct
  unified-exec shell mode instead of zsh-fork mode.
  - Ran the focused `codex-core` shell-parameter and zsh-fork tests.
  
  
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/24980).
  * #24982
  * #24981
  * __->__ #24980

  Michael Bolin · 2026-06-01 20:22:28 +00:00
  feb9eddc51
• feat: gate unified exec zsh fork composition (#24979)

  ## Why
  
  `shell_zsh_fork` and unified exec need to remain independently
  controllable for enterprise rollouts, but we also need a third mode that
  composes them. That composed mode is intended to preserve unified exec
  command lifecycle support while letting the zsh fork provide more
  accurate `execv(2)` interception.
  
  Enabling `unified_exec_zsh_fork` by itself is intentionally not
  sufficient. It is a composition gate, not a dependency-enabling
  shortcut:
  
  - `unified_exec` selects the PTY-backed unified exec tool.
  - `shell_zsh_fork` opts into the zsh fork backend.
  - `unified_exec_zsh_fork` only allows those two already-enabled modes to
  be composed so local zsh unified exec commands can launch through the
  zsh fork.
  
  This separation is deliberate. Enterprises and staged rollouts must be
  able to enable or disable unified exec and zsh-fork independently. If
  `unified_exec_zsh_fork` implied either dependency, then enabling one
  under-development composition flag would silently activate a shell
  backend that the configured feature set left disabled.
  
  This PR introduces only the configuration and planning gate for that
  composition. Existing `shell_zsh_fork` behavior continues to use the
  standalone shell tool unless the new composition feature is explicitly
  enabled alongside both dependencies.
  
  ## What Changed
  
  - Added the under-development feature flag `unified_exec_zsh_fork`.
  - Added `UnifiedExecFeatureMode` so the three input feature flags
  collapse into `Disabled`, `Direct`, or `ZshFork` mode before tool
  planning.
  - Updated tool selection so zsh-fork composition requires
  `unified_exec`, `shell_zsh_fork`, and `unified_exec_zsh_fork`.
  - Kept the existing standalone zsh-fork shell tool behavior when only
  `shell_zsh_fork` is enabled.
  - Updated config schema output for the new feature flag.
  
  ## Verification
  
  - Added feature and tool-config coverage for the new gate.
  - Added planner coverage proving `shell_zsh_fork` remains standalone
  until composition is explicitly enabled.
  - Ran focused tests for `codex-features`, `codex-tools`, and the
  affected `codex-core` planner case.
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/24979).
  * #24982
  * #24981
  * #24980
  * __->__ #24979

  Michael Bolin · 2026-06-01 13:01:36 -07:00
  d6748f741a
• [codex-rs] auto-review model override (#23767)

  ## Why
  
  Guardian auto-review normally uses the provider-preferred review model
  when one is available. Some parent models need model-catalog metadata to
  select a different review model while keeping older `/models` payloads
  compatible when that metadata is absent.
  
  ## What changed
  
  - Added optional `ModelInfo::auto_review_model_override` metadata to the
  public model payload as a review-model slug.
  - Updated Guardian review model selection to prefer the catalog override
  when present, while preserving the existing provider preferred-model
  path and parent-model fallback when it is omitted.
  - Added focused Guardian coverage for override and no-override model
  selection.
  - Added an `auto_review` core integration suite test that loads override
  metadata from a remote model catalog path and asserts the strict
  auto-review `/responses` request uses the catalog-selected review model.
  - Updated existing `ModelInfo` fixtures and local catalog constructors
  for the new optional field.
  
  ## Validation
  
  - `cargo test -p codex-protocol
  model_info_defaults_availability_nux_to_none_when_omitted`
  - `cargo test -p codex-core guardian_review_uses_`
  - `cargo test -p codex-core
  remote_model_override_uses_catalog_model_for_strict_auto_review --test
  all`
  - `just fix -p codex-protocol`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`

  Won Park · 2026-06-01 11:51:15 -07:00
  f1609d9fb6
• [codex] Consolidate shared prompts in codex-prompts (#25151)

  ## Why
  
  `codex_core` is consistently a bottleneck for incremental builds during
  iteration. The simplest fix is to make the crate smaller.
  
  ## Summary
  
  `codex-core` owns several reusable prompt renderers and static prompt
  assets, which makes the crate harder to split apart.
  
  Rename `codex-review-prompts` to `codex-prompts` and move shared review,
  goal, permissions, compaction, realtime, hierarchical AGENTS.md, and
  `apply_patch` prompts into it. Move prompt-only tests and update
  consumers and `CODEOWNERS`.
  
  ## Validation
  
  - `just test -p codex-prompts -p codex-apply-patch`
  - `just test -p codex-core prompt_caching`
  - Bazel builds for the affected crates

  Adam Perry @ OpenAI · 2026-06-01 18:45:07 +00:00
  ba2b67f9cd
• [codex] Rename multi-agent v2 assign_task to followup_task (#25636)

  ## Summary
  
  Renames the MultiAgentV2 turn-triggering tool from `assign_task` to
  `followup_task` so the exposed tool name better describes sending an
  additional task to an existing agent.
  
  This updates the tool spec, handler/module names, registry wiring,
  default multi-agent v2 usage hints, and tests. Rollout trace
  classification keeps accepting legacy `assign_task` events so older
  traces still reduce correctly, while docs show the new tool name.
  
  ## Test plan
  
  - `just test -p codex-core followup_task`
  - `just test -p codex-core -E
  'test(multi_agent_feature_selects_one_agent_tool_family) |
  test(multi_agent_v2_can_use_configured_tool_namespace) |
  test(code_mode_only_can_expose_namespaced_multi_agent_v2_as_normal_tools)'`
  - `just test -p codex-rollout-trace`
  - `just fix -p codex-core`
  - `just fix -p codex-rollout-trace`
  
  Notes: `just fmt` ran `cargo fmt` but failed in the Python ruff phase
  because the local environment could not resolve `hatchling>=1.27.0` from
  the configured internal registry. A full `just test -p codex-core` also
  hit unrelated environment-sensitive integration failures involving
  missing spawned test binaries/sandbox behavior; the changed multi-agent
  spec/handler tests passed in the filtered runs above.

  jif-oai · 2026-06-01 19:57:11 +02:00
  6ddb747e76
• Compress cold local rollouts (#25089)

  ## Rollout compression stack
  
  This stack splits #24941 into reviewable steps for local rollout
  compression. The design is intentionally staged:
  
  1. Teach readers, listing, search, and lookup to understand compressed
  rollouts.
  2. Make append and resume paths materialize compressed rollouts back to
  plain JSONL before writing.
  3. Add a disabled-by-default worker that can compress cold archived
  rollouts behind `local_thread_store_compression`.
  
  The key invariant is that writers append to plain `.jsonl`. A
  `.jsonl.zst` file is a cold/read representation; if a write is needed,
  the compressed file is materialized back to plain JSONL first. Readers
  prefer plain `.jsonl` when both forms exist and can fall back to the
  compressed sibling during transitions.
  
  The worker is deliberately the last PR and remains behind an
  under-development feature flag. It currently scans only
  `archived_sessions`, not active `sessions`, because active sessions have
  the highest resume/append race risk. That means this stack does not yet
  compress most unarchived local history.
  
  ## Known race / follow-up
  
  The remaining unresolved design question is writer/compressor
  coordination. Even for archived rollouts, a resume or metadata update
  can append while the worker is replacing the plain file with
  `.jsonl.zst`; the current double-stat checks narrow but do not fully
  eliminate the window where a writer has opened the plain file before
  unlink. Do not treat the worker PR as production-ready until we either:
  
  - prevent append/resume paths from racing archived compression, or
  - introduce a shared representation/append lock or equivalent
  coordination.
  
  The first two PRs are useful independently: they make compressed
  rollouts readable and make append paths safely recover back to plain
  JSONL. The third PR isolates the worker behavior so that coordination
  issue is reviewable separately.
  
  ## Validation
  
  Focused local validation for the stack includes:
  
  - `just test -p codex-rollout`
  - `just test -p codex-thread-store` where thread-store paths were
  touched
  - `just test -p codex-features` for the feature flag slice
  - `just bazel-lock-check` after dependency graph changes
  - scoped `just fix -p ...` passes for changed crates
  
  CI is still the source of truth for the full platform matrix.
  
  ## This PR in the stack
  
  This is PR 3/3, based on #25088. It adds the under-development feature
  flag and starts the best-effort background worker when enabled. The
  worker currently compresses only cold archived rollouts, skips active
  sessions, verifies compressed output, preserves mtime and permissions,
  keeps a store-level lock heartbeat, and cleans stale temp files.
  
  Stack order:
  
  1. #25087: read compressed local rollouts.
  2. #25088: materialize compressed rollouts before append.
  3. This PR: add the disabled local compression worker.

  jif-oai · 2026-06-01 18:35:58 +02:00
  01cb97851b
• Remove Plan-mode gate from idle turn injection (#25577)

  ## Why
  
  `try_start_turn_if_idle` is the core helper for starting injected input
  only when the session is actually idle. It should stay focused on
  generic turn-lifecycle safety. The previous `ModeKind::Plan` guard mixed
  caller policy into that helper: Plan mode may choose not to auto-start
  some extension work, but that decision belongs at the extension or
  caller boundary rather than in the session injection primitive.
  
  ## What changed
  
  - Removed the `ModeKind::Plan` early return from
  `Session::try_start_turn_if_idle`.
  - Removed the now-unused `ModeKind` import from
  `core/src/session/inject.rs`.
  
  ## Testing
  
  Not run locally.

  jif-oai · 2026-06-01 11:06:38 +02:00
  48c16b8bcb
• Add goal extension idle continuation (#25060)

  ## Why
  
  The goal extension needs a way to resume an active goal after the thread
  becomes idle, but the old core goal runtime should not be refactored as
  part of this step. The missing piece is a small core-owned turn-start
  primitive: let an extension ask for a normal model turn only when the
  thread is idle, and otherwise fail without injecting into whatever is
  currently active.
  
  ## What Changed
  
  - Adds `CodexThread::try_start_turn_if_idle(...)` as the narrow
  extension-facing primitive for synthetic idle work.
  - Implements the session side so it refuses to start when:
    - the provided input is empty,
    - the session is in plan mode,
    - a turn is already active, or
    - trigger-turn mailbox work is pending.
  - Gives trigger-turn mailbox work priority if it appears while the idle
  turn is being prepared.
  - Wires `GoalExtension::on_thread_idle` to read the active persisted
  goal and submit the continuation prompt through this idle-only
  primitive.
  - Keeps the legacy core goal continuation implementation in place
  instead of folding it into this PR.
  
  ## Behavior
  
  This is intentionally best-effort. If `try_start_turn_if_idle` observes
  that the thread is not idle, or that higher-priority mailbox work should
  run first, it returns the input to the caller. The goal extension drops
  that continuation prompt and waits for a future idle opportunity instead
  of injecting stale synthetic goal text into an active turn.
  
  ## Validation
  
  - `just test -p codex-core
  try_start_turn_if_idle_rejects_active_turn_without_injecting`
  - `just test -p codex-goal-extension`

  jif-oai · 2026-06-01 10:42:01 +02:00
  f1b1b64005
• Set multi-agent v2 dogfood defaults (#25266)

  ## Summary
  - default multi-agent v2 to direct-model-only tools so code mode does
  not wrap subagent tools
  - add default root/subagent team prompts aligned with dogfood training
  assumptions
  - tighten spawn-agent model override wording to prefer the inherited
  model by default
  
  ## Tests
  - just fmt
  - just test -p codex-core
  spawn_agent_description_lists_visible_models_and_reasoning_efforts
  - just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root
  - just test -p codex-rollout-trace
  - just fix -p codex-core
  - just fix -p codex-rollout-trace
  
  Note: a broad just test -p codex-core run was attempted locally, but
  this sandbox produced unrelated environment failures around
  sandbox-exec, missing test_stdio_server, and realtime timeouts.

  jif-oai · 2026-06-01 10:24:46 +02:00
  8d49394feb