3916 Commits

• [2/3] core: track starting environments in snapshots (#28683)

  ## Why
  
  Remote environments may still be resolving when Codex creates a session
  or turn. Waiting for the existing all-or-nothing environment snapshot
  can hold startup until the selected environment is usable.
  
  Behind the default-off `deferred_executor` feature, let callers take a
  useful snapshot immediately: completed environments remain available
  normally, while unfinished environments are reported without blocking
  startup. With the feature disabled, snapshots preserve the existing
  blocking behavior.
  
  Depends on #28674.
  
  ## What changed
  
  - Store one ordered list of selected environments in
  `ThreadEnvironments`. Each selection owns one shared resolution that
  produces its complete `TurnEnvironment`.
  - Start new resolutions in the background with `remote_handle()`,
  allowing snapshots and the future wait tool to share the same result
  while cancellation follows the retained handles.
  - Make `snapshot()` a read-only operation: nonblocking snapshots collect
  completed resolutions and retain handles for unfinished ones, while
  blocking snapshots await every resolution.
  - Replace completed failed resolutions from the current manager entry
  and log when failed environments are omitted.
  - Return attached and starting environments as a point-in-time view, and
  count starting environments when deciding whether a snapshot is
  local-only.
  - Keep existing consumers attached-only. `to_selections()` derives from
  attached environments, so child threads do not inherit an environment
  that is still starting.
  
  ## Test plan
  
  - `just test -p codex-core environment_selection`
  - `just test -p codex-core
  deferred_executor_reaches_model_before_remote_environment_is_ready`
  
  ## Landing note
  
  Keep `deferred_executor` disabled for slow-starting executors until
  configurable `environment/add` connection timeouts and caller support
  land. When enabled, an environment that attaches after session startup
  may remain absent from environment-derived model context, tools,
  instructions, skills, and related state until follow-up refresh work
  lands.

  sayan-oai · 2026-06-19 05:06:34 +00:00
  45a133bae0
• core: assign item IDs to compacted replacement history (#29012)

  ## Why
  
  Remote v2 compaction can return replacement-history items without IDs.
  Because replacement history is installed directly, those items bypass
  normal history preparation and remain ID-less in later Responses
  requests even when the `item_ids` feature is enabled.
  
  ## What changed
  
  - Pass the active `TurnContext` into `replace_compacted_history`.
  - When `item_ids` is enabled, assign missing IDs before installing and
  persisting replacement history.
  - Rebuild `CompactedItem` from the prepared history so live and
  persisted replacement histories match.
  - Add integration coverage requiring IDs on every ID-capable input item
  in the initial, remote v2 compaction, and post-compaction requests.
  
  ## Test plan
  
  - `just test -p codex-core response_item_ids`
  - `just test -p codex-core websocket_v2_test_codex_shell_chain`
  - `just test -p codex-core remote_compaction_parity_pre_turn_auto`
  - `just test -p codex-app-server
  thread_inject_items_adds_raw_response_items_to_thread_history`

  pakrym-oai · 2026-06-18 18:49:57 -07:00
  70a6aa2634
• [codex] add clock current-time tool (#29011)

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

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

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

  Alex Daley · 2026-06-18 20:08:04 -04:00
  7e37354a58
• core: 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
• [codex] Reuse parsed plugin skills during session startup (#28844)

  ## Summary
  
  - Preserve raw plugin skill-root snapshots in the matching loaded-plugin
  cache entry, keyed by the effective plugin root identity including
  namespace.
  - Pass those snapshots through `SkillsLoadInput` as an optional preload,
  so session startup reuses plugin parsing while ordinary skill loads pass
  `None`.
  - Keep plugin skill loading cohesive: the existing loaders accept the
  optional snapshots directly, and uncached or marketplace-detail paths do
  not create a cache.
  
  ## Why
  
  Plugin discovery already parses plugin skills to determine available
  capabilities. Cold session startup then scanned and parsed the same
  roots again while building the skills snapshot.
  
  This solves the same duplicate-work problem as #28623 while keeping
  ownership narrow: `PluginsManager` creates and owns
  `PluginSkillSnapshots` only for its loaded-plugin cache entry;
  `SkillsService` consumes an optional clone. Entry replacement or
  clearing naturally drops the snapshots, with no separate generation,
  capacity policy, or watcher coupling.
  
  ## Validation
  
  - `cargo clippy -p codex-core-skills --all-targets -- -D warnings`
  - `just test -p codex-core-plugins
  skills_service_reuses_skills_parsed_during_plugin_load`
  - `just test -p codex-core-skills
  namespaces_plugin_skills_using_provided_namespace`
  - `just fmt`

  xl-openai · 2026-06-18 16:45:58 -07:00
  e83b7841b0
• core: keep remote exec on reported shell (#28983)

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

  Adam Perry @ OpenAI · 2026-06-18 23:39:21 +00:00
  346d2c163f
• core: log AGENTS.md paths as URIs (#28989)

  ## Why
  
  No need to do path contortions when it's for our own logs.
  
  ## What
  
  Follow up on a previous PR's nit and update the path-types skill for
  future reference.

  Adam Perry @ OpenAI · 2026-06-18 16:16:19 -07:00
  195c936fa2
• [codex] Remove child AGENTS.md prompt experiment (#28993)

  ## Why
  
  `child_agents_md` is a disabled, under-development experiment that adds
  a second model-visible explanation of hierarchical `AGENTS.md` behavior.
  Keeping it leaves unused prompt, configuration, documentation, and test
  surface.
  
  ## What changed
  
  - remove the `ChildAgentsMd` feature and `child_agents_md` config schema
  entry
  - remove the hierarchical prompt asset, export, and instruction
  injection
  - remove feature-specific tests and documentation
  - keep the generic unstable-feature warning coverage using
  `apply_patch_streaming_events`
  
  Normal project `AGENTS.md` discovery and composition are unchanged.
  
  ## Testing
  
  - `just test -p codex-features`
  - `just test -p codex-prompts`
  - `just test -p codex-core agents_md`
  - `just test -p codex-core unstable_features_warning`

  pakrym-oai · 2026-06-18 16:13:07 -07:00
  bb72e151e5
• core: load AGENTS.md from foreign environments (#28958)

  ## Why
  
  Make it possible to load AGENTS.md from remote exec-servers whose OS is
  different than app-server.
  
  ## What
  
  - keep `AGENTS.md` discovery and provenance as `PathUri`, with
  root-aware parent and ancestor traversal
  - expose lifecycle instruction sources as legacy app-server path strings
  in events while retaining `PathUri` internally
  - preserve and test mixed POSIX and Windows paths in model context and
  TUI status output
  - cover remote Windows loading end to end by seeding the Wine prefix
  through host filesystem APIs
  - fix bug in `PathUri`'s parent() implementation that would erase
  Windows drive letters

  Adam Perry @ OpenAI · 2026-06-18 15:06:23 -07:00
  dce673905a
• [connectors] Ignore synthetic links for app accessibility (#28770)

  Summary
  - Stop treating Codex Apps MCP tools with
  `_meta._codex_apps.synthetic_link: true` as evidence that a connector is
  accessible in `app/list`.
  - Preserve synthetic tools in the agent-facing MCP connector set so they
  remain available for install/auth flows.
  - Keep the app-list accessibility cache limited to connectors backed by
  at least one non-synthetic tool.
  - Add focused regression coverage for both sides of the boundary.
  
  Validation
  - `just fmt`
  - `just test -p codex-core
  synthetic_links_are_exposed_to_the_agent_but_not_accessible_in_app_list`
  - `git diff --check`
  - A crate-wide `just test -p codex-core` run completed with 2,699
  passing and 51 unrelated local sandbox/state failures, primarily state
  DB migration races (`UNIQUE constraint failed:
  _sqlx_migrations.version`).

  Alex Daley · 2026-06-18 17:19:24 -04:00
  4af7762f01
• feat: opt ChatGPT auth into agent identity (#19049)

  ## Stack
  
  This is PR 2 of the simplified HAI single-run-task stack:
  
  - [#19047](https://github.com/openai/codex/pull/19047) Agent Identity
  assertion and task-registration primitives, including the shared
  run-task helper used by existing Agent Identity JWT auth.
  - [#19049](https://github.com/openai/codex/pull/19049)
  Disabled-by-default ChatGPT auth opt-in that provisions/reuses persisted
  Agent Identity runtime auth and its single run task.
  - [#19051](https://github.com/openai/codex/pull/19051) Run-scoped
  provider auth that uses one backend-owned task id for first-party
  inference and compaction requests.
  
  [#19054](https://github.com/openai/codex/pull/19054) collapsed out of
  the active stack because the simplified design no longer needs a
  separate background/control-plane task helper.
  
  ## Summary
  
  This PR adds the disabled-by-default path for normal ChatGPT-login Codex
  sessions to obtain Agent Identity runtime auth through the Codex
  backend. Existing Agent Identity JWT startup mode remains a separate
  path and does not require the feature flag.
  
  What changed:
  
  - adds the experimental `use_agent_identity` feature flag and config
  schema entry
  - adds an explicit `AgentIdentityAuthPolicy` so call sites choose
  `JwtOnly` or `ChatGptAuth` instead of passing a bare boolean
  - stores standalone Agent Identity JWT credentials separately from
  backend-registered Agent Identity records
  - persists the registered Agent Identity record, private key, and single
  run task id in `auth.json` so process restarts reuse the same identity
  - derives the agent/task registration base URL from ChatGPT/Codex auth
  config while keeping JWT JWKS lookup separate
  - provisions and caches ChatGPT-derived Agent Identity runtime auth when
  `use_agent_identity` is enabled
  - reuses the shared run-task registration helper from PR1 rather than
  adding a second task-registration path
  
  This PR intentionally does not switch model inference over to
  `AgentAssertion` auth. The provider-auth integration lands in the next
  PR.
  
  ## Testing
  
  - `just test -p codex-login`

  Adrian · 2026-06-18 14:05:27 -07:00
  ec848dde0e
• 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
• [codex] Remove hardcoded app ID filters (#28947)

  ## Summary
  
  - remove the duplicated originator-specific connector ID denylists
  - stop filtering connector directory/accessibility results and
  live/cached Codex Apps MCP tools by hardcoded connector ID
  - remove the now-unused `codex-login` dependency from
  `codex-utils-plugins`
  - update regression coverage so formerly blocked connector IDs are
  preserved
  
  ## Why
  
  The client-side policy was duplicated across crates, used opaque IDs
  without ownership or expiry information, and could drift between app
  listing and MCP tool behavior. Server-provided visibility,
  authorization, plugin discoverability, accessibility, enabled-state
  handling, and consequential-tool approval templates remain unchanged.
  
  ## Validation
  
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `git diff --check`
  - confirmed the final diff contains no hardcoded denylist symbols
  
  A targeted `codex-mcp` test build spent an unusually long time in local
  compilation/linking. Its first attempt exposed a test-only `PartialEq`
  assertion issue, which was corrected. A follow-up non-linking `cargo
  check -p codex-mcp --tests` was still running when this draft was
  opened; CI should provide the complete Rust validation.

  Eric Ning · 2026-06-18 20:29:01 +00:00
  29eb434bc5
• apply-patch: carry paths as PathUri (#28854)

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

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

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

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

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

  Gabriel Peal · 2026-06-18 11:54:49 -07:00
  21a599fa56
• [codex] rollout budget implementation (varlength 2/N) (#28494)

  ## Stack
  
  Depends on #28746. This PR implements shared rollout-budget accounting
  and model-visible reminders using the configuration defined in #28746.
  
  # Description / Main changes to Core:
  
  `AgentControl` will now be the area where "rollout level" features &
  accounting will have to live. It is incorrectly named for this
  responsibility, but I think it can hold all the necessary shared state &
  features (rollout token budget, mutliple thread interruption
  responsibilitym etc)
  
  In this PR, we have one "token ledger" that each thread will subtract
  from when sampling. The "charge" will occur when response.completed() is
  done and the calculation will be done on the responses api usage
  carrier. The calculation will weigh sampling and pre-fill tokens as
  specified.
  
  Every time the budget crosses the configured reminder threshold, a
  developer message is appended before the thread's next request
  
  This remaining budget will _always_ be restated/reminded after a
  compaction event.
  
  Expiration and fan-out interruption will be in the stacked follow-up
  (and also live in Agent Control).
  
  ## Reminders
  
  "You have weighted {session_tokens_left} tokens left in the shared
  session token budget."
  
  The first request in each thread context receives the current remainder.
  Later reminders are emitted after aggregate weighted usage crosses a
  configured interval. If several intervals are crossed before a thread
  sends another request, Core inserts one reminder with the latest
  remainder.
  
  Compaction response usage is charged before the next context starts. The
  next reminder is appended after the compaction summary, leaving the
  initial context content stable.
  
  ## Tests
  
  Integration coverage verifies:
  
  - weighted output and non-cached input accounting
  - initial and periodic reminders
  - shared accounting between a root and sub-agent
  - post-compaction remainder and message placement
  
  Local checks:
  
  - `just fmt`
  - `just test -p codex-core rollout_budget`
  - `git diff --check`
  
  The full workspace test suite was not run locally.

  rka-oai · 2026-06-18 18:52:19 +00:00
  32a696dbac
• Add Config for Time Reminders (varlatency 1/n) (#28822)

  ## Summary
  
  Example:
  
  > [features.current_time_reminder]
  enabled = true
  reminder_interval_model_requests = 1
  clock_source = "system"
  
  ## Testing
  
  - `just test -p codex-core varlatency`
  - `just test -p codex-core
  lock_contains_prompts_and_materializes_features`
  - `just fix -p codex-core -p codex-config -p codex-features`

  rka-oai · 2026-06-18 11:39:02 -07:00
  df5f122854
• Fix goal-first live threads missing from thread/list (#28808)

  Fixes #28263.
  
  ## Why
  
  When a thread starts with `/goal`, the goal extension can update SQLite
  goal state before the thread has any user-turn rollout items.
  `thread/list` and `thread/search` rely on persisted listing metadata, so
  a goal-first live thread could be absent from app-server listings after
  restart even though the goal itself existed.
  
  This regressed when goal handling moved out of core: the core path wrote
  the goal update through the live thread rollout path, while the
  extension-backed app-server path only updated goal state and emitted the
  live notification.
  
  ## What
  
  - Add `GoalSetOutcome::thread_goal_updated_item()` so the goal extension
  owns the canonical `ThreadGoalUpdated` rollout item shape.
  - Expose a narrow `CodexThread::append_rollout_items()` helper that
  appends through the live thread and keeps derived SQLite metadata in
  sync.
  - When app-server sets a goal on an active live thread, persist the goal
  update through that live-thread path.
  - Add an app-server regression test that starts a live thread with
  `thread/goal/set` and verifies it appears in state-DB-only
  `thread/list`.
  
  ## Verification
  
  - `env -u CODEX_SQLITE_HOME just test -p codex-app-server
  goal_first_live_thread_appears_in_state_db_thread_list`

  Eric Traut · 2026-06-18 10:50:15 -07:00
  e8dd1b45cb
• 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
• Scope MCP sandbox metadata to server environment (#28914)

  Scope MCP sandbox metadata to the MCP server's owning environment.
  
  Previously, `codex/sandbox-state-meta` always used the turn's primary
  cwd and rebuilt a legacy sandbox policy from that cwd. That can be wrong
  for MCP servers owned by a different execution environment.
  
  This now sends the owning environment cwd as a `file:` URI in
  `sandboxCwd`, keeps `permissionProfile` as the permission source of
  truth, and omits sandbox-state metadata when a non-default server
  environment is not selected for the turn. Local/default MCP servers keep
  the existing fallback cwd behavior.
  
  Tests:
  - `just fmt`
  - `just bazel-lock-update`
  - `just bazel-lock-check`
  - `just test -p codex-mcp`
  - `just test -p codex-core mcp_sandbox_cwd`
  - `cargo build -p codex-rmcp-client --bin test_stdio_server`
  - `just test -p codex-core
  stdio_mcp_tool_call_includes_sandbox_state_meta`

  jif · 2026-06-18 19:31:07 +02:00
  790213ded0
• Avoid sandbox helper in apply_patch approval tests (#28915)

  ## Summary
  This keeps the apply_patch approval tests focused on approval behavior
  instead of macOS sandboxed filesystem helper startup.
  
  The changed cases still force patch approval with `UnlessTrusted`, but
  use `DangerFullAccess` after approval so the patch write is direct and
  cheap. Workspace-write and sandbox-helper behavior remain covered by the
  filesystem and apply_patch sandbox tests.

  jif · 2026-06-18 15:13:55 +02:00
  5670360009
• Add network environment ID plumbing (#28766)

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

  jif · 2026-06-18 14:09:38 +02:00
  0369b24d54
• [codex] add rollout token budget configuration (varlength 1/N) (#28746)

  ## What
  
  This PR defines the structured configuration contract for shared rollout
  token budgets (across ALL agent threads under 1 rollout).
  
  ```toml
  [features.rollout_budget]
  enabled = true
  limit_tokens = 100000
  reminder_interval_tokens = 10000
  sampling_token_weight = 1.0
  prefill_token_weight = 0.1
  ```
  
  The reminder interval defaults to 10% of the rollout limit. Sampling and
  prefill weights default to `1.0`.
  
  ## Scope
  
  This PR only defines and validates configuration. It does not track
  usage, inject reminders, or stop a rollout. Accounting and reminders are
  implemented in the stacked follow-up #28494.
  
  The existing `token_budget` feature remains unchanged. `rollout_budget`
  has its own feature key and configuration type.
  
  ## Tests
  
  The config test verifies that the structured fields resolve into
  `RolloutBudgetConfig` and do not enable the existing `token_budget`
  feature.
  
  Local checks:
  
  - `just write-config-schema`
  - `just test -p codex-core load_config_resolves_rollout_budget`
  - `cargo check -p codex-thread-manager-sample`
  - `git diff --check`
  
  The full workspace test suite was not run locally.

  rka-oai · 2026-06-18 04:29:47 -07:00
  ecc4c30e28
• unified-exec: retain PathUri in command events (#28780)

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

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

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

  Won Park · 2026-06-18 04:07:54 +00:00
  78a9e169bb
• [codex] 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] Use unique IDs for realtime-routed turns (#28826)

  ## Why
  
  A durable realtime voice orchestrator can reconnect and resume through
  multiple fresh `Session` instances. Realtime handoffs were using the
  Session-local `auto-compact-N` counter as their turn identity, but that
  counter restarts at zero for every resumed Session. The durable thread
  could therefore accumulate duplicate turn IDs, violating the uniqueness
  assumptions made by app-server and web clients. In Codex Apps, a new
  delegated response stream could be attached to an older turn with the
  same ID, placing live output higher in history and putting turn-scoped
  actions at risk.
  
  Persisted rollout and reconstructed model-context order were already
  correct because raw response items remain append-only and chronological.
  This change restores unique identity for reconstructed and live turn
  surfaces.
  
  ## What changed
  
  - Generate a UUIDv7 specifically for each realtime-routed delegation.
  - Leave the existing `auto-compact-N` identity path unchanged for actual
  internal auto-compaction turns.
  - Extend the inbound realtime handoff integration test to require a UUID
  turn ID from `turn/started`.
  
  ## Verification
  
  - `just test -p codex-core inbound_handoff_request_starts_turn`
  - `just fix -p codex-core`
  - `just fmt`

  guinness-oai · 2026-06-17 19:13:38 -07:00
  a306ac4ee3
• [codex] Add optional IDs to response items (#28812)

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

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

  Add more tracing spans around tool building.

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

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

  Adam Perry @ OpenAI · 2026-06-17 19:36:16 +00:00
  5867b529ae
• [codex] Restore thread recency with compatible migration history (#28671)

  ## Summary
  
  - Revert #28655, restoring the thread `recencyAt` behavior introduced by
  #27910.
  - Move `threads_recency_at` to migration 0039 so it no longer collides
  with `external_agent_config_imports` at version 0038.
  - Repair databases that already applied the recency migration as version
  38 by moving the matching migration-history row to version 39 before
  SQLx validation. The current version-38 migration can then apply
  normally.
  
  ## Validation
  
  - `just test -p codex-state
  migrations::tests::repairs_recency_migration_that_was_applied_as_version_38`
  - `just test -p codex-state -p codex-rollout -p codex-thread-store -p
  codex-app-server-protocol -p codex-tui`: 3,439 passed; six TUI tests
  could not open the machine's existing read-only incident database at
  `~/.codex/sqlite/state_5.sqlite`.
  - `just fix -p codex-state`
  - `just fmt`
  - Verified that state migration versions are unique.

  Jeremy Rose · 2026-06-17 18:52:18 +00:00
  7dc7096ae1
• Scope command approvals by execution environment (#28738)

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

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

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

  iceweasel-oai · 2026-06-17 10:00:42 -07:00
  ef75171f18
• [ez][codex-rs] Support apps._default.default_tools_approval_mode (#27965)

  [from codex]
  
  ## Summary
  
  - add `default_tools_approval_mode` to `[apps._default]` and expose it
  through app-server v2 `config/read`
  - apply it after managed, per-tool, and per-app approval settings,
  before the built-in `auto` fallback
  - document the precedence, regenerate config/app-server schemas, and add
  unit plus end-to-end approval coverage
  
  ## Configuration
  
  ```toml
  [apps._default]
  default_tools_approval_mode = "prompt"
  ```
  
  The effective precedence is managed requirements, tool-specific
  `approval_mode`, app-specific `default_tools_approval_mode`,
  `apps._default.default_tools_approval_mode`, then `auto`.
  
  ## Test plan
  
  - `just write-config-schema`
  - `just write-app-server-schema`
  - `just write-app-server-schema --experimental`
  - `just test -p codex-core app_tool_policy`
  - `just test -p codex-core mcp_turn_metadata`
  - `just test -p codex-config`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server config_read_includes_apps`
  - `just fix -p codex-config -p codex-core -p codex-app-server-protocol
  -p codex-app-server`
  - `just fmt`

  Alex Zamoshchin · 2026-06-17 08:50:39 -07:00
  c78911e37f
• Replace SkillsManager with SkillsService (#28705)

  ## Why
  
  Host skill discovery was still exposed as a manager even though it is a
  process-owned service shared by sessions, the app-server catalog, and
  file-watcher invalidation. The skills extension also consumed an ad hoc
  loaded-skills wrapper instead of a named immutable snapshot.
  
  ## What changed
  
  - replace `SkillsManager` with concrete `SkillsService`
  - make the service cache and return immutable `HostSkillsSnapshot`
  values
  - migrate the skills extension host provider to the snapshot boundary
  - migrate app-server catalog, watcher, and invalidation paths to the
  service
  
  This keeps the service limited to host discovery, caching, roots, and
  invalidation. Catalog rendering and invocation remain extension
  responsibilities for the next stacked change.

  jif · 2026-06-17 17:01:06 +02:00
  0318381762
• app-server: keep the model cache warm (#28699)

  ## Why
  
  The app server is long-lived, but its shared model cache otherwise
  refreshes only when a caller needs it. Once the five-minute cache
  expires, starting a thread or calling `model/list` can wait for
  `/models` on the request path.
  
  Refresh the cache in the background before it expires so foreground
  callers normally use fresh local state.
  
  ## What changed
  
  - Start an app-server worker that refreshes models immediately and then
  every three minutes using the existing models-manager API.
  - Hold only a weak reference to the models manager between refreshes, so
  the worker does not extend its lifetime.
  - Stop scheduling refreshes when the app-server lifecycle handle is shut
  down or dropped. A refresh already in progress is allowed to finish.
  - Adjust affected app-server test fixtures to distinguish the background
  `/models` probe from the connection they are testing.
  
  The existing models-manager cache, refresh strategies, auth handling,
  ETag behavior, and concurrency semantics are unchanged.
  
  ## Testing
  
  -
  `models_refresh_worker::tests::refreshes_immediately_periodically_and_stops_when_dropped`
  -
  `suite::v2::remote_control::listen_off_honors_persisted_remote_control_enable`
  -
  `suite::v2::attestation::attestation_generate_round_trip_adds_header_to_responses_websocket_handshake`

  jif · 2026-06-17 16:18:39 +02:00
  5935a90619
• 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] Persist built-in image results reported as generating (#28656)

  ## Why
  
  #27920 stopped persisting image-generation items unless their status was
  `completed`, preventing failed standalone extension items with empty
  results from being saved. Built-in image generation can instead emit a
  terminal `response.output_item.done` containing a complete base64 PNG
  while the item status remains `generating`. In that case, app-server
  emits no `savedPath`, so Codex Apps can render the inline image but
  cannot expose a file artifact.
  
  ## What changed
  
  - Persist image-generation items whenever `result` contains image data.
  Failed terminal items still have empty results and remain unpersisted.
  - Update the existing built-in image-generation integration test to
  cover a terminal `generating` item and verify both `saved_path` and the
  written PNG bytes.
  
  ## Validation
  
  - Confirmed with a raw built-in websocket trace: the image progressed
  through `in_progress`, `generating`, and `partial_image`, then emitted
  one `response.output_item.done` with `status: "generating"` and a
  complete PNG result.
  - `just test -p codex-core builtin_image_generation_call_persisted` is
  currently blocked before test execution by a pre-existing compile error
  in `thread-store/src/thread_metadata_sync.rs:171`.

  Won Park · 2026-06-17 06:03:00 +00:00
  1315198853
• core: remove redundant TurnContext and Prompt fields (#28638)

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

  pakrym-oai · 2026-06-16 22:17:24 -07:00
  172b2218a5
• Revert thread recencyAt for sidebar ordering (#28655)

  ## Why
  
  Revert #27910 to remove the newly introduced thread `recencyAt`
  persistence and API behavior from `main`.
  
  ## What changed
  
  This reverts commit `fac3158c2a783095768076489815f361fa9b0db4`,
  including the state migration, thread-store propagation, app-server API
  surface, generated schemas, and related tests.
  
  ## Validation
  
  Not run before opening; relying on CI for the initial fast signal.

  pakrym-oai · 2026-06-16 21:39:30 -07:00
  cb15c64760
• [codex] Test code-mode variable truncation (#28471)

  ## Summary
  
  Code mode has two separate truncation points: the nested tool result
  returned to JavaScript and the code-mode output later recorded for the
  model. These tests now verify those behaviors independently.
  
  - Report whether `result.output` was truncated before printing it.
  - Verify omitted or sufficiently large nested limits produce `Variable
  truncated: False`, while allowing the printed value to be truncated
  downstream.
  - Verify an explicit nested limit produces `Variable truncated: True`
  when the command output exceeds it.
  - Use a token-policy model fixture so downstream truncation is visible
  as `…N tokens truncated…`.
  - Align the explicit nested-truncation expectation with the warning
  header.
  
  This PR changes test coverage only; runtime truncation behavior is
  unchanged.
  
  ## Validation
  
  - `env -u CODEX_SANDBOX_NETWORK_DISABLED RUST_MIN_STACK=8388608 cargo
  test -p codex-core --test all code_mode_exec -- --nocapture` (8 passed)

  Ahmed Ibrahim · 2026-06-16 20:14:23 -07:00
  0a3ad4c4ba
• [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
• Add thread recencyAt for sidebar ordering (#27910)

  ## Summary
  
  Add a server-owned `recencyAt` timestamp and `recency_at` thread-list
  sort key for product recency ordering while preserving the existing
  meaning of `updatedAt` as the latest persisted thread mutation.
  
  This is the server-side alternative to #27697. Rather than narrowing
  `updatedAt`, clients can sort the sidebar by `recency_at` and continue
  treating `updatedAt` as mutation time.
  
  Paired Codex Apps PR:
  [openai/openai#1024599](https://github.com/openai/openai/pull/1024599)
  
  ## Contract
  
  - `recencyAt` initializes when a thread is created.
  - A turn start advances `recencyAt` monotonically.
  - Commentary, agent output, tool results, token/accounting updates, turn
  completion, archive, unarchive, resume, and generic metadata writes do
  not advance it.
  - `updatedAt` retains its existing behavior and continues to advance for
  persisted thread mutations.
  - Current servers populate `recencyAt`; the response field is optional
  in generated TypeScript so clients connected to older servers can fall
  back to `updatedAt`.
  - Filesystem-only fallback uses existing updated/mtime ordering when
  SQLite is unavailable.
  
  ## Persistence and compatibility
  
  Migration 0038 adds second- and millisecond-precision recency columns,
  backfills them from the existing updated timestamp, creates list
  indexes, and includes an insert trigger so older binaries writing to a
  migrated database seed recency without causing later mutations to
  advance it.
  
  Generic metadata upserts preserve existing recency values. Turn-start
  updates use a dedicated monotonic touch, and process-local allocation
  keeps millisecond cursor values unique. State DB list, search, read,
  filtered-list repair, rollout fallback propagation, and app-server
  conversions all carry the new field.
  
  ## API
  
  `Thread` responses include:
  
  ```ts
  recencyAt?: number
  ```
  
  `thread/list` and `thread/search` accept:
  
  ```json
  { "sortKey": "recency_at" }
  ```
  
  Generated TypeScript and JSON schemas are included.
  
  ## Validation
  
  - `just test -p codex-state` — 146 passed
  - `just test -p codex-rollout` — 69 passed
  - `just test -p codex-thread-store` — 81 passed
  - `just test -p codex-app-server-protocol` — 231 passed
  - Focused app-server list ordering, response mapping, archive/unarchive,
  and resume lifecycle tests passed
  - Scoped `just fix` for state, rollout, thread-store,
  app-server-protocol, and app-server
  - `just fmt`
  - `git diff --check`
  - Independent correctness, simplicity, elegance, security, and
  test-quality reviews; actionable ordering, lifecycle, query-projection,
  and timestamp-uniqueness findings were addressed

  Jeremy Rose · 2026-06-16 17:06:22 -07:00
  fac3158c2a
• PAC 1 - Add system proxy feature config surface (#26706)

  ## Summary
  
  Introduces the default-off `respect_system_proxy` feature flag used to
  gate first-class system PAC/proxy support for Codex-owned native
  clients.
  
  With the feature disabled or absent, behavior remains unchanged. This PR
  establishes the configuration and managed-requirement surface; proxy
  discovery and request routing are implemented by follow-up PRs.
  
  ## Configuration
  
  User configuration uses the standard boolean feature form:
  
  ```toml
  [features]
  respect_system_proxy = true
  ```
  
  Managed feature requirements use the corresponding boolean key. The
  effective runtime configuration is exposed as a boolean and defaults to
  `false`.
  
  ## Implementation
  
  - Registers `respect_system_proxy` as an under-development, default-off
  feature.
  - Resolves user configuration and managed feature requirements into
  `Config.respect_system_proxy`.
  - Provides bootstrap resolution for startup paths that must evaluate the
  feature before full configuration loading completes.
  - Uses the standard feature CLI and config-editing behavior.
  - Excludes `features.respect_system_proxy` from project-local
  configuration.
  - Updates the generated configuration schema.
  
  ## End-user behavior
  
  - No networking behavior changes when the feature is absent or disabled.
  - Enabling the feature makes the boolean available to the native
  proxy-routing implementation in follow-up PRs.
  - Repository-local configuration cannot enable the feature.
  
  ## Test coverage
  
  Covers scalar configuration and CLI override resolution, managed
  requirement constraints, bootstrap resolution, and project-local
  filtering.

  canvrno-oai · 2026-06-16 16:54:37 -07:00
  f0cb96bcb1
• [codex] [4/4] Simplify recommended plugin install schema (#28403)

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

  Alex Daley · 2026-06-16 23:44:42 +00:00
  a397b59887
• 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