916 Commits

• [codex] Add internal auto-compaction opt-out (#28260)

  ## Summary
  
  - add a default-on `auto_compaction` feature flag as an internal escape
  hatch
  - skip pre-turn, model-switch/hash, and mid-turn automatic compaction
  when the flag is disabled
  - preserve manual `/compact` behavior and surface the existing
  context-window error when the provider runs out of room
  - add integration coverage for disabled pre-turn and mid-turn compaction
  
  ## Motivation
  
  Long-running SPO optimization rollouts need the option to preserve their
  full context and fail on context exhaustion instead of entering another
  compaction window. This deliberately uses the existing feature-flag
  mechanism rather than adding a dedicated public config or app-server
  API.
  
  Disable it with:
  
  ```sh
  codex --disable auto_compaction
  ```
  
  ## Testing
  
  - `just test -p codex-features` — 51 passed
  - `just test -p codex-core auto_compaction_feature_disabled` — 2 passed
  - `just fix -p codex-core -p codex-features`
  - `just write-config-schema`
  - `just test -p codex-core` — the new compaction tests passed; the
  overall local run had 54 unrelated environment failures, primarily
  missing first-party test binaries and shell-snapshot timeouts

  rhan-oai · 2026-06-21 20:11:50 -07:00
  b21f0e7a98
• Carry sandbox intent to remote exec servers (#29108)

  ## What changed
  
  PR #29099 stopped sending the orchestrator's concrete sandbox wrapper to
  a remote exec-server. Remote commands now arrive as plain native argv.
  
  This PR adds the next piece: Codex also sends portable sandbox intent
  next to that plain argv.
  
  For a remote unified-exec command, the request can now include:
  
  - the canonical permission profile before local workspace-root
  materialization
  - the sandbox cwd and workspace roots as `PathUri` values
  - Windows sandbox settings
  - the legacy Landlock setting
  - whether managed networking must be enforced
  
  The important part is that symbolic entries such as `:workspace_roots`
  stay symbolic while crossing the boundary. The executor can then bind
  them to its own workspace-root paths instead of receiving
  orchestrator-local absolute paths.
  
  The data travels through `ExecRequest` into `ExecParams`. Older
  exec-servers can still deserialize requests because the new fields have
  defaults.
  
  ## Why
  
  The orchestrator should not decide how another machine implements
  sandboxing.
  
  For example:
  
  - a local macOS Codex would normally build a Seatbelt command
  - a remote Linux executor needs a Linux sandbox command instead
  
  The orchestrator now sends the plain command plus the policy it intended
  to enforce. A later PR can let the exec-server choose and build the
  correct sandbox for its own operating system.
  
  ## Important detail
  
  This keeps the portable intent separate from the local `SandboxType`.
  
  `SandboxType::None` is ambiguous:
  
  - it can mean the command was explicitly approved to run without a
  sandbox
  - it can also mean the orchestrator host has no concrete sandbox
  implementation available
  
  Those cases are different for remote execution. This PR adds
  `sandbox_requested` so an executor can still receive sandbox intent when
  the orchestrator cannot build a local wrapper. Explicit unsandboxed
  retries still send no sandbox context.
  
  ## Behavior today
  
  This PR only transports the intent. The exec-server accepts the new
  fields but does not apply them yet.
  
  Remote commands therefore remain unsandboxed after this PR, just as they
  are after PR #29099.
  
  ## Follow-up
  
  The next PR will make exec-server read this portable intent, bind
  symbolic workspace permissions to executor-native roots, choose the
  sandbox for its own operating system, build the wrapper locally, and
  then spawn the command.

  jif · 2026-06-21 12:33:21 +02:00
  bd2968a4db
• Keep remote exec commands native to the executor (#29099)

  ## Summary
  
  - Remote unified-exec now sends the original command argv to exec-server
  instead of materializing the orchestrator's sandbox wrapper first.
  - Local unified-exec keeps the existing sandbox path unchanged.
  - Add a focused regression test for a macOS-selected sandbox producing
  plain remote argv.
  
  Before:
  
      macOS orchestrator -> /usr/bin/sandbox-exec ... -> Linux exec-server
  
  After:
  
      macOS orchestrator -> /bin/bash -lc pwd -> Linux exec-server
  
  This is intentionally only the first cleanup step. Remote unified-exec
  commands are sent without a process sandbox until the targeted
  follow-ups below land. For the macOS-to-Linux path this is not a
  practical regression: the old sandboxed attempt failed before process
  launch because the Linux executor could not spawn macOS sandbox paths.
  
  ## Targeted follow-ups
  
  1. Carry sandbox intent separately from argv.
     - Add an optional sandbox field to exec-server process params.
  - Reuse FileSystemSandboxContext rather than introducing a new sandbox
  model.
     - Carry managed-network enforcement as one explicit bit.
     - Keep argv plain.
  
  2. Apply that intent inside exec-server.
     - Add a small process-start adapter before LocalProcess::exec.
  - Reuse the existing codex-sandboxing SandboxManager and exec-server
  runtime paths.
  - Follow the same shape already used by exec-server filesystem
  sandboxing.
     - Do not duplicate or move the sandbox implementations.
  
  3. Report the sandbox actually used.
     - Return the executor-selected sandbox type from process/start.
  - Use that value in core for sandbox-denial detection and retry
  behavior.
  
  ## End state
  
  The orchestrator sends plain commands plus portable sandbox intent. The
  executor chooses and applies its own native sandbox: Linux executors use
  Linux sandboxing, macOS executors use Seatbelt, and Windows executors
  use Windows sandboxing. Concrete wrapper argv, helper paths, and sandbox
  env markers never cross the executor boundary.

  jif · 2026-06-19 17:05:51 +02:00
  04483f4ce5
• Add config toggles for orchestrator skills and MCP (#28942)

  ## Why
  
  Orchestrator-provided skills and Codex Apps MCP tools add model-visible
  instructions, resources, and tools beyond the local workspace. Hosts
  need config-level switches to disable those orchestrator-owned surfaces
  independently, without disabling regular skills or regular MCP servers.
  
  ## What changed
  
  - Adds `[orchestrator.skills].enabled` and `[orchestrator.mcp].enabled`
  config entries, both defaulting to `true`.
  - Includes the new settings in `config.schema.json` and in the config
  lock so resolved thread configuration preserves the same orchestrator
  exposure decisions.
  - Threads `orchestrator.skills.enabled` through the app-server skills
  extension so disabled orchestrator skills do not expose the `skills`
  namespace or inject orchestrator skill context.
  - Gates Codex Apps MCP exposure, app instructions, and app auth
  eligibility on `orchestrator.mcp.enabled` while leaving non-Codex-Apps
  MCP tools available.
  - Updates the thread-manager sample config to disable both
  orchestrator-owned surfaces.
  
  ## Verification
  
  - Added config parsing, loading, defaulting, and schema coverage for the
  new settings.
  - Added MCP exposure coverage that `orchestrator.mcp.enabled = false`
  removes Codex Apps tools while preserving regular MCP tools.
  - Added app-server coverage that `orchestrator.skills.enabled = false`
  prevents orchestrator skill tools, prompts, and resource reads from
  reaching the model turn.

  jif · 2026-06-19 14:42:26 +02:00
  81b000421d
• Add indexed web search mode (#28489)

  ## Summary
  
  - Add `web_search = "indexed"` alongside `disabled`, `cached`, and
  `live`.
  - Use that same resolved mode for both hosted and standalone web search.
  - For hosted search, send `index_gated_web_access: true` with external
  web access enabled only when `indexed` is selected.
  - For standalone search, preserve the existing boolean wire values for
  existing modes (`cached` maps to `false` and `live` to `true`) and send
  `"indexed"` only for `indexed`; `disabled` keeps the tool unavailable.
  - Carry the mode through managed configuration requirements and
  generated schemas.
  
  ## Why
  
  Indexed search provides a middle ground between cached-only search and
  unrestricted live page fetching. Search queries can remain live while
  direct page fetches are limited to URLs admitted by the server.
  
  The existing `web_search` setting remains the single source of truth, so
  hosted and standalone executors cannot drift into different access
  modes. Without an explicit `indexed` selection, the existing
  model-visible tool and request shapes are unchanged.
  
  ```toml
  web_search = "indexed"
  
  [features]
  standalone_web_search = true
  ```
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-api` (`126 passed`)
  - `just test -p codex-web-search-extension` (`7 passed`)
  - `just test -p codex-core
  code_mode_can_call_indexed_standalone_web_search` (`1 passed`)
  - Focused configuration, hosted request, standalone request, and
  managed-requirement coverage is included in the PR; remaining suites run
  in CI.
  
  The full workspace test suite was not run locally.

  Winston Howes · 2026-06-19 05:35:57 -07:00
  3a2712ea14
• Scope network approvals by environment (#28899)

  Stacked on #28766.
  
  ## Why
  
  Network approvals are environment-scoped: allowing a host in one
  execution environment should not allow the same host in another
  environment.
  
  #28766 adds the inert IDs and constructor plumbing. This PR applies the
  behavior on top.
  
  ## What changed
  
  - Route managed network traffic through per-environment HTTP and SOCKS
  proxy listeners.
  - Stamp HTTP, HTTPS CONNECT, SOCKS TCP, and SOCKS UDP policy requests
  with the source environment at the proxy boundary.
  - Carry the selected execution environment through shell, unified exec,
  zsh-fork, and sandbox transform paths.
  - Include the environment in pending, approved-for-session, and
  denied-for-session network approval cache keys.
  - Include the environment in approval IDs and approval prompts.
  - Preserve legacy fallback for unattributed requests, but deny when
  active-call attribution is ambiguous.
  - Fail closed if an environment-specific proxy endpoint cannot be
  prepared.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-19 13:49:45 +02:00
  bd5d31b250
• Expose thread-level multi-agent mode (#28792)

  ## Why
  
  Once multi-agent mode can be selected per turn, clients also need to
  choose the initial selection when creating a thread and observe that
  selection through lifecycle and settings APIs.
  
  The selected value is intentionally distinct from the effective
  model-visible value: no client selection is represented as `null`, even
  though an eligible multi-agent v2 turn derives `explicitRequestOnly` as
  its effective default.
  
  ## What changed
  
  - Add the optional experimental `thread/start.multiAgentMode` parameter
  and pass it through thread creation.
  - Preserve an omitted initial value as an unset selection rather than
  eagerly storing `explicitRequestOnly`.
  - Apply an explicit `thread/start` selection to the first turn through
  the session configuration established at thread creation.
  - Restore the latest persisted effective mode as the selected baseline
  on cold resume when rollout history contains one.
  - Inherit the optional selected mode from a loaded parent when creating
  related runtime threads.
  - Return the current selected `multiAgentMode` from `thread/start`,
  `thread/resume`, `thread/fork`, and thread settings, using `null` when
  no mode is selected.
  - Keep lifecycle reporting independent from model capability and feature
  eligibility; core turn construction remains responsible for calculating
  and persisting the effective mode.
  
  ## Not covered
  
  - Clearing an existing loaded-session selection back to unset through
  `turn/start`; omitted or `null` currently retains the session's
  selection.
  - A TUI control, slash command, or `config.toml` preference.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server-protocol`
  - `CARGO_INCREMENTAL=0 just test -p codex-app-server multi_agent_mode`
  
  The focused app-server coverage verifies explicit `thread/start`
  initialization, first-turn prompting, nullable reporting for an omitted
  selection, and retention of selections that are not currently
  runtime-eligible.
  
  ## Stack
  
  Stacked on #28685. This PR contains only the thread initialization and
  lifecycle/settings API layer.

  Shijie Rao · 2026-06-19 10:50:44 +02:00
  7abfcf220b
• [codex] add clock current-time tool (#29011)

  ## Summary
  - expose `clock.curr_time` when current-time reminders are enabled
  - query the session's configured time provider with the calling thread
  id
  - return the existing UTC reminder text for direct model calls
  - return `{ "current_time": "YYYY-MM-DD HH:MM:SS UTC" }` in Code Mode
  
  Clock lookup failures remain fatal, matching pre-inference reminder
  behavior.
  
  ## Testing
  - `just test -p codex-core current_time_tool_returns_the_latest_time`
  - `just test -p codex-core
  code_mode_current_time_returns_structured_result`
  - `just fix -p codex-core`

  rka-oai · 2026-06-19 01:46:57 +00:00
  73251b2f00
• [plugins] Refresh plugin and tool caches after remote install (#28951)

  Summary
  - Refresh the installed remote-plugin snapshot and Codex Apps tools
  after completing a remote JIT install.
  - Gate `completed: true` on every expected `app_connector_id` appearing
  after the uncached `tools/list` refresh, while continuing to skip local
  bundle verification for server-side installs.
  - Keep the cached recommendations response and filter refreshed
  installed remote IDs locally, so this does not add another
  recommendations fetch.
  - Add regression coverage for tools appearing after the hard refresh and
  remaining absent after the refresh. The resumed model request sees the
  refreshed tool router when installation completes.
  
  Root Cause
  - Remote suggestions from `openai-curated-remote` returned `true` before
  taking the existing connector refresh path, leaving the resumed turn
  with the pre-install Apps tool catalog.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core-plugins
  recommended_plugin_candidates_filter_installed_and_disabled_plugins`
  - `just test -p codex-core-plugins`
  - `just fix -p codex-core-plugins`
  - `just fix -p codex-core`
  - `just fmt`
  - `just test -p codex-core` was not fully clean locally: 2,729 passed,
  26 failed, and 16 skipped. The failures were dominated by local
  Seatbelt/network/timing issues, including plugin-install timeouts under
  full-suite contention; the focused plugin-install runs pass.

  Alex Daley · 2026-06-18 20:08:04 -04:00
  7e37354a58
• core: keep remote exec on reported shell (#28983)

  ## Why
  
  We need to avoid resolving shells on the app-server's host for remote
  environments. We might make it possible to do fancier shell resolution
  from remote envs but for now just require the model to produce a shell
  that matches the environment's default.
  
  This gets my e2e demo working for shell commands after #28854 moved
  shell resolution to PathUri and caused remote envs to hit the fallback
  shell when the shell wasn't available on the host.
  
  ## What
  
  Remote `exec_command` calls now accept only the environment's reported
  default shell name or exact path, and execute with that reported path.
  Other explicit shells return a concise error. A Wine-backed integration
  test covers explicit PowerShell execution in the Windows cwd.

  Adam Perry @ OpenAI · 2026-06-18 23:39:21 +00:00
  346d2c163f
• Emit Trusted MCP App Identity on Tool-Call Items (#27132)

  ## Summary
  
  - Add optional `appContext` to app-server MCP tool-call items with
  trusted `connectorId`, `linkId`, and `mcpAppResourceUri` metadata.
  - Preserve that context across tool-call events, persisted history,
  reconnects, and thread resume.
  - Keep the deprecated top-level `mcpAppResourceUri` temporarily for
  client migration.
  
  The consumer contract is `{ appContext: { connectorId, linkId,
  mcpAppResourceUri }, tool }`.
  
  ## Validation
  
  - Full GitHub Actions suite passes, including CLA, Bazel tests, clippy,
  release builds, and argument-comment lint.
  
  ---------
  
  Co-authored-by: martinauyeung-oai <280153141+martinauyeung-oai@users.noreply.github.com>

  martinauyeung-oai · 2026-06-18 14:02:54 -07:00
  765309d5a6
• apply-patch: carry paths as PathUri (#28854)

  ## Why
  
  Allows the model to edit files that are hosted on a different OS than
  where app-server is running.
  
  ## What
  
  * Use `PathUri` for apply_patch-internal data structures
  * Limit `PathUri` -> `AbsolutePathBuf` conversion to cases where the
  inferred path convention matches the host OS, allows requiring valid
  paths to pass to perms check
  * Adds `PathConvention::path_segments()` for iterating over path
  segments regardless of OS
  * Handle cross-platform relative paths in path filename parsing for
  sniffing a shell
  * Ensure we can apply patches in the wine e2e test

  Adam Perry @ OpenAI · 2026-06-18 19:31:19 +00:00
  0f89dd768c
• current time reminders impl for system clock (varlatency 2/n) (#28824)

  Stacked on #28822.
  
  ## Summary
  
  - add a host-injectable current-time provider with a built-in system
  implementation
  - record UTC developer reminders in history immediately before due model
  requests
  - keep cadence state per session and force a refresh after compaction
  
  This does NOT include the app server client <-> server clock logic. This
  PR is only for the reminder message & system clock that will be used in
  prod.
  
  ## Testing
  
  - `just test -p codex-core varlatency_`
  - `just clippy -p codex-core -p codex-app-server -p codex-mcp-server -p
  codex-thread-manager-sample`
  - `just fmt`

  rka-oai · 2026-06-18 19:18:42 +00:00
  752ed90d78
• Support openai/form extended form elicitations (#27500)

  # Summary
  Allow App Server clients to opt into `openai/form` MCP elicitations.

  Gabriel Peal · 2026-06-18 11:54:49 -07:00
  21a599fa56
• Add network environment ID plumbing (#28766)

  ## Why
  
  Prepare network approval scoping to distinguish execution environments
  without changing behavior yet.
  
  ## What changed
  
  - Add optional environment IDs to network policy requests.
  - Add optional network environment IDs to exec and sandbox request
  structs.
  - Thread default None values through existing construction points.
  - Fix stale constructor call sites that caused the CI compile failures.
  
  ## Not included
  
  - Per-environment proxy listeners.
  - Network approval cache or prompt behavior changes.
  - Ambiguous request attribution handling.
  
  Those behavior changes moved to stacked follow-up #28899.
  
  ## Validation
  
  - just fmt
  - CI will run tests and clippy

  jif · 2026-06-18 14:09:38 +02:00
  0369b24d54
• unified-exec: retain PathUri in command events (#28780)

  ## Why
  
  App-server must report command events containing foreign-platform paths
  without changing existing client or rollout path-string formats.
  
  ## What changed
  
  - retain `PathUri` through exec command begin/end events
  - convert cwd values to `LegacyAppPathString` at the app-server
  compatibility boundary
  - drop command actions with foreign paths and log them
  - serialize rollout-trace cwd values using their inferred native path
  representation
  - restore Wine coverage for retained Windows cwd values and successful
  completion

  Adam Perry @ OpenAI · 2026-06-18 05:00:04 +00:00
  3931bc2bde
• Expose selecte namespaces as direct model tools (#28825)

  ## Why
  
  Som tools, such as history and notes, must remain top-level when MCP
  deferral is enabled while staying unavailable through code-mode `exec`.
  
  ## What changed
  
  - Added `features.code_mode.direct_only_tool_namespaces`.
  - Classified matching MCP tools as `DirectModelOnly`.
  - Kept those tools top-level in `code_mode_only`.
  - Excluded them from `tool_search` deferral and the nested `exec`
  surface.
  - Updated the generated config schema.
  
  ## Validation
  
  - `code_mode_only_exposes_direct_model_only_mcp_namespaces`
  - `load_config_resolves_code_mode_config`

  Won Park · 2026-06-18 04:07:54 +00:00
  78a9e169bb
• [codex] Add optional IDs to response items (#28812)

  ## Why
  
  `ResponseItem` variants do not have a consistent internal ID shape: some
  variants carry required IDs, some carry optional IDs, and some cannot
  represent an ID at all. The existing fields also use inconsistent serde,
  TypeScript, and JSON-schema annotations. A single enum-level access path
  is needed before history recording can assign and retain IDs.
  
  This PR establishes that internal model only. It intentionally does not
  generate or serialize IDs; allocation and wire persistence are isolated
  in the stacked follow-up.
  
  ## What changed
  
  - Give every concrete `ResponseItem` variant an `Option<String>` ID
  field.
  - Apply the same internal-only annotations to every ID field:
  `#[serde(default, skip_serializing)]`, `#[ts(skip)]`, and
  `#[schemars(skip)]`.
  - Add `ResponseItem::id()` and `ResponseItem::set_id()` as the shared
  accessors.
  - Preserve IDs when history items are rewritten for truncation.
  - Adapt consumers that previously assumed reasoning and image-generation
  IDs were required.
  - Regenerate app-server schemas so the hidden fields are represented
  consistently.
  
  The serde catch-all `ResponseItem::Other` remains ID-less because it
  must remain a unit variant.
  
  ## Test plan
  
  - `cargo check --tests -p codex-core -p codex-api -p codex-rollout-trace
  -p codex-image-generation-extension`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-api -p codex-rollout-trace -p
  codex-image-generation-extension`
  - `just test -p codex-core event_mapping`

  pakrym-oai · 2026-06-17 18:27:43 -07:00
  dbd2857f4b
• [codex] trace tools build latency (#28782)

  Add more tracing spans around tool building.

  Owen Lin · 2026-06-17 14:53:54 -07:00
  38211a3ff8
• unified-exec: preserve PathUri through exec-server (#28681)

  ## Why
  
  It should be possible for app-server to handle "foreign" OS paths in
  unified_exec working directories, allowing e.g. a Linux app-server to
  run processes on e.g. a Windows exec-server.
  
  ## What
  
  Convert the core unified_exec cwd values to use `PathUri`.
  
  Adds fallible path conversion in several places to try to minimize the
  scope of this change. The only time this change suppresses errors from
  converting `PathUri` to an `AbsolutePathBuf` is when the turn is
  configured with no sandboxing at all to allow us to make progress
  testing without sandboxing.
  
  Future changes to apply_patch and sandboxing will clean up these error
  paths.
  
  A tool's cwd is resolved from joining a model-provided workdir to the
  environment's cwd. When using `AbsolutePathBuf::join()`, an
  absolute-path workdir would overwrite the environment's cwd and we would
  resolve permissions/sandboxing against the model-provided path. This
  change extends `PathUri::join()` to also treat an absolute rhs as an
  override of the base/lhs.
  
  This also removes some coverage from the remove_env_windows tests until
  a follow-up converts foreign paths in command exec events correctly.
  
  ## Breaking Changes
  
  When using `AbsolutePathBuf::join()` for workdir resolution, we ended up
  resolving tilde-prefixed paths against the app-server's `$HOME`, e.g.
  `~/foo/bar` becomes `/home/anp/foo/bar`. It's difficult to do this with
  `PathUri` joining, so after offline discussion this PR no longer
  implements it.
  
  A quick check of some power users' rollouts suggests that models don't
  actually generate home-prefixed absolute working directories for their
  spawns, so this shouldn't have any real blast radius.

  Adam Perry @ OpenAI · 2026-06-17 19:36:16 +00:00
  5867b529ae
• Scope command approvals by execution environment (#28738)

  ## Why
  
  Command approval cache keys included the command and working directory,
  but not the execution environment. An approval for `/workspace` locally
  could therefore be reused for the same command and path on an executor.
  
  ## What changed
  
  - Include the selected environment ID in shell and unified-exec approval
  cache keys.
  - Carry that ID through the normal command approval request so clients
  can show which environment is being approved.
  - Expose the environment through app-server as a required nullable
  `environmentId` and show it in the inline TUI approval prompt.
  - Keep older recorded approval events compatible when the environment is
  absent.
  
  For example, `echo ok` in local `/workspace` and `echo ok` in executor
  `/workspace` now produce different approval keys and separate prompts.
  
  ## Scope
  
  This PR does not change network approvals, Guardian review actions, MCP
  elicitation, full-screen TUI rendering, or environment-ID validation.
  Remote `shell_command` execution itself remains in #28722; this PR only
  makes its approval key environment-aware.

  jif · 2026-06-17 19:52:43 +02:00
  1391d786bc
• Run fs helper through Windows sandbox wrapper (#28359)

  ## Why
  
  This is the final PR in the Windows fs-helper sandbox stack and contains
  the actual bug fix.
  
  The exec-server filesystem helper is a direct-spawn path: it asks
  `SandboxManager` for a `SandboxExecRequest`, then launches the returned
  argv itself. That works on macOS and Linux because the transformed argv
  is already a self-contained sandbox wrapper. On Windows, the transformed
  request carried `WindowsRestrictedToken` metadata, but the direct-spawn
  fs-helper runner still launched the helper argv directly.
  
  That means Windows filesystem built-ins backed by the fs-helper could
  run with the parent Codex process permissions instead of the configured
  Windows sandbox. This PR makes the direct-spawn transform produce a
  self-contained Windows wrapper argv before fs-helper launches it.
  
  ## What Changed
  
  - Added `SandboxManager::transform_for_direct_spawn()` for callers that
  launch the returned argv themselves.
  - Wrapped Windows restricted-token direct-spawn requests with `codex.exe
  --run-as-windows-sandbox` and then marked the outer request as
  unsandboxed, matching the macOS/Linux wrapper argv shape.
  - Updated `exec-server/src/fs_sandbox.rs` to use the direct-spawn
  transform for fs-helper launches.
  - Materialized the inner `codex.exe --codex-run-as-fs-helper` executable
  into `.sandbox-bin` so the sandboxed user can run it.
  - Carried runtime workspace roots through `FileSystemSandboxContext` as
  `PathUri` values so `:workspace_roots` policies resolve correctly
  without sending native client paths over exec-server JSON.
  - Preserved wrapper setup identity environment needed by Windows sandbox
  setup without changing the serialized inner helper environment.
  
  ## Verification
  
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-sandboxing transform_for_direct_spawn_windows`
  - `just test -p codex-exec-server fs_sandbox::tests`
  - `just fix -p codex-windows-sandbox -p codex-sandboxing -p
  codex-exec-server -p codex-core -p codex-file-system`
  
  Local note: `just fmt` completed Rust formatting, but this workstation
  still fails the non-Rust formatter phases because uv cannot open its
  cache and the local buildifier/dotslash path is missing.

  iceweasel-oai · 2026-06-17 10:00:42 -07:00
  ef75171f18
• Add join key for MAv2 inter-agent messages (#28561)

  ## Summary
  This keeps inter-agent communication on the existing raw response item
  path and adds a join key for MAv2 tool calls.
  
  MAv2 `spawn_agent`, `send_message`, and `followup_task` now stamp the
  originating tool call id into `ResponseItemMetadata.source_call_id` on
  the raw `ResponseItem::AgentMessage`. App-server clients can join that
  raw item back to the existing tool/activity event by call id, while
  using the raw agent message's existing sender, receiver, and content
  fields.
  
  No new app-server `ThreadItem` or notification type is added.
  
  ## Tests
  - `just fmt`
  - `just write-app-server-schema`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core
  multi_agent_v2_spawn_returns_path_and_send_message_accepts_relative_path`
  - `just test -p codex-core
  multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn`
  - `just fix -p codex-protocol`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-core`

  jif · 2026-06-17 14:48:56 +02:00
  45f603302c
• core: remove redundant TurnContext and Prompt fields (#28638)

  ## Why
  
  `TurnContext` had accumulated dead fields and cached projections of
  values already owned by its per-turn `Config` or `ModelInfo`. Keeping
  both copies made ownership unclear and allowed artificial split-brain
  states, such as a compatibility hash differing from the model metadata
  it came from.
  
  `Prompt` similarly carried a write-only personality after personality
  selection had already been materialized into its base instructions.
  
  This makes the canonical owner explicit: configuration-backed values
  come from `config`, model-derived values come from `model_info`, and
  prompts contain only data consumed by request construction.
  
  ## What changed
  
  - Remove the unused `ghost_snapshot`, `codex_self_exe`, and
  `thread_source` fields.
  - Remove duplicate `comp_hash`, `truncation_policy`, `features`,
  `shell_environment_policy`, `codex_linux_sandbox_exe`, `compact_prompt`,
  and `tool_mode` fields.
  - Read those values directly from `TurnContext::config` or
  `TurnContext::model_info` at their consumers.
  - Remove the write-only `Prompt::personality` field and its constructor
  assignments.
  - Preserve review-turn inheritance of the parent turn's shell policy,
  Linux sandbox executable, and compact prompt through the review config.
  
  ## Testing
  
  - `cargo check -p codex-core --tests`

  pakrym-oai · 2026-06-16 22:17:24 -07:00
  172b2218a5
• [codex] [4/4] Simplify recommended plugin install schema (#28403)

  ## Summary
  - Simplify recommendation-context `request_plugin_install` arguments to
  `plugin_id` and `suggest_reason`.
  - Derive plugin type and install action from the matched candidate while
  preserving Codex-owned elicitation metadata.
  - Keep the legacy list-backed schema unchanged and accept resumed calls
  that still use `tool_id`.
  
  ## Stack
  - #28399
  - #28400
  - #27704
  - This PR
  
  ## Validation
  - `just test -p codex-tools -p codex-core request_plugin_install` (25
  passed)
  - `just fix -p codex-tools -p codex-core`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 23:44:42 +00:00
  a397b59887
• [codex] [3/4] Activate endpoint plugin recommendations (#27704)

  Summary\n- Await endpoint recommendation selection while constructing
  each authenticated turn, removing the first-turn cache race.\n- Snapshot
  and filter endpoint candidates once per turn, then use that same set for
  the bounded contextual user fragment, tool exposure, and exact install
  validation.\n- Keep recommendation selection ephemeral: do not persist
  recommendation state in or gate resumed threads on prior context.\n-
  Hide the legacy list tool in endpoint mode and preserve legacy discovery
  unchanged when the endpoint is disabled or unavailable.\n- Keep remote
  plugin and connector app identities out of model-visible context and
  attach them only to Codex-owned elicitation metadata.\n\nStack\n- 3/4,
  based on #28400.\n- Endpoint client and cache: #28399.\n- Generalized
  suggestion presentation: #28400.\n- Install-schema follow-up:
  #28403.\n\nValidation\n- \n- \n- \n- \n- Full : 2,649 passed and 88
  environment-dependent tests failed because this sandbox cannot write ,
  nest Seatbelt, or locate auxiliary test binaries.

  Alex Daley · 2026-06-16 23:04:07 +00:00
  a34da3b295
• [codex] [2/4] Generalize plugin suggestion presentation (#28400)

  Summary
  - Add list-backed and developer-context presentations for plugin
  suggestion candidates.
  - Let tool planning, install validation, and request-tool copy follow
  the selected presentation.
  - Keep every production caller on the existing list-backed presentation,
  preserving the current list tool, request schema, connector behavior,
  and model-visible copy.
  - Leave developer-context presentation latent until the final PR in the
  stack.
  
  Stack
  - 2/3, based on #28399.
  - Follow-up: #27704 activates endpoint recommendations.
  
  Validation
  - `just test -p codex-core request_plugin_install`
  - `just test -p codex-core spec_plan`
  - `just fix -p codex-core`
  - `just fmt`
  - `git diff --check`

  Alex Daley · 2026-06-16 22:44:10 +00:00
  587487df9e
• app-server: preserve target-native environment cwd (#28146)

  ## Why
  
  app-server may run on a different OS from the selected exec-server
  environment. Parsing that environment’s cwd with the Codex host’s path
  rules prevents thread startup.
  
  ## What
  
  Carry environment cwd values as `LegacyAppPathString` at the app-server
  boundary and `PathUri` internally. Existing tool-call schemas and
  relative-path behavior stay host-native; remaining local-only consumers
  convert explicitly and leave follow-up TODOs.
  
  The Wine integration test verifies app-server can start a thread and
  complete an ordinary turn with a Windows environment cwd from Linux.
  
  ## Validation
  
  - `bazel test //codex-rs/core/tests/remote_env_windows:smoke-test
  --test_output=errors`
  - focused app-server environment-selection and protocol schema tests
  - scoped Clippy for `codex-core` and `codex-app-server-protocol`

  Adam Perry @ OpenAI · 2026-06-16 21:42:28 +00:00
  f8850cab1d
• [codex] Warn clearly when code mode output is truncated (#28467)

  ## Summary
  
  - make `formatted_truncate_text` prepend `Warning: truncated output
  (original token count: N)` above the existing `Total output lines`
  header
  - update direct formatter, unified-exec, user-shell, and code-mode
  expectations
  - add core unit coverage that runs in Bazel without requiring the
  skipped V8-backed code-mode integration suite
  
  ## Validation
  
  - `cargo test -p codex-utils-output-truncation -- --nocapture` (17
  passed)
  - `cargo test -p codex-core --lib
  truncated_text_output_starts_with_warning -- --nocapture`
  - `cargo test -p codex-core --test all
  clamps_model_requested_max_output_tokens_to_policy -- --nocapture` (2
  passed)
  - `cargo test -p codex-core --test all
  unified_exec_formats_large_output_summary -- --nocapture`
  - `cargo test -p codex-core --test all
  user_shell_command_output_is_truncated_in_history -- --nocapture`
  - Bazel CI exercises the shared formatter and downstream integration
  expectations

  Ahmed Ibrahim · 2026-06-16 10:37:06 -07:00
  952656356a
• feat: render typed envelopes for multi-agent v2 messages (#28368)

  ## Why
  
  Multi-agent v2 messages need a consistent, model-visible envelope that
  identifies what kind of interaction occurred, who sent it, and which
  agent it targets. Previously, encrypted deliveries exposed only
  `encrypted_content`, while child completion used the legacy
  `<subagent_notification>` shape. That meant the client could not
  consistently present `NEW_TASK`, `MESSAGE`, and `FINAL_ANSWER` using the
  same format.
  
  This change adds the routing envelope as plaintext while keeping task
  and message payloads encrypted. No new Responses API field is required:
  an encrypted delivery is represented as an `input_text` header
  immediately followed by its existing `encrypted_content` item.
  
  Every envelope now follows this shape:
  
  ```text
  Message Type: <NEW_TASK | MESSAGE | FINAL_ANSWER>
  Task name: <recipient agent path>
  Sender: <author agent path>
  Payload:
  <message payload>
  ```
  
  ## Message types
  
  ### `NEW_TASK`
  
  `NEW_TASK` is used when the recipient should begin a new turn, including
  an initial `spawn_agent` task and a later `followup_task`.
  
  For a root agent spawning `/root/worker`, the request contains a
  plaintext envelope followed by the encrypted task:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root",
    "recipient": "/root/worker",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: NEW_TASK\nTask name: /root/worker\nSender: /root\nPayload:\n"
      },
      {
        "type": "encrypted_content",
        "encrypted_content": "<encrypted task payload>"
      }
    ]
  }
  ```
  
  Conceptually, the model receives:
  
  ```text
  Message Type: NEW_TASK
  Task name: /root/worker
  Sender: /root
  Payload:
  Review the authentication changes and report any regressions.
  ```
  
  ### `MESSAGE`
  
  `MESSAGE` is used for a queued `send_message` delivery. It communicates
  with an existing agent without starting a new turn.
  
  For `/root/worker` reporting progress to the root agent, the request
  contains:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root/worker",
    "recipient": "/root",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: MESSAGE\nTask name: /root\nSender: /root/worker\nPayload:\n"
      },
      {
        "type": "encrypted_content",
        "encrypted_content": "<encrypted message payload>"
      }
    ]
  }
  ```
  
  Conceptually, the model receives:
  
  ```text
  Message Type: MESSAGE
  Task name: /root
  Sender: /root/worker
  Payload:
  The protocol tests pass; I am checking the resume path now.
  ```
  
  ### `FINAL_ANSWER`
  
  `FINAL_ANSWER` is emitted when a child agent reaches a terminal state
  and reports its result to its parent. Completion payloads are already
  available locally, so the complete envelope is represented as plaintext
  rather than as a plaintext header plus encrypted content.
  
  For `/root/worker` completing work for the root agent, the request
  contains:
  
  ```json
  {
    "type": "agent_message",
    "author": "/root/worker",
    "recipient": "/root",
    "content": [
      {
        "type": "input_text",
        "text": "Message Type: FINAL_ANSWER\nTask name: /root\nSender: /root/worker\nPayload:\nNo regressions found."
      }
    ]
  }
  ```
  
  The model-visible form is:
  
  ```text
  Message Type: FINAL_ANSWER
  Task name: /root
  Sender: /root/worker
  Payload:
  No regressions found.
  ```
  
  Errored, shut down, and missing agents also use `FINAL_ANSWER`, with a
  terminal-status description in the payload.
  
  ## What changed
  
  - Render `NEW_TASK` or `MESSAGE` in
  `InterAgentCommunication::to_model_input_item`, based on whether the
  encrypted delivery starts a turn.
  - Replace the multi-agent v2 `<subagent_notification>` completion
  payload with a model-visible `FINAL_ANSWER` envelope.
  - Document `Task name`, `Sender`, and `Payload` consistently in the
  multi-agent developer instructions.
  - Prevent local-only history projections from treating an encrypted
  message's plaintext header as the complete assistant message.
  - Preserve rollout-trace interaction edges when an agent message
  contains both plaintext and encrypted content.
  
  Legacy multi-agent behavior remains unchanged.
  
  ## Verification
  
  - `just test -p codex-protocol`
  - `just test -p codex-rollout-trace`
  - `just test -p codex-web-search-extension`
  - `just test -p codex-core
  encrypted_multi_agent_v2_spawn_sends_agent_message_to_child`
  - `just test -p codex-core
  plaintext_multi_agent_v2_completion_sends_agent_message`
  - `just test -p codex-core
  multi_agent_v2_followup_task_completion_notifies_parent_on_every_turn`
  - `just test -p codex-core
  multi_agent_v2_completion_queues_message_for_direct_parent`

  jif · 2026-06-16 11:46:59 +02:00
  5b22a8e5b1
• [codex] Use local environment for user shell commands (#28163)

  ## Why
  
  User shell commands still read the legacy turn cwd and session shell
  even though execution context is now owned by selected turn
  environments. App-server also defines `thread/shellCommand` as a
  local-host escape hatch, so it must use an available local environment
  even when a remote environment is primary.
  
  ## What changed
  
  - Add `ResolvedTurnEnvironments::local()` to find the selected local
  environment.
  - Resolve the user shell command cwd and shell from that local
  `TurnEnvironment`.
  - Emit the standard `shell is unavailable in this session` error when no
  selected local environment or resolved local shell is available.
  - Add an integration test covering `/shell` without a local environment.
  
  ## Test plan
  
  - `just test -p codex-core
  user_shell_command_without_local_environment_emits_error`

  pakrym-oai · 2026-06-16 04:55:20 +00:00
  1e015884c5
• [codex] Add interruptible sleep tool (#28429)

  ## Why
  
  Models sometimes need to pause briefly while waiting for external work,
  but using a shell command for that delay ties the wait to a process and
  does not naturally resume when new turn input arrives.
  
  ## What changed
  
  - add a built-in `sleep` tool behind the under-development `sleep_tool`
  feature
  - accept a bounded `duration_ms` argument, matching the millisecond
  convention used by unified exec
  - end the sleep early when either steered user input or mailbox input
  arrives
  - include elapsed wall-clock time in completed and interrupted outputs
  - emit a dedicated core `SleepItem` through `item/started` and
  `item/completed`
  - expose the sleep item as app-server v2 `ThreadItem::Sleep` and retain
  it in reconstructed thread history
  - regenerate the configuration schema for the new feature flag
  - regenerate app-server JSON and TypeScript schema fixtures
  
  ## Test plan
  
  - `just test -p codex-core sleep_tool_follows_feature_gate`
  - `just test -p codex-core any_new_input_interrupts_sleep`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  sleep_emits_started_and_completed_items`

  pakrym-oai · 2026-06-15 21:39:21 -07:00
  08901fc8e1
• [codex] Bind shell snapshots to retained thread environments (#28421)

  ## Why
  
  Shell snapshots are currently session-scoped even though shell and cwd
  are properties of a selected turn environment. That makes snapshot
  refresh depend on separate session-cwd plumbing, prevents retained
  environments from retaining their snapshot work, and can make snapshot
  construction use a different shell than command execution.
  
  This follows #27955 by making the retained thread-environment service
  own environment snapshot lifecycles. Session configuration remains the
  requested selection state, while `ThreadEnvironments` remains the source
  of successfully resolved environments.
  
  ## What changed
  
  - Configure the shell-snapshot builder before initial environment
  resolution.
  - Start each local environment snapshot task when its `TurnEnvironment`
  is built and retain that shared task while environment ID and cwd still
  match.
  - Inherit retained environment snapshots into spawned child threads.
  - Carry the selected `TurnEnvironment` through shell runtimes so
  snapshot construction and command execution use the same
  environment-specific shell and cwd.
  - Load project instructions and warm plugins/skills after initial
  environment resolution.
  - Continue decoding invalid UTF-8 instruction files lossily without
  emitting a startup warning.
  - Keep requested selections in `SessionConfiguration`; failed or
  duplicate resolutions only affect the resolved environment snapshot.
  
  ## Validation
  
  - `cargo check -p codex-core --tests`
  - `just test -p codex-home instructions` (6 passed)
  - Focused environment, instruction, shell-snapshot, and user-shell tests
  (84 passed)
  - Focused shell-snapshot, user-shell, and unified-exec tests (126
  passed; two event-timing tests passed on retry)

  pakrym-oai · 2026-06-15 20:10:53 -07:00
  022f1221e8
• Use PathUri in filesystem permission paths for exec-server (#28165)

  ## Why
  
  Progress towards letting app-server and exec-server run on different
  platforms, specifically for sandbox configuration.
  
  ## What
  
  - Make the filesystem path containment hierarchy generic, defaulting to
  `AbsolutePathBuf` for now.
  - Have clients specify `AbsolutePathBuf` or `PathUri` directly where
  needed.
  - Use `PathUri` throughout exec-server filesystem protocol and trait
  boundaries.
  - Implement `From` for conversion to path URIs and `TryFrom` for
  fallible conversion to absolute paths through the generic type
  hierarchy.

  Adam Perry @ OpenAI · 2026-06-15 23:55:23 +00:00
  46f17930b6
• Respect blocking PostToolUse hooks in code mode (#28365)

  ## Summary
  
  Make blocking hook behavior reliable for tools invoked from code mode.
  
  Previously, a `PostToolUse` hook could block a completed tool result,
  but code mode would still return the original typed result to
  JavaScript. The hook appeared blocked in hook telemetry while the
  running script continued with the result.
  
  This change:
  
  - rejects the nested JavaScript tool promise when `PostToolUse` blocks
  - normalizes `decision: "block"` and exit code 2 to the same blocking
  behavior
  - surfaces the hook feedback as the rejected promise's error
  - adds end-to-end coverage for the relevant PreToolUse and PostToolUse
  interactions
  
  ## Hook semantics in code mode
  
  | Hook behavior | Code-mode result |
  |---|---|
  | PreToolUse block | Reject the promise before the tool executes |
  | PreToolUse `updatedInput` | Execute the rewritten invocation and
  return its result |
  | PostToolUse `decision: "block"` | Execute the tool, then reject the
  promise with the hook reason |
  | PostToolUse exit code 2 | Same behavior as `decision: "block"` |
  | PostToolUse `continue: false` | Preserve the existing feedback-only
  behavior; do not reject the promise |
  
  ## Test coverage
  
  Added or strengthened end-to-end coverage proving that:
  
  - a PreToolUse block rejects the JavaScript promise before execution
  - a PreToolUse input rewrite executes only the rewritten command
  - JavaScript receives the rewritten command's result
  - PostToolUse `decision: "block"` rejects after the command executes
  - PostToolUse exit code 2 has the same behavior
  - the hook observes the original completed tool response
  - the blocked original result does not reach JavaScript
  - existing direct-mode replacement behavior remains intact
  - `continue: false` without a reason produces deterministic fallback
  feedback

  Abhinav · 2026-06-15 15:12:26 -07:00
  d7f298fe20
• feat(core): add metadata field to ResponseItem (#28355)

  ## Description
  
  This PR adds an optional `metadata` field to `ResponseItem` for
  Responses API calls. Only mechanical plumbing, no actual values
  populated and sent yet. Turns out just adding a new field to
  `ResponseItem` has quite a large blast radius already.
  
  This change is backwards compatible because `metadata` is optional and
  omitted when absent, so existing response items and rollout history
  without it still deserialize and requests that do not set it keep the
  same wire shape. For provider compatibility, we strip out `metadata`
  before non-OpenAI Responses requests so Azure and AWS Bedrock never see
  this field.
  
  My followup PR here will actually make use of it to start storing and
  passing along `turn_id`: https://github.com/openai/codex/pull/28360
  
  ## What changed
  
  - Added `ResponseItemMetadata` with optional `turn_id`, plus optional
  `metadata` on Responses API item variants and inter-agent communication.
  - Preserved item metadata through response-item rewrites such as
  truncation, missing tool-output synthesis, compaction history
  rebuilding, visible-history conversion, rollout/resume, and generated
  app-server schemas/types.
  - Strip item metadata from non-OpenAI Responses requests while
  preserving it for OpenAI-shaped requests.
  - Updated the mechanical fixture/test construction churn required by the
  new optional field.

  Owen Lin · 2026-06-15 15:05:28 -07:00
  040dafa32d
• core: cache the tool search handler per session (#27258)

  ## Why
  
  Tool router construction rebuilds the deferred-tool BM25 index during
  session initialization and before each sampling continuation, even when
  the searchable tool metadata is unchanged. Local profiling measured
  `append_tool_search_executor` at roughly 113 ms per continuation, making
  repeated index construction the largest measured router-building cost.
  
  ## What changed
  
  - Add a session-scoped `ToolSearchHandlerCache` so continuations and
  user turns can reuse the existing handler.
  - Key reuse on the complete ordered `Vec<ToolSearchInfo>`, rebuilding
  when searchable text, loadable tool specs, source metadata, or ordering
  changes.
  - Build handlers outside the cache lock and recheck before publishing
  them, avoiding holding the mutex during index construction.
  
  ## Verification
  
  - `cache_reuses_identical_search_infos_and_rebuilds_changed_inputs`
  covers exact cache reuse and invalidation when the ordered search
  metadata changes.
  - Local rollout profiling showed the initial router build populating the
  cache and unchanged later continuations reusing it:
    - uncached: 118 ms median across 14 spans from 3 rollouts
    - cached: 4 ms median across 12 spans from 3 rollouts

  mchen-oai · 2026-06-15 14:48:30 -07:00
  af99f6a72f
• core: let steer interrupt wait_agent (#28341)

  ## Why
  
  `wait_agent` can block for a long timeout while waiting for sub-agent
  mailbox activity. Although same-turn user steer is accepted during that
  tool call, the input remains pending until the wait returns, so an
  explicit request to change direction can appear unresponsive.
  
  ## What changed
  
  - Notify active `wait_agent` calls when user input is steered into the
  current turn.
  - Check for already-pending steer input when subscribing so input that
  races with tool startup is not missed.
  - Distinguish mailbox activity, steered input, and timeout outcomes,
  returning `Wait interrupted by new input.` for the steer path.
  - Update the `wait_agent` tool description to document the early-return
  behavior.
  
  ## Testing
  
  - `just test -p codex-core input_queue_`
  - `just test -p codex-core wait_agent`
  
  The coverage includes steer notification before and after subscription,
  plus an end-to-end test that verifies the interrupted wait result and
  steered user input are both included exactly once in the follow-up model
  request.

  jif · 2026-06-15 20:08:15 +02:00
  ee40dddbf6
• [codex] remove stale PathExt import (#28344)

  ## Why
  
  `main` fails dev-profile Cargo and Bazel Clippy builds because
  `core/src/tools/runtimes/mod_tests.rs` imports `PathExt` after its last
  use was removed. With warnings denied, that stale import prevents
  `codex-core` test targets from compiling across platforms.
  
  ## What changed
  
  Remove the unused `PathExt` import. Remaining `.abs()` calls in the
  module operate on `PathBuf` and continue to use `PathBufExt`.
  
  ## Validation
  
  - `just fmt`
  - Focused `codex-core` test compile attempted; blocked locally by disk
  exhaustion before compilation completed. The CI failure itself is the
  unused-import diagnostic this change removes.

  pakrym-oai · 2026-06-15 09:56:21 -07:00
  5e58b6d77f
• [codex] simplify memory read metrics (#28164)

  ## Why
  
  Memory read telemetry currently reconstructs the executable shell
  command after a tool call finishes. That duplicates shell, login-policy,
  and cwd resolution owned by the tool handlers, and can diverge from the
  environment-specific command that unified exec actually ran.
  
  ## What changed
  
  - Expose the existing restricted shell-script parser directly for raw
  script text.
  - Parse `shell_command` and `exec_command` input into plain command argv
  before classifying memory reads.
  - Preserve all-or-nothing safe-command validation for multi-command
  scripts.
  - Remove cwd resolution, shell selection, and the unnecessary async
  boundary from memory read metric emission.
  
  ## Testing
  
  - `just test -p codex-shell-command`
  - `cargo check -p codex-core`

  pakrym-oai · 2026-06-15 08:28:02 -07:00
  42ad752f36
• [codex] simplify shell snapshot ownership (#27756)

  ## Why
  
  Shell snapshot lifecycle state was split between `Shell` and
  `SessionServices`: `Shell` carried the receiver while session code
  exposed and forwarded the raw sender. That coupled shell identity to
  mutable snapshot state and made refresh, inheritance, and file lifetime
  harder to reason about.
  
  ## What changed
  
  - make each `Arc<ShellSnapshot>` represent one cwd-specific snapshot
  generation
  - store the active generation in `SessionServices` with `ArcSwapOption`
  - have construction start the background build and expose only a
  cwd-validated snapshot path
  - use `ShellSnapshotFile` ownership to delete snapshot files
  automatically
  - pass snapshot paths explicitly to shell runtimes instead of storing
  snapshot state on `Shell`
  - preserve inherited and in-flight generations by pinning their `Arc`
  while they are in use
  
  ## Test plan
  
  - `cargo check -p codex-core --lib`
  - `just test -p codex-core 'shell_snapshot::tests'`
  - `just test -p codex-core
  shell_command_snapshot_still_intercepts_apply_patch`
  - `just test -p codex-core
  shell_snapshot_deleted_after_shutdown_with_skills`

  pakrym-oai · 2026-06-15 08:18:13 -07:00
  1aa3e432cc
• Represent dynamic tools with explicit namespaces internally (#27365)

  Follow-up to #27356.
  
  ## Stack note
  
  This PR changes Codex's internal dynamic-tool shape while leaving
  `thread/start` unchanged. App-server therefore converts the existing
  per-tool input into explicit functions and namespaces before passing it
  to core.
  
  [#27371](https://github.com/openai/codex/pull/27371) updates
  `thread/start` to use the same explicit shape and removes this temporary
  conversion.
  
  ## Why
  
  Dynamic tools repeat namespace metadata on every function. Core should
  keep one explicit namespace with its member tools so descriptions and
  membership stay consistent across sessions and runtime planning.
  
  ## What changed
  
  - Represent dynamic tools as top-level functions or explicit namespaces
  in protocol and session state.
  - Read old flat rollout metadata and write the canonical hierarchy.
  - Flatten namespace members only when registering callable tools.
  - Keep `thread/start.dynamicTools` flat for now and normalize it at the
  app-server boundary.
  
  New builds can read old rollout metadata. Older builds cannot read newly
  written hierarchical metadata.
  
  ## Test plan
  
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-protocol
  session_meta_normalizes_legacy_dynamic_tools`
  - `just test -p codex-core
  resume_restores_dynamic_tools_from_rollout_with_sqlite_enabled`
  - `just test -p codex-core
  tool_search_returns_deferred_dynamic_tool_and_routes_follow_up_call`
  - `just test -p codex-core code_mode_can_call_hidden_dynamic_tools`
  - `just test -p codex-tools`

  sayan-oai · 2026-06-15 08:06:14 -07:00
  a292faae5a
• [codex] update multi-agent v2 prompts (#28283)

  ## Summary
  
  - align the default multi-agent v2 root and subagent hints with the
  evaluated prompt guidance for direct collaboration-tool calls, parallel
  delegation, and shared workspaces
  - keep the current `interrupt_agent` tool name and existing
  concurrency-hint placement, with the explicit no-spawn instruction last
  - document the context tradeoff between `fork_turns="none"` and
  `fork_turns="all"` in the v2 `spawn_agent` description
  - extend the focused prompt and tool-surface tests
  
  ## Why
  
  The evaluated multi-agent prompt includes operational guidance that is
  missing from the current Codex defaults. This applies that guidance to
  the current tool surface without restoring stale `close_agent` or
  duplicated concurrency wording.
  
  ## User impact
  
  Multi-agent v2 receives clearer instructions about when and how to
  parallelize work, how agent workspaces interact, and how `fork_turns`
  affects subagent context. The existing default opt-out behavior remains
  in place.
  
  ## Testing
  
  - `just fmt`
  - `just test -p codex-core
  multi_agent_v2_default_usage_hints_use_configured_thread_cap`
  - `just test -p codex-core
  multi_agent_feature_selects_one_agent_tool_family`

  jif · 2026-06-15 12:21:02 +02:00
  127224cacc
• [codex] exec-server honors remote environment cwd and shell (#28122)

  ## Why
  
  Next slice needed to make progress on the `remote_env_windows` test is
  to support passing a Windows cwd for the remote environment and using
  that environment's native shell. This lets the test run a real Windows
  process instead of only recording an early path or shell mismatch.
  
  ## What
  
  - change `TurnEnvironmentSelection.cwd` from `AbsolutePathBuf` to
  `PathUri`
  - convert local cwd values to URIs when constructing selections
  - preserve a remote primary cwd instead of replacing it with the local
  legacy fallback
  - prefer the selected environment's discovered shell for unified exec,
  falling back to the session shell when unavailable
  - convert back to a host-native absolute path at current native-only
  consumer boundaries
  - reject or deny unsupported foreign cwd values at the existing
  request-permissions boundary, with TODOs for its future migration
  - extend the hermetic Wine test to execute Windows PowerShell in
  `C:\windows` and verify successful process completion
  - record the current app-server rejection against the same Wine-backed
  remote Windows fixture when its cwd is supplied as a native Windows path

  Adam Perry @ OpenAI · 2026-06-14 06:07:46 +00:00
  efbd00f21f
• [codex] make PathUri::from_abs_path infallible (#27976)

  ## Why
  
  `PathUri::from_abs_path` can fail for absolute paths that do not have a
  normal `file:` URI representation, forcing filesystem call sites to
  handle a conversion error even though the original path can be preserved
  losslessly.
  
  ## What
  
  Make `from_abs_path` infallible and migrate its callers. Unrepresentable
  paths use `file:///%00/bad/path/<base64>`, encoding Unix bytes or
  Windows UTF-16LE; `to_abs_path` validates and decodes that fallback. The
  leading encoded null reserves a namespace that cannot collide with a
  real Unix or Windows path, and fallback URIs remain opaque to lexical
  path operations.
  
  ## Validation
  
  Added path-URI coverage for Unix null and non-UTF-8 paths, Windows
  device/verbatim and non-Unicode paths, serialization, malformed
  fallbacks, opaque lexical operations, invalid native payloads, and
  literal `/bad/path` collision resistance.

  Adam Perry @ OpenAI · 2026-06-12 16:58:42 -07:00
  968a3ac9c1
• sandboxing: migrate cwd inputs to PathUri (#27816)

  ## Why
  
  Sandbox cwd values can cross app-server and exec-server host boundaries.
  They should retain URI semantics until the receiving host validates them
  instead of being interpreted early as native paths.
  
  ## What
  
  - Carry `PathUri` through filesystem sandbox contexts, sandbox commands,
  and transform inputs.
  - Convert command and policy cwd once in `SandboxManager::transform`,
  then keep launch requests native.
  - Preserve sandbox cwd over remote filesystem transport and reject
  non-native URIs without fallback.
  - Cache paired native/URI turn-environment cwd values during migration,
  with immutable access to keep them synchronized.
  - Extend existing protocol, forwarding, transform, and core runtime
  tests.

  Adam Perry @ OpenAI · 2026-06-12 11:38:01 -07:00
  52a50aec70
• chore: prompt MAv2 (#27919)

  Prompt update of MAv2

  jif · 2026-06-12 20:17:12 +02:00
  84520225b9
• Keep request_user_input direct-model only (#27316)

  ## Why
  
  `request_user_input` has direct blocking semantics when invoked by the
  model. When it is exposed as a nested code-mode tool, the call has to
  flow through code-mode waiting and continuation behavior instead, which
  is not the behavior we want for this user-input request surface.
  
  ## What changed
  
  - Mark `request_user_input` with `ToolExposure::DirectModelOnly` when
  registering the core utility tool.
  - Keep `request_user_input` direct-model visible, including in
  code-mode-only planning.
  - Add focused `spec_plan_tests` coverage that verifies
  `request_user_input` remains visible and registered as
  direct-model-only, while it is omitted from the nested code-mode tool
  description.
  
  No active goal suppression or runtime unavailability behavior is
  included in this PR.
  
  ## Validation
  
  - No new build/test run for this housekeeping pass, per maintainer
  request.
  - Earlier targeted run, confirmed from session context: `just test -p
  codex-core request_user_input` passed.

  Shijie Rao · 2026-06-11 23:23:44 -07:00
  7a19b14229
• Add request_user_input auto-resolution window contract (#27256)

  ## Why
  
  `request_user_input` is moving beyond its original plan-mode-only
  workflow, and future default/goal-mode usage needs a way for the model
  to ask helpful but non-blocking questions without forcing the turn to
  wait forever. This PR adds an explicit `autoResolutionMs` contract so a
  later client/runtime change can auto-resolve unanswered prompts after a
  bounded window while leaving truly blocking questions unchanged.
  
  This is contract plumbing only; it does not implement the client-side
  timer or auto-selection behavior, and the model-facing description
  treats the field as reserved unless the current runtime explicitly
  supports auto-resolution.
  
  ## What Changed
  
  - Added optional `autoResolutionMs` to the model-facing
  `request_user_input` args and core `RequestUserInputEvent`.
  - Added model-facing schema text for `autoResolutionMs` while marking it
  reserved for runtimes that explicitly support auto-resolution.
  - Bounds `autoResolutionMs` to `60_000..=240_000` ms during argument
  normalization by clamping out-of-range model-provided values.
  - Propagated the field through app-server v2
  `ToolRequestUserInputParams`, app-server request forwarding, generated
  TypeScript, and JSON schema fixtures.
  - Updated app-server, core, protocol, and TUI call sites/tests so
  omitted values preserve existing `None`/`null` behavior and coverage
  verifies a `Some(60_000)` round trip.
  
  ## Verification
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-core request_user_input`
  - `just test -p codex-app-server request_user_input_round_trip`
  - `just test -p codex-tui request_user_input`
  - `just test -p codex-protocol`

  Shijie Rao · 2026-06-11 22:30:41 -07:00
  216ce03031
• [codex] Remove async_trait from first-party code (#27475)

  ## Why
  
  First-party async traits should expose their `Send` contracts explicitly
  without requiring `async_trait`. This completes the migration pattern
  established in #27303 and #27304.
  
  ## What changed
  
  - Replaced the remaining first-party `async_trait` traits with native
  return-position `impl Future + Send` where statically dispatched and
  explicit boxed `Send` futures where object safety is required.
  - Kept implementations behavior-preserving, outlining existing async
  bodies into inherent methods where that keeps the diff reviewable.
  - Removed all direct first-party `async-trait` dependencies and the
  workspace dependency declaration.
  - Added a cargo-deny policy that permits `async-trait` only through the
  remaining transitive wrapper crates.
  - Updated `rand` from 0.8.5 to 0.8.6 to resolve RUSTSEC-2026-0097 and
  keep the full cargo-deny check passing.
  
  ## Validation
  
  - `just test -p codex-exec-server`: 216 passed, 2 skipped.
  - `just test -p codex-model-provider`: 39 passed.
  - `just test -p codex-core` and `just test`: changed tests passed;
  remaining failures are environment-sensitive suites unrelated to this
  migration.
  - `cargo deny check`
  - `just fix`
  - `just fmt`
  - `cargo shear`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 18:16:39 -07:00
  5a56caf18c