## Why
Plugin and skill catalog reads currently wait for the Apps server's initial `tools/list` to finish, even after its MCP transport is initialized.
## What changed
Add the disabled-by-default `features.apps_early_resource_discovery` flag. When enabled, host-owned Apps requests for `mcp/plugin` and `mcp/skill` resources can use the initialized transport while the initial tool inventory is pending. Server readiness still waits for the inventory to complete, and retries use normal readiness.
Bound early client acquisition by the configured startup timeout, propagate startup failures and cancellation, and reject pages if the connection, authentication scope, or resource cache generation changes during discovery.
## Testing
Add coverage for gated discovery, concurrent plugin and skill reads, startup timeouts and failures, cancellation, cache invalidation, and account switches. Verify that early discovery reuses a single handshake and tool inventory, including with the newer MCP protocol and connection sharing enabled.
GitOrigin-RevId: 955b1f6d43b733bdf9763c1caf2ce6913c686c81
## What changed
- Support an optional cloud provider alongside executor plugins, refreshing its thread-scoped catalog at each regular turn when plugins are enabled.
- Use cloud connector metadata for app attribution without starting cloud-declared MCP servers.
- Scope cached catalogs to authentication and Apps availability. Retain the previous catalog on discovery failure within the same scope, clear stale catalogs on auth changes, and reject results completed under outdated credentials.
- Add a cancellable regular-task startup phase that reconciles MCP before discovery and reapplies contributor state afterward without invalidating resource caches.
## Testing
Add regression coverage for per-turn refresh, empty catalogs, discovery failures, plugin disabling, auth changes during discovery, MCP reconciliation and cancellation, and cloud app attribution alongside executor MCP tools.
GitOrigin-RevId: 8469eb109ea316e21cbc4122c52ad8000caeef03
## Why
Orchestrator skill caches were tied to the entire MCP connection set, so runtime updates could discard cached catalogs and contents even when the Apps connection was reused. Plugin changes still need to refresh those resources without requiring a reconnect.
## What changed
Key orchestrator skill caches by the Apps server connection and an explicit invalidation generation. Preserve cached resources while that identity stays unchanged, and invalidate them on MCP runtime refresh requests or configuration refreshes. Replacing the connection also changes the cache identity.
## Testing
Extend the production-turn integration test to verify cache reuse across ordinary turns and approval-policy changes, refreshed skill contents after plugin invalidation without reconnecting, and fresh resource requests after a forced reconnect.
GitOrigin-RevId: 43ce059972369c4c735742e8224b60a692244b02
## Why
Codex Apps applies resource MIME filters to each request separately, so continuation requests must include the filter as well as the cursor.
## What changed
Add `McpResourceClient::list_codex_apps_resources` with a required `mime_type` and optional cursor. Send the filter as a top-level `mimeType` parameter in `resources/list` requests and return resources with the next cursor.
Require a host-owned `codex_apps` registration before sending filtered requests, rejecting extension servers that use the same name.
## Testing
Add integration tests covering MIME filters on both pagination requests, returned resource pages, and rejection of extension name collisions without sending a resource request.
GitOrigin-RevId: 4fb33da56c6ef99286564ead7f74b77d8b337335
## Why
Event subscriptions may need to outlive the MCP runtime associated with a task.
## What changed
- Add `McpEventStreamOpener`, which retains the hosted Apps MCP connection settings and opens each event stream with an independent client.
- Keep subscription cancellation tied to account changes and removal of the task's event server, including when cancellation ownership is forwarded across runtime replacement.
- Expose the opener and cancellation forwarding through `McpResourceClient`.
## Testing
Add an HTTP transport test that shuts down the runtime, refreshes credentials for the same account, and verifies that a new event stream connects with the current authorization and receives notifications.
GitOrigin-RevId: e102aa382e63121661ff0567f7523515e459922d
## What changed
- Add `McpEventStream::open` to construct event stream requests and keep the
underlying `RmcpClient` alive until the subscription completes or is canceled.
- Stop retaining the broader `McpServerConnection` for the lifetime of an event
stream, and remove the connection-returning lookup helper.
- Use MCP event server terminology in event discovery and subscription errors.
GitOrigin-RevId: 7d6c7b8ed9c5447d2d8cda4a077da845fb026173
## What changed
- Add experimental `mcpServer/event/stream/start` and `mcpServer/event/stream/stop` requests for hosted apps, plus `mcpServer/event/stream/notification` forwarding.
- Scope subscriptions to the owning app-server connection and subscribed thread, enforce unique IDs and a per-connection limit, and clean them up when the thread is unsubscribed or the connection closes.
- Wait for the MCP active notification before completing startup, retry streams that close immediately, and terminate them when authentication or hosted runtime ownership changes.
## Testing
- Add an app-server integration test covering activation, event forwarding, duplicate subscription rejection, and explicit cancellation.
GitOrigin-RevId: 8a6fc1615adfc5af7e67def3b824fa5909ab3e7b
## What changed
- Expose hosted Plugin Runtime event definitions through `McpResourceClient::list_events`.
- Add cancellable `events/stream` subscriptions that route lifecycle notifications to the matching request and cancel when the stream is dropped.
- Bound event notification and queue sizes, time out stalled response headers, and close streamable HTTP responses locally on cancellation.
## Testing
- Add streamable HTTP integration coverage for isolated concurrent subscriptions, local cancellation, and stalled response-header timeouts.
GitOrigin-RevId: 98c6fffa8f004eb2638c1b0705f659222cbbdfdb
## What changed
- Make `McpRuntime` own the published MCP configuration, connections, elicitation routing, and selected capability roots for a thread.
- Capture immutable MCP bindings for model steps and tool calls so in-flight work keeps a consistent connection set and approval authority while refreshed state is published atomically.
- Mark MCP state dirty when relevant configuration, plugins, environments, authentication, or elicitation capabilities change, then rebuild it before the next sampling request or out-of-band MCP operation.
- Separate config reloads from server invalidation: `ReloadMcpConfig` applies resolved MCP inputs, while `RefreshMcpServers` requests reinitialization from the thread's latest state.
## Testing
- Cover refreshed state visibility for existing turns, stable step bindings, current approval authority, cancelled refresh retries, resource-client reconciliation, and Apps recovery between sampling requests.
GitOrigin-RevId: 59eabb1aa8dc083426bd18ef4d3630508f376401
## What changed
- Make `McpResourceClient` resolve resource operations and cache identity from
the latest `McpRuntime` connection snapshot.
- Remove step-bound resource clients from `McpBinding` and the associated
per-binding client identity tracking.
GitOrigin-RevId: ee59f5867308c5a63e6e232384a50cf1e0c2a011
## What changed
- Use `McpConnectionSet` as the primary name for the collection of active MCP
server connections throughout `codex-mcp` and its callers.
- Keep `McpConnectionManager` as a backward-compatible type alias.
GitOrigin-RevId: 9753838b4fd0a0b6429a9c4af0c077137616f388
## Why
An MCP connection or tool catalog can change after a model step captures its
available tools. Calls from that step must not be rerouted to a replacement
client or run against a catalog revision the model did not see.
## What changed
- Add `McpBinding` to capture the ready clients, visible tools, resources, and
server metadata for one sampling request.
- Prepare calls against the captured client and reject them if the tool catalog
changes before call preparation and execution finish.
- Keep resource access and cache identity tied to the binding's exact connection
set, and omit servers that do not have a ready client.
- Preserve each client's unfiltered tool catalog so bindings can apply the
current filter consistently.
## Testing
Add coverage for connection replacement, stale catalog rejection, serialized
call preparation and refresh, ready-client capture, and binding-scoped resource
identity.
GitOrigin-RevId: a25da4d2c7f5ed06c41caa0c6d15c464c1698314
## What changed
- Add a thread-owned `McpRuntime` that atomically publishes connection-set
replacements and owns shutdown.
- Route `McpResourceClient` snapshots and cache keys through that runtime so
extension clients observe refreshed MCP servers.
- Keep model-step configuration snapshots separate from ownership of live MCP
connections.
## Testing
- Add coverage that captures an extension's session resource client, refreshes
the MCP server configuration, and verifies that the existing client sees the
newly published server.
GitOrigin-RevId: 351b2e25594b8eb6b91e50ff8d06b7d49768ae1c
## Why
Hosted orchestrator skills are read through the remote MCP resource
server. Within one thread, the same catalog or skill resource can be
requested multiple times by prompt injection and the `skills.list` /
`skills.read` tools. Re-fetching adds latency and can make those
surfaces observe different remote contents during the same thread.
This is a follow-up to #28333: orchestrator skills remain limited to
threads without a local executor, and those threads now get a stable
per-thread view of the remote skill data they use.
## What changed
- Reuse the existing per-thread orchestrator catalog snapshot for
`skills.list` and `skills.read` availability checks.
- Cache successful orchestrator resource reads by authority, package,
and resource so prompt injection and tool calls share the same contents.
- Keep the cache memory-only and bounded to 100 resources and 8 MiB per
thread.
- Leave host and executor skill reads unchanged, and do not cache failed
remote reads.
## Verification
- Extended the app-server MCP resource integration test to read the same
hosted skill resource twice and verify that the remote server receives
one read.
- The same test verifies that catalog discovery and the selected skill's
main prompt are each fetched only once per thread.
## Why
#27198 made the extension-owned `codex_apps` MCP connection the hosted
plugin runtime, but its `mcp/skill` resources still bypassed the skills
extension. App-server could list and read those resources through
generic MCP APIs, but a thread with no selected environment did not
expose them in the model's skills catalog or load their `SKILL.md`
through `$skill`.
Hosted skills should stay remote while using the same typed catalog,
source authority, deduplication, bounded contextual catalog, and
selected-skill prompt injection as host and executor skills. They should
not be downloaded or exposed as ambient filesystem paths.
## What changed
- Add a session-scoped `McpResourceClient` over the replaceable MCP
connection manager so resource list/read calls follow startup and
refresh replacements.
- Add a `BackendSkillProvider` that pages `codex_apps` resources,
accepts bounded and validated `mcp/skill` entries, and reads a selected
skill's `SKILL.md` through the same MCP connection.
- Register the remote provider in app-server and include it in the
skills catalog even when a thread has no selected capability roots or
executor.
- Contribute hosted skill metadata through the bounded
`AvailableSkillsInstructions` developer-context path, exclude remote
entries from per-turn catalog injection, and classify `<skills>`
messages as contextual developer content so rollback can trim and
rebuild them correctly.
## Testing
- Extend the app-server MCP resource integration test with
`environments: []` to exercise two-page discovery, filter a
non-`mcp/skill` resource, verify the escaped developer catalog entry and
user-role `<skill>` fragment containing the fetched `SKILL.md`, and
preserve generic MCP resource reads.
- Add core event-mapping coverage that classifies `<skills>` developer
messages as contextual history.
bkotsopoulos