824 Commits

• 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
• Fix extension turn item emitter test event ordering (#24936)

  ## Why
  
  PR #24813 added extension `TurnItemEmitter` coverage and introduced a
  test that records a conversation history item before asserting
  extension-emitted turn item events.
  
  `record_conversation_items()` also emits a `RawResponseItem` event to
  observers. The test was reading from the same event receiver and
  expected the next event to be `ItemStarted`, so the test failed reliably
  once the setup history item was present.
  
  ## What Changed
  
  Update
  `passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call` to
  consume and assert the expected setup `RawResponseItem` before checking
  the extension `ItemStarted`, `WebSearchBegin`, `ItemCompleted`, and
  `WebSearchEnd` events.
  
  This is test-only and does not change extension runtime behavior.
  
  ## Verification
  
  - `cargo nextest run --no-fail-fast -p codex-core
  tools::handlers::extension_tools::tests::passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call`

  Michael Bolin · 2026-05-28 09:59:34 -07:00
  2264fdd4a2
• Reap stale multi-agent slots (#24903)

  ## Summary
  
  - Let `close_agent` clean up an agent that is still registered in
  `AgentRegistry` even when its underlying thread is already missing.
  - Preserve the explicit-close boundary: for known stale thread-spawn
  agents, mark the persisted spawn edge `Closed`, then treat
  `ThreadNotFound` / `InternalAgentDied` as a successful close so the
  registry slot can be released.
  - Add a regression for MultiAgentV2 task-name targets where
  `close_agent("worker")` succeeds after the worker thread has already
  disappeared.
  
  ## Motivation
  
  A worker can disappear from `ThreadManager` while its metadata still
  exists in the root `AgentRegistry`. Before this change, the close tool
  failed while trying to subscribe to the missing thread status, so it
  never reached the cleanup path that releases the registered agent slot.
  With `agents.max_threads = 1`, an explicit close of that stale task-name
  agent could fail and leave the session unable to spawn a replacement.
  
  ## Scope
  
  This PR intentionally does not add automatic stale-agent reaping to
  `spawn_agent`, `resume_agent`, or `list_agents`. A thread being missing
  from `ThreadManager` is not the same as an explicit close: persisted
  open spawn edges are still the durable source of truth for resume and
  task-name ownership until `close_agent` is called.
  
  ## Validation
  
  - `just test -p codex-core -E
  'test(multi_agent_v2_close_agent_reaps_stale_task_name_target) |
  test(resume_agent_from_rollout_reopens_open_descendants_after_manager_shutdown)'`
  - `just fix -p codex-core`

  jif-oai · 2026-05-28 18:48:43 +02:00
  e2551a5e36
• extension-api: add TurnItemEmitter to tool calls (#24813)

  ## Why
  Extension-contributed tools need to emit visible turn items through
  Codex's normal event and persistence pipeline.
  
  ## What
  - Add `TurnItemEmitter` to extension `ToolCall`s and route the core
  implementation through `Session::emit_turn_item_*`.
  - Hold weak session and turn references so retained tool calls cannot
  keep host state alive.
  - Provide a no-op emitter for extension test callers.
  
  ## Test Plan
  - `just test -p codex-core -E
  'test(passes_turn_fields_and_scoped_turn_item_emitter_to_extension_call)'`
  
  ---------
  
  Co-authored-by: jif-oai <jif@openai.com>

  sayan-oai · 2026-05-28 09:13:43 -07:00
  2066874415
• [codex] Store pending response items directly (#24865)
  pakrym-oai · 2026-05-28 07:23:08 -07:00
  1c7832ffa3
• Update rmcp to 1.7.0 (#24763)

  WIll make it easier to uprev when the new draft spec is supported.
  
  Also updates reqwest where needed for compatibility but doesn't update
  it everywhere since this is already a large diff.
  
  The new version of rmcp handles certain kinds of authentication failures
  differently, this patch includes support for identifying the failing scope
  in a WWW-Authenticate header.

  Adam Perry @ OpenAI · 2026-05-27 14:52:06 -07:00
  910578792f
• fix(linux-sandbox): preserve shell cleanup on interruption (#22729)

  ## Why
  Interrupted `shell_command` calls can race with the outer tool-dispatch
  cancellation path. When that happens, the runtime future may be dropped
  before the spawned process gets a chance to run `SIGTERM` cleanup. For
  bwrapd-backed Linux sandbox commands, that can leave synthetic
  protected-path mount bookkeeping such as `.git/.codex` registrations
  under `/tmp` behind after a TUI interruption.
  
  The relevant cancellation points are the outer dispatch race in
  [`core/src/tools/parallel.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/tools/parallel.rs#L91-L132)
  and the process shutdown logic in
  [`core/src/exec.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/exec.rs#L1367-L1393).
  
  ## What changed
  - Keep `shell_command` dispatch alive long enough for the runtime to
  finish cancellation cleanup instead of immediately returning the
  synthetic aborted response.
  - Fold shell-turn cancellation into the existing `ExecExpiration` path
  in
  [`core/src/tools/runtimes/shell.rs`](https://github.com/openai/codex/blob/bd184ba84703cc924921ed883f0cf17d3dba60ff/codex-rs/core/src/tools/runtimes/shell.rs#L267-L274),
  so cancellation and timeout behavior stay centralized.
  - On cancellation, send `SIGTERM` first, wait briefly for cleanup to
  run, then hard-kill any remaining descendants in the original process
  group.
  - Treat `ESRCH` as an already-gone process-group cleanup case in
  `codex-utils-pty`, which keeps best-effort teardown from surfacing a
  stale-process race as an error.
  
  ## Verification
  - `cargo test -p codex-core cancellation`
  - Added regression coverage for:
    - `shell_tool_cancellation_waits_for_runtime_cleanup`
    - `process_exec_tool_call_cancellation_allows_sigterm_cleanup`

  viyatb-oai · 2026-05-27 12:59:11 -07:00
  9152ebd289
• chore: enable namespace tools for Bedrock (#24713)

  Client-side namespace tools are now supported by bedrock. Enable
  `namespace_tools` for the Amazon Bedrock provider while continuing to
  disable unsupported hosted tools such as image generation and web
  search.

  Celia Chen · 2026-05-27 19:39:01 +00:00
  07a930138f
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• Restore legacy image detail values (#24644)

  ## Why
  
  Older persisted rollouts can contain `input_image.detail` values of
  `auto` or `low` from before `ImageDetail` was narrowed to
  `high`/`original`. Current deserialization rejects those values, which
  can make resume skip later compacted checkpoints and reconstruct an
  oversized raw suffix before the next compaction attempt.
  
  Confirmed Sentry reports fixed by this compatibility path:
  
  - [CODEX-1H3F](https://openai.sentry.io/issues/7500642496/)
  - [CODEX-1H6N](https://openai.sentry.io/issues/7501025347/)
  - [CODEX-1JDP](https://openai.sentry.io/issues/7504549065/)
  - [CODEX-1HW6](https://openai.sentry.io/issues/7503407986/)
  
  ## Background
  
  [openai/codex#20693](https://github.com/openai/codex/pull/20693) added
  image-detail plumbing for app-server `UserInput` so input images could
  explicitly request `detail: original`. The Slack discussion behind that
  PR was about ScreenSpot / bridge evals where user input images were
  resized, while tool output images already had MCP/code-mode ways to
  request image detail.
  
  In review, the intended new API surface was narrowed to `high` and
  `original`: default to `high`, allow `original` when callers need
  unchanged image handling, and avoid encouraging new `auto` or `low`
  usage. That policy still makes sense for newly emitted values.
  
  The missing compatibility piece is persisted history. Older rollouts can
  already contain `auto` and `low`, and resume reconstructs typed history
  by deserializing those rollout records. Rejecting old values at that
  boundary causes valid compacted checkpoints to be skipped. This PR
  restores `auto` and `low` as real variants so old records deserialize
  and round-trip without being rewritten as `high`, while product paths
  can continue to default to `high` and avoid emitting `auto` for new
  behavior.
  
  ## What changed
  
  - Restored `ImageDetail::Auto` and `ImageDetail::Low` as first-class
  protocol values.
  - Preserved `auto`/`low` through rollout deserialization, MCP image
  metadata, code-mode image output, and schema/type generation.
  - Kept local image byte handling conservative: only `original` switches
  to original-resolution loading; `auto`/`low`/`high` continue through the
  resize-to-fit path while retaining their detail value.
  - Added regression coverage for enum round-tripping and code-mode `low`
  detail handling.
  
  ## Testing
  
  - `just write-app-server-schema`
  - `just test -p codex-protocol`
  - `just test -p codex-tools`
  - `just test -p codex-code-mode`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core
  suite::rmcp_client::stdio_image_responses_preserve_original_detail_metadata`
  - `just test -p codex-core
  suite::code_mode::code_mode_can_use_mcp_image_result_with_image_helper`
  - Loaded broken rollouts on local fixed builds, and started/completed
  new turns.
  
  I also attempted `just test -p codex-core`; the local broad run did not
  finish green: 2559 tests run, 2467 passed, 55 flaky, 91 failed, 1 timed
  out. The failures were broad timeout/deadline failures across unrelated
  areas; targeted changed-path core tests above passed.

  rhan-oai · 2026-05-26 16:24:33 -07:00
  dc4e54d061
• Clarify view_image tool description (#23949)
  Curtis 'Fjord' Hawthorne · 2026-05-26 14:17:43 -07:00
  675cb1afbd
• Add experimental turn additional context (#24154)

  ## Summary
  
  Adds experimental `additionalContext` support to `turn/start` and
  `turn/steer` so clients can provide ephemeral external context, such as
  browser or automation state, without turning that plumbing into a
  visible user prompt or triggering user-prompt lifecycle behavior.
  
  ## API Shape
  
  The parameter shape is:
  
  ```ts
  additionalContext?: Record<string, {
    value: string
    kind: "untrusted" | "application"
  }> | null
  ```
  
  Example:
  
  ```json
  {
    "additionalContext": {
      "browser_info": {
        "value": "Active tab is CI failures.",
        "kind": "untrusted"
      },
      "automation_info": {
        "value": "CI rerun is in progress.",
        "kind": "application"
      }
    }
  }
  ```
  
  The keys are opaque and caller-defined.
  
  ## Context Injection
  
  When provided, accepted entries are inserted into model context as
  hidden contextual message items, not as visible thread user-message
  items.
  
  `kind: "untrusted"` entries are inserted with role `user`:
  
  ```text
  <external_${key}>${value}</external_${key}>
  ```
  
  `kind: "application"` entries are inserted with role `developer`:
  
  ```text
  <${key}>${value}</${key}>
  ```
  
  Values are not escaped. Each value is truncated to 1k approximate tokens
  before wrapping.
  
  For `turn/start`, accepted additional context is inserted before normal
  user input. For `turn/steer`, additional context is merged only when the
  steer includes non-empty user input; context-only steers still reject as
  empty input.
  
  ## Dedupe Strategy
  
  `AdditionalContextStore` lives on session state and stores the latest
  complete additional-context map.
  
  Each `turn/start` or non-empty `turn/steer` treats its
  `additionalContext` as the current complete set of values. Entries are
  injected only when the key is new or the exact entry for that key
  changed, including `value` or `kind`. After merging, the store is
  replaced with the provided map, so omitted keys are removed from the
  retained set and can be injected again later if reintroduced.
  
  Omitting `additionalContext`, passing `null`, or passing an empty object
  resets the store to empty and injects nothing.
  
  ## What Changed
  
  - Threads experimental v2 `additionalContext` through app-server into
  core turn start and steer handling.
  - Adds separate contextual fragment types for untrusted user-role
  context and application developer-role context.
  - Uses pending response input items so additional context can be
  combined with normal user input without treating it as prompt text.
  - Adds integration coverage for start/steer flow, role routing,
  dedupe/reset behavior, deletion/re-add behavior, hook-blocked input
  behavior, empty context-only steer rejection, external-fragment marker
  matching, and truncation.

  pakrym-oai · 2026-05-26 13:02:34 -07:00
  768848ab6f
• standalone websearch extension (#23823)

  ## Summary
  
  Add the extension-backed standalone `web.run` tool so Codex can call the
  standalone search endpoint through the `codex-api` search client and
  return its encrypted output to Responses.
  
  - gate the new tool behind `standalone_web_search`
  - install the extension in the app-server thread registry and hide
  hosted `web_search` when standalone search is enabled for OpenAI
  providers so the two paths stay mutually exclusive
  - build search context from persisted history using a small tail
  heuristic: previous user message, assistant text between the last two
  user turns capped at about 1k tokens, and current user message
  
  ## Test Plan
  
  - `cargo test -p codex-web-search-extension`
  - `cargo test -p codex-api`
  - `cargo test -p codex-core
  hosted_tools_follow_provider_auth_model_and_config_gates`

  sayan-oai · 2026-05-26 11:12:24 -07:00
  a22706dfae
• Move MCP tool naming mode into manager (#21576)

  ## Why
  
  The `non_prefixed_mcp_tool_names` feature should be applied where MCP
  tools become model-visible, not by remapping names later in core.
  Keeping the decision in `McpConnectionManager` construction makes
  `ToolInfo` the single shaped view that spec building, deferred tool
  search, routing, and unavailable-tool placeholders can consume directly.
  
  This also preserves the existing external behavior while the feature is
  off, and keeps the feature-on behavior for code mode and hooks explicit
  at the manager boundary.
  
  ## What Changed
  
  - Add `McpToolNameMode` to `codex-mcp` and flow it through `McpConfig`
  into `McpConnectionManager::new`.
  - Normalize MCP `ToolInfo` names in the manager using either
  legacy-prefixed namespaces or non-prefixed namespaces; the legacy path
  adds `mcp__` without restoring the old trailing namespace suffix.
  - Remove the core-side MCP name remapping path so specs, tool search,
  session resolution, and unavailable-tool placeholder construction use
  the manager-provided `ToolName` values directly.
  - Keep code mode flattening on the `__` namespace separator.
  - Preserve hook compatibility by giving non-prefixed MCP hook names
  legacy `mcp__...` matcher aliases.
  - Add/adjust integration and unit coverage for non-prefixed code-mode
  behavior, hook matching with the feature on and off, and manager-level
  legacy prefixing.
  
  ## Testing
  
  - `cargo test -p codex-mcp --lib`
  - `cargo test -p codex-core --lib tools::spec::tests -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tools -- --nocapture`
  - `cargo test -p codex-core --lib mcp_tool_exposure -- --nocapture`
  - `cargo test -p codex-core --test all mcp_tool -- --nocapture`
  - `cargo test -p codex-core --test all search_tool -- --nocapture`
  - `cargo test -p codex-core --test all hooks_mcp -- --nocapture`
  - `cargo test -p codex-core --test all
  code_mode_uses_non_prefixed_mcp_tool_names_when_feature_enabled --
  --nocapture`
  - `cargo test -p codex-tools`
  - `cargo test -p codex-features`

  pakrym-oai · 2026-05-26 08:21:15 -07:00
  ff7513cd83
• [codex] Make active turn task singular (#24105)

  ## Why
  
  `ActiveTurn` already runs at most one task: starting a task requires
  that no task is present, and replacement aborts existing work first.
  Representing that state as an `IndexMap` leaves a multi-task shape for a
  single-task invariant and makes each lifecycle lookup operate like a
  collection lookup.
  
  The slot remains optional because goal continuation uses an empty active
  turn as a reservation while deciding whether to start continuation work.
  
  ## What changed
  
  - Replace `ActiveTurn.tasks` with `task: Option<RunningTask>`.
  - Update task abort/completion, session lookup and steering, input-queue
  matching, goal reservation, and network-approval lookup to operate on
  the singular slot.
  - Mutate the singular task slot directly instead of retaining
  collection-era add/remove/take helpers.
  - Record token usage on the completing active task span without a
  regular-task-only opt-in flag.
  
  ## Validation
  
  - `cargo test -p codex-core --lib session::tests::steer_input`
  - `cargo test -p codex-core --lib
  session::tests::abort_empty_active_turn_preserves_pending_input`
  - `cargo test -p codex-core --lib
  session::tests::queued_response_items_for_next_turn_move_into_next_active_turn`
  - `cargo test -p codex-core --lib
  session::tests::active_goal_continuation_runs_again_after_no_tool_turn`
  - `cargo test -p codex-core --lib
  session::tests::abort_regular_task_emits_turn_aborted_only`
  - `cargo test -p codex-core --lib session::input_queue::tests`

  pakrym-oai · 2026-05-26 08:20:58 -07:00
  b637fd26aa
• code-mode: merge stored values by key (#24159)

  ## Summary
  
  Change code-mode stored value updates to merge writes by key instead of
  replacing the session's complete stored-value map after each cell
  completes.
  
  Previously, each cell received a snapshot of stored values and returned
  the complete resulting map. When multiple cells ran concurrently, a
  later completion could overwrite values written by another cell because
  it committed an older snapshot.
  
  This change moves stored-value ownership into `CodeModeService`:
  
  - Each runtime starts from the service's current stored values.
  - Runtime completion reports only keys written by that cell.
  - The service merges those writes into the current stored-value map on
  successful completion.
  - Core no longer replaces its stored-value state from a cell result.
  
  As a result, concurrently executing cells can update different stored
  keys without clobbering one another.
  
  The move into CodeModeService is motivated by a desire to have this
  lifetime tied to a new lifetime object on that side in a subsequent PR.

  Channing Conger · 2026-05-22 19:09:02 -07:00
  f94157a4b2
• Default function tools into tool hooks (#23757)

  # Why
  
  `PreToolUse`, `PostToolUse`, and `updatedInput` coverage for local
  function tools currently depends on each handler remembering to wire up
  the hook contract itself. That makes coverage easy to miss as new
  function tools are added, even though most of them share the same basic
  shape: a model-facing function call with JSON arguments.
  
  # What
  
  This makes `CoreToolRuntime` provide the default hook contract for
  ordinary local function tools:
  
  - build generic `PreToolUse` and `PostToolUse` payloads from the
  function tool name and arguments
  - apply `updatedInput` rewrites back into function-tool arguments
  through the same default path
  - let tool outputs override the post-hook input or response when they
  have a more stable hook-facing contract
  
  The exceptions stay explicit:
  
  - hosted tools remain outside the generic local function path
  - code-mode `wait` and `write_stdin` opt out for now
  - `PostToolUse` feedback replaces only the model-visible response, so
  code mode keeps its typed tool result
  
  With the generic path in place, the MCP and extension-tool adapters no
  longer need their own duplicate pre/post hook plumbing. The new coverage
  exercises the registry default plus end-to-end local function behavior
  for pre-hook blocking, `updatedInput` rewriting, and post-hook context.

  Abhinav · 2026-05-23 00:56:58 +00:00
  5c20513a1b
• Allow parallel MCP tool calls when annotated readOnly (#23750)

  ## Summary
  - Treat MCP tools with `readOnlyHint: true` as parallel-safe even when
  `supports_parallel_tool_calls` is unset or `false`.
  - Keep server-level `supports_parallel_tool_calls` as an additive
  override for non-read-only tools.
  - Add focused unit coverage for the MCP handler eligibility decision.
  - Update RMCP integration coverage to keep the serial baseline on a
  mutable tool, verify read-only concurrency without server opt-in, and
  preserve the server opt-in concurrency path separately.
  
  ## Testing
  - `just fmt`
  - `cargo test -p codex-core --lib tools::handlers::mcp::tests::`
  - `cargo test -p codex-core --test all
  stdio_mcp_read_only_tool_calls_run_concurrently_without_server_opt_in`
  - `cargo test -p codex-core --test all
  stdio_mcp_parallel_tool_calls_opt_in_runs_concurrently`
  - `cargo test -p codex-rmcp-client`

  anp-oai · 2026-05-21 20:40:34 -07:00
  c83ba22359
• Expose conversation history to extension tools (#23963)

  ## Why
  
  Extension tools that need conversation context should be able to read it
  from the live tool invocation instead of reaching into thread
  persistence themselves.
  
  ## What changed
  
  - Add a `ConversationHistory` snapshot to extension `ToolCall`s and
  populate it from the current raw in-memory response history.
  - Expose all history items at this boundary so each extension can filter
  and bound the subset it needs before consuming or forwarding it.
  - Cover the adapter and registry dispatch paths and update existing
  extension tests that construct `ToolCall` literals.
  
  ## Test plan
  
  - `cargo test -p codex-tools`
  - `cargo test -p codex-extension-api`
  - `cargo test -p codex-goal-extension`
  - `cargo test -p codex-memories-extension`
  - `cargo test -p codex-core passes_turn_fields_to_extension_call`
  - `cargo test -p codex-core
  extension_tool_executors_are_model_visible_and_dispatchable`

  sayan-oai · 2026-05-22 01:11:47 +00:00
  7e802b22f1