Requesting this stays open, with the emphasis moved.

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.

Originally posted by @ChrisMcKee1 in https://github.com/github/copilot-cli/issues/4293#issuecomment-5122291931

まず、タスクツールのサブエージェントの実行経路と、MCPサーバーの設定または起動経路を追跡します。issue #3542 を基になる予算のコンテキストとして使用し、空の結果、セッションログ、UI のステータス、しきい値の警告がどのように処理されているかを確認します。完了の条件は、制限による失敗が空の成功と区別でき、ログに記録され、UI に表示され、設定時に警告されることです。