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

[ChrisMcKee1]

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.

[ChrisMcKee1]

Update: confirmed by controlled test. Halving the number of configured MCP servers fixes it.

I disabled 6 of my 12 configured MCP servers and restarted the client. Everything that previously returned empty now works, with no other change:

agent_type	12 MCP servers	6 MCP servers
explore	works	works
general-purpose	empty	works
rubber-duck	empty	works
task	empty	works

Same model (gpt-5.6-sol), same prompts, both sync and background. Verified with real work as well as trivial replies: a background general-purpose agent read a 90-line PowerShell file, answered three analysis questions about it, and correctly identified an edge case in the code.

A restart is required for the change to take effect. Toggling servers off in a running session does not help, which is consistent with the tool schema being materialised into context at session start.

This moves the report from "suspected" to a measured causal link: the failure tracks total tool-schema volume, not the agent type as such. explore only ever appeared immune because its restricted toolset kept it under the limit; it would presumably fail too given enough MCP servers.

Two things that make this expensive to diagnose in the wild:

1. The failure is completely silent. No error, no partial output, nothing in the session log. The parent agent cannot distinguish "sub-agent had nothing to say" from "sub-agent never ran."
2. There is no signal about which side of the limit you are on. Nothing warns that adding one more MCP server will silently disable your sub-agents.

Even before the underlying budget issue in #3542 is addressed, surfacing this as an error rather than an empty return would save a lot of time. In my case an entire code review came back empty four times across three different models before I isolated the variable.

[ChrisMcKee1]

Requesting this stays open, with the emphasis moved.

Our own situation is resolved: reducing the number of configured MCP servers restored sub-agents, and we have a workaround we can live with. That was a configuration problem on our side, and if the report were only about our environment it could be closed.

The configuration was never the bug. The bug is that hitting the limit is undetectable.

When a sub-agent fails this way, all of the following are true at once:

• The task tool returns success with an empty result. It does not error.
• The parent agent cannot distinguish "the sub-agent had nothing to say" from "the sub-agent never ran," so it may reasonably continue and act on nothing.
• Nothing is written to the session log. There are zero [ERROR] or [WARN] entries in the window where this happens; the only errors present were unrelated MCP startup failures from about a minute earlier.
• Nothing renders in the UI. There is no banner, badge, or status to indicate the agent was cut off rather than quiet.
• No warning is given when crossing the threshold. Adding one more MCP server silently disables every full-tool sub-agent, with no indication that it happened or which change caused it.

The practical cost of that combination: an entire code review returned empty four times, across three different models and both sync and background modes, before the variable was isolated. Each attempt looked like a model or agent-type problem, because those were the only things visibly changing. Considerable time went into an incorrect root cause before a controlled test pointed at tool-schema volume.

This is also likely invisible in your own telemetry. If nothing is logged or errored, these failures presumably register as successful task invocations that happened to produce no output, so the real frequency across users could be much higher than the issue count suggests.

Concrete asks, roughly in value order:

1. Fail loudly. If the sub-agent's context cannot be assembled within budget, return an error rather than an empty success. Even a generic message beats silence.
2. Log it. A single line naming the cause and the budget would have reduced this from hours to minutes.
3. Surface it in the UI. Distinguish "agent returned nothing" from "agent could not run."
4. Warn at configuration time. When adding an MCP server pushes the projected tool-schema size past the limit, say so at startup, while the user still has the context to connect cause and effect.

Items 1-3 are useful regardless of how the underlying budget problem in #3542 is resolved, because the silent-failure mode will otherwise reappear behind any future limit.