Agent should continue reasoning while blocked on tool calls and permission prompts
Problem
Every tool call and permission prompt is fully blocking. When a build takes 30 seconds, a test suite takes a minute, or a permission prompt goes unanswered because the user stepped away, Claude sits completely idle. There's no mechanism for it to:
- Start independent work while a slow command runs
- Reconsider its approach if something is taking too long
- Time out on a permission prompt and try an alternative path
- Monitor partial output from a running command and decide to kill it
The run_in_background parameter exists for Bash and Task, but it's opt-in per call. The agent must decide upfront whether something will be slow — it can't react to something becoming slow.
Proposed behavior
Slow tool calls: After a configurable threshold (e.g., 5 seconds), Claude receives the partial output and elapsed time as context, and can choose to: continue waiting, start independent work in parallel, or kill the command and try a different approach.
Permission prompts: After a timeout (e.g., 30 seconds), Claude is notified the prompt is still pending and can continue with other work, queue an alternative approach, or skip that operation entirely.
General principle: Tool execution should be asynchronous by default, with Claude receiving periodic status updates (elapsed time, output so far, CPU usage) and making autonomous decisions about whether to wait or move on.
Why this matters
Wall-clock time is the main bottleneck in interactive sessions. A 2-minute test suite followed by a 30-second build followed by a permission prompt the user doesn't see for a minute adds up to 3.5 minutes of pure idle time. An event-driven agent loop would let Claude use that time productively.
Related issues
- #18617 — Background execution for MCP tools (same core problem, scoped to MCP)
- #9905 — Background execution for Task tool (now implemented, but opt-in)
- #13024 — Hook for when Claude is waiting for input (adjacent — alerting the user, not Claude continuing to work)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗