3672 Commits

• feat(app-server): filter threads by parent (#26662)

  ## Why
  
  Clients that display or coordinate spawned subagents need an
  authoritative snapshot of a thread's immediate spawned children when
  they connect to app-server or recover after missing live events.
  `thread/list` cannot query by parent, so clients must otherwise scan
  unrelated threads or reconstruct relationships from rollout history and
  transient events.
  
  The direct spawn relationship already exists in persisted
  `thread_spawn_edges` state. Review and Guardian threads do not
  participate in that lifecycle and are intentionally outside this
  filter's scope.
  
  ## What changed
  
  This adds an experimental `parentThreadId` filter to `thread/list`.
  Parent-filtered requests return direct spawned children from persisted
  state while preserving the existing response shape, explicit filters,
  sorting, and timestamp-only cursor behavior. The lookup does not read
  rollout transcripts or recursively return descendants.
  
  Supersedes #25112 with the narrower `thread/list` filter approach.
  
  ## How it works
  
  1. An experimental client passes a valid thread ID as `parentThreadId`.
  2. App-server routes the list through the existing thread-store and
  state-database boundaries.
  3. SQLite selects threads whose IDs have a direct persisted spawn edge
  from that parent.
  4. Omitted provider and source filters include all values; explicit
  filters keep ordinary `thread/list` semantics.
  5. Grandchildren, Review threads, and Guardian threads are excluded.
  
  ## Verification
  
  State (144 tests), rollout (69 tests), and focused app-server
  thread-list (31 tests) suites passed. Scoped Clippy checks and
  repository formatting also passed. Coverage includes direct spawned
  children, omitted grandchildren, pagination, malformed IDs, mixed source
  kinds, explicit filters, and operation without rollout files.

  Brent Traut · 2026-06-14 00:14:26 -07:00
  dfd03ea01b
• [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
• build: run buildifier from just fmt (#28125)

  ## Intent
  
  Keep Bazel and Starlark files consistently formatted without requiring
  contributors to install or version buildifier themselves.
  
  ## Implementation
  
  - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier
  v8.5.1.
  - Run buildifier from the shared `just fmt` and `just fmt-check` driver,
  with Windows-safe explicit DotSlash invocation.
  - Provision DotSlash in formatting CI and contributor devcontainers, and
  document the source-build prerequisite.
  - Apply the initial mechanical buildifier formatting baseline.

  Adam Perry @ OpenAI · 2026-06-13 21:43:39 -07:00
  740c4f269d
• [codex] Dedupe plugin MCPs by app declaration name (#27607)

  ## Context
  
  This is the next step in the plugin auth-routing stack. The earlier PRs
  make `PluginsManager` auth-aware and move the broad App/MCP surface
  decision into that layer. This PR narrows the ChatGPT/SIWC behavior so
  we only hide a plugin MCP server when it conflicts with an App
  declaration of the same name.
  
  In product terms: if a plugin exposes both an App route and MCP route
  for `foo`, ChatGPT/SIWC sessions should use the App route for `foo`. If
  the same plugin also exposes a separate MCP server like `foo2`, that MCP
  server should remain available.
  
  ```json
  // .app.json
  {
    "apps": {
      "foo": {
        "id": "connector_abc"
      }
    }
  }
  ```
  
  ```json
  // .mcp.json
  {
    "mcpServers": {
      "foo": {
        "url": "https://mcp.foo.com/mcp"
      },
      "foo2": {
        "url": "https://mcp.foo2.com/mcp"
      }
    }
  }
  ```
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - Preserve App declaration names in loaded plugin metadata.
  - Keep public effective App outputs as deduped connector IDs for
  existing callers.
  - For ChatGPT/SIWC, suppress only plugin MCP servers whose names match
  declared App names.
  
  ## Validation
  
  ```bash
  cargo fmt --all
  cargo test -p codex-core-plugins plugin_auth_projection
  cargo test -p codex-core-plugins effective_apps
  cargo test -p codex-core-plugins read_plugin_for_config_installed_git_source_reads_from_cache_without_cloning
  cargo test -p codex-core explicit_plugin_mentions_use_apps_for_chatgpt_dual_surface_plugins
  cargo test -p codex-core explicit_plugin_mentions_keep_non_conflicting_mcp_for_chatgpt_auth
  cargo test -p codex-app-server --test all plugin_install_filters_disallowed_apps_needing_auth
  git diff --check
  ```
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  felixxia-oai · 2026-06-13 17:53:09 -07:00
  51316ead4a
• [codex] Carry exec-server cwd as PathUri (#28032)

  ## Why
  
  This is the second-to-last place in the exec-server protocol that needs
  to migrate to URIs to support cross-OS operation.
  
  ## What
  
  - Change `ExecParams.cwd` to `PathUri`.
  - Keep the cwd URI-shaped through core and rmcp producers, converting it
  to `AbsolutePathBuf` only in `LocalProcess::start_process`.
  - Reject non-native cwd URIs before launch and update the affected
  protocol documentation and call sites.

  Adam Perry @ OpenAI · 2026-06-13 20:56:42 +00:00
  0fed4497f5
• [codex] Send turn state through compact requests (#28002)

  ## Context
  
  Inline compaction is part of the active logical turn. Compact requests
  and the sampling requests around them should use the same turn state,
  including when compaction is the first request to establish it.
  
  ## Change
  
  Pass the turn-scoped `OnceLock` directly to inline v1 compaction so
  `/responses/compact` includes an established value in the existing HTTP
  header. Capture `x-codex-turn-state` from the compact response into that
  same lock, allowing pre-turn compact to establish the value that
  subsequent sampling reuses.
  
  V2 compact already uses the normal Responses HTTP/WebSocket path and
  continues to share the same `OnceLock` without separate plumbing. The
  first returned value wins for the logical turn.
  
  ## Test plan
  
  Integration coverage verifies that:
  
  - pre-turn v1 compact can establish state for the first sampling request
  - inline v1 compact receives established state over HTTP
  - inline v2 compact reuses established state over HTTP
  - inline v2 compact reuses established state over WebSocket
  
  CI validates the full change.

  Ahmed Ibrahim · 2026-06-13 01:27:58 -07:00
  f297b9f07d
• [codex] Send request-scoped turn state over WebSocket (#27996)

  ## Context
  
  Turn state is scoped to one logical turn, but the WebSocket path
  currently exchanges it through upgrade headers, which are scoped to the
  physical connection. A connection may be reused across turns, so its
  handshake cannot represent the turn lifecycle reliably.
  
  ## Change
  
  Exchange turn state on each WebSocket response request instead:
  
  - send an established value in `response.create.client_metadata`
  - read the returned value from the existing `response.metadata` event
  - retain the first value in the turn-scoped `ModelClientSession`
  `OnceLock`
  - start the next logical turn without state, even when it reuses the
  same WebSocket connection
  
  This gives WebSocket requests the same first-value-wins contract as the
  existing HTTP path.
  
  ## Test plan
  
  Integration coverage verifies that:
  
  - WebSocket replays returned state on same-turn follow-ups
  - later response metadata does not replace the first value
  - state resets at the logical turn boundary without requiring a
  reconnect
  
  CI validates the full change.
  
  ## Stack
  
  This is 1/2. #28002 builds on this request-scoped transport to carry
  established state through compact requests.

  Ahmed Ibrahim · 2026-06-13 00:44:39 -07:00
  640d61b121
• [codex] Add hermetic Wine exec-server test (#27937)

  ## Why
  
  We want to make it possible for an app-server orchestrator on one OS to
  control an exec-server on another host running a different OS. In
  practice this kinda already works if you get lucky and the two hosts
  have the same path format, but we mangle quite a lot of operations if
  either end is Windows.
  
  This test starts exercising that interaction, although right now the
  initial bootstrap fails. Future changes will expand the test's
  assertions to match improved support.
  
  ## What
  
  Stacked on #27964. This adds a small Windows exec-server fixture and a
  Linux protocol smoke test using the reusable Wine harness, covering
  Windows environment discovery, non-TTY `cmd.exe` execution, output, exit
  status, and working directory.
  
  Once we've got the full codex binary cross-building under Bazel we could
  consider moving to the real binary instead of the stripped down
  exec-server-only binary used here.

  Adam Perry @ OpenAI · 2026-06-12 20:20:23 -07:00
  9d938a46d9
• feat(app-server): enforce managed remote control disable (#27961)

  ## Why
  
  Managed deployments need a reliable deny gate for remote control.
  Persisted enablement and explicit startup requests currently remain able
  to start the transport, while the removed `features.remote_control` key
  is intentionally only a compatibility no-op.
  
  This adds a dedicated requirement that administrators can use to force
  remote control off without deleting the user's persisted preference.
  Removing the requirement and restarting restores the prior choice.
  
  ## What Changed
  
  - Added top-level `allow_remote_control` requirements parsing, sourced
  layer precedence, debug output, and `configRequirements/read` exposure
  as `allowRemoteControl`.
  - Added a typed transport policy captured from the startup requirements
  snapshot. Managed disable forces the initial state to disabled and
  prevents enrollment, refresh, connection, and persisted-preference
  mutation.
  - Rejected every `remoteControl/*` RPC before parameter deserialization
  with JSON-RPC `-32600` and `remote control is disabled by managed
  requirements`.
  - Preserved the existing disabled status notification and the previous
  behavior when the requirement is `true` or omitted.
  - Regenerated app-server protocol schemas and documented the new
  requirement.
  
  ## Verification
  
  - Confirmed all remote-control RPCs, including a malformed request,
  return the managed-policy error while the initial status notification
  remains `disabled`.
  - Confirmed explicit ephemeral startup and persisted enablement make no
  backend connection and leave the SQLite preference unchanged.
  - Confirmed `allow_remote_control = true` does not enable or block
  remote control and `configRequirements/read` returns
  `allowRemoteControl: false` for the deny policy.
  
  Related issue: N/A (managed-policy hardening).

  Anton Panasenko · 2026-06-12 20:10:12 -07:00
  b9dc3b7a8b
• [codex] Gate plugin MCP servers by auth route (#27459)

  ## Context
  
  Some plugins expose both Apps and MCP servers. This PR moves auth-aware
  surface projection into `core-plugins::PluginsManager`, so callers get a
  consistent effective plugin view. Later PRs narrow the conflict rule and
  update listing/install paths.
  
  The high level goal of this PR is to set up the plumbing to
  conditionally filter App/MCP in the plugin manager layer. We start by
  removing MCP servers when using SIWC/Codex-backend auth, and removing
  Apps when using API-key-style auth.
  
  This PR is now stacked on #27652, which contains only the constructor
  plumbing for seeding `PluginsManager` with the current auth mode.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - API-key/non-ChatGPT routes hide plugin Apps and keep plugin MCPs.
  - ChatGPT/SIWC with Apps enabled keeps plugin Apps and suppresses MCPs
  for dual-surface plugins.
  - MCP-only plugins stay available for ChatGPT/SIWC sessions.
  - Cached plugin load outcomes are re-projected when auth mode changes.
  
  ## Validation
  
  ```bash
  cargo test -p codex-core-plugins plugin_auth_projection
  cargo test -p codex-core list_tool_suggest_discoverable_plugins
  git diff --check
  ```

  felixxia-oai · 2026-06-12 19:42:11 -07:00
  5d7db08b61
• [codex] Add auth mode to plugin manager constructor (#27652)

  ## Context
  
  Plugins can expose more than one way for Codex to use them: App
  connectors for ChatGPT/SIWC-backed sessions and MCP servers for API key
  login sessions. The broader goal is to make `PluginsManager` the place
  that understands which plugin surfaces should be visible for the current
  auth route, so callers do not each have to make that decision
  themselves.
  
  This PR is the small setup step for that work. It lets the plugin
  manager be created with the current `AuthMode`, which gives the followup
  auth routing PRs the information they need without relying on setter
  injection.
  
  ## Stack
  
  - PR1: #27652 seed plugin manager auth at construction.
  - PR2: #27459 route plugin surfaces by auth mode.
  - PR3: #27607 dedupe plugin MCP servers by App declaration name.
  - PR4: #27602 preserve plugin Apps in connector listings.
  - PR5: #27461 skip install-time plugin MCP OAuth for matching App
  routes.
  
  ## Summary
  
  - Let `PluginsManager::new_with_restriction_product` accept an initial
  `AuthMode`.
  - Keep `PluginsManager::new` behavior unchanged for ordinary callers.
  
  ## Validation
  
  ```bash
  cargo test -p codex-core-plugins plugins_manager_tracks_auth_mode
  cargo test -p codex-core list_tool_suggest_discoverable_plugins
  git diff --check
  ```
  
  ---------
  
  Co-authored-by: Xin Lin <xl@openai.com>

  felixxia-oai · 2026-06-12 18:00:31 -07:00
  aef40ad91f
• [codex] Limit app-based plugin suggestions to remote catalogs (#27988)

  ## Summary
  
  - Keep local plugin suggestions bounded to fallback and explicitly
  configured plugins.
  - Preserve app-overlap recommendations for remote plugins using cached
  catalog metadata.
  - Remove the WSL-specific local discovery exception and move
  manager-owned discovery tests into `codex-core-plugins`.
  
  ## Why
  
  Local curated marketplaces were allowlisted before plugin detail
  loading, so every uninstalled candidate could be deep-read before its
  app IDs were checked. That caused per-turn reads of candidate plugin
  manifests, skills, app configs, hooks, and MCP configs, which is
  especially expensive on slow disks.
  
  Remote discovery does not need those local candidate reads because app
  IDs are already available in the cached remote catalog. Installed local
  plugins are still loaded when needed to determine the user's installed
  app IDs.
  
  ## Validation
  
  - `just fmt`
  - `just test -p codex-core-plugins discoverable::tests` (13 passed)
  - `just test -p codex-core plugins::discoverable::tests` (4 passed)
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `git diff --check`

  xl-openai · 2026-06-12 17:51:09 -07:00
  044c1420a1
• [codex] add latency tracing spans (#27710)

  ## Why
  
  We have some large gaps in our thread start, resume, and pre-sampling
  traces that make it hard to tell where latency is coming from.
  
  ## What Changed
  
  - Added coarse spans around thread start/resume, turn context
  construction, rollout reconstruction, skill/plugin loading, and tool
  preparation.
  - Added a breakdown of discoverable-tool preparation across connector
  loading, plugin discovery, and local plugin details.
  
  ## Testing
  
  - `cargo check -p codex-app-server -p codex-core -p codex-core-skills -p
  codex-core-plugins`
  - Built the app-server locally and exercised thread start, first turn,
  follow-up turn, server restart, thread resume, and a resumed turn.

  rphilizaire-openai · 2026-06-12 17:11:32 -07:00
  bacfc5e4c0
• [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
• [codex] Let generic test turns inherit their environment (#27972)

  ## Why
  
  The paired thread-environment migration changed several generic test
  turn helpers from supplying a fallback cwd to explicitly selecting the
  local environment. That changes their meaning under
  `build_with_remote_env()`: remote-only fixtures cannot resolve the
  forced local selection, so the tests fail before exercising apply-patch,
  RMCP, unified-exec, or view-image behavior.
  
  Generic helpers should inherit the environment selected by their
  fixture. Tests that intentionally exercise local routing continue to
  select the local environment explicitly.
  
  ## What changed
  
  - Remove forced `local_selections(...)` overrides from the generic
  apply-patch, RMCP, unified-exec, and view-image turn helpers.
  - Remove the imports made unused by those deletions.
  
  ## Testing
  
  - Not run locally; this is a test-fixture-only change and the `full-ci`
  branch will exercise the affected remote shards.

  pakrym-oai · 2026-06-12 16:37:14 -07:00
  7ebd10783b
• Add Guardian catalog diagnostics metadata (#27109)

  ## Why
  
  We need request-level evidence for Guardian cases where
  `codex-auto-review` is missing from the client-side model catalog and
  the review falls back to the parent model.
  
  ## What changed
  
  - Add `guardian_catalog_contains_auto_review` to Guardian Responses API
  client metadata.
  - Add `guardian_model_provider_id` to Guardian Responses API client
  metadata.
  - Keep review-session metadata optional so callers without metadata
  preserve the existing `None` path.
  - Add tests for override, normal preferred-model, and
  missing-auto-review-catalog behavior.
  
  ## Validation
  
  - `just test -p codex-core
  guardian_review_records_missing_auto_review_model_in_request_metadata`
  - `just test -p codex-core
  guardian_review_uses_model_catalog_override_when_preferred_review_model_exists`
  - `just test -p codex-core
  guardian_review_uses_preferred_review_model_without_model_catalog_override`
  - `git diff --check origin/main`

  Won Park · 2026-06-12 15:50:30 -07:00
  0605f9c14f
• [codex] add roles to realtime append text (#27936)

  ## Summary
  
  Add an explicit `user` or `developer` role to
  `thread/realtime/appendText` and propagate it through the realtime input
  queue into `conversation.item.create`. Older JSON clients that omit the
  field continue to default to `user`.
  
  This lets app-provided context such as memory retain developer authority
  without bypassing app-server through a renderer-owned data channel. The
  app-server schemas, API documentation, and focused protocol and
  websocket coverage are updated with the new contract.
  
  The Codex Apps consumer is tracked in
  [openai/openai#1025261](https://github.com/openai/openai/pull/1025261).

  Alex Gamble · 2026-06-12 15:05:37 -07:00
  216dee1189
• feat: use encrypted local secrets for MCP OAuth (#27541)

  ## Summary
  
  - store MCP OAuth credentials in the configured auth credential backend
  - support encrypted-local OAuth storage, including legacy keyring
  migration
  - propagate the credential backend through MCP refresh, session, CLI,
  and app-server paths
  
  ## Stack
  
  1. #27504 — config and feature flag
  2. #27535 — auth-specific secret namespaces
  3. #27539 — encrypted CLI auth storage
  4. this PR — encrypted MCP OAuth storage
  
  This is a parallel review stack; the original #17931 remains unchanged.
  
  ## Tests
  
  - `just test -p codex-rmcp-client` (the transport round-trip test passed
  after building the required `codex` binary and retrying)
  - `just test -p codex-mcp`
  - `just test -p codex-app-server
  refresh_config_uses_latest_auth_keyring_backend`
  - `just test -p codex-core
  refresh_mcp_servers_is_deferred_until_next_turn`
  - `just test -p codex-cli mcp`
  - `just fix -p codex-rmcp-client -p codex-mcp -p codex-core -p codex-cli
  -p codex-app-server -p codex-protocol`
  - `just bazel-lock-check`

  Celia Chen · 2026-06-12 22:03:51 +00:00
  9915d34684
• feat: use encrypted local secrets for CLI auth (#27539)

  ## Why
  
  Windows Credential Manager limits generic credential blobs to 2,560
  bytes. Large serialized ChatGPT auth payloads can exceed that limit, so
  keyring-mode CLI auth needs a backend that keeps only the encryption key
  in the OS keyring and stores the payload in Codex's encrypted
  local-secrets file.
  
  This is the third PR in the encrypted-auth stack:
  
  1. #27504 — feature and config selection
  2. #27535 — auth-specific local-secrets namespaces
  3. This PR — CLI auth implementation and activation
  4. MCP OAuth implementation and activation
  
  ## What Changed
  
  - Added encrypted CLI-auth storage using the `CliAuth` secrets
  namespace.
  - Preserved direct keyring storage for platforms/configurations where it
  remains selected.
  - Selected the backend consistently for login, logout, refresh,
  device-code login, auth loading, and login restrictions.
  - Threaded resolved bootstrap/full config through CLI, exec, TUI,
  app-server account handling, cloud config, and cloud tasks.
  - Removed stale `auth.json` fallback data after successful encrypted
  saves and removed encrypted, direct-keyring, and fallback data during
  logout.
  - Added storage and integration coverage for both direct and encrypted
  keyring modes.
  
  MCP OAuth persistence is intentionally left to the next PR.
  
  ## Validation
  
  - `just test -p codex-login` — 131 passed
  - `just test -p codex-cli` — 280 passed
  - `just test -p codex-app-server v2::account` — 25 passed
  - `just test -p codex-cloud-config service` — 21 passed, 7 skipped
  - `just fix -p codex-login`
  - `just fix -p codex-cli`
  - `just fmt`

  Celia Chen · 2026-06-12 21:23:50 +00:00
  56c97e3b5c
• Support plaintext agent messages (#27830)

  ## Why
  
  Multi-agent v2 `send_message` deliveries already reach the receiving
  model as typed `agent_message` items with encrypted content.
  Child-completion notifications are generated by Codex itself, so their
  content is plaintext and previously fell back to a serialized JSON
  envelope inside an assistant message.
  
  With plaintext `input_text` supported for `agent_message`, both delivery
  paths can use the same model-visible type while preserving explicit
  author and recipient metadata.
  
  ## What changed
  
  - add plaintext `input_text` support to `AgentMessageInputContent` and
  regenerate the affected app-server schemas
  - preserve `InterAgentCommunication` as structured mailbox input instead
  of converting it to assistant text
  - record delivered communications as typed `agent_message` history items
  - persist a dedicated rollout item so local delivery metadata such as
  `trigger_turn` remains available without leaking into the Responses
  request
  - reconstruct typed agent messages on resume and preserve fork-turn
  truncation behavior
  - remove request-time assistant-content parsing
  - preserve plaintext and encrypted inter-agent deliveries in stage-one
  memory inputs
  - normalize and link plaintext and encrypted agent messages in rollout
  traces without treating inbound messages as child results
  - cover the real MultiAgent V2 child-completion path end to end with
  deterministic mailbox synchronization
  
  ## Verification
  
  - `just test -p codex-core
  plaintext_multi_agent_v2_completion_sends_agent_message`
  - `just test -p codex-core input_queue_drains_mailbox_in_delivery_order
  record_initial_history_reconstructs_typed_inter_agent_message
  fork_turn_positions_use_inter_agent_delivery_metadata`
  - `just test -p codex-memories-write
  serializes_inter_agent_communications_for_memory`
  - `just test -p codex-rollout-trace
  agent_messages_preserve_routing_and_content
  sub_agent_started_activity_creates_spawn_edge`
  - `just test -p codex-rollout-trace
  agent_result_edge_falls_back_to_child_thread_without_result_message`
  - `just test -p codex-protocol -p codex-rollout -p
  codex-app-server-protocol`

  jif · 2026-06-12 13:50:04 -07:00
  8f2d6416ce
• fix(plugins) rm plugin descriptions (#23254)

  ## Summary
  Removes Plugin descriptions from the dev message, since descriptions of
  skills and MCPs cover the capabilities offered by the plugin.
  
  ## Testing
  - [x] Updates unit tests

  Dylan Hurd · 2026-06-12 13:31:11 -07:00
  3e2ee1da3f
• feat: add secret auth storage configuration (#27504)

  ## Why
  
  Windows Credential Manager limits generic credential blobs to 2,560
  bytes. The encrypted local secrets backend avoids storing large
  serialized auth payloads directly in the OS keyring, but selecting that
  backend needs an independently reviewable feature/config layer before
  the auth and secrets implementation is wired in.
  
  ## What Changed
  
  - Added the stable `secret_auth_storage` feature, enabled by default on
  Windows and disabled by default elsewhere.
  - Added `AuthKeyringBackendKind` and config resolution for full and
  bootstrap config loading.
  - Applied managed feature requirements when resolving the bootstrap auth
  backend.
  - Updated the generated config schema and added focused tests.
  
  This is the base PR for #17931. The auth, secrets, MCP, CLI, TUI, and
  app-server implementation remains in that follow-up PR.
  
  ## Validation
  
  - `just test -p codex-features`
  - `just test -p codex-config`
  - `just test -p codex-core
  resolve_bootstrap_auth_keyring_backend_kind_uses_secret_auth_storage_feature`
  - `just write-config-schema`
  - `just fix -p codex-core`
  
  The full `just test -p codex-core` run compiled successfully and ran
  2,690 tests; 2,589 passed, one was flaky, and 101 environment-sensitive
  tests failed because this shell injects a `pyenv` rehash warning into
  command output or because sandboxed subprocesses timed out.

  Celia Chen · 2026-06-12 19:15:21 +00:00
  b724f5966e
• Handle standalone image generation failures as terminal items (#27920)

  ## Why
  
  Standalone image generation emitted a started item but no terminal item
  when the backend failed. Clients could leave the operation unresolved or
  render it as successful.
  
  ## What changed
  
  - Emit a terminal image-generation item with `status: "failed"` when
  generation or editing fails.
  - Skip image persistence for failed terminal items.
  - Render failed image generation distinctly in TUI history.
  - Preserve the status when handling live and replayed terminal items.
  
  ## Looks for TUI, App-Side change needed 
  
  <img width="867" height="89" alt="image"
  src="https://github.com/user-attachments/assets/9e32342f-a982-411e-8498-456639fc468a"
  />
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - App-server image-generation tests
  - Core stream-event tests
  - TUI image-generation lifecycle and snapshot tests
  - Scoped Clippy and formatting

  Won Park · 2026-06-12 11:57:22 -07:00
  b6baa77eec
• 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
• realtime: add AVAS architecture override (#27720)

  ## Summary
  
  Adds a `RealtimeConversationArchitecture` option for realtime
  conversation startup, with `realtimeapi` as the default and `avas` as an
  opt-in architecture.
  
  The AVAS path is limited to realtime v1 conversational WebRTC starts,
  and WebRTC call creation appends `intent=quicksilver&architecture=avas`
  to `/v1/realtime/calls`. The existing sideband websocket still joins by
  `call_id`.
  
  This also exposes the per-session architecture override through
  app-server v2 `thread/realtime/start` params and updates the config
  schema for `[realtime].architecture`.
  
  ## Validation
  
  - `just fmt`
  - `just write-config-schema`
  - `just test -p codex-api sends_avas_session_call_query_params`
  - `just test -p codex-core -E
  'test(~conversation_webrtc_start_uses_avas_architecture_query)'`
  - `just test -p codex-core -E 'test(realtime_loads_from_config_toml)'`
  - `just test -p codex-app-server-protocol -E
  'test(~serialize_thread_realtime_start) |
  test(generated_ts_optional_nullable_fields_only_in_params)'`
  - `just test -p codex-app-server -E
  'test(realtime_webrtc_start_emits_sdp_notification)'`

  Peter Bakkum · 2026-06-12 18:11:13 +00:00
  6652e82dd0
• [ez][codex-rs] Support approvals reviewer in app defaults (#27075)

  [from codex]
  
  ## Summary
  
  - add `approvals_reviewer` support to `[apps._default]`
  - resolve connected-app reviewers in per-app, app-default, then global
  order
  - expose the setting through the v2 config API and regenerate schema
  fixtures
  
  ## Context
  
  PR #25167 added `apps.<connector_id>.approvals_reviewer`, but the shared
  app defaults table could not specify the reviewer. This extends the same
  behavior to `[apps._default]` while preserving per-app overrides.
  
  Managed `allowed_approvals_reviewers` requirements still constrain both
  default and per-app values. A disallowed app value falls back to the
  global reviewer, and non-app MCP servers continue using the global
  reviewer.
  
  ## Testing
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just fmt`
  - `just test -p codex-config`
  - `just test -p codex-core app_approvals_reviewer`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`

  Alex Zamoshchin · 2026-06-12 09:06:58 -07:00
  3cac2e0d3f
• [code-mode] Reject remote image URLs from output helpers (#27732)

  ## Summary
  
  - reject HTTP(S) image URLs from the shared code-mode output-image
  normalization path
  - return a concise model-visible tool error so the model can recover on
  its next turn
  - apply the targeted rejection to both `image()` and `generatedImage()`
  - leave other non-empty image URL values to existing downstream handling
  
  The returned error is:
  
  > Tool call failed: remote image URLs are not supported in tool outputs.
  Pass a base64 data URI instead
  
  ## Why
  
  Responses Lite cannot lower a remote image URL emitted from a structured
  tool output. Rejecting HTTP(S) values in the Codex harness preserves the
  tool-call metadata and gives the model a recoverable next turn instead
  of invalidating the sample.
  
  ## Test coverage
  
  The regression is covered primarily by a `test_codex()` agent
  integration test that simulates the Responses API exchange and asserts
  the failed model-visible exec output. A supplemental runtime test covers
  both `http://` and `https://` inputs across both image output helpers.
  
  ## Test plan
  
  - `cd codex-rs && just test -p codex-code-mode`
  - `cd codex-rs && just test -p codex-code-mode-protocol`
  - `cd codex-rs && just test -p codex-core
  code_mode_image_helper_rejects_remote_url`
  - `cd codex-rs && just fmt`
  - `git diff --check origin/main...HEAD`
  
  Related context: https://github.com/openai/openai/pull/1022346

  rka-oai · 2026-06-12 02:49:17 -07:00
  c09df9e353
• Make MCP server contributions thread-scoped (#27670)

  ## Why
  
  `selectedCapabilityRoots` belongs to one thread, but MCP contributors
  previously received only the global Codex config. That left no clean way
  for a selected executor capability to contribute MCP servers to its own
  thread.
  
  ## What this PR does
  
  - Gives MCP contributors a small context containing the config and, for
  a running thread, its frozen host-seeded inputs.
  - Uses the same thread inputs during startup, status queries, refreshes,
  and skill dependency checks.
  - Keeps threadless MCP operations and the existing hosted Apps behavior
  unchanged.
  - Adds coverage showing that two threads resolve independent
  registrations and that later lifecycle mutations do not change the
  frozen MCP inputs.
  
  This PR does not discover plugin manifests, add MCP servers, or launch
  anything new. It only establishes the thread-scoped registration
  boundary.
  
  ## Follow-ups
  
  - Resolve selected executor plugin roots through their owning
  environment filesystem.
  - Convert their stdio MCP declarations into environment-bound
  registrations and add an executor MCP end-to-end test.
  
  ## Verification
  
  - `just fmt`
  - `cargo check --tests -p codex-protocol -p codex-extension-api -p
  codex-mcp-extension -p codex-core -p codex-app-server`
  
  Tests and Clippy were not run.

  jif · 2026-06-12 11:20:34 +02:00
  693082f3c4
• [codex] Load AGENTS.md from all bound environments (#27696)

  ## Why
  
  We already have the machinery to support multiple environments on a
  single thread, but we only show the model the contents of `AGENTS.md`
  files in the primary environment.
  
  We should show the model all of the relevant project instructions when
  we know there's more than one environment.
  
  ## Known Gaps
  
  As discussed in the RFC, this implementation:
  
  1. doesn't handle environments being added/removed to/from the thread
  after its creation
  2. it doesn't enforce an aggregate context budget across environments,
  and instead applies the configured project maximum independently to each
  environment
  
  ## Implementation
  
  - Discover project instructions in environment order with an independent
  byte budget per environment and preserve source provenance/order.
  - Keep the legacy fragment byte-for-byte when exactly one environment
  contributes project instructions; use environment-labeled sections when
  two or more environments contribute.
  - Freeze the complete rendered fragment in `LoadedAgentsMd`, insert it
  directly into requests, and recognize both layouts in contextual and
  memory filtering.
  - Add exact rendering, independent-budget, source-order,
  creation-snapshot, and consumer coverage without changing app-server
  schemas.

  Adam Perry @ OpenAI · 2026-06-12 00:10:06 -07:00
  bf667c7003
• 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] resolve environment shell metadata eagerly (#27709)

  ## Why
  
  Turn construction passed resolved environments through several layers
  while leaving the environment shell unresolved. As a result,
  model-visible environment context could fall back to the session shell
  instead of reporting the selected remote environment's shell.
  
  Resolve environment metadata at the turn-context boundary so each turn
  carries the shell that belongs to its selected environment. Keep request
  validation in app-server, where invalid selections can be returned as
  straightforward JSON-RPC errors without coupling core turn construction
  to that policy.
  
  ## What changed
  
  - resolve environment selections eagerly in
  `new_turn_context_from_configuration`
  - store the full resolved `Shell` on each `TurnEnvironment`
  - simplify the now-redundant resolved-environment constructor plumbing
  - keep duplicate and unknown-environment validation as a small
  app-server preflight
  - add a remote-environment integration test that runs a full
  `test_codex` turn and verifies the model-visible environment message
  reports `bash`
  
  ## Testing
  
  - `cargo check -p codex-core --test all -p codex-app-server`
  - `remote_test_env_exposes_bash_shell_to_model` on the Linux
  remote-executor harness

  pakrym-oai · 2026-06-11 20:35:28 -07:00
  be338ee9a2
• [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
• Add spans to turn lifecycle gaps (#27623)

  ## Why
  Codex app-server latency traces do not granularly cover turn task
  startup and inter-request handoffs. These spans help attribute time
  across task execution, startup prewarm, in-flight tool completion, and
  rollout persistence.
  
  ## What changed
  - Add `session_task.run` spans around task execution and
  `session_task.flush_rollout` around flushing pending conversation
  transcript writes to durable storage
  - Add `regular_task.prepare_run_turn` around regular-turn startup (Send
  the `TurnStarted` event, reset turn-specific reasoning state, and
  resolve any startup prewarm)
  - Add `startup_prewarm.resolve` around waiting for background session
  prewarming to finish, fail, time out, or be cancelled
  - Add a function-level trace span around draining in-flight tool calls
  (Wait for tool calls to complete, record tool result in conversation
  history, and other bookkeeping)
  
  ## Verification
  Trigger Codex rollout and observe new spans are included

  mchen-oai · 2026-06-11 16:55:01 -07:00
  92d9036910
• Route image extension reads through turn environments v2 (#27498)

  ## Why
  
  Image generation used `std::fs::read` for referenced image paths, which
  did not support environment-backed filesystems or their sandbox context.
  
  ## What changed
  
  - Expose optional turn environments to extension tool calls.
  - Include each environment’s ID, working directory, filesystem, and
  sandbox context.
  - Read referenced images through the selected environment filesystem.
  - Keep sandbox usage at the extension call site so extensions can choose
  the appropriate access mode.
  - Consolidate image request construction into one async function.
  - Add coverage for successful environment reads and read failures.
  
  ## Validation
  
  - `cargo check -p codex-image-generation-extension --tests`
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  
  `just test -p codex-image-generation-extension` could not complete
  because the build exhausted available disk space.

  Won Park · 2026-06-11 16:32:52 -07:00
  19ce6394af
• [codex] Move persistence policy application into ThreadStore (#27318)

  Move the application of the persistence policy into the thread store, so
  thread stores can get raw append items rather than canonical append
  items. This will enable store-specific projections over the raw input
  items.

  Tom · 2026-06-11 16:24:12 -07:00
  b2cc01fc7c
• Include thread id in token budget context (#27663)

  ## Why
  
  The token budget full-context fragment identifies the current context
  window, but not the thread that owns that window. Including the thread
  id makes the initial context-window metadata self-contained, and
  `get_context_remaining` also needs to be usable from Code Mode without
  forcing callers to parse the model-facing fragment string.
  
  ## What changed
  
  - Include the session thread id in the initial `<token_budget>` context
  fragment.
  - Expose `get_context_remaining` as a Code Mode nested tool while
  keeping `new_context` direct-model-only.
  - Keep direct model-facing `get_context_remaining` output as the
  existing `<token_budget>` text fragment.
  - Return only `tokens_left` from the Code Mode structured result for
  `get_context_remaining`.
  - Update token-budget integration tests and add Code Mode coverage for
  the structured result.
  
  ## Verification
  
  - `just test -p codex-core token_budget`
  - `just test -p codex-core
  code_mode_get_context_remaining_returns_structured_result`
  - `just test -p core_test_support redacted_text_mode_normalizes_uuids`

  pakrym-oai · 2026-06-11 15:10:29 -07:00
  7516eb5c70
• core: Consolidate Responses API Codex metadata (#27122)

  ## What
  Introduce a `CodexResponsesMetadata` struct that defines all the core
  metadata we send to Responses API. Example fields are `thread_id`,
  `turn_id`, `window_id`, etc.
  
  Going forward, `client_metadata["x-codex-turn-metadata"]` will be the
  canonical way Codex sends metadata to Responses API across both HTTP and
  websocket transports.
  
  For now, we continue to emit the existing top-level HTTP headers and
  top-level `client_metadata` fields from the same
  `CodexResponsesMetadata` struct for compatibility reasons.
  
  Also, app-server clients who specify additional
  `responsesapi_client_metadata` via `turn/start` and `turn/steer` will
  have those fields merged into
  `client_metadata["x-codex-turn-metadata"]`, but cannot override the
  reserved fields that core uses (i.e. the fields in
  `CodexResponsesMetadata`).
  
  ## Why
  
  Responses API request instrumentation is the source of truth for
  downstream Codex analytics that join requests by Codex IDs such as
  session, thread, turn, and context window. Before this change, those
  values were assembled through several request-specific paths: HTTP
  request bodies, websocket handshake headers, websocket `response.create`
  payloads, compaction requests, and the rich `x-codex-turn-metadata`
  envelope all had their own wiring.
  
  That made metadata propagation easy to drift across API-key/direct
  Responses API requests, ChatGPT-auth/proxied requests, websocket
  requests, and compaction requests. It also made additions like
  `window_id` error-prone because a field could be added to one transport
  projection but missed in another.
  
  ## What changed
  
  - Added `CodexResponsesMetadata` as the core-owned snapshot for Codex
  metadata sent to ResponsesAPI.
  - Render `client_metadata["x-codex-turn-metadata"]`, flat
  `client_metadata` projections, and direct compatibility headers from
  that same snapshot.
  - Include the known Codex-owned fields in the turn metadata blob,
  including installation/session/thread/turn/window IDs, request kind,
  lineage, sandbox/workspace metadata, timing, and compaction details.
  - Treat app-server `responsesapi_client_metadata` as enrichment for the
  Codex turn metadata blob while preventing those extras from overriding
  Codex-owned fields.
  - Use the same metadata path for normal turns, websocket prewarm, local
  compaction, remote v1 compaction, and remote v2 compaction.
  - Keep websocket connection-only preconnect metadata separate so
  handshakes carry compatibility identity headers without inventing a fake
  turn metadata blob.
  
  ## Verification
  
  - `cargo check -p codex-core`
  - `just fix -p codex-core`

  Owen Lin · 2026-06-11 13:42:09 -07:00
  14df0e8833
• Resolve MCP server registrations through a catalog (#27634)

  ## Why
  
  MCP servers currently come from user config, local plugins,
  compatibility Apps synthesis, and host extensions. Those sources were
  composed by mutating a shared map, leaving registration identity,
  precedence, removal, and provenance implicit in assembly order.
  
  Before adding executor-owned MCPs, Codex needs one durable resolution
  boundary above `McpConnectionManager`. This PR introduces that boundary
  while preserving current server configuration, policy, and runtime
  behavior. Executor-scoped registrations and explicit policy layers
  remain follow-ups.
  
  ## What changed
  
  - Add typed `McpServerRegistration` inputs and an immutable
  `ResolvedMcpCatalog` in `codex-mcp`.
  - Retain each registration's complete `McpServerConfig`, including its
  environment binding, while recording its source and provenance.
  - Preserve the existing structural precedence between plugin, config,
  compatibility, and ordered extension sources.
  - Resolve equal-precedence actions by contribution order; provenance IDs
  are used only for diagnostics and cannot affect the winner.
  - Preserve extension removals and the existing name-scoped `enabled =
  false` veto.
  - Report same-tier conflicts with every contender and the final catalog
  outcome, including whether the winning action registers or removes the
  server.
  - Require MCP contributors to provide a stable diagnostic identity.
  - Derive materialized server maps and plugin ownership from the resolved
  catalog.
  
  `McpConnectionManager`, transport startup, tool calls, and resource
  routing continue to consume the same effective `McpServerConfig` values.
  
  ## Scope
  
  This PR does not add new MCP capabilities or change user-visible
  behavior. It does not add executor plugin discovery, thread-scoped
  registrations, dynamic refresh generations, or new user/managed policy
  semantics.
  
  ## Verification
  
  - Added focused catalog coverage for source precedence, complete
  configuration preservation, disabled vetoes, plugin ownership,
  contribution-order tie breaking, removal outcomes, and conflict
  diagnostics.
  - Extended hosted Apps coverage for ordered extension removal and
  Apps-disabled hosts with and without the hosted extension installed.
  - `cargo check -p codex-mcp --tests -p codex-extension-api -p
  codex-core`

  jif · 2026-06-11 21:54:52 +02:00
  4a5a676499
• [codex] Load user instructions through an injected provider (#27101)

  ## Why
  
  We want to remove implicit use of `$CODEX_HOME` from `codex-core` and
  make embedders responsible for supplying user-level instructions. This
  also ensures user instructions load when no primary environment is
  selected.
  
  ## What changed
  
  Stacked on #27415, which makes `codex exec` surface thread-scoped
  runtime warnings.
  
  - Added `UserInstructionsProvider` to `codex-extension-api`, with
  absolute source attribution and recoverable loading warnings.
  - Added `codex-home` with the filesystem-backed provider for
  `AGENTS.override.md` and `AGENTS.md`, preserving precedence, fallback,
  trimming, lossy UTF-8 handling, and the existing uncapped global
  instruction size.
  - Removed global instruction loading from `Config` and require
  `ThreadManager` callers to inject a provider.
  - Load provider instructions once for each fresh root runtime, including
  runtimes without a primary environment. Running sessions retain their
  snapshot, while child agents inherit the parent snapshot without
  invoking the provider.
  - Keep provider instructions separate while loading project `AGENTS.md`,
  then assemble the model-visible instructions with the existing ordering,
  source attribution, warning, and turn-context behavior.
  - Wired the Codex home provider through the CLI, app server, MCP server,
  core facade, and thread-manager sample.
  
  ## Validation
  
  - `just test -p codex-home -p codex-extension-api`
  - `just test -p codex-core agents_md`
  - `just test -p codex-core guardian`
  - `just test -p codex-app-server
  thread_start_without_selected_environment_includes_only_global_instruction_source`
  - `just test -p codex-exec warning`
  - `just bazel-lock-check`

  Adam Perry @ OpenAI · 2026-06-11 19:28:47 +00:00
  236b50125d
• [codex] migrate ExecutorFileSystem paths to PathUri (#27424)

  ## Why
  
  We're moving exec-server to use PathUri for its internal path
  representations.
  
  ## What
  
  Move `ExecutorFileSystem` APIs to use `PathUri` instead of
  `AbsolutePathBuf`. Future changes will convert higher-level parts of
  exec-server.

  Adam Perry @ OpenAI · 2026-06-11 18:44:18 +00:00
  b2a4e3be27
• multi-agent: move concurrency guidance into v2 usage hints (#27569)

  ## Why
  
  Native Codex currently teaches multi-agent concurrency through the
  `spawn_agent` tool description, while bridge-driven evals frame the same
  limit as a shared pool of active agent slots. That mismatch makes the
  model-facing story harder to reason about, especially because the
  tool-level wording does not make it explicit that the limit covers the
  whole agent team, including the current agent.
  
  This change gives native Codex the same mental model: tell the root
  agent and subagents how many active slots exist, and remove the separate
  `spawn_agent` limit wording.
  
  ## What changed
  
  - Extend the built-in `multi_agent_v2` root and subagent usage hints
  with shared-slot guidance derived from the resolved
  `max_concurrent_threads_per_session` value.
  - Keep the complete default hints in `MultiAgentV2Config` so initial
  context and forked histories consume the same canonical strings.
  - Drop the redundant `spawn_agent` description text and remove the
  now-unused limit plumbing from the tool spec path.
  
  ## Testing
  
  - `just test -p codex-core usage_hint`
  - `just test -p codex-core
  multi_agent_v2_default_session_thread_cap_counts_root`
  - `just test -p codex-core
  multi_agent_v2_default_usage_hints_use_configured_thread_cap`
  - `just test -p codex-core
  spawn_agent_tool_v2_requires_task_name_and_lists_visible_models`
  - `just test -p codex-core
  multi_agent_feature_selects_one_agent_tool_family`

  jif · 2026-06-11 12:41:44 +02:00
  0870352241
• core: enable remote compaction v2 by default (#27573)

  ## Why
  
  Remote compaction v2 is ready to become the default for providers that
  already support remote compaction. Leaving it behind an
  under-development opt-in keeps eligible sessions on the legacy
  remote-compaction path.
  
  This does not broaden provider eligibility: OpenAI and Azure move to v2,
  while Bedrock and OSS providers retain their existing local-compaction
  behavior.
  
  ## What changed
  
  - Mark `remote_compaction_v2` stable and enable it by default.
  - Make tests that intentionally cover legacy remote compaction
  explicitly disable v2.
  - Update parity coverage so v2 exercises the production default and only
  legacy mode opts out.
  
  ## Verification
  
  - `just test -p codex-core
  auto_compact_runs_after_resume_when_token_usage_is_over_limit
  auto_compact_counts_encrypted_reasoning_before_last_user
  auto_compact_runs_when_reasoning_header_clears_between_turns
  responses_lite_compact_request_uses_lite_transport_contract`

  jif · 2026-06-11 10:07:19 +00:00
  273a4aa4f2
• skills: make backend plugin skills invocable without an executor (#27387)

  ## Why
  
  #27198 made the extension-owned `codex_apps` MCP connection the hosted
  plugin runtime, but its `mcp/skill` resources still bypassed the skills
  extension. App-server could list and read those resources through
  generic MCP APIs, but a thread with no selected environment did not
  expose them in the model's skills catalog or load their `SKILL.md`
  through `$skill`.
  
  Hosted skills should stay remote while using the same typed catalog,
  source authority, deduplication, bounded contextual catalog, and
  selected-skill prompt injection as host and executor skills. They should
  not be downloaded or exposed as ambient filesystem paths.
  
  ## What changed
  
  - Add a session-scoped `McpResourceClient` over the replaceable MCP
  connection manager so resource list/read calls follow startup and
  refresh replacements.
  - Add a `BackendSkillProvider` that pages `codex_apps` resources,
  accepts bounded and validated `mcp/skill` entries, and reads a selected
  skill's `SKILL.md` through the same MCP connection.
  - Register the remote provider in app-server and include it in the
  skills catalog even when a thread has no selected capability roots or
  executor.
  - Contribute hosted skill metadata through the bounded
  `AvailableSkillsInstructions` developer-context path, exclude remote
  entries from per-turn catalog injection, and classify `<skills>`
  messages as contextual developer content so rollback can trim and
  rebuild them correctly.
  
  ## Testing
  
  - Extend the app-server MCP resource integration test with
  `environments: []` to exercise two-page discovery, filter a
  non-`mcp/skill` resource, verify the escaped developer catalog entry and
  user-role `<skill>` fragment containing the fetched `SKILL.md`, and
  preserve generic MCP resource reads.
  - Add core event-mapping coverage that classifies `<skills>` developer
  messages as contextual history.

  jif · 2026-06-11 11:28:16 +02:00
  a287c5dffd
• [codex-analytics] Emit structured compaction codex errors (#27082)

  ## Summary
  - replace raw compaction `error` analytics with `codex_error_kind` and
  `codex_error_http_status_code`
  - derive compaction error telemetry from `CodexErr` using the same
  `CodexErrKind` mapping and HTTP status helper used by turn events
  - remove the pre-compact hook stop reason from the internal compaction
  outcome now that it is no longer emitted as raw analytics text
  
  ## Why
  Compaction `error` was a raw `CodexErr::to_string()` value, which can
  carry free-form provider or user-derived text. Structured Codex error
  fields preserve useful low-cardinality telemetry without sending the raw
  string.
  
  ## Validation
  - `just fmt`
  - `just test -p codex-analytics`
  - `just test -p codex-core
  compact::tests::build_token_limited_compacted_history_appends_summary_message`
  
  Attempted `just test -p codex-core`; the changed crate compiled, but the
  full target failed in unrelated environment-dependent tests such as
  missing helper binaries and shell snapshot timeouts.

  rhan-oai · 2026-06-11 06:07:06 +00:00
  8d9f33c87c
• Use generic search metadata for dynamic tools (#27356)

  ## Why
  
  Dynamic tools maintained a separate search-text builder even though the
  shared tool search path already derives the same metadata from
  `ToolSpec`. Using the shared path removes duplicate behavior before
  adding explicit namespaces.
  
  ## What changed
  
  - Build dynamic-tool search entries with
  `ToolSearchInfo::from_tool_spec`.
  - Remove the custom search-text state and its implementation-only unit
  test.
  
  The old search text included the tool name, its space-separated form,
  description, namespace, and top-level parameter names. The shared
  builder preserves all of those terms and also indexes namespace
  descriptions and nested schema metadata.
  
  ## Test plan
  
  - `just test -p codex-core
  tool_search_returns_deferred_dynamic_tool_and_routes_follow_up_call`

  sayan-oai · 2026-06-10 23:06:34 -07:00
  b5a718ef67
• [codex-analytics] report cached input tokens for v2 compaction (#27103)

  ## Summary
  
  - add nullable `cached_input_tokens` to the compaction analytics event
  - populate it from response usage for compaction v2
  - leave it `null` for other compaction implementations
  
  This adds visibility into prompt-cache usage for v2 compaction without
  changing compaction behavior.
  
  ## Testing
  
  - `just test -p codex-analytics`
  - `just test -p codex-core
  collect_compaction_output_accepts_additional_output_items`

  rhan-oai · 2026-06-10 22:47:22 -07:00
  383708e74e
• [codex] Add context remaining tool (#27518)

  ## Why
  
  The token budget feature can inject remaining-context notices into
  model-visible context, but the model does not have a direct way to ask
  for that same remaining-token fragment on demand.
  
  This PR adds a small model tool for the token budget feature so the
  model can request the current remaining context window message without
  duplicating the fragment format.
  
  ## What changed
  
  - Adds a `get_context_remaining` direct-model tool behind
  `Feature::TokenBudget`.
  - Renders the tool output through `TokenBudgetRemainingContext`,
  matching the existing budget message shape.
  - Registers the tool alongside `new_context` in the token budget tool
  set.
  - Adds integration coverage that verifies the tool is exposed and
  returns the same `<token_budget>` remaining fragment already present in
  context.
  
  ## Validation
  
  - `just test -p codex-core token_budget`

  pakrym-oai · 2026-06-11 04:17:10 +00:00
  dac5f07403
• [codex] Compact when comp_hash changes (#27520)

  ## Summary
  - snapshot `comp_hash` into `TurnContext` when the turn is created and
  use that snapshot as the downstream source of truth
  - persist the turn hash in rollout context and recover it into
  previous-turn settings during resume and fork replay
  - compact existing history with the previous model only when both
  adjacent turns provide hashes and the values differ
  - record `comp_hash_changed` as the compaction reason
  - cover ordinary transitions, resume, and missing-hash compatibility
  with end-to-end tests
  
  ## Why
  History produced under one compaction-compatible model configuration may
  not be safe to carry directly into another. Compacting at the turn
  boundary converts that history before context updates and the new user
  message are added. Persisting the turn snapshot in `TurnContextItem`
  makes the same protection work after resuming a rollout.
  
  A missing hash is not treated as evidence of incompatibility. `None →
  Some`, `Some → None`, and `None → None` do not trigger compaction; only
  `Some(previous) → Some(current)` with unequal values does.
  
  ## Stack
  - depends on #27532
  - #27532 is based directly on `main`
  
  ## Testing
  - `just test -p codex-core pre_sampling_compact_` — 6 passed
  - `just test -p codex-core
  turn_context_item_uses_turn_context_comp_hash_snapshot` — passed
  - `just fix -p codex-core -p codex-protocol -p codex-analytics -p
  codex-models-manager`

  Ahmed Ibrahim · 2026-06-11 04:11:26 +00:00
  ba4925b3c2