[BUG] Workflow tool reports "completed" with an empty result when every parallel subagent fails (e.g. mid-run session-limit hit)

Resolved 💬 2 comments Opened Jul 4, 2026 by fracknut Closed Jul 7, 2026

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

  1. Bring an account's 5-hour usage window close to its limit.
  2. Launch a Workflow with a large parallel() fan-out (36 agents in my case).
  3. Let the usage limit land while agents are in flight.
  4. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗