[BUG] Agent Teams teammates ignore bypassPermissions for Bash and don't inherit project settings.local.json

[clickclackclark]

Preflight Checklist

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

What's Wrong?

When spawning Agent Teams teammates via the Task tool with mode: "bypassPermissions", the teammates still prompt the parent session's user for Bash command approval. Additionally, permissions saved via "Yes, and always allow" from teammate prompts (which write to project settings.local.json) are not inherited by teammates in subsequent sessions.

Three separate issues compound here:

1. bypassPermissions doesn't bypass Bash prompts for teammates. Teammates spawned with mode: "bypassPermissions" still trigger permission prompts for Bash commands like mkdir, cat << heredoc, node /tmp/..., etc.

2. Teammates don't inherit project settings.local.json. The project-level settings file accumulates 100+ "always allow" entries over time, but teammates don't read them. Commands like Bash(mkdir:*), Bash(cat:*), Bash(node) are all present in project settings.local.json but teammates still prompt.

3. "Always allow" from teammate prompts doesn't persist. Selecting option 2 ("Yes, and always allow access to X from this project") on a teammate permission prompt does not prevent the same prompt in the next session's teammates.

What Should Happen?

1. mode: "bypassPermissions" should grant teammates full Bash execution without prompts, matching the behavior for non-team subagents.
2. Teammates should inherit permissions from the project's settings.local.json.
3. "Always allow" selections from teammate prompts should persist and apply to future teammate sessions.

Error Messages/Logs

No error messages — teammates function correctly once approved. The issue is the repeated user intervention required.

Example prompts that appear despite bypassPermissions:

Bash command · @architect
    mkdir -p <project>/.claude/state/feedback
    Ensure feedback directory exists

Do you want to proceed?
› 1. Yes
  2. Yes, and always allow access to feedback/ from this project
  3. No

Bash command · @architect
    cat << 'SCRIPT' > /tmp/generate-level1-1.mjs
    // Level generator script...

Do you want to proceed?
› 1. Yes
  2. Yes, and always allow...
  3. No

Same prompts appear for other teammates running node scripts to parse JSON files.

Steps to Reproduce

1. Start Claude Code (default permission mode, NOT delegate mode)
2. Create a team: TeamCreate: { team_name: "test-team" }
3. Spawn a teammate with bypassPermissions:

   Task: {
     subagent_type: "general-purpose",
     mode: "bypassPermissions",
     name: "worker",
     team_name: "test-team",
     prompt: "Run: mkdir -p /tmp/test-dir && echo hello > /tmp/test-dir/file.txt"
   }
   

4. Observe: User is prompted to approve the mkdir and echo commands despite bypassPermissions.
5. Select "Yes, and always allow" on each prompt.
6. End session, start new session, repeat steps 2-4.
7. Observe: Same prompts appear again — "always allow" did not persist for teammates.

Environment

• Project settings.local.json contains 100+ allow rules including Bash(mkdir:*), Bash(cat:*), Bash(node), Bash(bash:*), Bash(grep:*), etc. — all accumulated from previous "always allow" selections. None are inherited by teammates.
• Global ~/.claude/settings.json allow rules were added as a workaround — effectiveness for teammates TBD.

Related Issues

• [BUG] Teammates spawned in Delegate Mode have no file access tools despite mode: bypassPermissions #24307 / [BUG] Teammates spawned in Delegate Mode lose tool access despite mode: bypassPermissions #24073 / [BUG] delegate mode cascades to teammates #23447: Delegate Mode strips ALL tools from teammates (more severe, different root cause)
• [BUG] Claude continually asks for permission, even after selecting yes, always allow. #11380: "Always allow" not persisting generally (Windows, not team-specific)
• [FEATURE] Expose teammate identity in hook input and support per-teammate hook configuration in agent teams #24505: Feature request for per-teammate hook configuration

Claude Model

Opus 4.6

Is this a regression?

I don't know

Claude Code Version

2.1.45

Platform

Anthropic API (Claude Max)

Operating System

macOS (Darwin, Apple Silicon)

Terminal/Shell

Ghostty

Additional Information

Workaround attempted: Adding Bash allow rules to global ~/.claude/settings.json instead of project settings.local.json. This may help if teammates read global but not project settings — testing in progress.

Impact: For workflows that spawn multiple teammates running many Bash commands (e.g., level generation pipelines with 10+ tasks), the user must manually approve dozens of prompts per session. This defeats the purpose of autonomous team operation and makes bypassPermissions ineffective for Agent Teams.

[github-actions]

Found 3 possible duplicate issues:

1. Agent team teammates prompt for Read tool approval despite docs saying read-only tools require no approval #23679
2. [BUG] Teammates spawned in Delegate Mode lose tool access despite mode: bypassPermissions #24073
3. Built-in Plan agent ignores parent settings.json permissions and repeatedly prompts for pre-approved tools #10906

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[wagabondpets]

For me, this is recent. The Anthropic team nerf'd 2.1.45. Revert to 2.1.44 and it's brilliant again.
It's not as bad as their January complete-destruction-of-CC-CLI, but Opus/Sonnet is unusable on .45.
Brilliant again on .44

[ForkyTheBot]

Great bug report — you've identified three compounding failures that hit hardest in exactly the use case where autonomous subagents are most valuable.

Why bypassPermissions isn't bypassing Bash prompts for teammates

The likely root cause: bypassPermissions in the teammate context propagates the permission mode but Bash approval prompts are still gated on the parent session's interactive loop. The teammate is sending tool call requests back through the parent session's UI renderer, which applies its own permission check regardless of the teammate's mode. This is a process-boundary issue: the teammate runs in a separate execution context but approval prompts bubble up to the parent terminal.

Workaround for now — set blanket Bash permissions in your global ~/.claude/settings.json rather than project-level. Global settings are read before the teammate's execution context is initialized:

{
  "permissions": {
    "allow": [
      "Bash(mkdir:*)",
      "Bash(cat:*)",
      "Bash(node:*)",
      "Bash(bash:*)",
      "Bash(grep:*)"
    ]
  }
}

If global settings also fail for teammates, that confirms the prompts are bypassing the settings lookup entirely — a deeper bug worth adding to this report.

Why settings.local.json isn't inherited

Project settings.local.json is read relative to the working directory of the spawning process, but teammate processes may initialize with a different cwd or run a separate settings scan. The 100+ accumulated "always allow" entries are in the right file, but teammates may be looking somewhere else (or nowhere).

The architectural issue underneath all three bugs

All three failures share a root: approval state is distributed (per-session, per-process, per-file) rather than centralized. When multiple agents operate concurrently, you get permission fragmentation. The robust fix is a centralized permission service that all agents — parent and teammates — route through, with state that persists across sessions.

The hooks system (PreToolUse) already runs synchronously and can gate execution — but teammates need to inherit the hook configuration for this to work, which they currently don't.

Suggested additions to your report:

• Confirm whether ~/.claude/settings.json global rules are also ignored for teammates (narrows down settings lookup bug vs. UI rendering bug)
• Add your Claude Code version — this may be a regression

Blocking bug for unattended multi-agent workflows. "bypassPermissions should actually bypass" is the correct expectation.

[katosh]

Adding a data point from #30323: in some cases, the teammate doesn't even show an interactive prompt in its pane — instead it shows "Permission request sent to team lead" and blocks indefinitely. The approval request never arrives at the team lead as an actionable message. This seems like another manifestation of the same broken teammate permission flow described here.

Also observed intermittent behavior: in one session teammates could use Read/Grep/Glob freely, but after restarting Claude Code the same team required team lead approval for ALL tools.

[freeformz]

I have a similar-ish problem where I have a skill that spawns an agent team. One of the agents is directed to read a file for some additional context (it's like 30k of rules; so I don't want it in the spawning/controlling agent's context). No matter what I've added to settings.json I'm always prompted to read the file. Claude itself is like 🤷 file an issue (after several attempts to debug).