681 Commits

• chore(core) rm AskForApproval::OnFailure (#28418)

  ## Summary
  Deletes the OnFailure variant of the `AskForApproval` enum. This option
  has been deprecated since #11631.
  
  ## Testing
  - [x] Tests pass

  Dylan Hurd · 2026-06-23 12:13:54 -07:00
  2cf2a6a844
• app-server: document thread and turn IDs are UUID7 (#27714)

  It's actually a very nice property that these are UUID7s, so documenting
  them so we think twice before changing it away from UUID7s in the
  future.

  Owen Lin · 2026-06-23 11:46:36 -07:00
  8d80b0176a
• Share resumed rollout history (#28426)

  ## Summary
  
  Resuming a persisted thread currently deep-clones its complete rollout
  history several times. `InitialHistory` is retained for the app-server
  response, copied into thread persistence, and copied again by read-only
  accessors. These copies scale with the complete rollout rather than the
  bounded model context and add measurable latency for large sessions.
  
  This change stores resumed rollout history in `Arc<Vec<RolloutItem>>`.
  Rollout loading wraps the parsed vector once, while app-server response
  construction, session initialization, and thread persistence share it
  through inexpensive `Arc` clones. Read-only history access now returns a
  borrowed slice, and fork paths use `Arc::unwrap_or_clone` where they
  genuinely need mutable ownership. Rollout reconstruction also consumes
  its temporary context instead of cloning the reconstructed model
  history.
  
  The serialized representation remains unchanged. In an artificial 123 MB
  rollout benchmark, sharing resumed history reduced cold resume latency
  by roughly 9–10%. The affected crates compile with their test targets,
  all 80 thread-store tests pass, and the Bazel dependency lock remains
  valid.

  Charlie Marsh · 2026-06-23 10:23:25 -04:00
  330ae6a516
• [codex] Use input items for Responses Lite tools (#27946)

  When using Responses Lite, we should all use `additional_tools` and a
  developer item instead of the top level tools array & instructions
  field. This keeps things 1-to-1.
  
  Forced namespacing for _all_ tools will land in a following PR after
  some coordination & fixes in Responses API (around collisions & return
  items).
  
  The goal is to eventually expand the scope of this to _all_ requests
  from codex, but that will require larger coordination across providers &
  slower rollout.

  rka-oai · 2026-06-22 23:56:16 -07:00
  33cc928d33
• Propagate safety buffering treatment metadata (#29473)

  ## Summary
  
  - read the request-scoped safety-buffering treatment from HTTP response
  headers and per-turn WebSocket metadata through one shared header parser
  - combine that treatment with Responses API safety-buffering signals
  - propagate `showBufferingUi` and nullable `fasterModel` through the
  existing `model/safetyBuffering/updated` app-server notification
  - update the app-server documentation and generated JSON and TypeScript
  schemas
  
  The public implementation contains no model mapping or real model
  identifier. Tests and protocol examples use generic `current-model` and
  `faster-model` placeholders only.
  
  ## Dependencies
  
  - server-side treatment evaluation:
  https://github.com/openai/openai/pull/1060247
  - initial Responses API safety-buffering propagation:
  https://github.com/openai/codex/pull/29371
  - Codex App UI: https://github.com/openai/openai/pull/1057789
  
  ## Validation
  
  - Codex API tests: 129 passed
  - focused Codex core safety-buffering integration test passed
  - app-server protocol tests passed after regenerating schema fixtures
  - Clippy fix and repository formatting completed successfully
  
  The broader app-server run compiled all changed crates and completed
  with 1,269 passing tests. Its remaining failures were unrelated
  environment limitations: macOS sandbox application was denied, one
  expected test binary was unavailable, and several existing subprocess
  tests timed out as a result.

  Francis Chalissery · 2026-06-22 19:51:03 -07:00
  7c22d376e5
• chore: improve expired Bedrock credential errors (#28992)

  ## Why
  
  Amazon Bedrock returns a `401 Unauthorized` response containing
  `Signature expired:` when an AWS credential, including a short-lived
  `AWS_BEARER_TOKEN_BEDROCK`, has expired. Codex currently surfaces that
  response as a generic `unexpected status` error, which does not explain
  how to recover.
  
  Environment-provided bearer tokens cannot be refreshed automatically, so
  the error should direct users to refresh their AWS credentials or
  replace or remove the environment token and restart Codex. This
  classification belongs to the Amazon Bedrock provider so similar
  responses from other providers retain their existing behavior.
  
  ## What changed
  
  - Add a synchronous `ModelProvider::map_api_error` hook that defaults to
  the existing provider-neutral API error mapping, and route model
  request, stream, WebSocket, and terminal unauthorized errors through the
  active provider.
  - Override the hook for Amazon Bedrock. After preserving the structured
  status, body, URL, and request metadata, recognize `401` responses
  containing `Signature expired:` and attach actionable credential
  guidance.
  - Keep `codex-protocol` provider-neutral by representing the guidance as
  an optional `user_message`. Error rendering prefers this message while
  continuing to append the URL, request ID, Cloudflare ray, and
  authorization diagnostics.
  - Add model-provider coverage for expired signatures and negative cases,
  core coverage for provider dispatch after unauthorized recovery, and a
  TUI snapshot for the rendered error.
  
  ## Testing
  Tested with a real request with expired bedrock key:
  <img width="962" height="126" alt="Screenshot 2026-06-22 at 3 56 51 PM"
  src="https://github.com/user-attachments/assets/7e21cc7c-798e-4662-8467-7f304a2f2b59"
  />

  Celia Chen · 2026-06-23 00:53:09 +00:00
  e65e480e0d
• feat(core): store turn_id on ResponseItem metadata (#28360)

  ## Description
  
  This PR is a followup to https://github.com/openai/codex/pull/28355 and
  starts assigning `internal_chat_message_metadata_passthrough.turn_id` to
  durable Responses API items created during a turn.
  
  The goal is that those items keep the `turn_id` that introduced them
  when Codex resends stateless HTTP context, reconstructs history for
  resume/fork paths, or reuses websocket response state.
  
  ## What changed
  
  - Set `internal_chat_message_metadata_passthrough.turn_id` when missing
  as response items enter durable history, initial/replacement history,
  inter-agent communication history, and local compaction summaries.
  - Preserve existing item turn IDs instead of overwriting them during
  persistence, resume reconstruction, compaction, forked history, and
  websocket incremental reuse.
  - Keep `compaction_trigger` fieldless because it is a request control,
  not a durable response item.
  - Update focused history/request assertions and fixtures for stateless
  requests, websocket incrementals, compaction, thread injection, prompt
  debug, and related CI coverage.

  Owen Lin · 2026-06-22 16:45:14 -07:00
  4a82ecc3c9
• core: wrap token budget window context (#29494)

  Token-budget initial context carries thread and context-window lineage
  that the model should treat as one structured context-window block.
  Wrapping it in `<context_window>` makes that boundary explicit while
  preserving the existing window id content.
  
  Before this change, the window identifiers were injected as an untagged
  developer text fragment:
  
  ```text
  Thread id <THREAD_ID>.
  First context window id: <FIRST_WINDOW_ID>
  Current context window id: <WINDOW_ID>
  Previous context window id: <PREVIOUS_WINDOW_ID>
  ```
  
  After this change, the same payload is wrapped as a context-window
  block:
  
  ```text
  <context_window>
  Thread id: <THREAD_ID>
  First context window id: <FIRST_WINDOW_ID>
  Current context window id: <WINDOW_ID>
  Previous context window id: <PREVIOUS_WINDOW_ID>
  </context_window>
  ```
  
  This adds shared `CONTEXT_WINDOW_*_TAG` protocol constants, updates
  `TokenBudgetContext` to render with those markers, treats the new
  wrapper as contextual developer content when mapping history, and
  refreshes the token-budget request-shape assertions and snapshot.
  
  Verification:
  - `just test -p codex-core token_budget`
  - `just test -p codex-core
  recognizes_context_window_as_contextual_developer_content`

  Michael Bolin · 2026-06-22 23:37:49 +00:00
  f1945de3b7
• Allow ChatGPT accounts without email (#28991)

  # Summary
  
  Codex required every ChatGPT account to have an email address. A
  service-account personal access token can return valid account metadata
  without one, so PAT login failed while decoding the metadata response.
  
  This change makes email optional in the account metadata type that owns
  it and preserves that absence through authentication, provider account
  state, the app-server API, generated clients, and TUI bootstrap.
  Existing accounts with email addresses keep the same behavior.
  
  ## Behavior-changing call sites
  
  | Call site | Behavior after this change |
  | --- | --- |
  | `login/src/auth/personal_access_token.rs` | PAT metadata accepts a
  missing or null email and retains `None`. |
  | `agent-identity/src/lib.rs` | Agent Identity JWT claims accept an
  omitted email. |
  | `login/src/auth/storage.rs` and `login/src/auth/agent_identity.rs` |
  Stored and managed Agent Identity records carry `Option<String>`.
  Deserialization maps the legacy empty-string sentinel to `None`. |
  | `login/src/auth/manager.rs` | `get_account_email` returns the stored
  option, and managed identity bootstrap no longer converts `None` to an
  empty string. |
  | `model-provider/src/provider.rs` and `protocol/src/account.rs` | A
  ChatGPT provider account requires a plan type but may carry no email. |
  | `app-server-protocol/src/protocol/v2/account.rs` | `account/read`
  keeps the `email` field on the wire and returns `null` when the account
  has no email. Generated TypeScript and JSON schemas describe a required,
  nullable field. |
  | `sdk/python/src/openai_codex/generated/v2_all.py` | The generated
  Python `ChatgptAccount` model accepts `None` for email. |
  | `tui/src/app_server_session.rs` | Email-less ChatGPT accounts
  bootstrap normally, keep external feedback routing, omit account-email
  telemetry, and display the plan in account status. |
  
  ## Design decisions
  
  - Missing email remains `None` at every layer. The code never uses an
  empty string as a substitute.
  - The app-server response includes `"email": null` instead of omitting
  the field. Clients retain a stable response shape.
  - Plan type remains required for provider account state. This change
  relaxes only the email assumption.
  
  ## Testing
  
  Tests: affected test targets compile, scoped Clippy and formatting pass,
  a focused TUI snapshot covers plan-only account status, real
  before/after PAT login smoke covers metadata without email, app-server
  smoke covers `account/read` with `email: null`, and a regression smoke
  covers an existing email-bearing PAT. Unit tests run in CI.
  
  ## Evidence
  
  Visual smoke evidence will be attached here.

  efrazer-oai · 2026-06-22 13:19:40 -07:00
  5a67d898a5
• core: rename metadata -> internal_chat_message_metadata_passthrough (#28968)

  ## Description
  This PR cuts Codex over from generic `ResponseItem.metadata` (introduced
  here: https://github.com/openai/codex/pull/28355) to
  `ResponseItem.internal_chat_message_metadata_passthrough`, which is the
  blessed path and has strongly-typed keys.
  
  For now we have to drop this MAv2 usage of `metadata`:
  https://github.com/openai/codex/pull/28561 until we figure out where
  that should live.

  Owen Lin · 2026-06-22 11:11:25 -07:00
  5b95745eae
• Simplify multi-agent mode controls (#29324)

  ## Why
  
  Multi-agent delegation policy was split across `multiAgentMode`,
  `features.multi_agent_mode`, and `usage_hint_enabled`. These controls
  could disagree: a requested mode could be downgraded by the feature
  flag, and disabling usage hints also disabled mode instructions.
  
  Some clients also need multi-agent tools without adding
  delegation-policy text to model context. The previous two-mode API could
  not express that directly.
  
  ## What changed
  
  `multiAgentMode` is now the only live delegation-policy control:
  
  | Mode | Behavior |
  | --- | --- |
  | `none` | Keep multi-agent tools available without adding mode
  instructions. |
  | `explicitRequestOnly` | Only delegate after an explicit user request.
  |
  | `proactive` | Delegate when parallel work materially improves speed or
  quality. |
  
  - new threads default to `explicitRequestOnly`; omitting the mode on
  later turns keeps the current value
  - thread start, resume, fork, and settings responses always report the
  concrete current mode instead of `null`
  - mode selection remains sticky across turns and resume
  - usage-hint text no longer controls whether mode instructions apply
  - `features.multi_agent_mode` and `usage_hint_enabled` remain accepted
  as ignored compatibility settings so existing configs continue to load
  - app-server documentation and generated schemas describe the three-mode
  API
  
  ## Tests
  
  - `just test -p codex-core multi_agent_mode`
  - `just test -p codex-core multi_agent_v2_config_from_feature_table`
  - `just test -p codex-core spawn_agent_description`
  - `just test -p codex-features`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server multi_agent_mode`

  jif · 2026-06-22 10:05:36 +02:00
  c03742ca0a
• Persist session IDs across thread resume (#29327)

  ## Summary
  
  A cold-resumed subagent kept its durable thread ID but could receive a
  new session ID, splitting one agent tree across multiple sessions after
  a restart.
  
  Persist the root session ID in every rollout `SessionMeta`, carry it
  through thread creation, and restore it before initializing the resumed
  `Session` and `AgentControl`.
  
  ## Behavior
  
  For a nested agent tree:
  
  ```text
  root session R
    parent thread P
      child thread C
  ```
  
  The child rollout stores:
  
  ```text
  session_id:       R
  parent_thread_id: P
  id:               C
  ```
  
  After a cold resume, the child still belongs to root session `R` while
  its immediate parent remains `P`. The integration coverage uses distinct
  values for all three IDs so it catches restoring the session from
  `parent_thread_id`.
  
  ## Legacy rollouts
  
  Previous rollouts have `id` but no `session_id`. `SessionMetaLine`
  deserialization treats a missing `session_id` as `id`, keeping those
  files readable, listable, and resumable. When a legacy subagent is
  resumed through its root, that synthesized child ID no longer overrides
  the inherited root-scoped `AgentControl`. New rollouts always persist
  the explicit root session ID.

  jif · 2026-06-22 09:36:08 +02:00
  6d15bb3d17
• Propagate safety buffering events to app-server clients (#29371)

  Responses API safety buffering metadata currently stops at the transport
  boundary, so app-server clients cannot render the in-progress safety
  review state.
  
  This change:
  - decodes and deduplicates `safety_buffering` metadata from Responses
  API SSE and WebSocket events without suppressing the original response
  event
  - emits a typed core event containing the requested model plus backend
  use cases and reasons
  - forwards that event as `turn/safetyBuffering/updated` through
  app-server v2 and updates generated protocol schemas
  - keeps the side-channel event out of persisted rollouts and turn timing
  
  This supports the Codex Apps buffering UX and depends on the Responses
  API backend work in https://github.com/openai/openai/pull/1044569 and
  https://github.com/openai/openai/pull/1044571.
  
  Validation:
  - focused `codex-core` safety-buffering integration test passes
  - `cargo check -p codex-core -p codex-app-server -p
  codex-app-server-protocol`
  - `just fix -p codex-api -p codex-protocol -p codex-core -p
  codex-app-server-protocol -p codex-app-server -p codex-rollout -p
  codex-rollout-trace -p codex-otel`
  - `just fmt`
  - broad package test run: 4,430/4,492 passed; 62 unrelated
  local-environment/concurrency failures involved unavailable test
  binaries, MCP subprocess setup, and app-server timeouts

  Francis Chalissery · 2026-06-22 03:39:14 +00:00
  566f7bf631
• core: add context window lineage IDs (#29256)

  ## Why
  
  The rendered `<token_budget>` fragment identifies the thread and current
  context window, but it does not expose enough lineage to identify the
  first window in the thread or the immediately preceding window. Those
  IDs also need to remain stable across compaction, resume, and rollback.
  
  ## What changed
  
  - Track first, previous, and current UUIDv7 context-window IDs in
  auto-compaction state.
  - Render `thread_id`, `first_window_id`, `previous_window_id`, and the
  current window ID in the full `<token_budget>` fragment.
  - Persist the first and previous window IDs in compacted rollout
  checkpoints and restore them during rollout reconstruction.
  - Preserve compatibility with older compacted records that do not
  contain the new optional fields.
  - Update focused state, rendering, reconstruction, rollback, and
  serialization coverage.
  
  ## Validation
  
  - `just test -p codex-core token_budget`
  - `just test -p codex-protocol compacted_item::tests`
  - `just test -p codex-core tracks_prefill_and_window_boundaries`
  - `just test -p codex-core
  reconstruct_history_uses_replacement_history_verbatim`
  - `just test -p codex-core
  thread_rollback_restores_cleared_reference_context_item_after_compaction`

  pakrym-oai · 2026-06-20 13:15:49 -07:00
  d1209bddfc
• 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
• 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
• Add per-turn multi-agent mode (#28685)

  ## Why
  
  Multi-agent v2 currently carries an explicit-request-only delegation
  rule in its static usage hint. That provides a safe default, but it
  prevents clients from selecting proactive delegation per turn without
  changing static guidance or rewriting prior model context.
  
  This change makes delegation mode a session selection that can be
  updated through `turn/start`, while deriving the effective model-visible
  mode separately for each turn. Eligible multi-agent v2 turns remain
  explicit-request-only unless proactive mode is both selected and
  enabled.
  
  ## What changed
  
  - Add the experimental `turn/start.multiAgentMode` parameter with
  `explicitRequestOnly` and `proactive` values. Omission retains the
  loaded session's current optional selection.
  - Add the default-off `features.multi_agent_mode` feature gate. Eligible
  multi-agent v2 turns use the selected mode when enabled; an unset
  selection or disabled gate resolves to `explicitRequestOnly`.
  - Treat mode prompting as inapplicable for multi-agent v1 and other
  unsupported session configurations, producing no multi-agent mode
  developer message rather than rejecting the turn.
  - Move the explicit-request-only rule out of the static v2 usage hint
  and into a bounded, tagged developer context fragment.
  - Emit the effective mode in initial context and only when that
  effective mode changes on later turns.
  - Persist the effective mode in `TurnContextItem` as the durable
  baseline for resume and context-update comparisons.
  
  Historical rollout items are not rewritten. Later mode developer
  messages establish the current rule incrementally.
  
  ## Not covered
  
  - Initial selection through `thread/start` and selected-mode reporting
  from thread lifecycle/settings APIs; those are isolated in the stacked
  #28792.
  - A TUI control or slash command for selecting the mode.
  - Persisting a preferred mode to `config.toml`; selection remains
  session/turn scoped.
  - Changes to multi-agent concurrency limits, tool availability, or model
  catalog capability declarations.
  - Rewriting historical rollout prompt items. Cold resume restores the
  latest persisted effective mode when available while leaving historical
  developer messages intact.
  
  ## Verification
  
  - `CARGO_INCREMENTAL=0 just test -p codex-core multi_agent_mode`
  - Focused app-server coverage verifies that `turn/start.multiAgentMode`
  produces proactive developer instructions for an eligible v2 turn.
  
  ## Stack
  
  Followed by #28792, which adds `thread/start` initialization and
  lifecycle/settings observability.

  Shijie Rao · 2026-06-18 22:47:51 -07:00
  fc8c6b7384
• [codex] Assign response item IDs when recording history (#28814)

  ## Why
  
  Client-created response items enter history without IDs, so their
  identity is lost across rollout persistence and resume. IDs should be
  assigned once at the history-recording boundary, while IDs returned by
  the server must remain unchanged.
  
  The Responses API validates item IDs using type-specific prefixes.
  Locally generated IDs therefore use the matching prefix plus a
  hyphenated UUIDv7, keeping them valid while distinguishable from
  server-generated IDs. Because this changes persisted history and
  provider request shapes, the behavior is opt-in behind the
  under-development `item_ids` feature. Compaction triggers remain request
  controls whose API shape does not accept an ID.
  
  ## What changed
  
  - Register the disabled-by-default `item_ids` feature and expose it in
  `config.schema.json`.
  - Make supported optional `ResponseItem` IDs serializable and expose
  them in the generated app-server schemas.
  - When `item_ids` is enabled, assign an ID during conversation-history
  preparation if an item has no ID.
  - Generate type-prefixed, hyphenated UUIDv7 IDs using the Responses API
  item conventions.
  - Preserve existing server IDs without rewriting them.
  - Persist assigned IDs in rollouts and include them in subsequent
  Responses requests.
  - Remove the unsupported ID field from `CompactionTrigger` and document
  why it has no ID.
  - Add integration coverage for enabled ID persistence, preservation of
  server IDs, and omission of generated IDs while the feature is disabled.
  
  `prepare_conversation_items_for_history` is the single response-item ID
  allocation boundary.
  
  ## Test plan
  
  - `just test -p codex-features`
  - `just test -p codex-core
  response_item_ids_persist_across_resume_and_preserve_server_ids`
  - `just test -p codex-core
  non_openai_responses_requests_omit_item_turn_metadata`
  - `just test -p codex-core
  resize_all_images_prepares_failures_before_history_insertion`
  - `just test -p codex-protocol`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-api azure_default_store_attaches_ids_and_headers`

  pakrym-oai · 2026-06-18 17:30:55 -07:00
  f00f93d8c0
• Always use AVAS for realtime WebRTC calls (#28856)

  ## Summary
  
  - Remove the realtime `architecture` selector from core protocol,
  app-server protocol, config parsing, generated schemas, and callers.
  - Always create WebRTC realtime calls with the AVAS query params:
  `intent=quicksilver&architecture=avas`.
  - Keep direct websocket realtime behavior on the existing config/default
  path, while WebRTC starts without an explicit version now default to
  realtime v1 because AVAS requires v1.
  
  ## Notes
  
  - WebRTC realtime now means AVAS. If a caller explicitly asks to start
  WebRTC with realtime v2, Codex rejects that request because the AVAS
  WebRTC path only supports realtime v1. Websocket realtime is separate
  and can still use realtime v2.
  - The old `[realtime] architecture = "realtimeapi" | "avas"` config knob
  is removed. Local configs that still set it will need to delete that
  line.
  - Some app-server tests that were only trying to exercise realtime v2
  protocol behavior now use websocket transport, because WebRTC is
  intentionally locked to AVAS/v1. Separate WebRTC tests cover the AVAS
  query params, v1 startup, SDP flow, and sideband join.
  
  ## Validation
  
  - Merged fresh `origin/main` at `83e6a786a2`.
  - `just fmt`
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `git diff --check`
  - `just test -p codex-api -p codex-core -p codex-app-server-protocol -p
  codex-app-server realtime` (176 passed)
  - `just test -p codex-protocol -p codex-config` (413 passed)

  Peter Bakkum · 2026-06-18 19:11:21 -05:00
  8e7c213f8f
• core: add UUIDv7 context window IDs (#28953)

  ## Why
  
  The token-budget context currently identifies a context window by its
  thread-local sequence number. A UUIDv7 gives the model a stable opaque
  identity that remains fixed for a window and rotates when compaction or
  `new_context` starts the next one.
  
  ## What changed
  
  - Preserve the existing monotonic value as `window_number` and add a
  UUIDv7 `window_id` to `CompactedItem`.
  - Generate and rotate the UUID with auto-compaction window state,
  persist it alongside the number, and reconstruct it on resume and
  rollback.
  - Accept legacy compacted rollout records where the numeric `window_id`
  represented the window number.
  - Use the UUID only in token-budget context; existing request headers
  and metadata continue using `thread_id:window_number`.
  
  ## Testing
  
  - `just test -p codex-protocol compacted_item::tests`
  - `just test -p codex-core token_budget`

  pakrym-oai · 2026-06-18 17:00:49 -07:00
  5c12034e42
• 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
• 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 turn-scoped context contributions (#28911)

  ## Summary
  - keep context injection on a single ContextContributor trait
  - split context injection into thread-scoped and turn-scoped
  contribution methods
  - wire turn-scoped fragments into initial context assembly so extensions
  can contribute context from turn-local state

  jif · 2026-06-18 19:40:28 +02:00
  9684ec25be
• 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
• [codex] Support assistant realtime append text (#28836)

  ## Why
  
  Frontend realtime voice continuity needs to replay a tiny
  previous-session overlap as actual conversation items, including
  assistant text. The app-server `thread/realtime/appendText` API already
  carries a role through to the Rust realtime websocket layer, but the
  shared role enum only accepted `user` and `developer`.
  
  ## What Changed
  
  - Added `assistant` to `ConversationTextRole` and regenerated the
  app-server schema/type fixtures.
  - Added `output_text` as a realtime conversation content type.
  - Updated realtime websocket item creation so assistant appendText emits
  `content: [{ type: "output_text", text }]`, while user and developer
  continue to emit `input_text`.
  - Updated app-server docs and tests to cover assistant appendText
  alongside the existing developer role behavior.
  
  ## Validation
  
  - `just write-app-server-schema`
  - `just fmt` (first sandboxed attempt failed because `uv` could not
  access `~/.cache/uv`; reran with filesystem access and passed)
  - `just test -p codex-api` passed: 126/126
  - `just test -p codex-app-server-protocol` passed: 239/239, including
  generated JSON/TypeScript fixture checks
  - `just test -p codex-app-server` was started locally but stopped per
  request after unrelated local sandbox/Seatbelt failures (`sandbox-exec:
  sandbox_apply: Operation not permitted`) and one missing local `codex`
  binary failure; CI should be faster and more authoritative for the full
  suite.

  guinness-oai · 2026-06-17 20:57:13 -07:00
  e922f46a0f
• [codex] control automatic realtime handoff delivery (#27986)

  ## What
  
  Built on the realtime speech-control plumbing merged in #27917.
  
  - Add optional `codexResponseHandoffPrefix` to `thread/realtime/start`.
  - Apply that prefix only to automatic V1 commentary sent through
  `conversation.handoff.append`; final answers remain unprefixed.
  - Add opt-in `clientManagedHandoffs`. When true, core suppresses
  automatic response handoffs and completion output so delivery is
  controlled by explicit client append APIs.
  - Preserve existing automatic behavior by default.
  `codexResponsesAsItems: true` continues to select item routing when
  client-managed mode is disabled.
  
  ## Why
  
  Voice clients need two delivery policies: automatic background context
  with silent commentary instructions and fully client-owned handoffs.
  Phase-aware prefixing keeps routine commentary silent without
  suppressing the final answer, while client-managed mode lets an app
  decide exactly which updates to append.
  
  ## Validation
  
  - `just fmt`
  - `cargo test -p codex-app-server-protocol
  serialize_thread_realtime_start`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-core --test all
  conversation_handoff_persists_across_item_done_until_turn_complete`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-app-server --test all
  webrtc_v1_client_managed_handoffs_disable_automatic_output`
  - `RUST_MIN_STACK=16777216 cargo test -p codex-app-server --test all
  webrtc_v1_final_automatic_handoff_omits_silent_prefix`
  - `cargo build -p codex-cli --bin codex`
  - Local Codex Apps compatibility check: 43 focused webview tests passed,
  and a live voice session routed through the source-built app-server.
  
  The explicit `RUST_MIN_STACK` avoids a macOS Tokio test-worker stack
  overflow seen with the default test environment.

  jiayuhuang-openai · 2026-06-18 02:22:29 +00:00
  683bd170dc
• [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
• 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
• 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
• [codex] core: restore absolute turn context cwd (#28629)

  ## Why
  
  #28152 jumped the gun on moving the rollout format to store URIs, and
  would likely break compat with some features that don't go through the
  same types as the core logic.
  
  ## What
  
  Make `TurnContextItem.cwd` an `AbsolutePathBuf` again, remove test added
  for `PathUri` serialization in rollouts. Also drops a bunch of error
  paths that are no longer needed.

  Adam Perry @ OpenAI · 2026-06-16 19:05:26 -07:00
  3d02c443bc
• core: render remote environment cwd natively (#28152)

  ## Why
  
  Model-visible `<environment_context>` should match the environment of
  the executor, not of the app server.
  
  Stacked on #28146.
  
  ## What
  
  - Keep selected environment cwd values as `PathUri` while building
  environment context.
  - Render cwd text using the path convention represented by the URI, with
  the canonical URI as a fallback.
  - Preserve compatibility with legacy `TurnContextItem.cwd` values when
  reconstructing and diffing context.
  - Extend the Wine-backed remote Windows test to assert that the model
  sees `powershell` and `C:\windows`.

  Adam Perry @ OpenAI · 2026-06-16 16:17:47 -07:00
  4c79527e31
• 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] expose Bedrock credential source in account/read (#27751)

  ## Why
  
  `account/read` currently reports only `type: "amazonBedrock"`, so
  clients cannot distinguish a Codex-managed Bedrock API key from
  credentials supplied by AWS. The app UI needs that distinction to render
  the appropriate account state without duplicating provider-auth logic.
  
  Credential-source selection belongs to the Bedrock model provider
  because it already owns the precedence between managed Bedrock auth and
  the external AWS credential path. This builds on #27443 and #27689.
  
  ## What changed
  
  - Added `AmazonBedrockCredentialSource` with `codexManaged` and
  `awsManaged` values.
  - Included the selected credential source in
  `ProviderAccount::AmazonBedrock` and the app-server `Account` response.
  - Made `AmazonBedrockModelProvider::account_state()` classify the source
  from its managed-auth state.
  - Regenerated the app-server JSON and TypeScript schemas.
  - Updated app-server account documentation and downstream TUI matches.
  
  `codexManaged` means the provider found a managed Bedrock API key.
  `awsManaged` identifies the provider's external AWS credential path; it
  does not assert that the AWS credential chain has been validated.
  
  ## Testing
  
  - Added model-provider coverage for Codex-managed precedence and
  AWS-managed fallback.
  - Added app-server protocol serialization coverage for both wire values.
  - Added app-server integration coverage for both `account/read`
  responses.
  - `just test -p codex-protocol -p codex-model-provider -p
  codex-app-server-protocol` (497 tests passed).
  
  After rebasing onto #27711, the `codex-app-server` test target compiled
  past the image-generation `PathUri` migration. Local linking was then
  interrupted by disk exhaustion (`No space left on device`).

  Celia Chen · 2026-06-16 07:14:53 +00:00
  12aaeb7bf8
• [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
• Add a toggle for realtime startup context (#28405)

  ## Summary
  - Add `includeStartupContext` to realtime start requests so callers can
  explicitly skip Codex startup context while keeping the backend prompt
  - Thread the new flag through protocol types, request processing, and
  realtime session config
  - Update app-server docs and coverage for the new default and opt-out
  behavior
  
  ## Testing
  - Added protocol serialization coverage for `includeStartupContext`
  - Added realtime integration coverage for starting a session with
  startup context disabled

  guinness-oai · 2026-06-15 17:14:22 -07:00
  d5b4b98370
• 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
• Add realtime speech append control (#27917)

  ## Why
  
  Realtime voice harness tuning needs app-side control over what backend
  Codex text is spoken. Backend orchestrator text is written for a reading
  UI, so automatically speaking every preamble, progress update, or final
  assistant message can make the realtime voice model too chatty.
  
  For experimentation, clients need two simple controls: keep app/client
  text-item injection on the existing item-create path, and add an
  explicit speakable path that app code can call only when it wants
  realtime to speak. Automatic Codex output also needs an opt-in way to
  switch from the protocol's default speakable path to regular realtime
  items, with a caller-provided prefix so prompt wording can be tuned
  outside core.
  
  The default remains unchanged: if a client omits the new start fields
  and never calls `appendSpeech`, automatic backend output continues down
  the existing speakable path for the selected realtime protocol.
  
  ## What Changed
  
  - Adds experimental `thread/realtime/appendSpeech` for app-provided
  speakable text.
  - Keeps existing `thread/realtime/appendText` as the item-create API for
  app-provided realtime text items.
  - Adds `codexResponsesAsItems` / `codex_responses_as_items` on
  `thread/realtime/start` to send automatic Codex responses with
  `conversation.item.create` instead of the protocol's default speakable
  output path.
  - Adds `codexResponseItemPrefix` / `codex_response_item_prefix` so
  clients can prepend experiment instructions to those automatic Codex
  response items.
  - Keeps literal `conversation.handoff.append` routing scoped to the v1
  speakable path; v2 default speech uses its item/function-output plus
  `response.create` behavior.
  - Removes the earlier public silent-context API and hardcoded
  silent-context prefix.
  - Updates realtime tests to cover default automatic speakable behavior,
  opt-in automatic item-create behavior, and explicit `appendSpeech`
  behavior.
  
  ## Validation
  
  - `cargo check -p codex-core -p codex-app-server -p codex-api`
  - `just test -p codex-app-server realtime_conversation`
  - `just test -p codex-core realtime_conversation` (50/51 passed in the
  filtered parallel run; the lone failure passed when rerun in isolation)
  - `just test -p codex-core
  conversation_mirrors_assistant_message_text_to_realtime_handoff`
  - `just test -p codex-api
  e2e_connect_and_exchange_events_against_mock_ws_server`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server`
  - `cargo build -p codex-cli`

  guinness-oai · 2026-06-15 16:15:58 -07:00
  1d8ff89aa3
• 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
• [codex] preserve explicit environment cwd (#27995)

  ## Why
  
  `TurnEnvironmentSelections::new` rewrote the primary environment's
  explicit `cwd` to the legacy fallback cwd. For a remote-first selection,
  this could replace the remote working directory with a local fallback
  path and made the legacy cwd overlay authoritative over
  environment-owned state.
  
  ## What changed
  
  - Preserve every explicit environment cwd when constructing turn
  environment selections.
  - Keep `cwd`-only app-server updates compatible by rebuilding the
  default environment selections at the requested cwd.
  - Cover both explicit primary cwd preservation and cwd-only updates
  reaching the model-visible execution environment.
  
  ## Testing
  
  - `just test -p codex-core
  session_update_settings_does_not_rewrite_sticky_environment_cwds`
  - `just test -p codex-core
  environment_settings_preserve_explicit_primary_cwd`
  - `just test -p codex-app-server
  thread_settings_update_cwd_retargets_default_environment`

  pakrym-oai · 2026-06-15 17:17:34 +00:00
  bd4fe31c5a
• Expose explicit dynamic tool namespaces in thread start (#27371)

  Stacked on #27365.
  
  ## Stack note
  
  [#27365](https://github.com/openai/codex/pull/27365) kept `thread/start`
  unchanged and converted its input in `thread_processor`. This PR updates
  `thread/start` to accept explicit functions and namespaces directly.
  
  Legacy per-tool arrays are still accepted and converted while reading
  the request. As a result, `thread_processor` can validate and pass the
  tools through directly, which is why some code added in #27365 is
  removed here.
  
  ## Why
  
  `thread/start.dynamicTools` still repeats namespace data on each
  function even though core now stores explicit namespace groups. The
  request API should use the same shape so each namespace has one
  description and one member list.
  
  ## What changed
  
  - Accept top-level functions and explicit namespace objects in
  `dynamicTools`.
  - Continue accepting fully legacy flat arrays, including
  `exposeToContext`.
  - Reject arrays that mix legacy and canonical entries.
  - Reuse the protocol types directly and remove the temporary app-server
  adapter.
  - Update validation, docs, the test client, and generated schemas.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server
  dynamic_tool_call_round_trip_sends_text_content_items_to_model`
  - `just test -p codex-app-server
  thread_start_normalizes_legacy_dynamic_tools_into_model_request`
  - `just test -p codex-app-server
  thread_start_rejects_mixed_dynamic_tool_formats`
  - `just test -p codex-app-server
  thread_start_rejects_hidden_dynamic_tools_without_namespace`

  sayan-oai · 2026-06-15 15:35:57 +00:00
  11faf9af94
• 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] 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] 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
• 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
• 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
• 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
• 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] 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