## Why
Prepared MCP calls cloned `ToolInfo` already stored in the binding's model-visible catalog, duplicating tool metadata.
## What changed
Store the binding catalog in an `Arc<[ToolInfo]>` and let prepared calls reference its entries by index. Keep separately owned metadata for tools hidden from the model and calls prepared outside the binding catalog.
## Testing
Extend the binding test to assert that advertised and prepared tool metadata share the same address, while preserving ready-client catalog selection and hidden-tool behavior when tool names collide.
GitOrigin-RevId: 24b92f7e1dbb421c9ebce875b9b1024f7d697c5e
## Why
Legacy MCP tool discovery discarded pagination cursors, leaving tools on later pages unavailable.
## What changed
Pass `tools/list` pagination cursors to the existing collector in both legacy and modern protocol modes. Legacy discovery now follows subsequent pages and applies the same pagination limits and cursor validation as modern discovery.
## Testing
Extend integration coverage to both protocol modes, checking that tools from later pages reach the model and can be called successfully, while catalogs with oversized cursors are rejected. Update the legacy discovery test to expect an error for a repeated cursor.
GitOrigin-RevId: a6daa8034d2a403c1f2a5846e385789d8a620af7
## Why
Inspecting one MCP server should not require full-inventory discovery or a separate connection when a thread already has one.
## What changed
- Add optional `serverName` to `mcpServerStatus/list` and update generated schemas and bindings.
- With `threadId`, apply any pending runtime refresh and reuse the thread's current connection and tool catalog, waiting only for the selected server during discovery.
- Without `threadId`, create a discovery connection for only the selected server. Unknown names return an empty page; omitting `serverName` preserves full-inventory discovery.
## Testing
Add a regression test covering both status detail modes, checking that tool metadata is preserved and that status reads do not repeat `initialize` or `tools/list` requests.
GitOrigin-RevId: 1b361b67a993ab45cae493e88c146f50cfaf753a
## Why
Cached executor MCP declarations must not gain access to host environment credentials when reconnecting to an executor that lacks environment credential resolution.
## What changed
- Retain credential policy through MCP registration, catalog materialization, and runtime setup. Derive selected HTTP plugin policy from the plugin's source environment.
- Reject host bearer-token fallback and transports requiring host environment headers or helpers for executor-owned declarations. Preserve host-configured credential resolution.
- Include credential policy in connection and tool catalog cache identities, and avoid reading host environment values for executor-only identities.
## Testing
Add regression coverage for legacy executors, cached declarations after a capability downgrade, policy preservation through catalog rebuilds, and connection and tool cache isolation.
GitOrigin-RevId: 2d5b85e4e98668c637c538cbe528914c936bd831
## Why
Fixed schema budgets can strip parameter descriptions from large MCP tools or render their Code Mode input types as `unknown`. Allow larger budgets to preserve that guidance.
## What changed
- Add `mcp_servers.<name>.tool_input_schema_max_bytes` to configure the UTF-8 byte threshold for best-effort input schema compaction, retaining the 5,000-byte default.
- Add `features.code_mode.tool_input_schema_max_bytes` for rendered input types. Use the largest of the 16,000-byte default, the Code Mode setting, and the ordinary MCP server's explicit setting.
- Apply rendering budgets to prompt declarations and the runtime tool catalog, and avoid reusing cached declarations after the Code Mode budget changes.
## Testing
Add coverage for UTF-8 compaction thresholds, budget precedence, configuration round trips, and preservation of parameter guidance in both the Code Mode prompt and `ALL_TOOLS`.
GitOrigin-RevId: 0ef2823a614d4794e636f518b09c0b03a5239b45
## Why
Required MCP servers can block startup while establishing a live connection even when a usable tool catalog is already cached.
## What changed
- Add per-server `startup_readiness = "catalog"` to expose cached tools while the connection starts, retaining `"connection"` as the default.
- Allow an eligible cached catalog to satisfy required-server startup validation and model binding capture. Explicit server or plugin requirements still wait for a live connection, and tool execution still requires the current connection.
- Check tool filters and model visibility when accepting cached catalogs, and preserve cached catalog revisions for binding reuse.
- Serialize the new setting, expose it in the configuration schema, and trace startup readiness at validation and model binding gates.
GitOrigin-RevId: a1cbdf1757ebb5824cffe2cc56408be49711c422
## Why
MCP OAuth configuration supported a pre-registered client ID but could not supply a client secret for token exchange or refresh.
## What changed
- Add `oauth.client_secret` and `codex mcp add --oauth-client-secret`, requiring a nonempty secret and client ID. Persist the secret in server configuration and accept `clientSecret` in plugin configuration.
- Pass configured credentials through CLI, app-server, and plugin login flows and token refresh. Require a new login when a configured confidential client's ID differs from stored credentials.
- Redact secrets in debug output and keep them out of authorization URLs and persisted OAuth token records.
- Invalidate cached OAuth connections when the configured client ID or secret changes.
## Testing
Add coverage for configuration validation and round trips, CLI argument redaction and subsequent login, app-server login, connection invalidation, and refresh with `client_secret_basic` and `client_secret_post` in both refresh modes. Verify secret exclusion from token records and reject mismatched client IDs before contacting the provider.
GitOrigin-RevId: 85bb0e410e9e68e6cd68eb6359badfc7eac78147
## Why
MCP requests requiring user input previously failed in subagents with guidance to ask the parent agent, blocking browser sign-in, form input, and interactive tool approval in the child thread.
## What changed
Remove the root-only MCP elicitation guard and `allow_user_interaction` plumbing so subagents can surface prompts and wait for responses under the existing approval policy and automatic review rules. Connector authentication can now return retry guidance after acceptance or preserve the original failure when declined.
Keep legacy tool approvals through `request_user_input` restricted to the root thread.
## Testing
Update unit and integration coverage for subagent prompt resolution, form responses, connector authentication acceptance and decline, automatic approval, strict review, and approval-policy updates on reused connections. Update the browser sign-in scenario snapshot to show the subagent continuing after an accepted response.
GitOrigin-RevId: c226fc6dfde724ed22b91dc04dd32bbc15245bee
## Why
MCP requests that need human input, including browser sign-in, must be handled by the root thread. Subagents need guidance to hand these blockers to their parent without prompting the user or automatically accepting requests that require input.
## What changed
- Reject interactive MCP elicitations and tool approval prompts in subagents with guidance to ask the parent and wait before retrying.
- Recognize browser authentication and `codex_requires_user_input` metadata even when the form schema is empty, while preserving automatic permission approvals and review decisions.
- Carry user-interaction eligibility through MCP runtime creation and connection reuse, and guard prompt registration.
- Preserve connector authentication diagnostics alongside handoff guidance, subject to normal tool-output limits.
## Testing
Add unit and integration coverage for blocked subagent prompts, root browser authentication, automatic approval and review, connection reuse, and authentication diagnostic preservation and truncation. Add a request-history snapshot for browser-auth handoff guidance.
GitOrigin-RevId: 83e146b6e5c1a2a22a34681ad45615f504b3c96c
## Why
Read-only MCP discovery and invocation need a consistent policy across requests, connection reuse, and tool catalogs. Reusing an unrestricted connection or cached catalog can bypass filtered discovery.
## What changed
- Thread `requires_read_only_mcp_tools` through MCP configuration and client setup, leaving it disabled by default.
- When enabled, set `openai/readOnly` to `true` in `tools/list` and `tools/call` request metadata, overriding a caller-supplied `false` while preserving other metadata, pagination, and arguments.
- Include the policy in connection identity and bypass shared Apps and persistent tool catalog caches for read-only connections.
## Testing
Add coverage for metadata propagation in legacy and modern protocol modes, preservation through session recovery, and isolation from unrestricted connections and shared Apps catalogs.
GitOrigin-RevId: f4a3a4021a54e302bffd53f08092b080c056246b
## 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
## 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
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
## 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
## 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
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
- 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
- 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
- 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
## 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
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
## 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
- 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
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
- Execute hook-triggered MCP calls through the runtime's latest connection set instead of preparing a separate catalog-bound call.
- Keep hook calls from waiting for server startup or reconnecting, and reject disconnected servers immediately.
- Apply the shorter of the hook-requested timeout and the server's configured tool timeout.
## Testing
- Update connection manager tests to cover non-waiting calls and disabled tool filters.
GitOrigin-RevId: 3166b2d1e26d9ae2b8b3a648b4d0897cc260eb93
## What changed
- Execute `mcp_tool` hook handlers through the session's shared MCP runtime, including managed hook configurations.
- Restrict hook calls to already-connected, cataloged, and policy-allowed tools. Unavailable servers fail immediately without starting or reconnecting them.
- Pass session metadata to hook tools, cap hook timeouts by the server timeout, and invoke hooks without model-tool approval or recursive hook dispatch.
- Record handler type and execution mode in hook telemetry, and mark memory as externally influenced after successful or blocking MCP hooks when configured.
## Testing
- Added end-to-end coverage for prompt interpolation, hidden tools, blocking decisions, unavailable servers, thread metadata, approval bypass, and memory-mode handling.
- Added MCP runtime coverage for startup readiness, tool filters, catalog revisions, and managed connector policy.
GitOrigin-RevId: 1647cb801ebc5fa385c7bda9d9c266a389c611b8
## Why
MCP runtime reconciliation can occur while an unchanged server is still
starting, such as when capability roots become available. Reconciliation
should neither wait for that startup nor initialize the same server again.
## What changed
- Reuse an active, uncancelled pending MCP connection when its identity,
catalog limit, and protocol mode still match.
- Publish the shared startup result through the reconciled server view while
applying its updated tool filter.
- Preserve cancellation when a reused pending server is subsequently removed.
## Testing
Added coverage for filtered-tool publication, disabling a reused pending
server, and capability-root reconciliation during Codex Apps startup.
GitOrigin-RevId: 690cf8695e75b341d097d7d22b5da6993b24e787
## Why
When an MCP server rejects existing OAuth credentials, reporting that the server
is merely not logged in obscures that the user needs to authenticate again.
## What changed
Pass the MCP startup failure reason into error formatting and report that the
server requires OAuth reauthentication when appropriate. Preserve the existing
recovery hint for either `codex mcp login` or the client's OAuth sign-in flow.
## Testing
Cover the reauthentication message for both login flows and verify it in the
streamable HTTP OAuth round-trip test.
GitOrigin-RevId: 6f6d5fe7519b1a476f8b70d976223b2ea1ec938e
## What changed
- Add `http_headers_helper` configuration for local streamable HTTP MCP servers. The configured shell command runs once per connection and returns a JSON object of headers that is cached across requests.
- Apply helper headers to MCP startup and OAuth flows while restricting them to the server origin, stopping redirects, rejecting reserved or duplicate headers, and enforcing output and execution limits.
- Reject helpers for remote or managed-disabled servers, use the local environment working directory, and redact helper commands from `codex mcp list` and `codex mcp get` output.
## Testing
- Cover configuration validation, helper lifecycle and output parsing, origin isolation, OAuth discovery and token refresh, managed requirements, environment selection, and CLI redaction.
GitOrigin-RevId: 84e0e26ce75520b0869d37c72b1678e033bd6818
## Why
Subagents should be able to use known HTTP MCP tool definitions without opening a connection until a tool is actually called.
## What changed
- Add streamable HTTP configurations to the process-scoped MCP tool catalog cache when their authentication identity can be derived safely.
- Fingerprint transport settings, relevant environment variables, protocol mode, plugin status, and client capabilities so catalogs are reused only across equivalent connections.
- Keep OAuth and other dynamically resolved credential configurations out of the shared cache.
## Testing
- Add an integration test proving that a subagent receives cached HTTP tools without reinitializing the server, then starts its own connection when it calls one.
GitOrigin-RevId: bb2787e29e9b71993def31aafd1f0d8f1b728d26
## What changed
- Cover non-blocking credential probes when the file or secrets store is locked, including retaining only a matching prior credential snapshot and recovering after the lock is released.
- Extend the streamable HTTP OAuth round trip to verify that user turns continue during store contention, newly discovered servers recover after contention, and logged-out servers do not reuse authenticated connections.
- Cover reconciliation of authentication failures and effective `Authorization` headers.
GitOrigin-RevId: 8e377644001bd0be04dc9f79841080094d09d199
## Why
Standard MCP forms can require user-entered values even when tool permissions are
otherwise auto-approved in full-access sessions.
## What changed
- Recognize the `openai/standard-form-input` client extension and surface
non-approval forms in full-access, user-initiated root threads.
- Keep approval forms, automation and subagent threads, headless sessions, and
clients without the capability on their existing decline or review paths.
- Treat the capability as client-only so it is not advertised to MCP servers,
and enable it after session startup so required servers cannot block startup
waiting for form input.
## Testing
Add unit and app-server coverage for accepted form round trips, declined cases,
approval metadata safeguards, resumed threads, and extension filtering.
GitOrigin-RevId: 053bfe397a5c79eceef90a81d13e2aca6353af43
## Why
Refreshing MCP connection identities should not stall the async executor while another process holds the OAuth credential-store lock.
## What changed
- Probe file and secrets credential stores without waiting during runtime refreshes, retaining the last known credentials when the store is contended.
- Reuse unchanged authentication failures while credentials are temporarily unavailable instead of restarting the connection.
- Run blocking credential loads on a blocking worker during MCP client construction.
- Allow OAuth fallback when a configured authorization header is missing, empty, or invalid.
GitOrigin-RevId: 38dad5606da9a1ceb30fe945000ec9151a5058fa
## What changed
- Add lifecycle-backed gauges for in-flight and queued app requests, pending server requests and mailbox messages, active turns, and live MCP connections.
- Register each gauge on first use and decrement it when the tracked work or resource is dropped.
- Document the new `server/diagnostics` gauge names and account for the diagnostics request itself in the response example and test.
GitOrigin-RevId: 4bb82a3918af0b502d149b5d761ad669b2083f39
## Why
An OAuth-backed Streamable HTTP MCP server can fail startup when its stored credentials are rejected. If a client then completes OAuth sign-in and replaces those credentials, the failed server needs to become available without restarting the Codex session.
## What changed
- Track the credential store and OAuth tokens used for each MCP connection, and detect replacements after authentication failures.
- Refresh affected MCP servers before the next turn and include their recovered tools in the model request.
- Classify HTTP authentication challenges and rejected refresh tokens as requiring reauthentication, with sign-in guidance appropriate to local and client-managed environments.
## Testing
- Cover recovery from expired credentials through an externally written replacement token.
- Cover authentication-error classification, startup messaging, and `Auto` store migration from file credentials to the keyring.
GitOrigin-RevId: 9b090089d4e7a44ffc182f4e25da20a18e97b70f
## Why
Subagents can reuse cached MCP tool definitions without starting every optional
server before any of its tools are used.
## What changed
- Defer startup for subagent-owned, optional MCP servers when their cache has at
least one visible, allowed tool, and trigger startup on the first operation
that needs the live client.
- Keep root sessions, required servers, selected plugin servers, and explicit
reconnects eager.
- Exclude empty catalogs from cache eligibility and keep dormant servers out of
the initial startup summary.
## Testing
- Extend MCP tool-cache coverage for eager root startup, unused and filtered
subagent servers, deferred startup status events, and startup that survives an
interrupted first tool call.
GitOrigin-RevId: e7528ff08312583a6747cbc6550ea5b6eabda9a6
## What changed
- Cache an `McpBinding` on each published MCP runtime once server startup has
settled and the tool catalog revision is stable.
- Reuse the cached binding while the catalog revision remains unchanged, and
rebuild it after a runtime publish or catalog change.
- Treat terminal failures from optional servers as stable, while continuing to
wait for required servers and reconnecting Codex Apps servers.
## Testing
- Cover binding reuse within one published runtime and invalidation after a
republish.
- Cover stability checks for pending, failed optional, required, and
reconnected servers.
GitOrigin-RevId: 783a6b04897f6c484a6d56fd9cee542814041759
Owen Lin