842 Commits

• Rename multi-agent v2 close_agent to interrupt_agent (#26994)

  ## Why
  
  `close_agent` is the wrong model-facing name for the v2 operation after
  the residency changes. V2 agents remain reusable by task name, and
  residency/unloading owns capacity management; the exposed tool should
  describe the action it actually performs: interrupt the target agent's
  current turn without making the agent unavailable for future messages or
  follow-up tasks.
  
  ## What changed
  
  - Rename the multi-agent v2 tool from `close_agent` to
  `interrupt_agent`.
  - Keep the v1 `close_agent` surface unchanged.
  - Update the v2 handler to send `Op::Interrupt`, keep interrupted agents
  registered, and reject root/self targets with interrupt-specific errors.
  - Route interrupt delivery through the existing dead-thread cleanup path
  so stale resident entries do not keep consuming capacity.
  - Update tool planning and handler tests for the new v2 surface and
  semantics.
  
  ## Verification
  
  Added focused coverage in:
  
  - `core/src/tools/spec_plan_tests.rs`
  - `core/src/tools/handlers/multi_agents_tests.rs`

  jif · 2026-06-08 14:46:35 +02:00
  8d415050fc
• fix: preserve approval sandbox decisions in unified exec (#24981)

  ## Why
  
  This PR fixes approval sandbox semantics in the unified-exec path. The
  zsh-fork runtime exposed the bug because the shell can do meaningful
  work before any intercepted child `execv(2)` exists: redirections,
  builtins, globbing, and pipeline setup all happen in the launch process.
  If the model requested `sandbox_permissions=require_escalated`, or an
  exec-policy `allow` rule explicitly bypassed the sandbox, that approved
  sandbox decision needs to be preserved for the launch path and for
  intercepted execs that use the same approval machinery.
  
  The behavior is not only about zsh fork. The production changes are in
  shared approval/escalation code, so they also affect non-zsh-fork
  intercepted exec paths that go through the same sandbox decision logic.
  The narrow intent is to preserve the approval decision while still
  keeping denied-read profiles and bounded additional-permission requests
  sandboxed.
  
  ## Production Changes
  
  - `codex-rs/core/src/tools/runtimes/unified_exec.rs`: derives a
  `launch_sandbox_permissions` value from the requested sandbox
  permissions and the runtime filesystem policy, then uses that value for
  managed-network/env setup and launch sandbox selection. This keeps full
  approval or policy-bypass decisions visible to the first unified-exec
  attempt, while still preventing a full sandbox override from discarding
  denied-read restrictions. Direct unified exec keeps the same decision
  surface; the important difference is that zsh-fork launch setup no
  longer accidentally loses the approved parent sandbox decision.
  
  - `codex-rs/core/src/tools/runtimes/shell/unix_escalation.rs`: makes
  intercepted-exec escalation selection explicit for the three sandbox
  permission modes. `UseDefault` only escalates when an exec-policy
  decision allows sandbox bypass, `RequireEscalated` escalates when
  unsandboxed execution is allowed, and `WithAdditionalPermissions`
  escalates through the bounded additional-permissions path instead of
  being treated as a full unsandboxed override. Unsandboxed intercepted
  execs now also rebuild the environment as `RequireEscalated`, which
  strips managed-network proxy variables consistently with other
  unsandboxed execution.
  
  ## Test Coverage
  
  Most of the PR is tests. The new coverage verifies:
  
  - unified exec preserves parent approval and exec-policy sandbox
  decisions for zsh-fork launch selection;
  - bounded `with_additional_permissions` remains sandboxed and
  permission-profile based;
  - denied-read profiles are not weakened by parent approval;
  - explicit prompt rules still prompt for intercepted execs after the
  parent command is approved;
  - unsandboxed intercepted execs strip managed-network env vars.
  
  No documentation update is needed; this is an internal approval/sandbox
  correctness fix.
  
  
  
  
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/24981).
  * #24982
  * __->__ #24981

  Michael Bolin · 2026-06-07 11:33:16 -07:00
  e6c470957d
• [codex] Use standalone tools for Responses Lite (#26490)

  ## Summary
  
  Responses Lite does not execute hosted Responses tools, so models using
  it must route web search and image generation through Codex-owned
  executors & standalone Response's API endpoints.
  
  This PR is stacked on #26487.
  
  ## Validation
  
  - `cargo test -p codex-core responses_lite_ --lib`
  - `cargo test -p codex-core
  standalone_executors_remain_hidden_without_flags_or_responses_lite
  --lib`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates --lib`
  - `cargo test -p codex-web-search-extension -p
  codex-image-generation-extension`
  - `cargo test -p codex-app-server --test all standalone_`
  - `cargo fmt --all -- --check`

  rka-oai · 2026-06-06 00:23:40 +00:00
  ffe90cb5c3
• [2 of 2] Finish moving goal runtime to extension (#26548)

  ## Stack
  
  1. [#26547](https://github.com/openai/codex/pull/26547) - [1 of 2] Align
  goal extension with core behavior
  2. [#26548](https://github.com/openai/codex/pull/26548) - [2 of 2] Move
  goal runtime to extension
  
  ## Why
  
  This PR completes the switch of the goal behavior to the
  extension-backed runtime and removes the old core goal implementation.
  
  ## What Changed
  
  - Installs the goal extension for app-server `ThreadManager` sessions.
  - Routes app-server thread goal `get`, `set`, and `clear` through
  `GoalService`.
  - Uses thread-idle lifecycle emission after goal resume and snapshot
  ordering so the extension can decide whether to continue the goal.
  - Forwards extension goal updates through a FIFO async app-server
  notification path so backpressure does not drop them or reorder updates.
  - Keeps review turns from enabling goal runtime behavior.
  - Plans extension tools before dynamic tools so built-in goal tool names
  keep their old precedence when goals are enabled.
  - Removes the old core goal runtime, core goal tool handlers, and core
  goal tool specs.
  - Updates tests that were coupled to the core-owned goal runtime while
  leaving the legacy `<goal_context>` compatibility path in core for old
  threads.
  - Removes the stale cargo-shear ignore now that `codex-goal-extension`
  is used by the workspace.
  - Keeps realtime event matching exhaustive after removing the old
  goal-specific realtime text path.
  
  
  ## Validation
  
  - Ran manual `/goal` runs in TUI. Validated time accounting matched
  wall-clock time and goal lifecycle state transitions.

  Eric Traut · 2026-06-05 14:17:30 -07:00
  479a14cf59
• [codex] Respect Windows sandbox backend in exec policy (#26307)

  ## Why
  
  Windows managed filesystem permissions can now be backed by a real
  Windows sandbox. `exec-policy` was still treating the managed read-only
  policy shape as if there were never a sandbox backend, so benign
  unmatched commands such as PowerShell directory listings could be
  rejected with `blocked by policy` even when `windows.sandbox` was
  enabled.
  
  The inverse case still needs to stay conservative: when the Windows
  sandbox backend is disabled, managed filesystem restrictions are only
  configuration intent, not an enforced filesystem boundary. That applies
  to writable-root restricted profiles too, not just read-only profiles.
  
  ## What Changed
  
  - Thread the effective `WindowsSandboxLevel` into exec-policy approval
  decisions for shell, unified exec, and intercepted shell exec paths.
  - Treat managed restricted filesystem profiles as lacking sandbox
  protection only on Windows when `WindowsSandboxLevel::Disabled`.
  - Exclude full-disk-write profiles from that no-backend path because
  they do not rely on filesystem sandbox enforcement.
  - Remove the cwd-sensitive read-only heuristic and the now-stale cwd
  plumbing from exec-policy approval contexts.
  - Add Windows coverage for both enabled-sandbox and disabled-backend
  behavior, including a writable-root managed profile.
  
  ## Validation
  
  - Added/updated `exec_policy` coverage for managed filesystem
  restrictions, full-disk-write exclusion, enabled Windows sandbox
  behavior, and disabled-backend read-only/writable-root behavior.
  - `just test -p codex-core exec_policy` — 100 passed, 10 leaky
  - Empirical local `codex exec` probe with `--sandbox read-only -c
  'windows.sandbox="unelevated"'`: PowerShell directory listing completed
  successfully.
  - Disabled-backend control with Windows sandbox cleared: the same
  command was rejected with `blocked by policy`.

  iceweasel-oai · 2026-06-05 11:20:52 -07:00
  82b15b65e2
• Make turn diff tracker multi-env aware (#26433)

  ## Why
  
  Turn diffs were tracked as one flat set of absolute paths. In
  multi-environment turns, local and remote environments can report the
  same path while representing different filesystems, so a single path key
  can collapse distinct changes or attribute them to the wrong
  environment.
  
  The environment name is **NOT** included in the generated unified diff.
  This can come later.

  pakrym-oai · 2026-06-05 17:31:22 +00:00
  86a1ddd028
• feat: reload v2 agents on delivery (#26623)

  ## Summary
  
  This is the first small step toward making multi-agent v2 agents durable
  logical agents whose `ThreadManager` residency is only an implementation
  detail.
  
  This PR adds a narrow v2 reload-on-delivery hook:
  
  - If a known v2 agent target is already loaded, delivery is unchanged.
  - If the target is still registered but missing from `ThreadManager`,
  delivery reloads that exact v2 thread from durable rollout history
  before submitting the message.
  - If the target is unknown, closed, missing from storage, or not a v2
  thread, delivery still fails as not found.
  
  The reload is wired only into existing-agent delivery paths: v2
  `send_message` / `followup_task`, and legacy `send_input` when its
  target is a known v2 agent.
  
  ## Stack
  
  1. **Reload on delivery**: load known unloaded v2 agents before
  `followup_task`, `send_message`, or `send_input` delivery. This PR.
  2. **Residency LRU**: unload idle resident v2 agents from
  `ThreadManager` without making them closed or unreachable.
  3. **Execution concurrency**: count active non-root turns, not logical
  agents or resident idle threads.
  4. **Close semantics**: make v2 close interrupt-only and leave durable
  agent identity intact.
  5. **Resume cleanup**: remove user-facing v2 resume semantics;
  addressing an unloaded durable agent reloads it implicitly.
  
  ## Validation
  
  - Ran `just fmt`.
  - Left broader tests and clippy to CI.

  jif · 2026-06-05 18:18:29 +02:00
  d5e4f01af4
• [codex] Keep v1 spawn metadata visible (#26599)

  ## Summary
  - keep the legacy v1 `spawn_agent` role and model selectors visible
  - add regression coverage for the default v1 tool plan
  
  ## Why
  `hide_spawn_agent_metadata` is a multi-agent v2 setting, but the v1
  planning branch also consumed it. After the default changed to `true`,
  v1 stopped advertising `agent_type`, `model`, `reasoning_effort`, and
  `service_tier`, preventing configured agents from being selected.
  
  This keeps the hidden-metadata default for v2 while opting v1 out of
  that behavior.
  
  Fixes #26363.
  
  ## Validation
  Not run locally, per request; CI will validate the change.

  jif · 2026-06-05 14:52:51 +02:00
  66232220e2
• nit: doc (#26566)

  Matching CBv9

  jif · 2026-06-05 11:10:32 +02:00
  6dc28ba6e0
• Encrypt multi-agent v2 message payloads (#26210)

  ## Why
  
  Multi-agent v2 currently routes agent instructions through normal tool
  arguments and inter-agent context. That means the parent model can emit
  plaintext task text, Codex can persist it in history/rollouts, and the
  recipient can receive it as ordinary assistant-message JSON.
  
  This changes the v2 path so agent instructions stay encrypted between
  model calls: Responses encrypts the `message` argument returned by the
  model, Codex forwards only that ciphertext, and Responses decrypts it
  internally for the recipient model.
  
  ## What changed
  
  - Mark the v2 `message` parameter as encrypted for `spawn_agent`,
  `send_message`, and `followup_task`.
  - Treat multi-agent v2 tool `message` values as ciphertext
  unconditionally.
  - Store v2 inter-agent task text in
  `InterAgentCommunication.encrypted_content` with empty plaintext
  `content`.
  - Convert encrypted inter-agent communications into the Responses
  `agent_message` input item before sending the child request.
  - Preserve `agent_message` items across history, rollout, compaction,
  telemetry, and app-server schema paths.
  - Leave multi-agent v1 unchanged.
  
  ## Message shape
  
  The model still calls the v2 tools with a `message` argument, but that
  value is now ciphertext:
  
  ```json
  {
    "name": "spawn_agent",
    "arguments": {
      "task_name": "worker",
      "message": "<ciphertext>"
    }
  }
  ```
  
  Codex stores the task as encrypted inter-agent communication:
  
  ```json
  {
    "author": "/root",
    "recipient": "/root/worker",
    "content": "",
    "encrypted_content": "<ciphertext>",
    "trigger_turn": true
  }
  ```
  
  When Codex builds the recipient request, it forwards the ciphertext
  using the new Responses input item:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root",
    "recipient": "/root/worker",
    "content": [
      {
        "type": "encrypted_content",
        "encrypted_content": "<ciphertext>"
      }
    ]
  }
  ```
  
  Responses decrypts that item internally for the recipient model.
  
  ## Context impact
  
  - Parent context no longer carries plaintext v2 agent task instructions
  from these tool arguments.
  - Codex rollout/history stores ciphertext for v2 agent instructions.
  - Recipient requests receive an `agent_message` item instead of
  assistant commentary JSON for encrypted task delivery.
  - Plaintext completion/status notifications are still plaintext because
  they are Codex-generated status messages, not encrypted model tool
  arguments.
  
  ## Validation
  
  - `just test -p codex-tools`
  - `just test -p codex-protocol`
  - `just test -p codex-rollout`
  - `just test -p codex-rollout-trace`
  - `just test -p codex-otel`
  - `just write-app-server-schema`

  jif · 2026-06-05 10:25:57 +02:00
  5f4d06ef18
• [codex] Add environment shell info (#26480)

  ## Why
  
  Shell detection needs to be available through the `Environment`
  abstraction so callers can ask the selected local or remote environment
  for shell metadata without adding a separate HTTP endpoint or parallel
  info-source path. This keeps shell metadata shaped like the existing
  environment-owned filesystem capability and lets remote environments
  answer through exec-server JSON-RPC.
  
  ## What changed
  
  - Added `environment/info` to the exec-server protocol/client/server and
  exposed `Environment::info()`.
  - Added local and remote environment info providers on `Environment`,
  following the existing capability-provider pattern used for filesystem
  access.
  - Moved the shared shell detection logic into `codex-shell-command` and
  kept core shell APIs as wrappers around that implementation.
  - Returned shell metadata as `EnvironmentInfo { shell: ShellInfo }`
  using the existing shell detection path.
  - Added a remote environment test that calls `Environment::info()`
  through an exec-server-backed environment.
  
  ## Validation
  
  - `git diff --check`
  - `just test -p codex-shell-command`
  - `just test -p codex-core -E 'test(/shell::tests::/)'`\n- `just test -p
  codex-exec-server environment`

  pakrym-oai · 2026-06-04 22:36:25 -07:00
  6a6a5f925e
• core: derive exec policy filesystem policy from profile (#26499)

  ## Why
  
  `PermissionProfile` already owns the runtime filesystem sandbox policy
  through `file_system_sandbox_policy()`. Keeping a separate
  `FileSystemSandboxPolicy` on exec-policy fallback contexts made it
  possible for callers and tests to construct split states that the
  production permission model should not rely on.
  
  ## What changed
  
  - Removed `file_system_sandbox_policy` from `UnmatchedCommandContext`,
  `ExecApprovalRequest`, and the intercepted Unix exec-policy context.
  - Derived filesystem sandbox policy inside unmatched-command decision
  logic from `PermissionProfile::file_system_sandbox_policy()`.
  - Simplified shell/unified-exec callers and tests that were only
  plumbing the duplicate policy through.
  
  ## Testing
  
  Local tests not run per request; relying on remote CI.

  Michael Bolin · 2026-06-04 21:48:45 -07:00
  a2f5874b7a
• [codex] Emit sandbox outcome telemetry event (#25955)

  ## Summary
  
  Adds a dedicated `codex.sandbox_outcome` telemetry event so we can query
  sandbox edge outcomes without threading sandbox metadata through
  tool-result output types.
  
  This is meant to make sandbox failures and approved escalation retries
  visible in OTEL while keeping the existing `codex.tool_result` event
  shape focused on tool completion data.
  
  ## What changed
  
  - Adds `SessionTelemetry::sandbox_outcome(...)`, which emits
  `codex.sandbox_outcome` as both a log and trace event.
  - Records the tool name, call id, sandbox outcome, initial attempt
  duration, and escalated attempt duration when a retry runs.
  - Emits `denied` when the sandbox blocks execution and no retry is run.
  - Emits `timed_out` and `signal` when those sandbox errors surface from
  tool execution.
  - Emits `escalated` when the initial sandboxed attempt fails and the
  approved unsandboxed retry succeeds.
  - Adds OTEL coverage for the new event payload, including timing fields.
  
  ## Validation
  
  - `RUST_MIN_STACK=8388608 just test -p codex-core
  sandbox_outcome_event_records_outcome
  handle_sandbox_error_user_approves_retry_records_tool_decision`
  - `just test -p codex-otel
  otel_export_routing_policy_routes_tool_result_log_and_trace_events
  runtime_metrics_summary_collects_tool_api_and_streaming_metrics`
  - `just fix -p codex-core`
  - `just fix -p codex-otel`

  rreichel3-oai · 2026-06-04 20:58:14 -04:00
  ecae412740
• [codex] Support model-defined reasoning efforts (#26444)

  ## Summary
  - accept non-empty model-defined reasoning effort values while
  preserving built-in effort behavior
  - propagate the non-Copy effort type through core, app-server, TUI,
  telemetry, and persistence call sites
  - preserve string wire encoding and expose an open-string schema for
  clients
  - update model selection and shortcut behavior for model-advertised
  effort values
  
  ## Root cause
  `ReasoningEffort` gained a string-backed custom variant, so it could no
  longer implement `Copy` or rely on derived closed-enum serialization.
  Existing consumers still moved effort values from shared references and
  assumed a fixed built-in value set.
  
  ## Validation
  - `just fmt`
  - Local tests and compilation were not run per request; relying on CI.

  Ahmed Ibrahim · 2026-06-04 13:36:24 -07:00
  8ac304c299
• Route AGENTS.md loading through environment filesystems (#26205)

  ## Why
  
  Workspace-specific `AGENTS.md` loading needs to use the selected
  environment filesystem so remote workspaces and child agents read
  instructions from their actual environment instead of the host
  filesystem. The app-server should report the same instruction sources
  the initialized thread actually loaded, rather than independently
  rescanning configuration and filesystem state.
  
  ## What changed
  
  - Introduce `LoadedAgentsMd` to retain ordered user, project, and
  internal instructions with their provenance.
  - Load and canonicalize workspace `AGENTS.md` paths through the primary
  `EnvironmentManager` environment, then render the loaded instructions
  when constructing turn context.
  - Expose cached loaded instruction sources from initialized threads and
  use them for app-server start, resume, and fork responses.
  - Preserve global `CODEX_HOME` loading and separator behavior while
  excluding empty project files that did not supply model-visible
  instructions.
  - Add integration coverage for CLI injection, selected-environment
  provenance and rendering, empty environment selection, and cached
  sources on loaded-thread resume.
  
  ## Validation
  
  - `just test -p codex-core agents_md`
  - `just test -p codex-core
  selected_environment_sources_match_model_visible_instructions`
  - `just test -p codex-exec agents_md`
  - `just test -p codex-app-server instruction_sources`
  - `just test -p codex-app-server --status-level fail`

  Adam Perry @ OpenAI · 2026-06-04 12:43:07 -07:00
  e64b469bbc
• core: allow excluding tool namespaces from code mode (#26320)

  ## Why
  
  Research and training setups need to control which tool namespaces
  appear inside code mode's nested `tools` surface without disabling those
  tools entirely. This makes it possible to train against a deliberately
  reduced nested-tool setup while preserving the normal direct and
  deferred tool paths.
  
  ## What
  
  - Extend `features.code_mode` to accept structured configuration while
  preserving the existing boolean syntax.
  - Add an exact `excluded_tool_namespaces` list under
  `[features.code_mode]`:
  
    ```toml
    [features.code_mode]
    enabled = true
    excluded_tool_namespaces = ["mcp__codex_apps", "multi_agent_v1"]
    ```
  
  - Filter matching canonical `ToolName` namespaces when constructing code
  mode's nested router and code-mode-specific direct tool descriptions.
  - Keep excluded tools registered, directly exposed in mixed code mode,
  and discoverable through top-level `tool_search` when otherwise
  eligible.
  - Derive deferred nested-tool guidance after namespace filtering so the
  `exec` description does not advertise excluded-only deferred tools.
  - Preserve the boolean/table representation when materializing config
  locks and update the generated config schema.
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-config`
  - `just test -p codex-core load_config_resolves_code_mode_config`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just test -p codex-core
  excluded_deferred_namespaces_do_not_enable_nested_tool_guidance`
  - `just test -p codex-core
  code_mode_excludes_configured_nested_tool_namespaces`
  - `cargo check -p codex-thread-manager-sample`

  sayan-oai · 2026-06-04 18:40:18 +00:00
  8b1238856b
• cli: add package path from install context (#26189)

  ## Why
  
  Codex package installs include helper binaries in `codex-path`, such as
  the bundled `rg`. Package-layout launches should add that directory
  before user commands run, but standalone launches were missing it while
  npm launches only worked because `codex.js` had its own legacy `PATH`
  rewrite. That made npm and standalone package behavior diverge.
  
  Shell snapshot restoration can also reset `PATH` after runtime setup.
  Any package-owned `PATH` prepend has to be recorded as an explicit
  runtime override so shells, unified exec, and user-shell commands keep
  access to `codex-path` after a snapshot is sourced.
  
  ## Repro
  
  Before this change, a curl-installed package could contain `rg` under
  `codex-path` but still fail to put it on `PATH`:
  
  ```shell
  mkdir /tmp/test-codex-curl
  curl -fsSL https://chatgpt.com/codex/install.sh \
    | CODEX_HOME=/tmp/test-codex-curl CODEX_NON_INTERACTIVE=1 sh
  /tmp/test-codex-curl/packages/standalone/current/bin/codex exec \
    --skip-git-repo-check 'print `which -a rg`'
  find /tmp/test-codex-curl -name rg
  ```
  
  The `which -a rg` output omitted the packaged helper even though `find`
  showed it under
  `/tmp/test-codex-curl/packages/standalone/releases/.../codex-path/rg`.
  
  The npm install path behaved differently only because
  `codex-cli/bin/codex.js` had legacy `PATH` rewriting:
  
  ```shell
  mkdir /tmp/test-codex-npm
  cd /tmp/test-codex-npm
  npm install @openai/codex
  ./node_modules/.bin/codex exec --skip-git-repo-check 'print `which -a rg`'
  ```
  
  That printed the npm package's `vendor/<target>/codex-path/rg` first.
  This PR moves that behavior into Rust-side package launch setup so
  curl/standalone and npm/bun launches agree without JS rewriting `PATH`.
  
  ## What Changed
  
  - `codex-rs/arg0` now uses
  `InstallContext::current().package_layout.path_dir` to prepend the
  package helper directory before any threads are created.
  - Package helper `PATH` setup is independent from the temporary arg0
  alias setup, so `codex-path` is still added even if CODEX_HOME tempdir,
  lock, or symlink setup fails.
  - `codex-rs/install-context` detects the canonical package layout we
  ship: `bin/`, `codex-resources/`, and `codex-path/` next to
  `codex-package.json`.
  - Shell, local unified exec, and user-shell runtimes now record package
  `codex-path` prepends in `explicit_env_overrides`, matching the existing
  zsh-fork behavior so shell snapshots cannot restore over the package
  helper path.
  - Remote unified exec requests do not receive the local app-server
  package path overlay.
  - `codex-cli/bin/codex.js` no longer computes or overrides `PATH`; it
  only locates the native binary in the canonical package layout and
  passes npm/bun management metadata.
  - Added regression tests for `PATH` ordering, package layout detection,
  and shell snapshot preservation of package path prepends.
  
  ## Verification
  
  - `node --check codex-cli/bin/codex.js`
  - `just test -p codex-install-context -p codex-arg0`
  - `just test -p codex-core
  user_shell_snapshot_preserves_package_path_prepend`
  - `just test -p codex-core tools::runtimes::tests`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just fix -p codex-install-context -p codex-arg0 -p codex-core`

  Michael Bolin · 2026-06-03 19:08:19 -07:00
  6bcccb0ee6
• feat: catalog multi-agent v2 config (#26254)

  ## Why
  
  Model metadata can now select multi-agent v2 even when a user has not
  enabled `features.multi_agent_v2` in their config. Some existing configs
  still set the legacy `agents.max_threads` knob for v1 multi-agent
  behavior, so treating every v2 runtime as incompatible with
  `agents.max_threads` would break users whose only v2 signal came from
  the model catalog.
  
  The incompatible configuration is specifically enabling
  `features.multi_agent_v2` while also setting `agents.max_threads`.
  Catalog-forced v2 should use the v2 concurrency setting and ignore the
  legacy v1 cap instead of rejecting the config.
  
  ## What changed
  
  - Split config validation from runtime concurrency calculation:
  `effective_agent_max_threads` now just returns the effective cap for the
  resolved multi-agent runtime.
  - Added explicit validation for `features.multi_agent_v2` +
  `agents.max_threads` at session startup.
  - Preserved catalog-selected v2 behavior when `features.multi_agent_v2`
  is disabled, so existing configs with `agents.max_threads` keep
  starting.
  - Updated model-runtime selector coverage so a catalog v2 model still
  exposes v2 tools even when `agents.max_threads` is set and the config
  flag is disabled.
  
  ## Validation
  
  - `cargo check -p codex-core --lib`
  - `just test -p codex-core --lib -E
  "test(multi_agent_v2_feature_rejects_agents_max_threads) |
  test(catalog_v2_allows_agents_max_threads_when_feature_disabled)"`

  jif · 2026-06-04 00:24:40 +02:00
  11bceb8f8b
• 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
• 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
• feat: default hide_spawn_agent_metadata to true (#26114)

  For MAv2 CBv9

  jif · 2026-06-03 12:22:23 +02:00
  668703c23f
• [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
• 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
• 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
• fix: main oops (#25840)

  Fix main, comment is self-explainatory

  jif-oai · 2026-06-02 14:48:04 +02:00
  06e9a33d09
• 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
• [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
• 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] 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
• 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
• store and expose parent_thread_id on Threads (#25113)

  ## Why
  
  This PR
  https://github.com/openai/codex/pull/24161#discussion_r3325692763
  revealed a subagent data modeling issue, where we overloaded
  `forked_from_id` to also mean `parent_thread_id`. That's incorrect since
  guardian and review subagents can be a subagent and NOT fork the main
  thread's history.
  
  The solution here is to explicitly store a new `parent_thread_id` on
  `SessionMeta`, alongside `forked_from_id` which already exists. While
  we're at it, also expose it in the app-server protocol on the `Thread`
  object.
  
  A thread->subagent relationship and a fork of thread history are
  orthogonal concepts.
  
  ## What Changed
  
  - Added top-level `parent_thread_id` persistence on `SessionMeta` and
  runtime/session plumbing through `SessionConfiguredEvent`,
  `CodexSpawnArgs`, `SessionConfiguration`, `ThreadConfigSnapshot`,
  `TurnContext`, and `ModelClient`.
  - Made turn metadata, request headers, analytics, and subagent-start
  events read the separate runtime/top-level parent field instead of
  deriving general parent lineage from `SessionSource` or
  `forked_from_thread_id`.
  - Passed parent lineage separately at delegated subagent, review,
  guardian, agent-job, and multi-agent spawn construction sites;
  copied-history fork lineage remains derived only from `InitialHistory`.
  - Persisted and exposed parent lineage through rollout/thread-store
  projections and app-server v2 `Thread.parentThreadId`.
  - Updated app-server README text and regenerated app-server schema
  fixtures for the additive `parentThreadId` response field.

  Owen Lin · 2026-06-01 04:33:20 +00:00
  cf0911076f
• Rename multi-agent v2 assignment tool (#25267)

  ## Summary
  - rename the multi-agent v2 follow-up task tool surface to assign_task
  - update core tests and spec-plan expectations
  - keep rollout-trace classification backward-compatible with legacy
  followup_task
  
  ## Tests
  - just fmt
  - just test -p codex-core
  multi_agents_spec::tests::assign_task_tool_requires_message_and_has_no_output_schema
  - 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-05-30 14:13:05 +02:00
  8acaec73b6
• feat(config) experimental_request_user_input toggle (#24541)

  ## Summary
  Experimental flag to allow toggling `request_user_input`:
  
  ```
  tools.experimental_request_user_input = false
  ```
  
  ## Testing
  - [x] Added unit tests

  Dylan Hurd · 2026-05-29 21:35:53 -07:00
  e0435afb72
• Filter plugin install suggestions by installed apps (#24996)

  ## Summary
  
  - Keep the original `TOOL_SUGGEST_DISCOVERABLE_PLUGIN_ALLOWLIST` as a
  fallback seed list, so users with no installed plugins still get initial
  install suggestions.
  - Allow additional install suggestions from trusted marketplaces:
  `openai-curated` and `openai-bundled`.
  - Require non-fallback, non-configured marketplace candidates to share
  `.app.json` connector IDs with already installed plugins.
  - Preserve explicit configured plugin discoverables as an override,
  while still omitting installed, disabled, and `NOT_AVAILABLE` plugins.
  
  ## Context
  
  `list_available_plugins_to_install` controls which plugins the model can
  trigger via `request_plugin_install`. We want a small starter set for
  empty/new users, but we also want installed workflow plugins to unlock
  relevant source plugins without maintaining every source plugin ID by
  hand.
  
  This keeps the legacy plugin ID allowlist only as the starter fallback.
  For everything else, the trusted marketplace is the candidate boundary,
  and installed app connector overlap is the relevance filter. For
  example, an installed Sales plugin can make HubSpot and Granola
  suggestible when those source plugins are in `openai-curated` and share
  Sales app connector IDs, while an unrelated test-source plugin with an
  app connector not declared by Sales stays hidden.
  
  ## Test Coverage
  
  - Empty/no-installed-plugin case: returns the fallback seed plugins from
  the original allowlist.
  - Installed-app expansion: returns non-fallback marketplace plugins only
  when their app connector IDs overlap with an installed plugin.
  - Sales workflow case: installed Sales declares HubSpot and Granola
  apps, so `hubspot@openai-curated` and `granola@openai-curated` are
  returned.
  - Sales negative case: `test-source@openai-curated` has an app connector
  not declared by Sales, so it is not returned.
  - Existing guardrails: installed plugins, disabled suggestions, and
  `NOT_AVAILABLE` plugins remain omitted; explicit configured
  discoverables still work as an override.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core plugins::discoverable::tests`
  - `just test -p codex-core` was attempted earlier, but current `main` /
  local env failed with unrelated existing failures around missing
  `test_stdio_server`, CLI/code-mode MCP tool setup, and
  unified_exec/shell snapshot flakes/timeouts. The touched discoverable
  tests pass.

  Noah MacCallum · 2026-05-29 15:32:04 -07:00
  8e5f561697
• [codex] Require model for standalone web search (#25131)

  ## Why
  
  The standalone `/v1/alpha/search` request now requires a `model`, but
  the `web.run` extension currently omits it.
  
  Adds `model` to extension `ToolCall` invocation.
  
  Follow-up to #23823.
  
  ## What changed
  
  - Make `SearchRequest.model` required.
  - Expose the effective per-turn model on extension tool calls and pass
  it in standalone web-search requests.
  - Assert the model is forwarded in the app-server round-trip test.
  
  ## Testing
  
  - `just test -p codex-api -p codex-tools -p codex-web-search-extension
  -p codex-memories-extension -p codex-goal-extension`
  - `just test -p codex-core -E
  'test(passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call)'`
  - `just test -p codex-app-server -E
  'test(standalone_web_search_round_trips_encrypted_output)'`

  sayan-oai · 2026-05-29 12:03:04 -07:00
  1f93706e99
• code-mode: introduce durable session interface (#24180)

  ## Summary
  
  Introduce a `CodeModeSession` interface for executing and managing
  code-mode cells.
  
  This moves cell lifecycle, callback delegation, termination, and
  shutdown behind a session abstraction, while continuing to use the
  existing in-process implementation, and the ability to implement an
  external process one behind this interface.
  
  A Codex session owns one `CodeModeSession`, which in turn owns its
  running cells and stored code-mode state. Each cell is represented to
  the caller as a `StartedCell`, exposing its cell ID and initial
  response.
  
  It also introduces a `CodeModeSessionDelegate` callback interface. A
  session uses the delegate to invoke nested host tools and emit
  notifications while a cell is running, allowing the runtime to
  communicate with its owning Codex session without depending directly on
  core turn handling.
  
  <img width="2121" height="1001" alt="image"
  src="https://github.com/user-attachments/assets/c349a819-2a59-485c-bda4-2caf68ac4c31"
  />

  Channing Conger · 2026-05-29 11:42:52 -07:00
  c9dc0f6338
• Route extension image generation through the native image completion pipeline (#24972)

  ## Why
  
  The standalone `image_gen.imagegen` extension should behave like native
  image generation for artifact persistence and UI completion, while
  returning its save-location guidance as part of the tool result instead
  of injecting a developer message.
  
  ## What Changed
  
  - Added an image-generation completion hook for extension tools so core
  can persist generated images and emit the existing `ImageGeneration`
  lifecycle events.
  - Reused core image artifact persistence for extension output and
  removed extension-local save-path/file-writing logic.
  - Split shared image persistence from built-in finalization so native
  image generation keeps its existing developer-message instruction
  behavior.
  - Returned the generated image save-location instruction through the
  extension `FunctionCallOutput`, alongside the generated image input for
  model follow-up.
  - Preserved the existing image-generation event shape for current UI and
  replay compatibility.
  - Avoided cloning the full generated-image base64 payload when emitting
  the in-progress image item.
  - Removed dependencies no longer needed after moving persistence out of
  the extension crate.
  
  ## Fast Follow
  - Adjust the existing Extension API and add a general `TurnItem`
  finalization path for re-usability of code
  
  ## Validation
  
  - Ran `just fmt`.
  - Ran `just bazel-lock-update`.
  - Ran `just bazel-lock-check`.
  - Ran `just test -p codex-tools -p codex-extension-api -p
  codex-image-generation-extension`.
  - Ran `just test -p codex-core
  image_generation_publication_is_finalized_by_core`.
  - Ran `just test -p codex-core
  handle_output_item_done_records_image_save_history_message`.
  - Ran `just fix -p codex-tools -p codex-extension-api -p codex-core -p
  codex-image-generation-extension`.

  Won Park · 2026-05-29 17:33:13 +00:00
  10b0399034
• [codex] Add model tool mode selector (#25031)

  ## Why
  Some models need to select their code-execution behavior through model
  catalog metadata. Models without that metadata must continue to follow
  the existing `CodeMode` and `CodeModeOnly` feature flags, including when
  a newer server sends an enum value this client does not recognize.
  
  ## What changed
  - add optional `ModelInfo.tool_mode` metadata with `direct`,
  `code_mode`, and `code_mode_only`
  - treat omitted and unknown wire values as `None`
  - resolve `None` from the existing feature flags
  - carry the resolved `ToolMode` directly on `TurnContext`, outside
  `Config`
  - use the resolved value for turn creation, model switches, review
  turns, tool planning, and code execution
  
  ## Coverage
  - add protocol coverage for omitted, known, and unknown enum values
  - add focused coverage for flag fallback and explicit metadata
  overriding feature flags
  - add core integration coverage that fetches remote model metadata
  through `/v1/models` and verifies the outbound `/responses` tools for
  explicit `direct` and `code_mode_only` selectors
  
  ## Stack
  - followed by #25032

  Ahmed Ibrahim · 2026-05-29 09:05:05 -07:00
  5577a9e148
• [codex] Improve built-in tool schema docs (#24794)

  ## Summary
  - Clarify default, omission, and bounded behavior across built-in tool
  schemas, including unified exec, classic shell, Code Mode exec/wait,
  multi-agent, agent job, MCP resource, image, goal, plan, tool_search,
  and test-sync fields.
  - Convert update_plan status to an enum and add short field descriptions
  where the schema previously relied on surrounding context.
  - Remove the dedicated permission-approval schema test and keep only
  updates to existing expected-spec tests.
  
  ## Validation
  - Ran `just fmt`.
  - Ran `git diff --check`.
  - Did not run clippy or tests, per request.
  
  Regression has been eval
  [here](https://openai.slack.com/archives/C09GDSP1J9X/p1779905065496949)
  and we proved there are no regressions

  jif-oai · 2026-05-29 13:32:19 +02:00
  1c55bb2702
• fix: preserve deny-read sandboxing for safe commands (#23943)

  ## Why
  
  Permission profiles can mark filesystem entries as unreadable with
  `deny` rules, including glob patterns. Several shell execution paths
  treated known-safe commands or execpolicy `allow` rules as sufficient to
  run outside the filesystem sandbox. That is not valid for read-capable
  commands: for example, `cat` or `ls` may be reasonable to allow
  generally, but dropping the sandbox would also drop deny-read
  constraints such as `**/*.env`.
  
  ## What changed
  
  - Added a shared check that treats active deny-read restrictions as
  incompatible with unsandboxed execution.
  - Kept first-attempt execution sandboxed for explicit escalation and
  execpolicy allow bypasses when deny-read entries are present.
  - Prevented no-sandbox retry after a sandbox denial when the active
  filesystem policy contains deny-read entries.
  - Updated the zsh-fork execve path so prefix-rule `allow` decisions
  continue inside the current sandbox when deny-read restrictions are
  active.
  
  ## Verification
  
  - `cargo test -p codex-core tools::sandboxing::tests`
  - `cargo test -p codex-core
  tools::runtimes::shell::unix_escalation::tests`
  - `cargo test -p codex-core
  shell_command_enforces_glob_deny_read_policy`

  Michael Bolin · 2026-05-28 22:49:37 -07:00
  6e10142199
• windows-sandbox: pass workspace roots to runner (#24108)

  ## Why
  
  #23813 switches the Windows sandbox runner path to `PermissionProfile`,
  but it still left one runtime anchor for resolving symbolic
  `:workspace_roots` entries. That is not enough once a turn has multiple
  effective workspace roots: exact entries and deny globs under
  `:workspace_roots` need to be materialized for every runtime root before
  the command runner chooses token mode or builds ACL plans.
  
  ## What Changed
  
  - Replaces the Windows runner/setup `permission_profile_cwd` plumbing
  with `workspace_roots: Vec<AbsolutePathBuf>`.
  - Resolves Windows-local `PermissionProfile` data with
  `materialize_project_roots_with_workspace_roots(...)` instead of the
  single-cwd helper.
  - Threads `Config::effective_workspace_roots()` through core execution,
  unified exec, TUI setup/read-grant flows, app-server setup, app-server
  `command/exec`, and `debug sandbox` on Windows.
  - Preserves those workspace roots through the zsh-fork escalation
  executor instead of rebuilding them from `sandbox_policy_cwd`.
  - Makes `ExecRequest::new(...)` and the remaining
  `build_exec_request(...)` helper path take
  `windows_sandbox_workspace_roots` explicitly so new call sites cannot
  silently fall back to `vec![cwd]`.
  - Clarifies the `debug sandbox` non-Windows comment: remaining
  cwd-dependent resolution still uses `sandbox_policy_cwd`, while
  `:workspace_roots` entries are already materialized from config roots.
  - Updates elevated runner IPC `SpawnRequest` to send `workspace_roots`
  and bumps the framed IPC protocol version to `3` for the payload shape
  change.
  - Adds Windows-local resolver coverage for expanding exact and glob
  `:workspace_roots` entries across multiple roots, plus core helper
  coverage proving explicit roots are preserved.
  
  ## Verification
  
  - `cargo check -p codex-windows-sandbox -p codex-core -p codex-tui -p
  codex-cli -p codex-app-server`
  - `cargo test -p codex-windows-sandbox`
  - `cargo test -p codex-core windows_sandbox`
  - `cargo test -p codex-core unix_escalation`
  - `cargo test -p codex-app-server windows_sandbox`
  - `cargo test -p codex-tui windows_sandbox`
  - `cargo test -p codex-cli debug_sandbox`
  - `just test -p codex-core unified_exec`
  - `just test -p codex-core
  build_exec_request_preserves_windows_workspace_roots`
  - `env -u CODEX_NETWORK_PROXY_ACTIVE -u
  CODEX_NETWORK_ALLOW_LOCAL_BINDING just test -p codex-app-server --lib
  command_exec`
  - `just test -p codex-windows-sandbox`
  - `just test -p codex-exec sandbox`
  - `just fix -p codex-core -p codex-app-server -p codex-windows-sandbox`
  
  A local macOS cross-check with `cargo check --target
  x86_64-pc-windows-msvc ...` did not reach crate Rust code because native
  dependencies require Windows SDK headers (`windows.h` / `assert.h`) in
  this environment; Windows CI remains the real target validation.
  
  Two local targeted filters compile but do not run assertions on macOS:
  `env -u CODEX_NETWORK_PROXY_ACTIVE -u CODEX_NETWORK_ALLOW_LOCAL_BINDING
  just test -p codex-app-server --lib command_exec_processor` matched zero
  tests, and `just test -p codex-linux-sandbox landlock` matched zero
  tests because the landlock suite is Linux-only.

  Michael Bolin · 2026-05-28 15:26:55 -07:00
  986c60467b
• runtime: prepend zsh fork bin dir to PATH (#23768)

  ## Why
  
  #23756 makes packaged Codex builds include and default to the bundled
  zsh fork. The important reason to put that fork's directory at the front
  of `PATH` is to keep executable-level escalation working after a command
  leaves the original shell and later re-enters zsh through `env`.
  
  The expected chain is:
  
  1. The zsh fork runs the top-level shell command.
  2. That command launches another program, such as `python3`, while
  inheriting the `EXEC_WRAPPER` environment and the escalation socket fd.
  3. That program spawns a shell script whose shebang is `#!/usr/bin/env
  zsh` rather than `#!/bin/zsh`, and it does not close the escalation fd.
  4. `/usr/bin/env` resolves `zsh` through `PATH`, so it must find the
  packaged zsh fork before the system zsh.
  5. Commands inside that nested script are intercepted by the zsh fork
  and can still request escalation from Codex.
  
  If `PATH` resolves `zsh` to the system shell instead, the nested script
  loses zsh-fork exec interception. Commands that should request
  escalation can then run only in the original sandbox, or fail there,
  without Codex ever receiving the approval request.
  
  Shell snapshots make this slightly more subtle: a snapshot can restore
  an older `PATH` after the child shell starts. This PR treats the zsh
  fork `PATH` prepend as an explicit environment override so snapshot
  wrapping preserves it.
  
  ## What Changed
  
  - Added shared zsh-fork runtime helpers that prepend the configured zsh
  executable parent directory to `PATH` without duplicate entries.
  - Applied the zsh fork `PATH` prepend to both zsh-fork `shell_command`
  launches and unified-exec zsh-fork launches before sandbox command
  construction.
  - Kept the shell-command zsh-fork backend API narrow: it derives the
  configured zsh path from session services and rebuilds its sandbox
  environment from `req.env`, rather than accepting a second, competing
  environment map or a separately threaded bin dir.
  - Kept Unix-only zsh-fork `PATH` mutation out of Windows clippy-visible
  mutability.
  - Added coverage for duplicate `PATH` entries, for preserving the zsh
  fork prepend through shell snapshot wrapping, and for the nested
  `python3` -> `#!/usr/bin/env zsh` escalation flow.
  
  ## Testing
  
  - `just fmt`
  - `just fix -p codex-core`
  
  I left final test validation to CI after the latest review-comment
  cleanup. Before that cleanup, `just test -p codex-core zsh_fork` passed
  locally for the zsh-fork-focused tests.

  Michael Bolin · 2026-05-28 14:10:40 -07:00
  bc10e5b390
• Add feature-gated standalone image generation extension (#24723)

  ## Why
  
  Add a standalone image generation path that can be exercised
  independently of hosted Responses image generation, while retaining the
  hosted tool as fallback unless the extension is actually available to
  the model.
  
  ## What changed
  
  - Added the `codex-image-generation-extension` crate with standalone
  generate/edit execution, prior-image selection for edits, model-visible
  image output, and local generated-image persistence.
  - Installed the extension in app-server behind the disabled-by-default
  `imagegenext` feature and backend eligibility checks.
  - Updated core tool planning so eligible `image_gen.imagegen` exposure
  replaces hosted `image_generation`, while unavailable configurations
  retain hosted fallback.
  - Added coverage for extension behavior, edit history reuse, feature
  gating, auth eligibility, and hosted-tool replacement.
  - The extension is installed through app-server only in this PR; other
  execution paths retain hosted image generation because hosted
  replacement occurs only when the standalone executor is actually
  registered and model-visible.
  - The initial extension contract intentionally fixes the image model to
  `gpt-image-2` and uses automatic image parameters.
  - Native generated-image history/card parity and rollout persistence
  cleanup are intentionally deferred follow-up work.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-features`
  - `just test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`
  - `just test -p codex-app-server`
  - `just fix -p codex-image-generation-extension -p codex-features -p
  codex-core -p codex-app-server`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  Won Park · 2026-05-28 11:44:55 -07:00
  ecb41fcb64