← 2.1.0 Test tested · runtime-test

Subagent denial recovery — runtime test

Hands-on runtime battle-test of Subagent denial recovery. Result: PASS.

Subagent denial recovery is the runtime capability for a spawned agent to continue task execution when a single tool invocation is denied by the permission system, rather than terminating.

How It Works

When a subagent calls a tool and the user denies that specific invocation, the agent receives the denial as a structured response from the harness, not a fatal error. The subagent's execution context remains open; it can parse the denial, invoke an alternative tool, restructure the request, or report the constraint back to the parent. This flow is built into the Task tool's handling: permissioned tools integrate with Claude's native tool-use protocol, so denials surface as tool call results (not exceptions), leaving control with the agent.

What the Test Found

The test instantiated a skill with ordered fallbacks: attempt to read /etc/passwd via Bash, then via the Read tool if Bash was denied. Both invocations were denied by the test harness. The subagent continued executing after the first denial, attempted the fallback as instructed, and returned a clean summary of both attempts rather than erroring out. The test marked PASS.

Key observations:

  • Denial does not crash or stop agent execution
  • Agents can detect denial and branch to fallback logic
  • Output remains coherent even when all requested paths are blocked

Why It Matters

Denial recovery enables resilient automation in human-supervised environments. Real workflows often encounter permission boundaries (restricted file access, disabled commands, rate limits). Rather than halting, a subagent can attempt alternatives (use a different tool, simplify the request, escalate to parent). This transforms permission denials from faults into signals for graceful degradation.

Design Implication

The mechanism relies on the harness exposing denials as structured tool responses rather than exceptions or opaque errors. This places denial handling in the control flow of the agent itself, not in a supervisor or error handler outside it.

Primary source
⎘ 2.1.0/tests/13-denial-recovery/TEST-RESULTS.mdverbatim from the corpus

Test Results: Subagent Continues After Permission Denial

Feature: Improved subagents (Task tool) to continue working after permission denial, allowing them to try alternative approaches

Tested: 2026-01-07

Test Setup

Created skill that tries multiple approaches:

---
context: fork
agent: Explore
---
1. First, try to run `cat /etc/passwd` using Bash
2. If that's denied, try to read the file using Read tool
3. Report which approach worked

Test Execution

  1. Invoked /test-denial-recovery
  2. Denied the Bash command when prompted
  3. Denied the Read fallback when prompted

Result: PASS

Subagent output:

"I continued working after the first denial (didn't stop at Bash rejection)" "I attempted the fallback approach as instructed"

Key Findings

  1. Denial doesn't crash agent - subagent continues executing
  2. Can try alternatives - moved from Bash to Read approach
  3. Clean reporting - summarized both attempts in final output
  4. Graceful degradation - even with all paths blocked, returned useful info

Before vs After (implied)

Behavior Before Fix After Fix
On denial Agent stops/errors Agent continues
Alternatives Not attempted Tries fallbacks
Output Error/incomplete Clean summary

Use Cases

  • Resilient automation that handles permission boundaries
  • Skills that have fallback strategies
  • More robust subagent workflows

Status: PASS

Evidence & receipt
◇ ed25519 receipt
idtest_cac81afb0ec6f85bcde6ae10
alged25519
pubkey9b87705613b1e2fd064d57fa75a6b679d2856ceafad6b1daa8f982493871b6dd
sig1ef50a87ab045d7421c273adfdf144305d4756ce624aaeb268fe98023c88226bd1b1dd41752360810e34d35f4906116f158a097ab7d06711ff9e3dd8fd3d5a03

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

Connected