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.