MCP instruction deltas fork subagent conversations, doubling execution cost

Summary

When a subagent is spawned via the Agent tool (with teams), late-arriving MCP instruction deltas create a conversation fork — a second branch with a new promptId that replays from the same starting point. Both branches execute independently, effectively doubling the work and token cost for every subagent.

Reproduction

1. Have a global MCP server configured (e.g., Telegram plugin in ~/.claude/settings.json)
2. Create a team via TeamCreate
3. Spawn a subagent via Agent(subagent_type=..., team_name=...)
4. Observe subagent JSONL logs: two separate conversation branches exist, each with a different promptId, both executing the same dispatch prompt

Evidence from real session

In an email triage workflow session, I dispatched 4 subagents (2 work batches, 2 personal batches). JSONL logs showed 11 subagent processes instead of the expected 4-5:

promptId=9f49a1d2  agents=4  (original branches)
promptId=368249e6  agents=7  (forked branches from MCP delta)

The 368249e6 branches all have an attachment entry at line 4-6 with:

{
  "type": "attachment",
  "attachment": {
    "type": "mcp_instructions_delta",
    "addedNames": ["plugin:telegram:telegram"],
    "addedBlocks": ["## plugin:telegram:telegram\n..."]
  }
}

After this attachment, the forked branch continues executing the same tool calls as the original. Both branches independently call external APIs (Gmail in this case), run bash commands, and write to files.

Token cost impact

For the 04-07 triage run in this session:

| Branch set | Agents | Cache create | Purpose |
|-----------|--------|-------------|---------|
| Original (9f49a1d2) | 4 | 446K | Real work |
| MCP fork (368249e6) | 7 | 2.0M | Duplicate work |

The MCP forks consumed ~4.5× more cache_create tokens than the original branches and performed the same external API calls redundantly.

Expected behavior

MCP instruction deltas arriving after subagent spawn should be merged into the existing conversation branch, not create a new fork. The model should see the updated instructions on its next turn within the same promptId.

Workaround

Disabling the MCP server (Telegram in this case) before spawning subagents prevents the fork. But this requires users to manually manage MCP server state around subagent dispatch.

Feature request

In addition to fixing the fork behavior, it would be useful to have:

• Per-agent MCP server exclusion (e.g., excludeMcpServers in agent frontmatter) so subagents that don't need certain MCP servers don't load them at all
• Or a global setting like propagateToSubagents: false per MCP server configuration

Related

• #32730 — Subagent-created teams persist on disk after session ends
• #4476 — Agent-Scoped MCP Configuration with Strict Isolation

Environment

• Claude Code version: 2.1.92
• OS: macOS
• MCP server: Telegram plugin (telegram@claude-plugins-official)