MCP stdio transport for sub-agents (task tool) closes after ~4 seconds while agent is still running

[dsotelo-hiberuscom]

Bug Report

Summary

When a sub-agent is launched via the task tool, the MCP stdio transport for all configured MCP servers closes approximately 4 seconds after the agent's connections are established — while the LLM is still generating its first response turn. Any MCP tool calls made after those 4 seconds fail with MCP server 'X': Error: Not connected.

Environment

• Copilot CLI version: 1.0.34
• OS: Ubuntu (WSL2)
• MCP server: engram (local stdio, SQLite-backed)

Steps to Reproduce

1. Configure an MCP server in ~/.copilot/config.json under mcp
2. Launch a sub-agent via the task tool (e.g., a custom agent)
3. Ask the sub-agent to call any MCP tool

Observed Behavior

From Copilot CLI logs (~/.copilot/logs/process-*.log):

T+0ms    MCP client for engram connected, took 432ms
T+0ms    Started MCP client for engram
T+0ms    Successfully started MCP server 'engram'
T+0ms    Found 11 MCP tools from server 'engram'
         ... LLM generating response (agent still running) ...
T+4135ms MCP transport for engram closed   ← BUG: transport closes here
T+4135ms MCP client for engram closed
         ... agent continues running for 20-70 more seconds ...
T+25000ms Agent completes

All MCP tool calls in the agent return: MCP server 'engram': Error: Not connected

Expected Behavior

The MCP transport should remain open for the lifetime of the sub-agent context, not close after a fixed ~4-second timeout during the LLM generation phase.

Additional Notes

• The main (orchestrator) agent's MCP connections remain open indefinitely ✅
• Only sub-agents launched via the task tool are affected ❌
• The 4-second timeout appears to be a hardcoded connection lifetime for sub-agent MCP transports
• The first MCP tool call occasionally succeeds if made within the 4-second window (race condition)
• Reproduced consistently across multiple restarts

Log Evidence

2026-04-22T08:29:42.945Z [ERROR] Started MCP client for engram
2026-04-22T08:29:42.945Z [INFO] Successfully started MCP server 'engram'
2026-04-22T08:29:42.945Z [INFO] Found 11 MCP tools from server 'engram'
2026-04-22T08:29:46.647Z [ERROR] MCP transport for engram closed   <- 3702ms later
2026-04-22T08:29:46.647Z [ERROR] MCP client for engram closed
2026-04-22T08:30:11.381Z [INFO] Agent completed successfully        <- 24734ms later

[yangfei222666-9]

This is a good example of why agent workflows need lifecycle-level evidence, not only final completion status.

From an operator view, the important split is:

• sub-agent context is still running
• MCP transport is closed
• tool calls after that point are guaranteed to fail
• final agent completion may still look successful

That should probably become a first-class degraded state instead of being discovered only through later tool-call failures.

I am working on a small agent regression guard that records exactly these before/after lifecycle facts so "agent completed" cannot hide "tool channel died mid-run". Not a fix for this issue, but this is the failure class it is meant to catch.

[ewh1995]

Version: 1.0.51
OS: macOS (Darwin, Apple Silicon arm64)
MCP server: @azure-devops/mcp v2.7.0 (stdio, envvar auth)
Agent invocation: via task tool (background sub-agent)

Reproducing this on v1.0.51 with a slightly different timing signature — the transport closes ~1.575 seconds after connection (not ~4 seconds as in the original report), specifically immediately after the AI model returns its first turn response.

Exact log sequence:

T+0ms    [mcp server ado stderr] Starting Azure DevOps MCP Server (envvar auth, domains: core, wiki)
T+6ms    MCP client for ado connected, took 535ms
T+6ms    Started MCP client for ado
T+6ms    Successfully started MCP server 'ado'
T+8ms    Found 9 MCP tools from server 'ado'
T+8ms    Custom agent using tools: ado-wiki_create_or_update_page, ado-wiki_get_page, ...
T+141ms  Sending request to the AI model  ← model turn begins
T+1575ms MCP transport for ado closed     ← transport closes exactly when model responds
T+1575ms MCP client for ado closed
         ... agent runs for ~90 more seconds, all MCP tool calls return "Not connected"

The transport closes at the exact same timestamp as the AI model's first turn completing (within 53ms). All subsequent tool calls from the agent return MCP server 'ado': Error: Not connected.

The MCP server itself is healthy — running it manually with the correct env var set keeps it alive indefinitely. The issue is solely in how the sub-agent context manages the connection lifetime.

Also noting a double-start pattern visible in logs: the runtime starts the MCP server twice — once before the agent begins (tool discovery) and again when the agent actually runs. The second instance is the one that closes prematurely.

cc #2630 — related: confirmed sub-agents on v1.0.51 do receive mcp-servers: frontmatter tools (discovery works), but the transport doesn't survive past the first model turn.

[copilot-cli-bot]

This appears to be resolved as of GitHub Copilot CLI v1.0.86. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.

[yangfei222666-9]

One question, plus something optional.

Has anyone hit the first-turn transport closure again on v1.0.86 or later? The bot closed this against v1.0.86, and I have not verified that fix myself — I don't have a copilot-cli setup to reproduce against (the original ~4s and the later ~1.575s signatures are both other people's reports), so I'd rather flag that than imply the fix is confirmed. If it does still happen, that seems worth reopening.

For context on why I'm asking here: in April I argued that this class is nasty because the sub-agent context can still be running while its MCP transport has already closed — any later tool call that depends on that transport fails, and yet the run can still end in a "completed" state. I suggested that deserved to be a first-class degraded state rather than something you only learn from downstream tool-call errors.

Optional, and I want to be exact about its limits: I built something small in that direction, but it is not a fix for this bug and does not instrument MCP at all, so it would not have caught #2892. It demonstrates only the downstream part — a heartbeat that refuses to run when its evidence ledger has been tampered with, instead of printing a green summary. That is an integrity check, not a lifecycle check; I'm not claiming it covers the transport-closure mechanism itself.

git clone https://github.com/yangfei222666-9/xiaojiu-ops-brain.git
cd xiaojiu-ops-brain/reference/butler-skeleton && ./demo.sh

You need git for the clone; the demo itself needs only bash and python3, runs in a throwaway copy, and needs no keys. If you'd rather not clone anything, the CI log for that exact commit is public (ubuntu + macOS, both green): https://github.com/yangfei222666-9/xiaojiu-ops-brain/actions/runs/35473692339

A report I could actually act on would say: OS, python3 --version, that steps 1–2 passed, and what step 3 did (a non-zero exit there is the expected outcome; the line to look for is [ok] heartbeat refused the corrupt ledger, as opposed to an unrelated environment error). If it doesn't run at all on your setup, a one-line note would help me understand portability.

If nothing turns up, that's a fine answer too — I'll record my April argument as externally unverified and check back on this thread in about two weeks.