Sub-agents with full tool access return empty with no error; restricted-tool agent types work identically

Describe the bug

Sub-agents launched via the task tool return no response at all — no error, no partial output, no log entry — when the agent type has access to the full tool set. The same model, same prompt, and same session succeed when launched with a restricted-tool agent type.

The tool call returns Agent completed but produced no response. and the parent agent has no way to distinguish this from a legitimately empty answer.

Affected version

CLI 1.0.73, GitHub Copilot desktop app, Windows 11 x64.

Steps to reproduce the behavior

With 12 MCP servers configured (mix of stdio and http), run the same trivial prompt through different agent types:

task(agent_type: "explore",          model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-SOL-EXPLORE. Do not use any tools. Nothing else.")
task(agent_type: "general-purpose",  model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE. Nothing else.")
task(agent_type: "rubber-duck",      model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-DUCK. Do not use any tools. Nothing else.")
task(agent_type: "task",             model: "gpt-5.6-sol", prompt: "Reply with exactly: ALIVE-TASK. Do not use any tools. Nothing else.")

Results:

agent_type	tool access	result
explore	restricted (grep/glob/view/bash)	✅ returns ALIVE-SOL-EXPLORE
general-purpose	all tools + MCP	❌ empty
rubber-duck	all tools + MCP	❌ empty
task	all CLI tools	❌ empty

This is not model-specific. The same matrix fails identically on gpt-5.6-sol, gpt-5.6-terra, and claude-opus-4.8, in both sync and background mode. It reproduces with a prompt that explicitly forbids tool use, so it is not caused by the sub-agent attempting a tool call.

Expected behavior

Either the sub-agent returns its response, or the failure surfaces as an error the parent agent can act on. A silent empty return is the worst outcome: the parent cannot tell "the agent had nothing to say" from "the agent never ran".

Additional context

Nothing is logged. The session CLI log contains zero [ERROR] or [WARN] entries during the sub-agent window. The only errors in the whole session log are unrelated MCP startup problems from ~60s earlier:

[ERROR] MCP server "workiq": also defined by plugin "workiq"; using the version from plugin "msx-mcp".
[ERROR] Failed to start MCP client for msx-mcp: failed to initialize MCP client: connection closed: initialize response
[ERROR] Failed to start MCP client for azure: failed to initialize MCP client: connection closed: initialize response
[ERROR] [rust:rmcp::transport::worker] worker quit with fatal: Transport channel closed, when Client(OAuthChallenge ...)

Session config: contextTier: long_context, model: claude-opus-5, effortLevel: high. 12 MCP servers configured (powerbi-remote, pekg, WebIQ, workiq, aspire, context7, Eng-Hub, bluebird, microsoftdocs, foundry-mcp-remote, azure, msx-mcp).

Suspected cause, not proven: the correlation is exactly with how much tool schema the agent type carries into context. That matches #3542, which measured ~573K tokens of enterprise MCP tool schema against a ~136K runtime cap and reported contextTier: long_context being ignored. I have verified the correlation with agent type and ruled out the model; I have not instrumented the actual token budget, so the causal link to schema size is inference rather than measurement.

If that is the mechanism, the fix in #3542 (honor contextTier, or lazy-load tool schemas) would likely resolve this too — but the silent-empty-return behaviour is worth fixing independently, since it turns a budget problem into an invisible one.

Practical impact: any workflow that delegates to general-purpose or a specialist agent silently produces nothing. In my case an entire adversarial code review returned empty four times across three models before I isolated the agent type as the variable. The workaround is to route work through explore, which defeats the purpose of the specialist types.

Possibly related: #3542 (MCP schema exceeds token limit), #2630 (custom agent mcp-servers not connected in sub-agent contexts), #3293 (extension tools not propagated to sub-agents).

Separate observation

The same ~/.copilot/logs directory contains single session logs of 6.25 GB and 5.17 GB. Whatever is being written at that volume may be worth a look independently of this bug.

Commencez par le task tool et la gestion de l’agent-type des sub-agents, en reproduisant la matrice de prompts fournie avec un accès complet et restreint aux outils. Vérifiez comment les réponses vides et les échecs sont propagés et consignés ; le travail est terminé lorsque le parent reçoit la réponse ou une erreur exploitable, plutôt qu’un résultat vide silencieux.