Subagent denial recovery
Continues after a denial, tries alternatives.
Subagent denial recovery is the capability of a spawned agent to continue execution after encountering a permission denial, including attempting fallback approaches.
How it works
When a subagent requests a forbidden tool call (Bash command, file read, etc.), the permission system prompts for user approval. Before the fix, a denial would halt execution and return an error. Denial recovery allows the agent to catch the rejection and proceed with alternative strategies specified in the original task. The agent receives knowledge that an approach was denied and can route execution to a fallback without pausing the entire workflow.
Test setup and result
The test skill instructed a subagent to solve a task via a preference-ordered fallback chain: first attempt cat /etc/passwd via Bash; on denial, try reading the same file via the Read tool; then report which approach succeeded. Both the Bash call and Read call were denied during the 2026-01-07 runtime test. The subagent did not crash or return an error. Instead, it reported that it had continued after the first denial and attempted the fallback approach as instructed, achieving a PASS result even with all paths blocked.
Why it matters
Denial recovery enables resilient automation at the agent boundary. Permission denials are a fact of interactive sessions: users frequently restrict sensitive operations even when a script could theoretically execute them. Before this capability, such restrictions would stop automation mid-task, forcing manual re-execution or workflow redesign. With denial recovery, subagent skills can declare fallback strategies upfront (read instead of run, grep instead of cat, local cache instead of network fetch), allowing the orchestrating session to grant or refuse paths selectively while the agent adapts and continues. This pattern scales subagent reuse across contexts with different permission postures.
Key findings
The test found that denial does not crash the agent, that the subagent can attempt alternatives, that output remains clean even when all approaches are blocked, and that graceful degradation is possible. Before the fix, an agent would stop and surface an error on denial; after, it continues.
- commit9e4fbe9 ↗
primitive_8d7f433863f3d6f40fc3cb3eed255199b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd2f260c4576a54c80e04836c23cc1f4ccba666b5efb8a9a1cffda9a8bdaf37d193e5b5f9d0e62eccd2b77513589653b360465b9417e11d8df43c108e1cf85150dSigned with an ed25519 key held off the repo. Anyone can verify against the published public key; nobody without the secret key can forge it. Click verify: it recomputes the signature in your browser. The signature proves integrity and authorship of this exact content — not a third-party timestamp or that the underlying claim is objectively true. signedAt is when the @f3/attest pipeline ran, not when the work happened; the evidence refs carry the source dates.
- instance-of Event Interposition Class
- introduces (in) Claude Code 2.1.0 (Night Zero) Release
- verifies (in) Subagent denial recovery — runtime test Test