[BUG] Workflow/background-spawned agents block indefinitely on unanswered permission prompts — no auto-deny, timeout, or idle watchdog (55-min silent stall)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

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:

1. 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.

1. 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

1. 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").
2. Invoke it via the Workflow tool and let it run in the background.
3. Do not answer the permission prompt (or run from a context where the prompt never surfaces).
4. 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.