Preflight Checklist
What's Wrong?
Agents spawned by the Workflow tool (background, unattended — agent() calls inside a .claude/workflows/*.mjs script) have no backstop when a tool call requires interactive permission approval and nobody answers. The pending prompt holds the spawned agent — and the whole workflow run — open indefinitely, with zero failure signal. Observed twice in one week on our team:
-
Unanswered permission prompt (~55 min stall). A workflow-spawned investigation agent ran a broad filesystem search (find / -iname "<file>" — permission-gated). Inside the backgrounded workflow run there was no approver present, so the tool call sat pending. The /workflows UI showed the agent at idle 51m 15s (total run 55m26s) with zero token output. The only way to unstick it was killing the parent task via TaskStop — the transcript's final entry synthesizes a "user rejected this tool use" result solely because of that kill.
-
Same user-visible symptom, different path (~58 min stall). In a separate workflow run (different machine), one of 6 parallel agents idled 58m while its siblings finished in 1-6 minutes. Its transcript spans only ~23 seconds of activity and contains no pending tool call; the run journal logs its started event only after all siblings had already logged result — consistent with a silent re-dispatch/scheduling stall. Again nothing surfaced the stall; a human noticed the idle timer in the UI.
Since v2.1.186 background subagents no longer auto-deny permission-prompting tool calls (the prompt routes to the main session — see #70143). When that routed prompt is never answered (user away from the terminal, or the prompt isn't visible — cf. #69482), there is no timeout, no auto-deny fallback, and no idle watchdog. A single broad-but-benign Bash command can silently stall an entire multi-agent workflow for as long as nobody happens to look.
What Should Happen?
An unattended/background agent's permission prompt should have a deterministic terminal outcome:
- a (configurable) timeout after which the tool call is auto-denied — failing loudly so the agent can recover or conclude; and/or
- a no-output-for-N-minutes watchdog on workflow-spawned agents that fails the agent with a visible error instead of idling forever.
A pending permission prompt should never be able to hold a background workflow open indefinitely with zero signal.
Error Messages/Logs
None — that is the bug. The agent journal shows a `started` entry with no
matching `result` for the full stuck period; the /workflows UI shows
`idle 51m 15s` / `idle 58m 5s`; the transcript ends with a synthesized
"user rejected this tool use" only after TaskStop killed the parent.
Steps to Reproduce
- Create a workflow script (
.claude/workflows/repro.mjs) whose agent() prompt instructs the agent to run a Bash command outside the session's allow rules (e.g. find / -iname "nonexistent-file.md").
- Invoke it via the Workflow tool and let it run in the background.
- Do not answer the permission prompt (or run from a context where the prompt never surfaces).
- Observe: the spawned agent idles indefinitely (55+ minutes observed) with no timeout, auto-deny, or surfaced failure. Only TaskStop unsticks it.
Claude Model
Sonnet (default)
Is this a regression?
I don't know — pre-2.1.186 background subagents auto-denied prompting tool calls (per the old docs, see #70143), which would have failed fast instead of hanging.
Last Working Version
No response
Claude Code Version
2.1.212 (current); occurrences observed on 2026-07-15 on the then-current release
Platform
Anthropic API
Operating System
Windows (both occurrences); Linux/macOS equally exposed by design
Terminal/Shell
Other
Additional Information
Related issues: #70143 (docs still describe the old auto-deny behavior), #69482 (subagent permission prompts invisible in remote/web sessions — same indefinite-wait symptom from the visibility side), #47339 (closed stale: background subagents escalating permission requests), #73633 (Workflow subagents don't inherit project allow rules, which multiplies prompt opportunities inside workflows).
Occurrence 2 above may be a distinct scheduler-side cause landing on the same symptom; filing under the missing-backstop umbrella because a wall-clock/no-output backstop would deterministically catch both.
Preflight Checklist
What's Wrong?
Agents spawned by the Workflow tool (background, unattended —
agent()calls inside a.claude/workflows/*.mjsscript) have no backstop when a tool call requires interactive permission approval and nobody answers. The pending prompt holds the spawned agent — and the whole workflow run — open indefinitely, with zero failure signal. Observed twice in one week on our team:Unanswered permission prompt (~55 min stall). A workflow-spawned investigation agent ran a broad filesystem search (
find / -iname "<file>"— permission-gated). Inside the backgrounded workflow run there was no approver present, so the tool call sat pending. The/workflowsUI showed the agent atidle 51m 15s(total run55m26s) with zero token output. The only way to unstick it was killing the parent task via TaskStop — the transcript's final entry synthesizes a "user rejected this tool use" result solely because of that kill.Same user-visible symptom, different path (~58 min stall). In a separate workflow run (different machine), one of 6 parallel agents idled 58m while its siblings finished in 1-6 minutes. Its transcript spans only ~23 seconds of activity and contains no pending tool call; the run journal logs its
startedevent only after all siblings had already loggedresult— consistent with a silent re-dispatch/scheduling stall. Again nothing surfaced the stall; a human noticed the idle timer in the UI.Since v2.1.186 background subagents no longer auto-deny permission-prompting tool calls (the prompt routes to the main session — see #70143). When that routed prompt is never answered (user away from the terminal, or the prompt isn't visible — cf. #69482), there is no timeout, no auto-deny fallback, and no idle watchdog. A single broad-but-benign Bash command can silently stall an entire multi-agent workflow for as long as nobody happens to look.
What Should Happen?
An unattended/background agent's permission prompt should have a deterministic terminal outcome:
A pending permission prompt should never be able to hold a background workflow open indefinitely with zero signal.
Error Messages/Logs
Steps to Reproduce
.claude/workflows/repro.mjs) whoseagent()prompt instructs the agent to run a Bash command outside the session's allow rules (e.g.find / -iname "nonexistent-file.md").Claude Model
Sonnet (default)
Is this a regression?
I don't know — pre-2.1.186 background subagents auto-denied prompting tool calls (per the old docs, see #70143), which would have failed fast instead of hanging.
Last Working Version
No response
Claude Code Version
2.1.212 (current); occurrences observed on 2026-07-15 on the then-current release
Platform
Anthropic API
Operating System
Windows (both occurrences); Linux/macOS equally exposed by design
Terminal/Shell
Other
Additional Information
Related issues: #70143 (docs still describe the old auto-deny behavior), #69482 (subagent permission prompts invisible in remote/web sessions — same indefinite-wait symptom from the visibility side), #47339 (closed stale: background subagents escalating permission requests), #73633 (Workflow subagents don't inherit project allow rules, which multiplies prompt opportunities inside workflows).
Occurrence 2 above may be a distinct scheduler-side cause landing on the same symptom; filing under the missing-backstop umbrella because a wall-clock/no-output backstop would deterministically catch both.