1074 Commits

• Expose MCP app identity in app context (#29934)

  ## Why
  
  MCP tool-call events need to expose trusted app identity and action
  metadata directly so v2 clients do not have to infer it from tool names
  or resource URIs.
  
  ## What changed
  
  - Add optional `appName`, `templateId`, and `actionName` fields to MCP
  tool-call `appContext`.
  - Populate `appName` and `templateId` from trusted Codex Apps metadata,
  and derive `actionName` from the trusted app resource metadata.
  - Preserve all three fields through core events, legacy protocol events,
  persisted thread history, resume redaction, and app-server v2 responses.
  - Document the public `appContext` fields in
  `codex-rs/app-server/README.md`.
  - Regenerate app-server JSON and TypeScript schemas and add coverage for
  serialization, persistence, redaction, and metadata propagation.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol mcp_tool_call`
  - `just test -p codex-core
  mcp_tool_call_item_metadata_only_trusts_codex_apps_identity
  mcp_tool_call_item_includes_app_identity`
  - `just write-app-server-schema`
  
  ---------
  
  Co-authored-by: Martin Au-Yeung <280153141+martinauyeung-oai@users.noreply.github.com>

  Martin Au-Yeung · 2026-06-25 18:31:10 -07:00
  ec300bc7bd
• [codex] Attribute app-server analytics by thread originator (#29935)

  ## Why
  
  Desktop Work threads and regular Codex threads can share the same
  app-server connection. App-server analytics currently copy
  `product_client_id` from connection metadata for every thread-scoped
  event, so Work thread activity is attributed to the Desktop connection
  instead of the thread's resolved originator. This prevents analytics
  from distinguishing the two products on a shared connection.
  
  ## What changed
  
  - Publish the resolved originator after a thread is materialized,
  covering new, resumed, forked, and subagent threads.
  - Store that originator in the analytics reducer's existing per-thread
  state.
  - Override only `app_server_client.product_client_id` for thread, turn,
  tool, review, goal, guardian, and compaction events while preserving the
  connection's client name, version, and transport metadata.
  - Fall back to the connection-wide product client ID when a thread has
  no originator override.
  - Preserve persisted originators in thread initialization analytics for
  resume and fork flows.
  
  ## Validation
  
  - `just test -p codex-analytics
  thread_originator_overrides_shared_connection_across_thread_events
  subagent_events_keep_thread_originator_with_explicit_turn_connection`
  - `just test -p codex-app-server
  turn_start_tracks_thread_originator_in_analytics
  thread_start_tracks_thread_initialized_analytics
  thread_fork_tracks_thread_initialized_analytics
  thread_resume_tracks_thread_initialized_analytics`
  - `just test -p codex-core thread_manager`

  alexsong-oai · 2026-06-25 18:15:48 -07:00
  841f30598c
• Project selected plugin runtime by environment availability (#30093)

  ## Why
  
  Selected plugin metadata is stable, but MCP processes are live runtime
  state. They need different lifetimes:
  
  - the MCP extension caches manifest, MCP, and connector declarations for
  each stable selected root;
  - each model step projects that cached metadata through the roots that
  resolved as ready for that exact step;
  - the MCP manager is rebuilt only when that availability projection
  changes.
  
  This matches executor skills: both features consume the same resolved
  step roots instead of inferring readiness from the turn's selected
  environments.
  
  ## Behavior
  
  ```text
  E1 not ready for this step
    -> no E1 MCP servers or connectors
    -> cached plugin metadata stays in ext/mcp
  
  E1 becomes ready
    -> reuse cached metadata
    -> publish one MCP runtime containing E1 capabilities
  
  same ready roots on the next step
    -> reuse the exact runtime; no rediscovery and no MCP restart
  
  resume
    -> create new extension thread state and a new MCP runtime
  ```
  
  All model-facing consumers use the same step snapshot:
  
  ```text
  resolved selected roots
          |
          v
  extension MCP/connector projection
          |
          v
  { MCP config, connector snapshot, MCP manager }
          |
          +-> advertise model tools
          +-> build app/connector tools
          +-> execute MCP calls
  ```
  
  ## Cache contract
  
  The existing MCP extension owns a cache keyed by the full
  `SelectedCapabilityRoot`:
  
  ```rust
  let state = thread_store.get_or_init(SelectedExecutorPluginMcpState::default);
  ```
  
  The cache lives with extension thread state. Environment availability
  filters projection but does not invalidate metadata. Resume creates new
  thread state. There is no file watcher or executor generation because
  contents behind a stable environment/root are assumed stable.
  
  ## What changes
  
  - Keeps executor plugin discovery and cached metadata in `ext/mcp`.
  - Caches MCP and connector declarations together per selected root.
  - Uses the step's already-resolved capability roots, including lazy
  environments that are not turn environments.
  - Reuses the current MCP runtime when the ready-root projection is
  unchanged.
  - Uses the same step MCP manager and connector snapshot for
  model-visible tools and execution.
  - Resolves direct thread-scoped MCP requests from the current
  selected-root projection.
  
  ## Deliberately out of scope
  
  - `app/list` remains based on the latest global host-plugin state; this
  PR does not make its response or notifications thread-specific.
  - `required = true` startup semantics do not apply to delayed executor
  MCP activation.
  - No filesystem/content invalidation.
  - No transport-disconnect watcher.
  - No executor generations or environment replacement semantics.
  - No client sharing across complete manager replacements.
  
  ## Stack
  
  1. Extension-owned World State sections.
  2. Project executor skills through World State.
  3. Pin one MCP runtime to each model step.
  4. **This PR:** project selected MCP and connector state from
  extension-owned metadata.
  5. Integration coverage for selected capability availability and resume.
  
  ## Verification
  
  -
  `selected_plugin_servers_use_managed_requirements_for_the_selected_root_id`
  - The stacked integration PR covers unavailable to ready activation,
  unchanged-runtime reuse, skills, MCP tools, connector attribution, and
  cold resume.

  jif · 2026-06-26 01:36:44 +01:00
  3095ea9c3d
• Pin MCP runtimes to model steps (#30101)

  ## Why
  
  An MCP refresh can replace the session's current manager while a model
  step is still running. The step must execute calls through the same
  manager whose tools it advertised.
  
  ## Boundary
  
  ```text
  current session MCP runtime
            |
            | capture once for this model step
            v
  StepContext.mcp
    - exact MCP config
    - exact connection manager
    - exact runtime environment context
  ```
  
  ```rust
  pub struct McpRuntimeSnapshot {
      config: Arc<McpConfig>,
      manager: Arc<McpConnectionManager>,
      runtime_context: McpRuntimeContext,
  }
  ```
  
  ## Example
  
  ```text
  step A captures runtime A and advertises A's tools
  refresh publishes runtime B
  step A tool call -> runtime A
  next step        -> runtime B
  ```
  
  Capturing the snapshot is only an `Arc` clone. It does not restart MCPs
  or make an RPC.
  
  ## What changes
  
  - Captures one MCP runtime in `StepContext`.
  - Uses it for tool planning, tool calls, resources, approvals, connector
  attribution, and elicitation.
  - Publishes replacement runtimes atomically.
  - Lets an old runtime live only while an in-flight step or request still
  holds its `Arc`.
  
  Most of this diff is mechanical routing from the session-global manager
  to `step_context.mcp`; it does not introduce selected-plugin discovery
  yet.
  
  ## What does not change
  
  - No plugin or extension migration.
  - No new MCP cache policy.
  - No environment file watching.
  - No client sharing between separate managers.
  
  ## Stack
  
  1. Extension-owned World State sections.
  2. Project executor skills through World State.
  3. **This PR:** pin one MCP runtime to each model step.
  4. Project selected MCP/app/connector metadata by environment
  availability.
  5. One end-to-end integration scenario.

  jif · 2026-06-26 00:53:07 +01:00
  ee9e0f6387
• [codex] Surface MCP reauthentication-required startup failures (#29877)

  ## Summary
  
  - distinguish expired, non-refreshable stored MCP OAuth credentials from
  first-time missing credentials
  - carry a typed `failureReason: "reauthenticationRequired"` on the
  existing `mcpServer/startupStatus/updated` notification only when user
  action is required
  - keep the public MCP auth-status API unchanged and regenerate the
  app-server protocol schemas and documentation
  
  ## Why
  
  An MCP server with an expired access token and no usable refresh token
  currently fails startup without giving clients a reliable, typed
  recovery signal.
  
  The existing startup-status notification is the natural place to carry
  this state. Its nullable `failureReason` keeps the recovery reason
  attached to the failed startup transition without adding a one-off
  notification. Internally, Codex distinguishes first-time login from
  reauthentication and emits the reason only when the startup error itself
  requires authentication.
  
  ## User impact
  
  App clients can prompt an existing user to reconnect an MCP server when
  automatic recovery is impossible by handling a failed
  `mcpServer/startupStatus/updated` notification whose `failureReason` is
  `reauthenticationRequired`. Starting, ready, cancelled, unrelated
  failures, and first-time setup carry no reauthentication reason.
  
  ## Companion app PR
  
  - openai/openai#1069582
  
  ## Validation
  
  - `just test -p codex-app-server-protocol` — 248 passed; schema fixture
  tests passed
  - `cargo check -p codex-app-server -p codex-tui`
  - `just test -p codex-rmcp-client -p codex-mcp` — 184 passed, 2 skipped
  - `just test -p codex-protocol -p codex-app-server-protocol -p
  codex-mcp` — 579 passed
  - `just write-app-server-schema`
  - `just fmt`

  felixxia-oai · 2026-06-25 21:50:36 +00:00
  a6d20ed297
• fix(app-server): suppress TUI rollback warning (#30124)

  ## Why
  
  The TUI uses `thread/rollback` internally for user-facing flows such as
  prompt cancellation/backtracking. After `thread/rollback` was marked
  deprecated, those internal calls started surfacing `deprecationNotice`
  messages in the TUI, even though the user did not explicitly call the
  deprecated app-server API.
  
  The endpoint should remain deprecated for external app-server clients,
  but the built-in `codex-tui` client should not show this
  implementation-detail warning during normal interaction.
  
  ## What changed
  
  - Pass the initialized app-server client name into the `thread/rollback`
  request processor.
  - Suppress the `thread/rollback` deprecation notice only for
  `codex-tui`.
  - Preserve the existing `deprecationNotice` behavior for non-TUI
  clients.
  - Add regression coverage for the `codex-tui` suppression path.
  
  ## How to Test
  
  1. Start Codex TUI from this branch.
  2. Type text into the composer and press `Esc` to cancel/backtrack.
  3. Confirm the TUI restores/cancels the prompt without showing
  `thread/rollback is deprecated and will be removed soon`.
  4. Also verify an external app-server client that calls
  `thread/rollback` still receives `deprecationNotice`.
  
  Targeted tests:
  
  - `just test -p codex-app-server thread_rollback`
  - `just argument-comment-lint`

  Felipe Coury · 2026-06-25 18:44:35 -03:00
  b80fbb70cd
• feat(core, mcp): cache codex_apps tools in memory (#29003)

  ## Description
  
  This makes Codex Apps tool reads use a shared in-memory snapshot instead
  of rereading the disk cache every time `list_all_tools()` runs. Disk
  still seeds the cache on startup and gets updated after successful
  fetches, but it is no longer the live read path.
  
  The core change is that `McpManager` now owns a process-scoped
  `CodexAppsToolsCache`. Codex threads in the same app-server process now
  share this Codex Apps in-memory tools snapshot. The snapshot is keyed by
  the Codex home plus the Codex Apps identity: the active Codex auth
  user/workspace and the effective Codex Apps MCP source config.
  
  There's already code to hard-refresh the cache, so we respect it in this
  PR.
  
  ## Local benchmark
  
  I ran a local steady-state microbenchmark of the exact repeated Codex
  Apps cached-tools read this PR removes, using the same real local cache
  payload in both trees: `3,678,138` bytes and `381` tools. The cache file
  was already warm in the OS page cache, so this measures same-process
  reread/deserialization work rather than cold-disk latency or full turn
  latency. Each run is 25 iterations (mimicking a turn that makes 25
  inference calls).
  
  | Version | Run 1 | Run 2 | Avg |
  |---|---:|---:|---:|
  | `origin/main` disk read + JSON deserialize + `filter_tools` | `50.755
  ms` | `52.894 ms` | `51.825 ms` |
  | This branch in-memory `current_tools` + `filter_tools` | `0.740 ms` |
  `0.778 ms` | `0.759 ms` |
  
  That removes about `51 ms` from each repeated Codex Apps cached-tools
  read on this machine, roughly `68x` faster for that subpath. It is
  useful evidence for the hot path this PR changes, but not a claim that
  every production turn gets `51 ms` faster; end-to-end impact also
  depends on the rest of `list_all_tools()` and tool-payload construction.
  
  This is on my M2 Max macbook, so with a slower disk this would be much
  worse (and indeed we did see this really blew up turn runtime with a
  slow disk).

  Owen Lin · 2026-06-25 20:54:48 +00:00
  703793c22e
• [codex] poll external clock during sleep (#30113)

  ## Summary
  
  - make the external app-server time provider establish sleep deadlines
  using `currentTime/read`
  - poll the external clock once per second and complete `clock.sleep`
  when the deadline is reached
  - keep the system-clock timer and existing steer/agent-message
  interruption behavior unchanged
  
  ## Why
  
  This lets training control `clock.sleep` through its existing external
  simulated clock without adding separate sleep/wake protocol methods.
  
  ## Testing
  
  - `just fmt`
  - `just test -p codex-app-server
  external_sleep_polls_current_time_and_emits_items`

  rka-oai · 2026-06-25 13:46:42 -07:00
  62c7f506d9
• feat: add provider-aware model fallback to thread start (#29942)

  ## Why
  
  Helper threads such as task title generation can request a model ID that
  is valid for the default OpenAI provider but unavailable from the active
  provider. With Amazon Bedrock, `gpt-5.4-mini` is rejected while the
  provider static catalog exposes Bedrock model IDs such as
  `openai.gpt-5.5` and `openai.gpt-5.4`. This causes repeated background
  404s and can surface a misleading turn error even when the main turn
  succeeds.
  
  Clients need an explicit way to ask app-server to resolve an unavailable
  helper model to the active provider default. That fallback must remain
  limited to providers with an authoritative static catalog so custom or
  dynamically discovered model IDs are not rewritten based on an
  incomplete catalog.
  
  Fixes #28741.
  
  ## What changed
  
  - Add the experimental `allowProviderModelFallback` option to
  `thread/start`, defaulting to `false` to preserve existing behavior.
  - Thread the option through thread creation and model selection.
  - When enabled for a static model manager, preserve requested models
  present in the catalog and replace unavailable models with the provider
  default.
  - Continue preserving explicit model IDs for dynamic model managers
  without fetching a catalog solely to validate them.
  - Document the new `thread/start` behavior in the app-server API
  overview.
  
  ## Test
  Temporary test-client harness:
  ```
  ThreadStartParams {
      model: Some("gpt-5.4-mini".to_string()),
      allow_provider_model_fallback: true,
      ..Default::default()
  }
  ```
  Command:
  ```
  CODEX_HOME=/tmp/codex-bedrock-thread-start-home \
  CODEX_E2E_BEDROCK_THREAD_START_ONLY=1 \
  ./target/debug/codex-app-server-test-client \
    --codex-bin ./target/debug/codex \
    -c 'model_provider="amazon-bedrock"' \
    send-message-v2 --experimental-api ignored
  ```
  Relevant output:
  ```
  > "method": "thread/start",
  > "params": {
  >   "model": "gpt-5.4-mini",
  >   "modelProvider": null,
  >   "allowProviderModelFallback": true,
  >   ...
  > }
  
  < "result": {
  <   "model": "openai.gpt-5.5",
  <   "modelProvider": "amazon-bedrock",
  <   ...
  < }
  ```

  Celia Chen · 2026-06-25 18:24:34 +00:00
  6d9dbacf1a
• Persist selected capability roots and resolve availability per model step (#29856)

  ## Why
  
  `selectedCapabilityRoots` is durable thread intent: “use this capability
  root from environment `worker`.”
  
  The important product assumption is:
  
  > One environment ID always names the same logical executor and stable
  contents.
  
  `worker` does not silently change from executor A to an unrelated
  executor B. The process-local connection handle for `worker` can still
  be replaced while Codex is running, though, for example when
  `environment/add` registers a fresh handle for the same logical
  environment.
  
  The thread should persist only the stable selection. Each model step
  should pair that selection with the exact ready handle captured for that
  step.
  
  ## The boundary
  
  ```text
  persisted thread intent
    plugin@1 -> environment "worker"
                  |
                  | capture the current step
                  v
  model-step view
    unavailable, or
    plugin@1 + worker's exact captured ready handle
  ```
  
  The environment ID is the stable identity and cache key. The
  `Arc<Environment>` is only a process-local handle retained so consumers
  of one model step use the same captured environment. It is never
  persisted and it does not imply different environment contents.
  
  ## What changes
  
  ### Persist the stable selection
  
  Selected roots are written into `SessionMeta` and restored with the
  thread. Forked subagents inherit the same selections, including
  bounded-history forks.
  
  Only stable data is persisted: root ID, environment ID, and root path.
  
  ### Capture readiness together with the exact handle
  
  The environment snapshot records:
  
  ```rust
  environment_id -> Some(Arc<Environment>) // ready in this step
  environment_id -> None                   // still starting in this step
  ```
  
  This prevents readiness and execution from coming from different
  registry snapshots.
  
  For example:
  
  ```text
  step snapshot: worker -> handle A, ready
  environment/add: worker -> fresh handle B for the same logical environment
  current step: plugin@1 still uses captured handle A
  ```
  
  Without carrying handle A in the snapshot, the resolver could combine “A
  was ready” with handle B and treat B as ready before it had finished
  starting.
  
  This does not change cache invalidation. Stable capability metadata
  remains identified by environment ID and capability root. Replacing a
  process-local handle under the same stable environment ID does not
  invalidate or rediscover that metadata.
  
  ### Resolve availability per model step
  
  - A ready captured environment produces resolved roots using its
  captured handle.
  - A starting, missing, or failed environment is omitted from that step.
  - A selected lazy environment that is outside the turn's captured
  environment set is asked to start, and a later step can observe it as
  ready.
  - No capability files are scanned here.
  
  Transient transport disconnects remain the remote client's reconnect
  concern. This PR models initial attachment/readiness; it does not add
  live socket-connectivity state.
  
  ## Example
  
  ```text
  thread selection: plugin@1 -> environment "worker"
  
  step 1: worker is starting -> plugin@1 unavailable
  step 2: worker is ready    -> plugin@1 resolves through worker's captured handle
  step 3: fresh local handle -> current step remains pinned; a later step captures its own view
  ```
  
  Temporary unavailability does not discard the durable selection. Later
  PRs can retain stable metadata caches while projecting only currently
  available capabilities into model-visible World State.
  
  ## Compatibility
  
  The app-server request shape does not change. Older rollouts without
  `selected_capability_roots` deserialize to an empty list.
  
  ## Stack
  
  1. **This PR:** persist stable selected roots and resolve them through
  an exact model-step handle.
  2. #29960: cache stable skill metadata and project available skills into
  World State.
  3. #29946: cache stable plugin declarations and manage the separate live
  MCP runtime.

  jif · 2026-06-25 17:49:43 +00:00
  8f02973d25
• chore(app-server): mark thread/rollback as deprecated (#29928)

  We will drop support for this in the near future due to the complexity
  it introduces.

  Owen Lin · 2026-06-25 17:15:46 +00:00
  268328001f
• Support OAuth for HTTP MCP servers from selected executor plugins (#28529)

  ## Why
  
  #28522 routes selected-plugin HTTP MCP traffic through the owning
  executor, but OAuth bootstrap and refresh still used host-local clients.
  Executor-only servers therefore cannot complete discovery or login
  through the same network boundary as the MCP connection.
  
  ## What changed
  
  - adapt `codex_exec_server::HttpClient` to RMCP 1.8's `OAuthHttpClient`
  contract
  - let RMCP own discovery, dynamic registration, PKCE, token exchange,
  and refresh
  - route auth status, persisted-token startup, and app-server login
  through the server runtime while preserving the existing local discovery
  path
  - add optional `threadId` to `mcpServer/oauth/login` and echo it in the
  completion notification
  - implement RMCP's redirect policy and 1 MiB OAuth response limit over
  executor HTTP
  - cover selected-thread OAuth discovery and login through an
  executor-only route
  
  Depends on #28522.

  jif · 2026-06-25 10:31:17 +01:00
  b215961a56
• [codex] route sleep through time providers (#29973)

  ## Summary
  
  - add a cancellable sleep operation to `TimeProvider`
  - route `clock.sleep` through the configured provider
  - extend the supported sleep duration to 12 hours
  - complete the sleep turn item before propagating provider failures
  
  ## Why
  
  This isolates the core clock abstraction needed by external clock
  integrations. Existing system and app-server behavior remains wall-clock
  based in this PR; the stacked follow-up supplies app-server sleeps from
  an external clock.

  rka-oai · 2026-06-24 22:17:43 -07:00
  f66d793a2d
• [codex] Add Ultra reasoning effort (#29899)

  ## Why
  
  Ultra should be one user-facing reasoning selection for work that
  benefits from both maximum reasoning and proactive multi-agent
  delegation. Without it, clients must coordinate maximum reasoning with
  the experimental `multiAgentMode` setting, even though the inference
  backend still expects its existing `max` effort value.
  
  This change makes reasoning effort the source of truth: clients select
  `ultra`, core derives proactive multi-agent behavior when the turn is
  eligible for multi-agent V2, and inference requests continue to use the
  backend-compatible `max` value.
  
  ## What changed
  
  - Add `ultra` as a first-class reasoning effort and preserve
  model-catalog ordering when exposing it to clients.
  - Convert `ultra` to `max` at the inference request boundary, including
  Responses HTTP/WebSocket requests, startup prewarm, compaction, and
  memory summarization.
  - Derive effective multi-agent mode per turn from effective reasoning
  effort:
    - eligible multi-agent V2 + `ultra` → `proactive`
    - eligible multi-agent V2 + any other effort → `explicitRequestOnly`
  - V1 or otherwise ineligible sessions → no multi-agent mode instruction
  - Keep the derived effective mode in turn context history so successive
  turns can emit a developer-message update only when the effective mode
  changes.
  - Remove selected multi-agent mode from core session configuration, turn
  construction, thread settings, resume/fork restoration, and subagent
  spawn plumbing. Subagents inherit reasoning effort and derive their own
  effective mode.
  - Retain the experimental app-server `multiAgentMode` fields for wire
  compatibility while marking them deprecated. Request values are accepted
  but ignored; compatibility response fields report `explicitRequestOnly`.
  - Display Ultra in the TUI using the order supplied by `model/list`.
  
  ## Validation
  
  - `just test -p codex-core ultra_reasoning_uses_max_for_requests`
  - `just test -p codex-tui model_reasoning_selection_popup`

  Shijie Rao · 2026-06-24 20:13:52 -07:00
  df1199fddb
• [codex] Populate remote plugin local versions (#29956)

  # What
  
  - Carry installed remote release versions through remote plugin
  summaries as `localVersion`.
  - Keep the app-server mapping a pure adapter by populating that value in
  the remote catalog layer.
  
  # Why
  
  Remote plugin summaries always returned `localVersion: null` even after
  their versioned bundles had been installed locally. Consumers such as
  scheduled-task template discovery use `localVersion` to resolve a
  plugin's materialized root, so templates from remote curated plugins
  were silently skipped.

  Abhinav · 2026-06-25 03:13:03 +00:00
  6db937275f
• Add a connector declaration snapshot (#29851)

  ## Why
  
  Connector declarations currently enter Codex through broad plugin
  capability summaries, then MCP setup, turn tooling, and `app/list` each
  reconstruct the same information. That makes executor-selected
  connectors difficult to add without coupling connector behavior to the
  host plugin loader.
  
  This PR introduces a small connector-owned value that later stack layers
  can populate before thread startup.
  
  ## What changed
  
  - Move the pure app-declaration parser into `codex-connectors`,
  preserving declaration order and category cleanup while leaving
  host-side validation and deduplication unchanged.
  - Add an immutable `ConnectorSnapshot` with ordered connector IDs and
  plugin display-name provenance.
  - Adapt the existing local-plugin capability summaries into that
  snapshot at current consumer boundaries.
  - Use the snapshot for MCP tool provenance, turn connector inventory,
  and `app/list`.
  - Keep the crate API narrow: no test-only snapshot accessors are
  exposed.
  
  The externally visible behavior is unchanged. Connector tools still come
  from the orchestrator-owned `/ps/mcp` server, and local plugin
  enablement remains owned by the existing plugin loader.
  
  ## Stack scope
  
  This is the foundation only. It does not read selected executor packages
  or change thread startup. #29852 adds the executor-backed declaration
  reader, and #29856 composes selected declarations into a thread
  snapshot.

  jif · 2026-06-24 23:24:01 +01:00
  4e0f863df3
• [apps] Thread structured icon assets through app list (#29889)

  ## Summary
  
  - Add `iconAssets` and `iconDarkAssets` to the app-list protocol.
  - Preserve structured icons through directory merging and the connector,
  app-
    server, and TUI boundaries.
  - Keep legacy logo URLs unchanged as compatibility fallbacks.
  - Update generated protocol schemas and TypeScript types.

  Drew · 2026-06-24 13:25:44 -07:00
  a33ad93996
• [codex] Inject agent graph store into ThreadManager (#29736)

  Pick up the AgentGraphStore migration.
  
  - Inject an explicit optional agent graph store into `ThreadManager` 
  - Move all calls to spawn, close, recursive resume, and
  subtree/archive/delete/feedback traversal through it
  - Keep using  `LocalAgentGraphStore` when SQLite is available
  
  This required some changes to the interface to deal with futures:
  
  - The interface now matches `ThreadStore`'s object-safe pattern by
  returning a boxed `AgentGraphStoreFuture` directly, allowing
  `ThreadManager` to hold `Arc<dyn AgentGraphStore>`
  
  *Slight behavior change!* Unfiltered subtree enumeration now performs a
  single all-status breadth-first traversal, so a closed grandchild
  beneath an open edge is included; the previous Open-then-Closed
  traversals could not cross mixed-status paths and silently omitted it.

  Tom · 2026-06-24 13:24:10 -07:00
  ece1dfece0
• feat(app-server): list descendant threads by ancestor (#29591)

  ## Why
  
  `thread/list` can filter direct children with `parentThreadId`, but
  clients cannot request an entire spawned subtree. Discovering every
  descendant requires repeated client-side requests and gives up the
  database's existing filtering and pagination path.
  
  ## What changed
  
  Experimental clients can use `ancestorThreadId` to return strict
  descendants at any depth while `parentThreadId` retains its direct-child
  meaning. The filters are mutually exclusive, the ancestor is excluded,
  and every result preserves its immediate `parentThreadId` so callers can
  reconstruct the tree.
  
  ## How it works
  
  - **Explicit relationship:** Internal list parameters distinguish direct
  children from transitive descendants without changing the meaning of
  `parentThreadId`.
  - **Existing graph:** Persisted parent-child spawn edges remain the
  source of truth, so descendant lookup needs no schema migration or
  ancestry cache.
  - **Indexed traversal:** A recursive SQLite query starts from the
  parent-edge index, walks each generation, and applies thread filters,
  sorting, and cursor pagination in the same database request.
  - **Reconstructable results:** The response stays flat and normally
  ordered while carrying each descendant's immediate parent.
  
  ## Verification
  
  Ran 550 tests across the protocol, state, rollout, and thread-store
  crates, then reran the four focused state, store, and app-server
  descendant-listing tests after the final diff reduction. Scoped Clippy
  and formatting checks passed. Stable and experimental schema generation
  was checked; the stable fixtures remain unchanged while the experimental
  schema includes the new field.

  Brent Traut · 2026-06-24 13:08:14 -07:00
  8057603d0c
• [codex] show external import result counts (#29567)

  ## What changed
  
  - Show per-type import counts in the `/import` review UI and started
  message.
  - Render completion results as a multi-line summary with total
  imported/failed counts and one row per import type.
  - Add snapshot coverage for the updated review and completion output.
  
  <img width="537" height="322" alt="Screenshot 2026-06-23 at 9 41 20 PM"
  src="https://github.com/user-attachments/assets/166542eb-2097-4b2b-8130-8f6fd8c680ce"
  />
  
  
  ## Why
  
  The TUI previously only reported that Claude Code import started or
  finished. Users could not see how many items of each type were selected
  or how many actually imported versus failed.

  charlesgong-openai · 2026-06-24 08:56:57 -07:00
  3694b48a82
• connectors: own app metadata types (#29723)

  ## Why
  
  Connector metadata is consumed by connector discovery, ChatGPT
  integration, core, and TUI code. Treating app-server's wire DTO as the
  shared domain model reverses the intended dependency direction.
  
  ## What changed
  
  - Added connector-owned app branding, review, screenshot, metadata, and
  info types.
  - Added explicit conversions in app-server and TUI while preserving
  app-server's wire payloads.
  - Removed production app-server-protocol dependencies from connectors
  and ChatGPT connector code.
  
  ## Stack
  
  This is PR 4 of 6, stacked on [PR
  #29722](https://github.com/openai/codex/pull/29722). Review only the
  delta from `codex/split-config-layer-types`. Next: [PR
  #29724](https://github.com/openai/codex/pull/29724).
  
  ## Validation
  
  - Connector and tools coverage passed.
  - App-server app-list coverage passed: 13 tests.

  Adam Perry @ OpenAI · 2026-06-23 22:08:23 -07:00
  e639e8c4bd
• config: own layer provenance types (#29722)

  ## Why
  
  Config layer provenance describes how effective configuration was
  assembled, so it belongs with the config loader rather than in
  app-server's serialized API types.
  
  ## What changed
  
  - Moved `ConfigLayerSource`, `ConfigLayerMetadata`, and `ConfigLayer`
  ownership into `codex-config`.
  - Kept app-server's wire payloads unchanged and added explicit
  conversions at the app boundary.
  - Removed lower-level app-server-protocol dependencies from config
  consumers.
  
  ## Stack
  
  This is PR 3 of 6, stacked on [PR
  #29721](https://github.com/openai/codex/pull/29721). Review only the
  delta from `codex/split-auth-domain-types`. Next: [PR
  #29723](https://github.com/openai/codex/pull/29723).
  
  ## Validation
  
  - `codex-config` coverage passed.
  - App-server config-manager and config RPC coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 04:03:04 +00:00
  1d65ccabd5
• [plugins] Enforce marketplace source admission requirements (#29753)

  ## Why
  
  Managed marketplace source requirements only become effective when every
  local marketplace mutation path applies the same admission decision.
  This change centralizes that decision so CLI, app-server, and
  external-agent migration flows cannot add, install from, or refresh a
  disallowed source.
  
  ## What changed
  
  - Match exact normalized Git repository URLs with an optional exact
  `ref`.
  - Match Git hosts with managed regular expressions.
  - Match local marketplaces by exact absolute path.
  - Preserve the expected path/name boundary for managed OpenAI
  marketplaces.
  - Enforce source admission during marketplace add, plugin install, and
  configured Git marketplace upgrade.
  - Continue upgrading independent marketplaces when one source is
  rejected and return a per-marketplace error.
  - Load the effective requirements stack at CLI, app-server, and
  external-agent migration entry points.
  
  This PR does not filter already configured marketplaces at runtime; that
  remains in draft follow-up #29691.
  
  ## Stack
  
  This is PR 2 of 3 and is based on #29690, which introduces the
  requirements data shape and merge behavior.
  
  ## Test plan
  
  - Source matcher coverage for Git URL/ref, host-pattern, local-path, and
  managed marketplace cases.
  - Marketplace add and plugin install coverage for allowed and rejected
  sources.
  - Marketplace upgrade coverage for rejection and per-marketplace
  continuation.

  xl-openai · 2026-06-23 20:13:11 -07:00
  4fe02f4fcf
• auth: move domain mode below app wire types (#29721)

  ## Why
  
  Authentication mode is a domain concept used by login, model selection,
  telemetry, and transports. Keeping the canonical type in app-server
  protocol forces those lower-level crates to depend on an unrelated wire
  API.
  
  ## What changed
  
  - Added canonical `codex_protocol::auth::AuthMode` domain values.
  - Kept the app-server wire DTO unchanged and added an explicit app-side
  conversion.
  - Removed production app-server-protocol dependencies from login,
  model-provider-info, models-manager, and otel call paths.
  
  ## Stack
  
  This is PR 2 of 6, stacked on [PR
  #29714](https://github.com/openai/codex/pull/29714). Review only the
  delta from `codex/split-json-rpc-protocols`. Next: [PR
  #29722](https://github.com/openai/codex/pull/29722).
  
  ## Validation
  
  - Auth and login coverage passed in the focused protocol/domain test
  run.
  - App-server account and auth conversion coverage passed.

  Adam Perry @ OpenAI · 2026-06-24 03:10:20 +00:00
  31372078d1
• Let image generation extension hosts control output persistence (#29711)

  ## Why
  
  Some extension hosts need generated images returned without writing them
  to the local filesystem or giving the model a local path.
  
  ## What changed
  
  **tl;dr**: we now conduct all extension operations in the image gen
  extension
  
  - Let hosts provide an optional image save root when installing the
  extension.
  - Save images and return path hints only when a save root is configured.
  - Return image data without saving or adding a path hint when no save
  root is configured.
  - Preserve the extension-provided `saved_path` instead of persisting
  extension images again in core.
  - Leave built-in image generation unchanged.
  
  ## Validation
  
  - `just test -p codex-image-generation-extension`
  - `just test -p codex-app-server
  standalone_image_generation_returns_saved_path_hint_to_model`
  - `just test -p codex-core
  extension_tool_uses_granted_turn_permissions_without_local_persistence`
  - `just test -p codex-core tools::handlers::extension_tools::tests`
  - tested on CODEX CLI on both save_root: CODEX_HOME and None 
  - tested on CODEX APP on both as well

  Won Park · 2026-06-23 18:51:49 -07:00
  61f5a84930
• Support thread-level originator overrides (#29477)

  ## Why
  
  Work(TPP) threads can be launched from the Desktop app, but if they all
  keep the Desktop app's default originator then downstream attribution
  cannot distinguish local Work launches from cloud-backed Work launches.
  `thread/start.serviceName` already carries that launch signal, while
  `SessionMeta.originator` is the durable thread-level value that survives
  resume and fork.
  
  This change converts the Desktop Work service names into an effective
  originator at thread creation time, persists that originator with the
  thread, and keeps using it for later model requests and memory writes.
  
  ## What changed
  
  - Map `CODEX_WORK_LOCAL` and `CODEX_WORK_CLOUD` service names to
  per-thread originators, while preserving
  `CODEX_INTERNAL_ORIGINATOR_OVERRIDE` as the highest-precedence override.
  - Persist the effective originator in `SessionMeta.originator`, read it
  back on resume/fork, and inherit the parent originator for subagent
  spawns when there is no persisted session metadata.
  - Handle truncated `SpawnAgentForkMode::LastNTurns` forks by falling
  back to the live parent originator when the forked history no longer
  includes `SessionMeta`.
  - Thread the per-thread originator through Responses headers,
  websocket/compaction request paths, thread-store creation, rollout
  metadata, and memory stage-one telemetry.
  
  ## Verification
  
  - `just test -p codex-core
  agent::control::tests::spawn_thread_subagent_inherits_parent_originator_without_fork
  agent::control::tests::spawn_thread_subagent_fork_last_n_turns_inherits_parent_originator_without_session_meta
  thread_manager::tests::originator_override_precedes_service_name_remapping`
  - `just test -p codex-core
  agent::control::tests::resume_thread_subagent_restores_stored_metadata_and_effective_multi_agent_mode`
  - `just test -p codex-memories-write`
  - `just fix -p codex-core -p codex-memories-write`
  - `git diff --check`

  alexsong-oai · 2026-06-23 17:23:38 -07:00
  1acb722e8a
• core: persist initial context window metadata (#29519)

  ## Why
  
  PR #29494 made context-window IDs visible to the model by wrapping the
  token-budget window payload in `<context_window>`, but rollout JSONL
  consumers still could not see the initial window identity by tailing the
  session file. Compacted rollout items carry window IDs only after
  compaction has happened, so a session with no compaction had no durable
  JSONL record for window 0.
  
  This change gives tailing consumers a stable initial-window record at
  session creation time.
  
  ## What Changed
  
  - Added `session_meta.context_window.window_id` for the initial
  context-window identity.
  - `CreateThreadParams` now requires `initial_window_id: String`, so
  thread-store callers cannot accidentally create new threads without
  window-0 metadata.
  - Live thread creation derives the persisted initial window ID from the
  same `AutoCompactWindowIds` used to initialize `SessionState`, keeping
  runtime state and JSONL metadata aligned.
  - Rollout reconstruction uses `session_meta.context_window.window_id` as
  the initial-window fallback and derives `window_number = 0`,
  `first_window_id = window_id`, and `previous_window_id = None`
  internally.
  - Fork reconstruction intentionally uses the same rollout reconstruction
  path; consumers that need to distinguish copied initial-window metadata
  can use the rollout `thread_id`.
  - Legacy compactions without `window_number` still use compaction-count
  fallback accounting instead of being reset to window 0 by the
  initial-window fallback.
  - Compacted rollout metadata still takes precedence once compaction
  records exist, preserving the richer chain fields there.
  
  ## JSONL Shape
  
  Real rollout JSONL is one object per line. This example is expanded for
  readability, but shows the new initial `session_meta.context_window`
  record followed by the existing compacted rollout item shape that also
  carries window IDs:
  
  ```jsonl
  {
    "timestamp": "2026-06-22T12:00:00.000Z",
    "type": "session_meta",
    "payload": {
      "session_id": "<THREAD_ID>",
      "id": "<THREAD_ID>",
      "timestamp": "2026-06-22T12:00:00.000Z",
      "cwd": "/repo",
      "originator": "codex",
      "cli_version": "0.0.0",
      "source": "cli",
      "model_provider": "<MODEL_PROVIDER>",
      "context_window": {
        "window_id": "<INITIAL_WINDOW_ID>"
      }
    }
  }
  ...
  {
    "timestamp": "2026-06-22T12:34:56.000Z",
    "type": "compacted",
    "payload": {
      "message": "<COMPACTION_SUMMARY>",
      "replacement_history": [
        "..."
      ],
      "window_number": 1,
      "first_window_id": "<INITIAL_WINDOW_ID>",
      "previous_window_id": "<INITIAL_WINDOW_ID>",
      "window_id": "<NEXT_WINDOW_ID>"
    }
  }
  ```
  
  The nested `context_window` object is intentional: it gives rollout
  consumers a stable namespace for context-window metadata while only
  writing the non-derivable initial `window_id`. For the initial window,
  `window_number`, `first_window_id`, and `previous_window_id` are derived
  internally instead of being written to the rollout.
  
  ## Verification
  
  - `just test -p codex-protocol`
  - `just test -p codex-rollout
  recorder_materializes_on_flush_with_pending_items`
  - `just test -p codex-core reconstruct_history`
  - `just test -p codex-core
  record_initial_history_reconstructs_forked_transcript`
  - `just test -p codex-thread-store`
  - `just test -p codex-state`
  - `just test -p codex-app-server
  thread_read_returns_summary_without_turns`
  - `just test -p codex-rollout persistence_metrics`

  Michael Bolin · 2026-06-23 21:50:50 +00:00
  01f89c8c59
• feat(app-server): thread/turns/items/list -> thread/items/list (#29705)

  ## Description
  
  Rename the experimental app-server item pagination API from
  `thread/turns/items/list` to `thread/items/list` and make `turnId`
  optional. Clients can now page persisted items across a thread, or still
  filter to one turn when needed.
  
  ## What changed
  
  - Rename the request/response protocol types and JSON-RPC method to
  `ThreadItemsList*` / `thread/items/list`.
  - Pass optional `turnId` through to `ThreadStore::list_items`.
  - Update app-server docs and focused protocol/app-server tests.
  
  ## Validation
  
  - `just test -p codex-app-server-protocol thread_items_list_round_trips`
  - `just test -p codex-app-server thread_items_list_returns_unsupported`

  Owen Lin · 2026-06-23 13:57:08 -07:00
  1882719b30
• Separate local and remote plugin analytics IDs (#29495)

  ## Why
  
  Plugin analytics overloaded `plugin_id`: most events used the Codex
  `<plugin>@<marketplace>` identity, while remote install events used the
  backend plugin ID. That makes the same field change meaning across event
  types and complicates downstream identity resolution.
  
  This change makes the contract unambiguous:
  
  - `plugin_id`: the local Codex `<plugin>@<marketplace>` identity, when
  resolved
  - `remote_plugin_id`: the backend plugin identity, when available
  
  For a remote install failure that happens before plugin details resolve,
  `plugin_id` is `null` and `remote_plugin_id` remains populated.
  
  ## What changed
  
  All six plugin analytics events use the same identity contract:
  
  - `codex_plugin_installed`
  - `codex_plugin_install_failed`
  - `codex_plugin_uninstalled`
  - `codex_plugin_enabled`
  - `codex_plugin_disabled`
  - `codex_plugin_used`
  
  Remote identity is resolved from the current installed-plugin snapshot
  first, with persisted install metadata as fallback. The telemetry
  metadata type keeps local identity optional for failures that occur
  before remote details are available.
  
  The app-server test client's manual analytics smokes now find remote
  mutation events through `remote_plugin_id` and validate that `plugin_id`
  remains local.
  
  ## Remote uninstall
  
  Resolve and capture telemetry metadata before removing the local plugin
  cache, then emit `codex_plugin_uninstalled` after the backend confirms
  success. The event is also emitted when backend uninstall succeeds but
  local cache cleanup reports `CacheRemove`.
  
  If a concurrent remote-cache refresh removes the local bundle before
  telemetry capture, the already-fetched remote plugin detail supplies
  fallback capability metadata.
  
  ## Validation
  
  - `just test -p codex-analytics` — 82 passed
  - `just test -p codex-core-plugins` — 271 passed
  - `just test -p codex-app-server-test-client` — 5 passed
  - `just test -p codex-plugin` — 3 passed
  - `just test -p codex-app-server plugin_install` — 37 passed
  - `just test -p codex-app-server plugin_uninstall` — 10 passed
  
  The production app-server install/uninstall flow was also exercised
  against `plugins~Plugin_f1b845ac33888191ac156169c58733c2`
  (`build-ios-apps@openai-curated-remote`), and the plugin's original
  uninstalled state was restored.

  jameswt-oai · 2026-06-23 12:27:14 -07:00
  ff50b47dce
• core: add extra metadata field to Thread struct (#29675)

  # Summary
  
  Adds a field Thread.extras that can be used to hold arbitrary metadata
  specific to a given thread.

  Boyang Niu · 2026-06-23 19:15:59 +00:00
  354807920e
• 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
• Handle additional tools in image URL validation (#29577)

  ## Why
  
  `ResponseItem::AdditionalTools` was added without updating app-server
  image URL validation. The exhaustive match therefore prevents app-server
  and downstream targets from compiling on `main`.
  
  ## What changed
  
  Treat `AdditionalTools` like the other response items that cannot
  contain input-image URLs.

  Ahmed Ibrahim · 2026-06-23 00:20:23 -07:00
  6e0c8b4517
• 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
• [codex] reject remote images at app-server ingress (#29419)

  ## Stack
  
  Stacked on #29417. Review and land that PR first.
  
  ## Summary
  
  - reject HTTP(S) image URLs in the handlers for `turn/start` and
  `turn/steer`
  - validate `thread/inject_items` after its existing
  JSON-to-`ResponseItem` conversion, so each item is deserialized once
  - turn invalid dynamic-tool image responses into the existing
  unsuccessful text fallback; the model receives the validation message as
  the function output
  - leave `thread/resume.history` compatible with legacy history; #29417
  replaces remote images before model input
  - continue accepting inline data URLs and `localImage` inputs
  - keep this policy in app-server; this PR does not add a shared protocol
  API or change core image preparation
  
  ## Test plan
  
  - `just test -p codex-app-server -E
  'test(/request_handlers_reject_remote_image_urls|dynamic_tool_remote_image_response_becomes_model_visible_error|dynamic_tool_call_round_trip_sends_content_items_to_model|turn_start_tracks_turn_event_analytics|standalone_image_edit_uses_recent_pathless_image/)'`
  (5 passed)
  - `just fix -p codex-app-server`
  - `just fmt`

  rka-oai · 2026-06-23 00:43:56 +00:00
  b294638bb5
• [plugins] Add dark-mode logo metadata (#29488)

  Adds additive dark-mode plugin logo metadata across manifests, remote
  catalogs, and the app-server protocol while keeping uninstalled Git
  listings free of synthetic local paths.
  
  Supersedes #28945. This replacement uses an upstream branch so trusted
  CI can use the repository-provided remote Bazel configuration.
  
  ## Current state
  
  Plugin interfaces expose only the default logo asset. Clients therefore
  cannot select a dedicated dark-mode logo even when a plugin provides
  one.
  
  ## What this PR changes
  
  - Adds nullable `logoDark` and `logoUrlDark` fields to
  `PluginInterface`.
  - Resolves local `interface.logoDark` assets and maps remote
  `logo_url_dark` values.
  - Removes path-backed interface assets, including `logoDark`, from
  uninstalled Git fallback listings until the plugin has a real local
  root.
  - Updates the bundled plugin validator and manifest reference.
  - Regenerates the app-server JSON schemas and TypeScript types.
  
  Local manifests expose `interface.logoDark` as a package-relative asset
  path. Remote catalog responses expose `logo_url_dark`. These values map
  into separate app-server fields so clients can preserve local-path and
  remote-URL handling.
  
  ## Risk
  
  The fields are additive and nullable, so existing clients retain their
  current logo behavior. The main risks are an incomplete mapping path or
  exposing a synthetic local path for an uninstalled Git plugin.
  Local-manifest, remote-catalog, fallback-listing, protocol
  serialization, and app-server integration tests cover those paths.
  
  Spiciness: 2/5
  
  ## Testing
  
  - `just write-app-server-schema`
  - `just fmt`
  - Regression test first failed with `logo_dark` resolved to
  `/assets/logo-dark.png`, then passed after the fallback-listing fix.
  - `just test -p codex-core-plugins` (267 tests passed)
  - `just test -p codex-app-server 'suite::v2::plugin'` (114 tests passed)
  - `just test -p codex-app-server-protocol -p codex-core-plugins -p
  codex-plugin -p codex-skills` (517 tests passed before the follow-up)
  - `just test -p codex-tui plugin` (47 tests passed)
  - Validated a local plugin manifest containing `interface.logoDark` with
  the bundled validator.
  
  ## Manual verification
  
  Create a local plugin with both `interface.logo` and
  `interface.logoDark`, then call `plugin/list` or `plugin/read`. Confirm
  the response contains separate `logo` and `logoDark` paths. For a remote
  catalog entry, confirm `logoUrlDark` is populated from `logo_url_dark`.
  For an uninstalled Git marketplace entry, confirm path-backed interface
  assets remain absent until installation.
  
  Issue: N/A - coordinated maintainer change.

  Drew · 2026-06-22 16:01:27 -07:00
  2c351cb864
• [codex] fetch featured IDs for remote plugins (#29485)

  ## Summary
  
  - fetch featured plugin IDs when the loaded catalog includes
  `openai-curated-remote`
  - extend the existing remote marketplace regression test to cover the
  featured IDs response
  
  ## Why
  
  When the remote plugin catalog was enabled, app-server loaded
  `openai-curated-remote` but skipped `/plugins/featured` because the
  request processor only fetched featured IDs for the local
  `openai-curated` marketplace. As a result, the desktop app could not
  render the backend-curated remote featured set.
  
  This keeps the existing local behavior and also returns the curated
  ranking for remote plugins.
  
  ## Test plan
  
  - `just fmt`
  - `git diff --check`
  - `just test -p codex-app-server
  plugin_list_includes_remote_marketplaces_when_remote_plugin_enabled`

  Eric Ning · 2026-06-22 15:08:59 -07:00
  bf7148626b
• permission profiles: expose availability to clients (#26678)

  ## Why
  
  `permissionProfile/list` currently advertises every built-in and
  configured profile even when effective enterprise requirements prevent
  selecting it. That forces each client to reconstruct policy from
  lower-level requirement fields, which is easy to miss and difficult to
  keep consistent.
  
  The catalog should remain complete so clients can explain that an option
  was disabled by an administrator, while also reporting whether each
  profile is selectable.
  
  ## What
  
  - Add an `allowed` field to each permission profile summary.
  - Build a shared catalog from the effective config and current
  requirements, including `allowed_sandbox_modes`, `allowed_permissions`,
  and filesystem restrictions.
  - Use the shared catalog in app-server and the TUI so disallowed
  profiles remain visible but cannot be selected.
  - Use the canonical `:danger-full-access` profile ID in the TUI.
  - Update the app-server schemas, API documentation, behavioral tests,
  and TUI snapshots.
  
  ## Scope
  
  This PR targets `main` directly and is independent of #24852. It
  preserves the current behavior where built-in profiles are constrained
  by sandbox-mode requirements and `allowed_permissions` applies to
  configured profiles.
  
  ## Testing
  
  - `just test -p codex-core
  permission_profile_catalog_marks_profiles_disallowed_by_requirements`
  - `just test -p codex-app-server permission_profile_list`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-tui profile_permissions`
  - `just fix -p codex-core`
  - `just fix -p codex-app-server-protocol`
  - `just fix -p codex-app-server`
  - `just fix -p codex-tui`
  - `just fmt`
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>
  Co-authored-by: Joey Trasatti <joey.trasatti@openai.com>

  viyatb-oai · 2026-06-22 13:48:09 -07:00
  ced3e4b9a7
• PAC 2 - Add shared auth system proxy contract (#26707)

  ## Summary
  
  Stacked on #26706.
  
  Adds the shared auth/system-proxy contract that later platform resolver
  PRs plug into. This PR moves Codex-owned auth and startup HTTP clients
  through a common route-aware boundary, but does not yet add Windows or
  macOS system proxy resolution.
  
  The default path remains unchanged when `respect_system_proxy` is absent
  or disabled.
  
  ## Implementation
  
  - Adds `codex-client/src/outbound_proxy.rs` with the shared
  route-selection model:
    - `OutboundProxyConfig`;
    - `ClientRouteClass`;
    - `RouteFailureClass`;
    - `build_reqwest_client_for_route`.
  - Preserves the existing reqwest/default-client behavior when no route
  config is supplied.
  - Uses the fixed MVP routing policy when route config is supplied:
  platform system/PAC/WPAD discovery, then explicit env proxy variables,
  then direct connection.
  - Keeps platform-specific system discovery behind the shared client
  boundary. This PR provides the contract and fallback behavior; later
  resolver PRs plug in Windows and macOS discovery.
  - Adds `login::AuthRouteConfig` so auth call sites depend on a small
  policy type instead of platform resolver details.
  - Maps the resolved `Config.respect_system_proxy` boolean into
  `AuthRouteConfig` for auth-owned clients.
  - Wires the route config through browser login, device-code login,
  access-token login, login status, logout/revoke, token refresh, API-key
  exchange, app-server account login, TUI/app startup, cloud-config
  bootstrap, cloud tasks, plugin auth, and exec startup config loading.
  
  ## End-user behavior
  
  - No behavior changes by default.
  - When `respect_system_proxy = true`, auth-owned clients opt into the
  shared route-aware client path.
  - On platforms without a resolver implementation in this PR, system
  discovery is unavailable and the route-aware path falls back to explicit
  env proxy handling, then direct connection.
  - Custom CA handling remains separate from proxy route selection and
  still runs through the shared client builder.
  - No proxy URLs, PAC contents, or resolved platform details are exposed
  through the public config surface introduced here.
  
  ## Tests
  
  Adds or updates coverage for:
  
  - preserving default auth-client fallback behavior when no route config
  is provided;
  - injected environment-proxy fallback without mutating process
  environment;
  - existing login-server E2E flows using explicit `auth_route_config:
  None` to guard unchanged default behavior;
  - updated auth manager, login, logout, cloud-config, startup, and
  plugin-auth call sites passing route config explicitly.

  canvrno-oai · 2026-06-22 13:03:11 -07:00
  1659c4a629
• [codex] Centralize Plugin Analytics Metadata (#27102)

  This PR moves construction of `PluginTelemetryMetadata` from loader and
  model helpers into `PluginsManager`, which already owns installed plugin
  state and will eventually perform remote identity enrichment. The
  metadata type remains in `codex-plugin`, and serialized analytics events
  remain unchanged.
  
  ## Before
  
  ```mermaid
  flowchart LR
      subgraph Events["Analytics event paths"]
          direction TB
          Lifecycle["Local install / uninstall"]
          Config["Enable / disable"]
          Remote["Remote install"]
          Used["Plugin used"]
      end
  
      subgraph Construction["Metadata construction"]
          direction TB
          Loader["Loader telemetry helpers"]
          Summary["PluginCapabilitySummary::telemetry_metadata"]
          Override["Caller adds remote_plugin_id"]
      end
  
      Metadata["PluginTelemetryMetadata"]
  
      Lifecycle --> Loader
      Config --> Loader
      Remote --> Loader
      Loader -->|"local events"| Metadata
      Loader -->|"remote install"| Override
      Override --> Metadata
      Used --> Summary
      Summary --> Metadata
  ```
  
  Telemetry metadata was constructed through loader helpers, a
  capability-summary method, and a remote-install call-site override.
  
  ## After
  
  ```mermaid
  flowchart LR
      subgraph Events["Analytics event paths"]
          direction TB
          Lifecycle["Local install / uninstall"]
          Config["Enable / disable"]
          Remote["Remote install"]
          Used["Plugin used"]
      end
  
      Manager["PluginsManager — single construction owner"]
      Metadata["PluginTelemetryMetadata"]
  
      Lifecycle --> Manager
      Config --> Manager
      Remote -->|"authoritative remote ID"| Manager
      Used -->|"capability summary"| Manager
      Manager --> Metadata
  ```
  
  Every analytics path delegates metadata construction to
  `PluginsManager`. Remote install still supplies its authoritative
  backend ID explicitly.
  
  ## What Changes
  
  - Make loader code return a focused plugin capability summary instead of
  constructing analytics metadata.
  - Centralize immutable plugin telemetry metadata construction in
  `PluginsManager`.
  - Route local install/uninstall, remote install, enable/disable, and
  plugin-used emitters through the manager.
  - Preserve the current serialized analytics contract exactly.
  
  Normal metadata still has no remote override. Remote install continues
  to provide its authoritative backend ID explicitly, so the existing
  serializer continues reporting that ID through `plugin_id`.
  Snapshot-based enrichment is intentionally deferred to the final PR.
  
  ## Testing
  
  - `just test -p codex-core-plugins` (238 tests passed)
  - `just test -p codex-plugin` (3 tests passed)
  - Scoped Clippy/compile checks passed for `codex-plugin`,
  `codex-core-plugins`, `codex-app-server`, and `codex-core`.
  
  ## Split Overview
  
  ```text
  main
  ├── #27093  Debug analytics capture                 (merged)
  ├── #27099  Non-mutating plugin smoke               (merged)
  ├── #27100  Remote install/uninstall smoke          (merged)
  └── #27102  Plugin telemetry metadata refactor      ← you are here
      └── #27669  Persist remote plugin identity
  
  After #27102 and #27669 merge:
  └── Final PR: add explicit local and remote IDs to plugin analytics
  ```
  
  Review order and dependencies:
  
  1. [#27093 Add debug-only analytics event
  capture](https://github.com/openai/codex/pull/27093) (merged)
  2. [#27099 Add a plugin analytics smoke
  workflow](https://github.com/openai/codex/pull/27099) (merged)
  3. [#27100 Add a remote plugin analytics mutation smoke
  workflow](https://github.com/openai/codex/pull/27100) (merged)
  4. This metadata refactor, independent and based on `main`
  5. [#27669 Persist remote plugin
  identity](https://github.com/openai/codex/pull/27669), stacked on this
  PR
  6. Final remote-ID behavior PR, created after the prerequisites merge
  
  The original [#26281](https://github.com/openai/codex/pull/26281)
  remains open as the aggregate reference until the final replacement PR
  is published.

  jameswt-oai · 2026-06-22 10:27:23 -07:00
  44dbae90eb
• Filter noisy targets from persistent logs (#29457)

  ## Why
  
  The local SQLite log sink currently enables TRACE for every target. This
  persists high-volume dependency logs bridged through `target=log` and
  duplicates OpenTelemetry mirror events in `codex_otel.log_only` and
  `codex_otel.trace_safe`.
  
  These records rapidly consume the per-partition log budget and cause
  unnecessary SQLite insert-and-prune churn.
  
  ## What changed
  
  - Keep TRACE persistence for other targets.
  - Exclude bridged `target=log` events from the SQLite sink.
  - Exclude the two `codex_otel` mirror targets from the SQLite sink.
  - Share the same filter between app-server and TUI.
  
  Remote OpenTelemetry export and metrics are unchanged.

  jif · 2026-06-22 18:17:04 +02:00
  e98d43ac37
• Add workspace messages app-server API (#29001)

  ## Summary
  
  - Add backend-client types and fetch support for active workspace
  messages.
  - Add the app-server v2 `account/workspaceMessages/read` method,
  generated schemas, and README documentation.
  - Delegate workspace-message eligibility to the Codex backend feature
  gate; map a backend 404 to `featureEnabled: false`.
  
  ## Testing
  
  - `just write-app-server-schema`
  - `just test -p codex-backend-client`
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-app-server workspace_messages`
  - `just fix -p codex-backend-client -p codex-app-server-protocol -p
  codex-app-server`
  - `just fmt`
  
  ## Stack
  
  - Base PR for #28232, which adds the TUI status-line integration.

  xli-oai · 2026-06-22 04:25:07 -07:00
  21d36296f1
• 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
• Add config toggles for orchestrator skills and MCP (#28942)

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

  jif · 2026-06-19 14:42:26 +02:00
  81b000421d
• 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
• [3/3] app-server: configure environment connection timeout (#29025)

  ## Why
  
  Remote environments registered through `environment/add` currently use
  the fixed 10-second WebSocket connection timeout. Slow-starting
  executors need a caller-selected connection window, but this should not
  add retry policy or couple exec-server behavior to Core’s
  `deferred_executor` feature.
  
  Make the timeout an optional part of the existing experimental request.
  Existing clients continue using the current default, while callers that
  know an executor may take longer can request a larger window explicitly.
  
  Depends on #28683.
  
  ## What changed
  
  - Add optional `connectTimeoutMs` to `EnvironmentAddParams` and document
  it in the app-server README.
  - Pass the optional timeout through `EnvironmentRequestProcessor` into
  one `EnvironmentManager::upsert_environment()` path; the manager applies
  the existing default when it is omitted.
  - Preserve the existing single-attempt lifecycle. The configured value
  controls WebSocket connection and handshake time for both initial
  connection and later reconnects; initialization retains its separate
  timeout.
  - Add an app-server integration test that sends the real JSON-RPC
  request and verifies a stalled handshake observes the requested timeout.
  
  ## Test plan
  
  - `just test -p codex-app-server-protocol`
  - `just test -p codex-exec-server`
  - `just test -p codex-app-server
  environment_add_applies_connect_timeout`
  
  ## Rollout
  
  This is additive and does not enable `deferred_executor`. Callers should
  send a non-default timeout only after a compatible app-server is
  deployed; omitted or `null` values retain the existing 10-second
  default.

  sayan-oai · 2026-06-19 05:27:45 +00:00
  f886e33e5a
• 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
• [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: 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