Desktop: Confirm before a denied permission prompt aborts an entire multi-agent workflow

Problem

In the Claude Code desktop app, when a multi-agent workflow (Workflow tool / parallel subagents) is running and a permission prompt appears for a single tool call, pressing Esc or clicking Deny does not just reject that one tool call — it can interrupt the entire run. All parallel agents receive "Request interrupted by user" and every intermediate result is lost (resume is same-session only).

Real-world impact (2026-08-20, Windows 11, desktop app ~1.32885.1):

• A research workflow with 5 parallel agents (each 25-38 events deep) was killed by a single declined prompt.
• The declined prompt was guarding a purely read-only operation (a PowerShell one-liner listing and reading local transcript files). Nothing was written, deleted, sent, or executed with side effects — there was no security-relevant decision to make, yet answering it wrong destroyed the whole run.
• All work was lost and had to be re-run from scratch (~560k subagent tokens for the repeat run).

When many prompts stack up during a long run, a user will understandably mis-click eventually. One mis-click currently costs the entire run. The asymmetry feels absurd from the user's side: the prompt protects a read of local files (essentially zero risk), while the penalty for declining it is the loss of an entire multi-agent workload (very real cost in tokens, time, and unfinished work). Read-only tool calls arguably should not be able to take down a run at all.

Suggested improvements (any of these would help)

1. Confirmation step ("Are you sure?"): If denying/escaping a permission prompt would interrupt a running workflow with N active agents, show a second confirmation — like the standard Windows pattern — e.g. "This will stop 5 running agents and discard their progress. Stop the whole run, or only skip this tool call?"
2. Scope the denial to the single tool call: Let the denied call fail into the agent as a tool error (agents already handle "tool use was rejected" gracefully) instead of propagating an interrupt to the whole run.
3. Reword the rejection message: The injected text "The user doesn't want to proceed with this tool use" misstates intent when the denial was an accidental Esc under prompt fatigue. Something neutral like "This tool call was not permitted" would keep agents from drawing wrong conclusions about user intent.
4. Cross-session resume for workflows: resumeFromRunId currently works same-session only; allowing resume after an interrupt/restart would turn a total loss into a partial one.

Environment

• Windows 11 Home, Claude desktop app (MSIX), Claude Code 2.1.x
• Permission mode: auto (default-allow with background classifier)
• Reproduction: start a Workflow with parallel agents; when any agent triggers a permission prompt, press Esc → whole run aborts.