High-severity 1.0.80+ regression: MCP schemas are eagerly injected, adding 354K startup tokens

Describe the bug

Severity / impact: High.

Starting in the 1.0.80 runtime line, the CLI appears to have stopped deferring MCP tool schemas. A fresh session now injects the full ambient MCP catalog into the first model request, even when the user submits a trivial prompt that needs no tools.

With the same configuration and equivalent no-tool prompt:

Runtime	First-request input tokens	Tool definitions marked deferred
1.0.79	49,084	1,597
1.0.81-3	403,209	0

That is 354,125 additional input tokens, an 8.2x request, and an 87.8% reduction when reverting to 1.0.79. The affected request consumes about 38% of a 1.05M-token model window before substantive work begins. An independent earlier 1.0.80-0 observation used 454,691 input tokens, about 43% of that window.

These numbers come from actual first-assistant-request usage accounting, not the /context display estimate.

The behavior increases startup latency and input cost. It also leaves much less context for conversation history, repository content, and the user's task. Large MCP catalogs are a supported configuration and were handled correctly by deferred loading in 1.0.79.

Affected version

• Known good: 1.0.79
• Measured affected: 1.0.80-0, 1.0.81-3
• Environment: macOS on ARM64, Node.js 25.4.0
• The newer v1.0.81-11 prerelease has not been tested, so I am not claiming it is affected.

Steps to reproduce the behavior

1. Configure a valid ambient MCP catalog with many tools. The measured configuration had 56 MCP servers and 1,597 deferred tool definitions on 1.0.79.
2. Start a fresh CLI session on 1.0.81-3.
3. Submit a no-tool prompt such as: Reply exactly OK without using tools.
4. Record the first assistant request's input-token usage.
5. Inspect debug logs for tool-definition deferral.
6. Repeat with the same configuration and prompt on package runtime 1.0.79, using --no-auto-update so the launcher cannot select a newer cached runtime.

Observed:

• 1.0.81-3: 403,209 first-request input tokens and zero tool definitions marked with "deferLoading": true.
• 1.0.79: 49,084 first-request input tokens and 1,597 tool definitions marked with "deferLoading": true.

The raw logs contain private MCP configuration, so they are not attached. The aggregate counts above were derived after redacting tool and server identities.

Expected behavior

The initial request should include enough MCP metadata to discover available tools, while deferring full input schemas until a tool or server is selected. First-request usage should not grow in proportion to every configured tool's complete JSON schema.

This was the observed behavior in 1.0.79, where tool definitions carried "deferLoading": true.

Additional context

This appears to be a runtime regression in the MCP tool-definition serialization or deferred-loading path introduced between 1.0.79 and 1.0.80.

This is distinct from #4189. That issue reports that /context displays the undeferred schema footprint even though actual deferred MCP cost remains small. Here, actual request usage rises to 403K because the deferred markers disappear.

Current workaround:

1. Launch the cached 1.0.79 package runtime directly.
2. Always pass --no-auto-update.
3. Do not rely on pinning only the native launcher, because it can select a newer cached package runtime.

A regression test could create a large synthetic MCP catalog, start a fresh no-tool session, and assert that:

1. Tool schemas remain deferred in the first model request.
2. Initial input usage does not scale with the complete schema bytes of every registered tool.

Commencez par la sérialisation des définitions d’outils MCP et le chemin de chargement différé, en comparant runtime 1.0.79 à 1.0.80+. Exécutez une session synthétique avec un grand catalogue et sans outil, puis inspectez la première requête du modèle et les journaux de débogage. C’est terminé lorsque les schémas d’outils conservent les marqueurs deferLoading et que l’utilisation initiale de l’input n’évolue pas avec chaque schéma enregistré.