Workflow tool: ~180s per-agent no-progress kill is hard-coded — ignores CLAUDE_STREAM_IDLE_TIMEOUT_MS / CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS; please make it configurable
Preflight Checklist
- [x] I have searched existing issues. Closest matches and why this is distinct:
- #63698 (closed as stale) — "one stall retried 6× at full token cost; no-progress signal
can't tell slow-but-alive from hung." Same family, but that report asks for a smarter
liveness signal / bounded retries; it does not report that the threshold ignores the
documented timeout env vars, nor ask to make it configurable.
- #75036 (open) — "watchdog detects stalls but has no recovery path"; attributes it to
transient stream/connection drops and asks for auto-resume.
- #66095 (open) — 180000ms idle abort, but attributed to the **server withholding stream
bytes** (network layer).
- #68842 (open) — the inverse: no per-agent timeout fires, agent hangs 15–50 min.
This report is specifically: the Workflow-tool ~180s no-progress kill is a hard-coded
constant that ignores every documented timeout override, and the ask is to make it
configurable. I did not find an existing issue making that specific point.
- [x] This is a single bug report.
- [x] I am using the latest version of Claude Code (2.1.215).
What's Wrong?
When running a multi-agent build through the Workflow tool (agent() / parallel() DSL),
a worker agent is killed and retried whenever ~180s elapse without a stream event. In my
runs this silent gap consistently occurs right after a tool call returns its result — i.e.
between receiving a tool result and the next stream event (the cause could be a long thinking
phase, model time-to-first-token, or a transient stream delay; I can't distinguish them, but
the outcome is the same: no response within ~180s → the agent is killed).
The decisive point: I have already raised every documented timeout to large values insettings.json → env, and the ~180s kill still fires, which shows the Workflow-tool
threshold does not read any of them:
CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS = 3600000(1h)CLAUDE_STREAM_IDLE_TIMEOUT_MS = 1200000(20m)API_TIMEOUT_MS = 3600000,CLAUDE_CODE_MAX_RETRIES = 30,
CLAUDE_ENABLE_STREAM_WATCHDOG = 1
Despite all of these, Workflow worker agents are killed at ~180s of no-progress. The value
appears to be a hard-coded ~180000ms constant in the Workflow runtime that is not exposed via
any environment variable or agent() option.
It is effort-dependent: at effortLevel: max the kill fires far more often than atxhigh, consistent with higher-effort turns spending longer between stream events.
Agent-tool subagents do not show this — under the same session they honorCLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS (they run for many minutes without being killed). Only
Workflow-tool worker agents hit the ~180s wall.
What Should Happen?
Make the Workflow-tool no-progress timeout configurable — ideally honoring the existingCLAUDE_STREAM_IDLE_TIMEOUT_MS / CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS (as the Agent tool
already appears to), or a dedicated env var / agent() option — so long-but-silent turns
(high-effort thinking, slow first byte) can raise or disable it. A sensible default is fine;
the request is an escape hatch, since right now there is no supported way to run Workflow
agents whose normal operation includes >180s between stream events.
Steps to Reproduce
I don't have a minimal repro script to attach, but the trigger is reliable:
- Set the timeout env vars above to large values.
- Run a Workflow (
agent()workers) on tasks that induce >180s of silence after a tool result
— high-effort Opus 4.8 (effortLevel: max) on hard steps makes it frequent.
- Observe workers killed at ~180s and retried until judged failed, despite the large
configured timeouts.
Environment
- Claude Code version: 2.1.215
- Effort:
max(also reproduced atxhigh, less frequently) - Relevant env (all set, all apparently ignored by the Workflow ~180s kill):
CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS=3600000, CLAUDE_STREAM_IDLE_TIMEOUT_MS=1200000,
API_TIMEOUT_MS=3600000, CLAUDE_CODE_MAX_RETRIES=30
3 Comments
Running into the same problem. This needs to be solved somehow, it is really annyoing!
Running into the same problem here too. This is really hostile behaviour for any real-world usage of workflows
Same issue here.