[FEATURE] Parent session gets no signal when a background subagent is blocked on a permission prompt — unattended runs stall for hours
Summary
In the desktop app (Code tab), a background subagent (Agent tool) that reaches a permission-gated action shows a permission prompt to the user. The orchestrating (parent) session is never told: no task notification, no status it can read.
In an unattended run, nothing moves until a human clicks — including the parent's own scheduled fallback wake-ups. The parent cannot cancel that subagent or route around it, because from its side the subagent is simply "still running".
What happened
- Windows 11, Claude Code desktop app, CLI 2.1.281, Opus. Night of 2026-09-26 to 27.
- A self-paced overnight
/looprun was orchestrating several background subagents that implemented and reviewed pull requests. - One implementer subagent tried to open a local HTML file (a UI mockup), to compare it with the screen it had built. That action requires user permission.
- The whole run stayed frozen from about 01:30 to 13:00, until the user came back and clicked "Allow". The parent's fallback wake-ups did not unblock anything.
- The next morning, the parent agent told the user that "nothing was waiting for you". From its side, nothing was visible.
Expected
Any of these would have avoided it:
- Notify the parent — for example a task notification "subagent X is waiting for permission: <tool / action>". The parent can then wait, stop that subagent, or carry on with other work.
- An unattended-run policy for background subagents — auto-deny, or deny after a timeout. The subagent gets a tool error it can work around, instead of blocking.
- Expose the state — the parent's view of the subagent says "waiting for permission" rather than "running".
Workaround we use today
Every subagent prompt for unattended runs now forbids browser tools, opening HTML files, previews, Artifacts and computer use. It works, but it has to be repeated in every prompt, and one forgotten line costs a night.
Related
- #69482 — subagent permission prompts are invisible in remote/web sessions (open). That one is about the user not seeing the prompt remotely; this one is about the orchestrating agent being blind to it, and unattended runs stalling.
- #81238, #84905 — prompts not forwarded to mobile / Remote Control (closed).
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗