Subagents cannot use Bash despite parent Bash(*) allow rule

Resolved 💬 3 comments Opened Feb 13, 2026 by u4047464554-gith Closed Feb 17, 2026

Problem

When the parent session has Bash(*) in .claude/settings.local.json allow list, subagents (launched via Task tool) still get denied Bash permission. The subagent hits an interactive approval prompt that it cannot respond to, causing the tool call to fail with "Permission to use Bash has been denied."

Reproduction

  1. Set .claude/settings.local.json:
{
  "permissions": {
    "allow": ["Bash(*)", "Read(*)", "Write(*)", "Edit(*)", "Glob(*)", "Grep(*)"],
    "deny": ["Bash(rm -rf *)"]
  }
}
  1. Launch a subagent via Task tool that runs uv run python -m pytest ...
  2. The subagent gets permission denied on every Bash call, even though the parent session can run the same command without prompting.

Expected Behavior

Subagents should inherit the parent session's permission allow/deny rules. If Bash(*) is allowed for the parent, subagents should also be able to run Bash commands without interactive approval.

Current Workaround

Run all Bash commands (tests, linting) from the main context after subagents complete their file-writing work. This is suboptimal because:

  • Subagents cannot self-verify their work (run tests, lint)
  • The main context has to do extra work that could be parallelized
  • Users are pushed toward --dangerously-skip-permissions which removes all safety checks

Impact

This effectively makes the coordinator/delegator pattern (recommended in docs) unable to include verification steps in subagents. Parallel subagents that write code + run tests become write-only, requiring sequential verification afterwards.

Environment

  • Claude Code v2.1.41
  • WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
  • Model: claude-opus-4-6

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗