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:
- 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.
- Log it. A single line naming the cause and the budget would have reduced this from hours to minutes.
- Surface it in the UI. Distinguish "agent returned nothing" from "agent could not run."
- 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 #4293 (comment)
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:
tasktool returns success with an empty result. It does not error.[ERROR]or[WARN]entries in the window where this happens; the only errors present were unrelated MCP startup failures from about a minute earlier.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:
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 #4293 (comment)