## What changed
- Retain the trusted enterprise identity provider in runtime configuration and bind winning MCP registrations during catalog finalization. Require `features.use_xaa` and a configured identity provider for activation, while preserving existing server restrictions.
- Apply plugin `ema_auth` client, issuer, resource, and scope settings to installed and selected plugins. Disable registrations with mismatched endpoints or empty resources without rewriting plugin endpoints.
- Preserve enterprise auth policy across catalog rebuilds and rebind registrations when materialized server settings change. Keep registration rejection separate from persistent server-name vetoes so it does not disable replacement hosted apps.
## Testing
Add coverage for activation gates, configuration ownership, plugin endpoint validation, catalog rebuilds, and skipping interactive OAuth during installation of enterprise-managed plugins. Stabilize the sandbox network proxy test by reading request headers before closing the loopback connection.
GitOrigin-RevId: 3374f507d120835b285767cedbbb511fc7b0fba2
## Why
Idle Apps clients and cached MCP bindings can retain replaced tool definitions. Shared catalog updates can also invalidate prepared calls even when the current definitions match the captured catalog, including after tools are restored while a call awaits approval.
## What changed
- Share immutable tool arrays across equivalent live discovery contexts and reuse storage for equal results. Let unused providers and cached bindings expire.
- Include requested capabilities and initialization results in the sharing scope, and detach servers that disable catalog caching from live sharing.
- Capture catalog snapshots for prepared calls. Accept equivalent shared catalogs regardless of tool-list order, while rejecting changed definitions and calls captured before an explicit refresh on that client.
## Testing
Add regression coverage for shared storage and scope isolation, release of replaced tools and unused bindings, equivalent catalog restoration, explicit refresh invalidation, and an Apps call completing after catalog restoration while awaiting approval.
GitOrigin-RevId: a0516186e4286d0ff13405fafbab6fcf3f1f3773
## Why
`connector_auth_failure_from_tool_result` requires an install URL to return an auth failure, even when the tool result contains valid auth failure metadata.
## What changed
Export `is_connector_auth_failure_from_tool_result` from `codex-mcp` to detect auth failures independently of an install URL. Share metadata validation with the existing parser, requiring an error result, an explicit auth failure flag, and a nonempty connector ID that does not conflict with the metadata.
## Testing
Add unit tests for detection without an install URL, rejection of missing or mismatched connector identities and non-auth errors or successful results, and detection for all three supported auth reasons.
GitOrigin-RevId: 6e4e177f26d9a34c56874b0360bae63f6c89107e
## Why
Enterprise MCP authorization must remain controlled by host, user, or managed configuration. Project settings and plugin declarations must not redirect enterprise credentials or downgrade the selected authentication mode.
## What changed
- Add `auth = "ema_auth"`, shared `mcp_enterprise_managed_auth` IdP configuration, and per-plugin enterprise registration settings.
- Require enterprise registrations to come from one non-project configuration layer, preserve managed IdP precedence, and reject project overrides that change authorization or re-enable disabled enterprise servers.
- Add the disabled-by-default `use_xaa` feature flag and require non-project opt-in or a managed requirement.
- Reject plugin declarations that select `ema_auth`. Keep EMA connections unsupported and block ordinary MCP OAuth login and credential fallback for this mode.
- Extend the configuration schema and serialization for the new settings.
## Testing
Add coverage for IdP precedence, incomplete registrations, alternate credential validation, project-only opt-in, plugin self-declaration rejection, configuration round-tripping, and trusted-project attempts to downgrade enterprise auth to OAuth or ChatGPT auth.
GitOrigin-RevId: f193bdfda74208c98e496a23bf2916955b131a1c
## What changed
Add `serverCapabilities` to `mcpServerStatus/list` responses in both `full` and `toolsAndAuthOnly` modes, including thread-scoped reads. Return the initialized server's capabilities object, including its `extensions` map, or `null` when unavailable.
Capture capabilities during initialization so they remain available when tool discovery fails. Clear them on each new connection attempt and keep them independent of shared tool caches. Update the protocol schemas, generated TypeScript and Python types, and documentation.
## Testing
Add coverage for extension capabilities surviving tool-discovery failures in both detail modes. Extend existing tests to check advertised extensions, absent capabilities after initialization failure, and serialization of unavailable capabilities as `null`.
GitOrigin-RevId: 8e9d67c10fac3a54e82bef8be5d99caaf82597d1
## What changed
- Apply `disabled_plugin_ids` to plugin skills, recommendations, hooks, and MCP servers without modifying shared plugin state.
- Activate selection changes when the next task starts, keeping pending settings from changing the active runtime.
- Hide app tools contributed only by disabled plugins from model tool catalogs and search. Preserve connectors shared with enabled plugins and existing direct Apps RPC behavior.
- Include plugin identity in MCP approval keys and use that identity when persisting plugin tool approvals.
## Testing
Add regression coverage for disabling and re-enabling plugin skills and tools, deferred activation of settings, shared connector ownership, selected plugin servers, executor hooks, and plugin-specific approval keys and persistence.
GitOrigin-RevId: 1153ff6aa7ab6953d50e838da05203904ecd2956
## Why
Extension-owned HTTP MCP servers previously inherited the default protocol mode. Extensions need to select a mode for their own server independently of other HTTP servers.
## What changed
- Add `McpServerContribution::SetWithProtocolMode` and re-export `McpProtocolMode` through the extension API.
- Carry the winning registration's protocol override through catalog resolution and materialization, and apply it to Streamable HTTP connections.
- Preserve existing defaults when no override is present. Selecting a protocol mode does not grant host-owned Apps cache access or environment authority.
## Testing
Add coverage for registration precedence and materialization, and extend cache isolation tests to cover explicit protocol selection. Add an integration test verifying that extension servers can select either the legacy or newer protocol while other HTTP servers retain the default mode.
GitOrigin-RevId: 606cecc03094a93258ffc433849f575020b81473
## 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
Status-only discovery could retain an `OAuth` status based on stored credentials even after the connection attempt failed authentication. This discovery path has no event channel to report the failure.
## What changed
Update the snapshot to report `NotLoggedIn` for servers previously marked `OAuth` whose connection attempts failed authentication. Preserve other authentication statuses and OAuth statuses for failures unrelated to authentication.
## Testing
Add a regression test covering OAuth authentication failure, successful OAuth startup, an unrelated provider error, and a bearer-token authentication failure.
GitOrigin-RevId: 9df68fb1f818e40acab0c71bb4fda118f03a7611
## Why
Hosted Codex Apps shared the `mcp_2026_07_28` protocol setting with other MCP servers, preventing independent protocol selection.
## What changed
- Add `features.codex_apps_mcp_2026_07_28`, disabled by default, for the host-owned HTTP `codex_apps` server. Enabling it attempts 2026-07-28 discovery with Legacy fallback.
- Keep other servers, including third-party registrations with Apps-like names or URLs and local stdio servers, governed by `mcp_2026_07_28`.
- Support the new flag through `experimentalFeature/enablement/set` and refresh protocol settings in existing sessions. Track protocol mode per server when deciding whether to reuse connections.
## Testing
Add coverage for independent feature and protocol selection, hosted event-stream protocol selection, standalone Legacy defaults and discovery fallback, and runtime enablement refreshing an existing app-server thread.
GitOrigin-RevId: 640e8e251f0c45e5f4829cc2b73c3082cf42f715
## Why
Dormant MCP servers with usable cached tool catalogs prevented binding reuse, causing each model step to capture a new binding even when the catalog was unchanged.
## What changed
Track dormant catalog revisions alongside ready client revisions so bindings can be reused until the catalog changes or the server starts. Explicit server and plugin requirements still trigger binding capture and startup. Check cached catalog availability without cloning tool definitions.
## Testing
Extend the lazy-startup integration test to verify that two model steps share one binding while the server stays dormant, and that starting the server invalidates that binding.
GitOrigin-RevId: ef0469a85000f84a928946c24350e3bda1522fb5
## Why
Refreshing installed Apps without a thread should update the tools available to existing threads on their next turn.
## What changed
- Publish live tool catalogs to clients with matching transport, auth, protocol, and listing settings within the same account and home directory. Ignore the thread attribution header when matching scopes.
- Adopt updated tools before catalog reads and new calls, preserving running calls and rejecting calls prepared against an outdated catalog revision.
- Keep the newest successful fetch per scope so older refreshes cannot overwrite newer tools, and exclude disk snapshots from live updates.
## Testing
Add regression coverage for refresh propagation to an existing thread without another tools listing, scope and account isolation, out-of-order refreshes, late client startup, and running versus stale prepared calls.
GitOrigin-RevId: 7a5ee34e23742ce374c6647dc8928b76ea622448
## Why
Configured MCP servers must not be able to request user verification, even when they reuse the hosted apps server name. Local verification identity selection also needs to distinguish a user's workspace memberships.
## What changed
- Advertise `userVerification` only to the host-owned apps MCP server and cancel verification requests from other servers before prompting the client.
- Add `CodexAuth::get_chatgpt_account_user_id()` to read the access token's opaque `chatgpt_account_user_id` only when its workspace matches the selected account. Missing or malformed claims return no identity, without falling back to another user ID or breaking ordinary authentication.
## Testing
Add coverage for capability filtering, rejection of configured servers including those using the hosted apps name, and account-user identity selection with malformed or mismatched claims. Add an MCP round-trip test showing that verification waits for a client response even in full access mode, returns the supplied proof, and discards response metadata.
GitOrigin-RevId: 156e83d5a0302c013b85e564b46b4bfe858cbdb0
## What changed
Advertise the experimental `codex/auth-change` capability for stdio MCP connections with an auth manager. When the server opts in, send `notifications/codex/authChanged` after initialization and on subsequent auth changes, with credential and owner generation counters and no credentials.
Track owner changes separately from credential refreshes so consumers can detect login, logout, or user, workspace, and auth-mode changes even when notifications coalesce. Treat credential changes with incomplete owner identity as owner changes as well.
Tie the notification watcher to the managed client's lifetime, limit each send to five seconds, and close the connection if a subsequent notification fails.
## Testing
Add tests for credential refreshes versus owner changes, coalesced logout and account switches, capability opt-in, notification payloads, and watcher cleanup.
GitOrigin-RevId: 35a99f5252bd48ca60a71fbdd1f708a8158e812c
## Why
Device-authenticated verification needs an app response outside automated approval and review. Previously, MCP user-verification requests were always cancelled.
## What changed
- Add typed `openai/userVerification` elicitations carrying a title, description, and challenge through core and app-server.
- Route verification to one connection enabled by trusted host activation. Restrict responses to that owner, exclude requests from replay, and cancel on disconnect or authentication changes, including account switches away and back.
- Return proofs in `content`, discard response metadata, and cancel malformed acceptances. Suppress verification response logging and analytics, and send only a generic verification notice to realtime.
- Keep the mode experimental and exclude it from stable schema exports. Capability advertisement remains disabled, and the TUI cancels verification requests.
## Testing
Add coverage for owner isolation, disconnect and authentication races, proof response handling, automated-review bypass, inactive-host cancellation, stable schema filtering, and realtime payload exclusion. Update the MCP integration test to verify that an activated request holds the tool until the client responds.
GitOrigin-RevId: c8c7b6691a3f7756682bbcca9def1df0d1feb906
## What changed
- Handle `openai/userVerification` requests through `openai/elicitation/create` when the client advertises `userVerification` support.
- Validate request fields, size limits, and base64url encoding. Require a correctly shaped, bounded proof for acceptance; cancel invalid acceptance responses and discard proof material on decline or cancellation.
- Handle request and service cancellation, including cancellation received before request dispatch. Bound early-cancellation storage and cancel new verifications when capacity is exceeded.
- Keep verification inactive in Codex: cancel requests without prompting until the typed app-server and UI path is available.
## Testing
Add tests for request and proof validation, malformed modes, cancellation races and capacity limits, timeout-pause cleanup, and independent concurrent requests. Add integration coverage showing that verification does not prompt or prevent tool and turn completion before activation.
GitOrigin-RevId: 6313c1be40fae0b33cc3ce0f8fe025b4124ed2ef
## Why
Refreshed Apps catalogs need to survive connection reuse. Catalog revisions scoped to the connection set can lose refreshed tools during reconciliation and invalidate prepared calls for unrelated servers.
## What changed
- Store tools, revisions, and refresh coordination on each MCP client, and key cached bindings by client identity and revision.
- Preserve existing binding snapshots while rejecting stale calls before preparation. Wait for active calls to finish before publishing a refreshed catalog.
- Add `CodexThread::refresh_codex_apps_tools` to reconcile the runtime and return the refreshed client's raw Apps inventory alongside tool names eligible under that runtime's generic MCP policy. Keep hidden and disabled tools in the inventory for callers to apply app-specific policy.
## Testing
Add regression coverage for refreshed catalogs surviving client reuse, unrelated calls remaining valid, binding cache invalidation, and refresh snapshots retaining the client's own inventory when another client wins the shared-cache race. Update stale-call and preparation tests to use client-owned catalogs.
GitOrigin-RevId: f2308c81f7474eb31f3380c091c977030123cda2
## Why
An empty tool map does not distinguish a successfully returned empty catalog from a server whose startup or tool discovery failed.
## What changed
- Add nullable `toolsError` to each `mcpServerStatus/list` entry when no catalog is available because startup or tool discovery failed.
- Keep `toolsError` null for returned catalogs, including cached and empty catalogs, and continue returning healthy servers when another server fails.
- Update the protocol schemas and generated TypeScript type.
## Testing
- Extend the app-server status integration test with a broken MCP server and verify its error without losing the healthy server's inventory.
GitOrigin-RevId: 30b4ca4d9a45cec6998f5f626d3fddbee90a525d
## What changed
- Honor `McpOAuthRefreshMode::Coordinated` for streamable HTTP MCP connections by letting RMCP refresh and persist credentials through the pinned credential store.
- Reread credentials while holding the refresh lock, persist refreshed tokens before retrying requests, and serialize login and logout writes with in-flight refreshes.
- Keep OAuth preparation outside MCP operation and handshake deadlines, and allow refresh persistence to finish if the initiating caller is cancelled.
## Testing
- Cover coordinated startup refresh, concurrent refreshes, `401` retries, credential mutation races, provider timeouts, and caller cancellation.
GitOrigin-RevId: 100ae788048087be23e26bb43f868b1fcebb007a
## Why
Selected plugin MCP servers may be skipped after the optional startup grace
period. When a user explicitly mentions a plugin or MCP server, the turn should
continue waiting so the requested tools are available to the model.
## What changed
- Track explicitly mentioned plugin IDs and MCP servers across later samples,
steered input, and same-turn restarts.
- Require matching selected-plugin MCP servers to finish startup before
capturing the tool catalog, while leaving unmentioned servers optional.
- Match `plugin://` identities independently of display names and ignore
targeting query parameters such as `app` and `browserFamily`.
## Testing
Added coverage for linked and structured plugin mentions, direct and batched
capability discovery, delayed environment attachment, steering, and same-turn
restarts.
GitOrigin-RevId: c509ef8df45df1a7edb0da6afdb2682dc53a4de8
## What changed
- Log failed MCP server startup outcomes once per startup attempt, including failures during discovery that do not emit startup notifications.
- Preserve the full error chain when converting startup failures into cloneable outcome errors.
GitOrigin-RevId: 54bbf2abaf3329d9828b2d2bc5d877fddc2917e1
## What changed
- Add the under-development `mcp_oauth_refresh_coordination` feature and pin its selected refresh mode to each MCP connection.
- Treat the refresh mode as part of OAuth connection identity so runtime and MCP configuration refreshes reconnect when the mode changes.
- Keep legacy refresh behavior in builds where coordination is unavailable and emit a warning when coordinated mode is selected.
## Testing
- Cover connection replacement when the feature is toggled through both runtime and MCP configuration refresh paths.
GitOrigin-RevId: 89596150f0338e6ede0e712badecea4450831766
## 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
- Allow MCP server names to contain `:`, `@`, `/`, and `.`, enabling names such as `npm:@modelcontextprotocol/server-sequential.thinking`.
- Preserve these names across `mcp add`, `get`, `list`, and `remove`, runtime tool namespaces, and OAuth credential lookup.
- Quote non-bare server names in generated `config.toml` recovery hints and keep similarly escaped OAuth credential names isolated.
## Testing
- Add CLI and runtime round-trip coverage for npm-style names.
- Add snapshot coverage for quoted recovery hints and a regression test for OAuth credential-name collisions.
GitOrigin-RevId: 97e9353cdbc544db4eb2377ddbfa1d2d539b1e04
## What changed
- Advertise `openai/elicitation` form support when the client declares an
object-valued `form` capability, without deriving it from the legacy
`openai/form` capability.
- Handle `openai/elicitation/create` requests in `form` mode and forward their
metadata and opaque schema through app-server as `openaiForm`, preserving
`x-openai-*` annotations.
- Keep legacy form handling independent and have the TUI automatically decline
the new form requests it cannot render.
## Testing
- Add an app-server round-trip test for capability negotiation, request
forwarding, and accepted responses.
- Extend MCP capability filtering coverage for `openai/elicitation.form`.
GitOrigin-RevId: 88f39257bffafe4ee98a9c910e38507843cd7eeb
## What changed
- Add a positive `output_token_limit` setting to each entry under an MCP server's `tools` configuration.
- Apply the most restrictive limit when plugin and user policies overlap, while keeping approval policy independent.
- Carry the effective MCP output budget in conversation history so tool output, post-tool hook responses, and resumed sessions use the same truncation limit.
## Testing
- Cover configuration parsing, serialization, schema validation, and plugin policy merging.
- Cover MCP output below and above the configured limit, post-tool hook responses, and session resume.
GitOrigin-RevId: d0beb4fca9ba6055d9e1d31c137373b465d50d61
## Why
An MCP binding can wait for one server while another connection updates a
shared tool catalog. Preferring the catalog captured before that wait can omit
newly available tools from the first model request.
## What changed
- Recheck the current MCP tool catalog before using the captured fallback.
- Keep the captured catalog when it expires during the wait, while honoring a
server that disables catalog caching.
## Testing
- Cover a shared Apps cache populated by a peer while binding capture waits.
- Cover cache opt-out while capture waits for another server.
GitOrigin-RevId: e4389c7ba23e4d8397dbae0930c9e36ba0a172fb
## Why
Binding capture can wait for multiple MCP servers concurrently. During that wait, a tool catalog may be published by another connection or expire after it has already allowed a server to remain dormant. Re-reading only the current cache could omit those tools or trigger unnecessary startup.
## What changed
- Retain the cached catalog that permits lazy startup for the duration of binding capture.
- Recheck the cache after the optional startup grace so catalogs published while waiting are included.
- Add regression coverage for catalogs published during startup and catalogs that expire while another server is resolving.
GitOrigin-RevId: b5c66831db8f9ebecc79ff25c5b4b0182ad68a2f
## What changed
- Add `mcp_optional_startup_grace_ms` with a default of 1,000 ms to control how long tool catalog capture waits for optional MCP servers.
- Treat a value of `0` as disabling the shared grace, so optional servers use their configured `startup_timeout_sec` instead.
- Apply updated grace values during runtime and MCP configuration refreshes, and reset cached startup deadlines when the configured duration changes.
## Testing
- Cover custom, disabled, refreshed, and shared startup grace behavior in MCP connection and core integration tests.
GitOrigin-RevId: 936196215ed6e0a29c9ec72cfee17663978df8ef
## Why
Plugin MCP trust decisions must describe the exact host-discovered server
registration. Looking up a plugin again by ID can resolve a different root.
## What changed
- Retain the host plugin root in MCP catalog attribution and connection identity.
- Reconnect an MCP server when its attributed plugin root changes.
- Pass the retained root through tool lifecycle attribution and use it directly
when building trusted tool context.
## Testing
Add coverage for catalog identity, connection reconciliation, lifecycle
attribution, and rejecting a different root associated with the same plugin ID.
GitOrigin-RevId: bc92743dd40ab44065a07c3ea972b4956ef8351f
## What changed
- Fetch ChatGPT account access and attach `cyber_trusted_access` under
`openai/entitlementContext` when an installed or selected plugin explicitly
requests it from a local, read-only stdio tool with no arguments.
- Reject caller-supplied entitlement context on direct MCP calls, and fall back
to an `unknown` status when access cannot be verified or the account changes
during the lookup.
- Count entitlement lookup time against the MCP tool-call timeout.
## Testing
- Cover eligible calls plus unowned, remote, HTTP, mutable, argument-bearing,
API-key, undeclared, direct, and account-switch cases in core and app-server
integration tests.
GitOrigin-RevId: 303b61585ef4530276c373d914a2d0ccef1f4ac2
## What changed
- Add `TrustedAccessContext` to fetch account-bound cyber verified-access grants and attach them as host-owned `openai/entitlementContext` metadata.
- Replace caller-supplied entitlement metadata and return an `unknown` status when authentication, identity consistency, response validation, size limits, or the lookup deadline cannot be verified.
- Add `HttpResponseBodyStream::from_chunks` for lightweight in-memory streaming clients.
## Testing
- Cover grant mapping, unsupported authentication, account and workspace changes, malformed or oversized responses, duplicate programs, and lookup timeouts.
GitOrigin-RevId: 343b6a6608c98c45a34939ef507c2183516a11c1
## What changed
- Add optional `McpToolContext` metadata to `ToolStartInput`, exposing the
model-visible MCP tool details and its source classification without exposing
the executable client.
- Classify MCP calls as connectors, configured servers, plugin servers,
executor-selected plugins, or other registrations based on the prepared call.
- Prepare each MCP call before notifying tool lifecycle contributors and reuse
that same call for execution so the callback describes the call that runs.
## Testing
- Cover host-owned connector calls and extension-owned Apps server calls,
including their distinct provenance and executed tool names.
GitOrigin-RevId: efd23f511b1045ffdd96349d621ad62365569b2b
## Why
MCP servers attached to executor environments must retain their owner's
permission profile instead of inheriting the thread-wide sandbox authority.
## What changed
- Resolve and capture a permission profile for each enabled MCP server when
publishing the runtime, and reject calls or elicitations when that authority
is unavailable.
- Use the captured server profile for tool approval decisions, elicitation, and
sandbox metadata, including after runtime refreshes.
- Materialize `:workspace_roots` from `PathUri` values so permissions preserve
the path convention of remote executor environments.
- Give threadless app discovery and resource reads an explicit default
permission profile.
## Testing
Added coverage for per-server elicitation authority, unresolved attachments,
runtime refreshes, restricted tool calls, and foreign-platform workspace roots.
GitOrigin-RevId: 6b188d4b08b29e9971ff7aa68a7785a0cdf9e394
## Why
MCP servers can share an OAuth callback URL. Without a validated issuer or a
server-specific callback path, an authorization response could be associated
with the wrong server.
## What changed
- Use stable callbacks when authorization metadata advertises issuer-bound
responses, and validate the returned issuer before exchanging the code.
- Retain server-specific callback IDs for providers without issuer support,
including fallback to the global or default callback for legacy registered
clients.
- Persist registered callback URLs for MCP servers and plugins, and insert the
active listener port into portless loopback redirects.
## Testing
Add coverage for issuer validation, callback-mode discovery, registered and
legacy clients, plugin OAuth, CLI persistence, and loopback listener ports.
GitOrigin-RevId: 2878c92e237fc17fd3def0bd2e1cce3e104a3db8
## Why
Reusing an MCP connection that is still starting after its
`startup_timeout_sec` changes leaves the old startup budget in effect.
## What changed
- Track the effective startup timeout on each MCP connection.
- Reuse a pending startup only when its timeout still matches the current
configuration.
- Continue reusing ready connections when only the startup timeout changes.
## Testing
Added integration coverage that refreshes the timeout while one server is
still initializing and another is ready, verifying that only the pending
startup is replaced.
GitOrigin-RevId: 5ed71a57d3bf0dd6e227aacd16acd3a35bc37ecf
## What changed
- Include the configured authentication mode in the MCP connection identity so
runtime reconciliation replaces connections instead of reusing them after an
authentication-mode change.
- Add a regression test covering a switch from OAuth to ChatGPT authentication
for an executor-owned MCP server.
GitOrigin-RevId: 18cd9df62a9a5ee44594dcde6a844ad7d5e67ee2
## What changed
- Add Windows sandbox mode, private-desktop behavior, and legacy Landlock selection to each `EnvironmentConfig`.
- Centralize sandbox context construction on `TurnEnvironment`, preserving environment-owned permissions, paths, and backend settings while applying additional permission grants.
- Use the environment-derived context for project instructions, capability discovery, file uploads, and filesystem-oriented tools.
## Testing
- Verify capability discovery uses the selected environment's permission profile and sandbox backends when they differ from the thread defaults.
GitOrigin-RevId: 7ae2fed90c8ada950f2e8431e571e9b2c793c291
## Why
MCP inventory can be cached or collected separately from a thread's live
connections, so tool availability alone does not describe the current runtime
state.
## What changed
- Add a nullable `runtimeStatus` to `mcpServerStatus/list` for thread-scoped
requests, covering not-started, starting, connected, authentication-required,
failed, cancelled, and disabled connections.
- Observe published connection state without starting or reconnecting servers,
and return an unknown status when no thread is supplied or the active
configuration no longer matches the published registration.
- Show connection state and tool counts in the compact `/mcp` view while
retaining the detailed inventory in `/mcp verbose` and compatibility with
servers that omit `runtimeStatus`.
## Testing
- Cover runtime status transitions, deferred and disabled servers, closed
transports, configuration changes, protocol compatibility, and TUI rendering.
GitOrigin-RevId: e3bb6efe652f0fa8b3c97d5c53e4729b3a87cd91
## What changed
Propagate canonical denial, timeout, and abort responses from strict MCP
auto-review instead of replacing them with a generic decline. This preserves
the reviewer's action and metadata, including denial rationale, while still
failing closed when no canonical decision is available.
Update the fallback message to direct the agent to request explicit user
approval before proceeding.
## Testing
Add unit and app-server integration coverage for strict auto-review denials
and cancellations.
GitOrigin-RevId: d8126ab223ab546b95e2d984f6e4dd540a324a59
## What changed
- Scope executor-provided stop-hook calls to the MCP server environment that registered the hook, and reject calls when that environment does not match.
- Forward turn metadata with executor stop-hook requests while retaining the hook call's `threadId` metadata.
## Testing
- Cover environment matching for MCP tool calls and verify executor stop hooks receive their environment ID and request metadata.
GitOrigin-RevId: b544ea3a6ca1f61389fb4597978ed7aac27d529a
## Why
Older executors do not support resolving HTTP header values from their own
environment. Sending environment-backed bearer tokens to them can prevent MCP
servers from starting.
## What changed
- Advertise executor support for environment-backed HTTP headers with the
`httpHeaderEnvVars` capability.
- Delegate bearer-token resolution only when the selected executor advertises
that capability; otherwise, resolve tokens available in the host environment.
- Exclude executor-owned MCP servers that require environment-backed bearer
tokens when the executor cannot resolve them, while retaining compatible
host-owned and executor-owned servers.
## Testing
Added protocol and environment-variable coverage plus an end-to-end test that
simulates an older executor and verifies compatible MCP servers remain usable.
GitOrigin-RevId: 43545926f6f7e0f3b1091eb29d34647f6372bc4a
## What changed
- Read `mcp_servers` configuration and requirements from each selected remote
executor and add eligible HTTP servers to the thread's MCP runtime.
- Bind discovered servers to the thread's concrete executor snapshot and apply
environment MCP policy and requirements. Discovery is best effort, and
executor-local servers are not treated as required at startup.
- Ignore unsupported stdio servers and HTTP configurations that depend on
environment-provided headers or header helpers.
## Testing
- Added an app-server integration test covering discovery, authenticated HTTP
tool invocation, requirements enforcement, and exclusion of stdio servers.
GitOrigin-RevId: 6e1cdcebdbb1cc21a5a2285fbc5617d8d5997182
## Why
Remote HTTP MCP connections can source header values from the host environment,
so those variables must remain part of the connection identity even when the MCP
server runs in an executor environment.
## What changed
- Track `env_http_headers` variables for remote HTTP MCP connections.
- Continue tracking `bearer_token_env_var` only for local environments, where the
host resolves the token.
## Testing
Add coverage that verifies remote connections track host header variables without
tracking executor bearer-token variables, while local connections track both.
GitOrigin-RevId: 8fe175c54a101721a27b76495dcd298f0c2bc6a3
## Why
Executor-owned HTTP MCP servers need to read their bearer credentials from the
selected executor environment instead of the host process.
## What changed
- Preserve `bearer_token_env_var` for executor-owned HTTP MCP configurations and
resolve it when the executor sends each request.
- Extend delegated HTTP headers with executor-local environment references while
rejecting missing, empty, or protected credential variables.
- Keep transport-provided bearer authentication compatible with MCP redirect and
OAuth handling without sending a placeholder authorization value.
## Testing
- Cover authenticated executor-owned MCP requests end to end.
- Cover delegated header resolution and rejection of protected variables.
- Cover parsing executor-owned bearer configuration and transport-provided bearer
behavior.
GitOrigin-RevId: 442bf7382198ffb69eba797eb36d4c74faabda88
## 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
## Why
The Responses API accepts tool names up to 128 bytes, but MCP tool name
normalization limited model-visible names to 64 bytes.
## What changed
- Preserve MCP tool names up to the 128-byte Responses API limit.
- Continue shortening and hashing names that exceed the limit so generated
names remain bounded and unique.
## Testing
- Cover names at the 128-byte boundary and immediately above it.
- Verify distinct long names remain 128 bytes and code-mode compatible.
GitOrigin-RevId: 75544d00e75dd0e9328b3e2ac763d26f9cc99a48
## What changed
- Add environment-provided MCP restrictions for configured and plugin-provided servers.
- Disable attachment-scoped servers while their environment configuration is pending, failed, or unselected, while preserving selected-plugin access and the controller-owned Apps server.
- Apply the resolved policy to runtime startup, model tool exposure, telemetry, OAuth flows, and skill dependency installation.
## Testing
- Cover policy filtering for configured and plugin servers, environment state transitions, Apps ownership, and managed OAuth rejection.
GitOrigin-RevId: 7ca5d4dda14068e758497f88835d5cba685e159e
