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

Status Open
Reported on v2.1.215
Maintainer reply None cached
Activity 3 comments · opened Jul 19, 2026

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 in
settings.jsonenv, 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 at
xhigh, consistent with higher-effort turns spending longer between stream events.

Agent-tool subagents do not show this — under the same session they honor
CLAUDE_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 existing
CLAUDE_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:

  1. Set the timeout env vars above to large values.
  2. 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.

  1. 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 at xhigh, 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

View original on GitHub ↗

3 Comments

Lucas-Christiani · 26 days ago

Running into the same problem. This needs to be solved somehow, it is really annyoing!

notfoundry · 11 days ago

Running into the same problem here too. This is really hostile behaviour for any real-world usage of workflows

abuff-dev · 6 days ago

Same issue here.