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_

Bắt đầu bằng cách lần theo đường dẫn thực thi của sub-agent của công cụ tác vụ và đường dẫn cấu hình hoặc khởi động máy chủ MCP. Kiểm tra cách xử lý kết quả trống, ghi nhật ký phiên, trạng thái UI và các cảnh báo ngưỡng, sử dụng issue #3542 cho ngữ cảnh ngân sách cơ bản. Hoàn thành có nghĩa là các lỗi do đạt giới hạn có thể được phân biệt với một lần thành công nhưng không có kết quả, được ghi nhật ký, hiển thị trong UI và cảnh báo trong quá trình cấu hình.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.