[BUG] Workflow tool reports "completed" with an empty result when every parallel subagent fails (e.g. mid-run session-limit hit)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Description
When a Workflow (Claude Code's multi-agent orchestration tool) has every one of its parallel subagents fail — in my case because the account's 5-hour session/usage limit was hit while dozens of agents were in flight — the parent workflow's completion notification still reports a generic "completed" status, with a result payload that looks like a valid empty result (e.g. {"findings": [], "mutations": []}). The only place the real cause is visible is a separate <failures> list attached to the notification, which is easy to miss — especially because the result object's shape looks like a legitimate "nothing was found" outcome rather than "every agent errored out."
Root cause (suspected)
The workflow harness appears to treat "all agent() calls resolved without the orchestration script itself throwing" as equivalent to a successful completion, rather than distinguishing "0 of N subagents produced real output because of a platform-level interruption" from "the script legitimately ran and found nothing."
Impact
- A user (or the assistant orchestrating on their behalf) can easily read "completed" + an empty-but-valid-looking result and conclude the task found nothing — when in fact every subagent was killed mid-flight and a large number of tokens were spent for zero usable output.
- This is especially costly in high-parallelism ("Ultracode") workflows, where dozens of agents can be in flight when a usage limit lands.
Environment
- Claude Code (CLI), running in a git worktree session
- Operating System: macOS (Darwin)
- Claude Code Version: [fill in — run
claude --version] - Model in use during the failing run: Fable 5 (claude-fable-5)
- Feature: Workflow tool / multi-agent orchestration ("Ultracode")
Is this a regression?
Unknown / not applicable — first time exercising this path at this scale.
Last Working Version
No response
Claude Model
Fable 5 (during the failing run)
Platform
[Desktop app / CLI — confirm which you're filing under]
Terminal/Shell
[fill in if filing from the CLI, e.g. Terminal.app (macOS)]
What Should Happen?
Expected behavior
One of the following:
When 100% of a workflow's agent() calls fail, the parent task's status should reflect a failure/interrupted state, not "completed."
At minimum, the top-level notification summary (not just a nested failures array) should state plainly that the run did not complete as intended — e.g. "0/36 agents succeeded — likely usage-limit interruption" — before the caller has to dig into per-agent errors to discover this.
Error Messages/Logs
Observe the task notification: status "completed," result is an empty default object, and the real cause is buried in a `<failures>` array listing the same "You've hit your session limit" error once per agent (36 identical entries in my case).
Steps to Reproduce
- Bring an account's 5-hour usage window close to its limit.
- Launch a Workflow with a large
parallel()fan-out (36 agents in my case). - Let the usage limit land while agents are in flight.
- Observe the task notification: status "completed," result is an empty default object, and the real cause is buried in a
<failures>array listing the same "You've hit your session limit" error once per agent (36 identical entries in my case).
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.18286.0 (259c3f) 2026-07-02T07:11:03.000Z
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
I'd like my tokens back.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗