[BUG] Subagent permission cascade-failure when multiple Agent tool calls in one message (2.1.126)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Subagent permission cascade-failure when multiple Agent tool calls in one message

Environment

• Claude Code version: 2.1.126
• OS: macOS Darwin 24.6.0
• Subscription / login: Claude Pro/Max (Console for Anthropic API tokens; not enterprise managed)
• Repo / cwd: A standard git repo, session cwd is a subdirectory (/Users/marcobrien/DEV/rise/docs) of the repo root (/Users/marcobrien/DEV/rise)

Summary

When the parent assistant emits multiple Agent tool calls in a single message (intended for parallel work), every spawned subagent gets a permission cascade-failure: the first Bash call (typically pwd) succeeds, then every subsequent tool call (Read, Bash, Edit, Write, Grep, Glob) is rejected with the literal error string

Permission to use <Tool> has been denied.

Spawning the same agents one at a time, in separate assistant turns, with identical project settings, succeeds end-to-end. So the project-level permission grants ARE being applied for sequential agents, but something in the parallel-spawn code path breaks them.

Reproduction

.claude/settings.json (project-level, committed)

{
  "permissions": {
    "allow": [
      "Read", "Bash", "Edit", "Write",
      "Grep", "Glob", "WebFetch", "WebSearch"
    ],
    "additionalDirectories": [
      "/Users/marcobrien/DEV/rise",
      "/Users/marcobrien/Dev/rise"
    ]
  }
}

(Both case variants in additionalDirectories because pwd returns lowercase Dev on this Mac while pwd -P returns uppercase DEV — the harness does case-sensitive string comparison; this is a separate finding but stable across both branches of this report.)

Sequence that PASSES

Single Agent tool call in one assistant message:

subagent_type: general-purpose
prompt: "Run pwd, cat /Users/marcobrien/DEV/rise/.claude/settings.json,
ls /Users/marcobrien/DEV/rise/src/automations/ | wc -l, Read
src/integrations/google_sheets.py, run a python -c snippet."

Result: All 5 steps succeed, 0 permission denials.

Sequence that FAILS

Two Agent tool calls in one assistant message (parallel batch). Same settings.json. Either prompt could be the same as above or different — the failure is independent of prompt content.

Result for each spawned agent:

• Step 1 (pwd) → ✅ succeeds, returns /Users/marcobrien/Dev/rise/docs
• Step 2 (cat /path/to/anything) → ❌ Permission to use Bash has been denied.
• Step 3+ (Read, Write, Edit, Grep, Glob) → ❌ all rejected, literal string Permission to use <Tool> has been denied.

The denial cascade kicks in after the first tool call. Both parallel agents exhibit it identically.

What I tried before filing

1. Path scope only — additionalDirectories with the repo root.

Outcome: First single agent worked once; subsequent agents (sequential or parallel) all failed with Permission to use Bash has been denied. Tool grant, not path scope, was the issue.

1. Both case variants in additionalDirectories — added /Users/marcobrien/Dev/rise (lowercase) alongside /Users/marcobrien/DEV/rise (uppercase).

Outcome: No change for the parallel failure, but appears to be required separately for agents whose tools build absolute paths from $PWD (which returns lowercase on this Mac).

1. Adding permissions.allow with explicit tool grants — ["Read", "Bash", "Edit", "Write", "Grep", "Glob", ...].

Outcome: Single sequential agents now reliably succeed. Parallel agents still cascade-fail.

1. Different subagent_type — tried both general-purpose and Explore. Both fail the same way when spawned in parallel; both succeed when spawned single.

The fix in #3 is necessary for sequential agents to work at all (without explicit allow, even single agents got denied at the tool-grant level), and it's surprising on its own — the parent session has these tools granted implicitly via user-level/CLI defaults but subagents don't inherit those. That's a separate UX surprise but not the bug being reported here.

Hypotheses

I don't have access to the harness internals, but based on the failure pattern:

• The first tool call in each parallel-spawned agent appears to use a permission context that's correctly populated.
• The second call's permission lookup returns "denied" for every tool, including ones explicitly in permissions.allow.
• This suggests either (a) a per-agent permission context is initialized lazily and only one slot is allocated when N agents start in parallel, or (b) a shared mutable cache gets clobbered when two agents execute concurrently.

Workaround we're using

Spawn agents sequentially, one per assistant message. Reliable but defeats the purpose of asking the model to parallelize work.

Diagnostic data on request

The session log is available; reproductions in this report come from agent transcripts I can attach. Specific session ID: 26c11dab-099a-4dcb-81ff-94bd2a35ef92, branch feature/agent-sandbox-case-variants (commit 8e9116d), reproduced 2026-05-06 in multiple consecutive batches.

Concrete ask

If permissions.allow + additionalDirectories is the intended way to grant subagents repo access (which the docs strongly imply), then the parallel-spawn path needs to apply those grants the same way the sequential path does. Either fix the parallel-spawn permission init, or (lower-priority) document the parallel-agent limitation in the settings.json schema reference so users don't lose hours diagnosing.

What Should Happen?

If permissions.allow + additionalDirectories is the intended way to grant subagents repo access (which the docs strongly imply), then the parallel-spawn path needs to apply those grants the same way the sequential path does. Either fix the parallel-spawn permission init, or (lower-priority) document the parallel-agent limitation in the settings.json schema reference so users don't lose hours diagnosing.

Error Messages/Logs

(`cat /path/to/anything`) → ❌ `Permission to use Bash has been denied.`
(Read, Write, Edit, Grep, Glob) → ❌ all rejected, literal string `Permission to use <Tool> has been denied.`

Steps to Reproduce

1. Path scope only — additionalDirectories with the repo root.

Outcome: First single agent worked once; subsequent agents (sequential or parallel) all failed with Permission to use Bash has been denied. Tool grant, not path scope, was the issue.

1. Both case variants in additionalDirectories — added /Users/marcobrien/Dev/rise (lowercase) alongside /Users/marcobrien/DEV/rise (uppercase).

Outcome: No change for the parallel failure, but appears to be required separately for agents whose tools build absolute paths from $PWD (which returns lowercase on this Mac).

1. Adding permissions.allow with explicit tool grants — ["Read", "Bash", "Edit", "Write", "Grep", "Glob", ...].

Outcome: Single sequential agents now reliably succeed. Parallel agents still cascade-fail.

1. Different subagent_type — tried both general-purpose and Explore. Both fail the same way when spawned in parallel; both succeed when spawned single.

The fix in #3 is necessary for sequential agents to work at all (without explicit allow, even single agents got denied at the tool-grant level), and it's surprising on its own — the parent session has these tools granted implicitly via user-level/CLI defaults but subagents don't inherit those. That's a separate UX surprise but not the bug being reported here.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_