›_ Claude Code Issues
Claude Code Issues / #26479

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

Status Open
Reported on v2.1.45
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 12 comments · opened Feb 18, 2026

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?

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.
  1. 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.
  1. "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"
}
``

  1. Observe: User is prompted to approve the mkdir and echo commands despite bypassPermissions.
  2. Select "Yes, and always allow" on each prompt.
  3. End session, start new session, repeat steps 2-4.
  4. 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

  • #24307 / #24073 / #23447: Delegate Mode strips ALL tools from teammates (more severe, different root cause)
  • #11380: "Always allow" not persisting generally (Windows, not team-specific)
  • #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.

View original on GitHub ↗

12 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/23679
  2. https://github.com/anthropics/claude-code/issues/24073
  3. https://github.com/anthropics/claude-code/issues/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 · 6 months ago

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 · 6 months ago

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 · 6 months ago

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 · 5 months ago

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

bobthearsonist · 5 months ago

so if im reading this correctly:

"set blanket Bash permissions in your global"

https://github.com/anthropics/claude-code/issues/26479#issuecomment-3921724367

the advice is to give blanket permissions for tasks? that defeats the entire purpose of the permissions functionality. probably not going to be doing that.

hscfm · 5 months ago

Same issue here but with Write/Edit tools instead of Bash.

Spawned 4 teammates via TeamCreate + Agent (general-purpose, Opus).
When teammates attempt Write tool calls, the permission_request shows
up as raw JSON in the teammate-message stream but never surfaces as
an actionable approval prompt in the UI. The user sees the JSON but
has no approve/deny button.

Unlike the Bash case described above (where a prompt appears but
shouldn't), Write/Edit permission requests produce NO prompt at all —
the teammate just blocks indefinitely waiting for approval that can
never come.

Environment: Claude Code CLI on macOS, claude-opus-4-6, v2.1.x
Workaround: Team lead writes files on behalf of blocked teammates.

dmer41 · 4 months ago

Confirmed on v2.1.113 (Apr 17 2026) — reproduces across all 5 workaround permutations (agent-spawn mode, user defaultMode: auto, user defaultMode: bypassPermissions, project-committed .claude/settings.json, project .claude/settings.local.json). Same root cause as #49865 (team-lead UI crashes on permission_request marshaling across tmux IPC, so teammate deadlocks). Neither user-level nor project-level permission rules are being inherited by sonnet teammates in tmux-teammate mode.

tiezox · 4 months ago

Still reproducing on 2.1.114 — bypassPermissions not inherited by teammates

Confirming this bug is still active on Claude Code 2.1.114 (current latest, published after all previously-mentioned fix versions 2.1.97 / 2.1.98 / 2.1.101 / 2.1.108).

Environment

  • Claude Code 2.1.114, WSL2 Ubuntu, tmux backend
  • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true
  • Lead permissions.defaultMode: "bypassPermissions" + skipDangerousModePermissionPrompt: true in ~/.claude/settings.json
  • Lead launched with claude --dangerously-skip-permissions -r

Symptom

Teammate (auditor, agentType: general-purpose, spawned via Agent Teams) still shows:

Waiting for team lead approval
Tool: Edit
Action: A tool for editing files
Permission request sent to team "audit-team" leader

...on every Edit / Write / NotebookEdit call, blocking the teammate indefinitely until the lead manually approves. This contradicts the official documentation at https://code.claude.com/docs/en/agent-teams which states:

"Teammates start with the lead's permission settings. If the lead runs with --dangerously-skip-permissions, all teammates do too."

Additional findings from local investigation

  1. Lead's PermissionRequest hook does not fire for team-forwarded requests (confirmed by inspecting the hook's raw stdin log — zero entries originate from teammate sessions while hundreds fire for Lead's own tool calls). The forward appears to go through an internal mailbox channel that entirely bypasses the hook system.
  2. No workable config key exists for: teams.skipPermissionRequests, autoApproveTeammates, members[].permissions, members[].permissionMode. The Agent Teams docs explicitly state "you can't set per-teammate modes at spawn time".
  3. Neither --dangerously-skip-permissions pass-through to teammate nor an environment variable (CLAUDE_CODE_TEAM_AUTO_APPROVE etc.) exists.
  4. The only working local mitigation is teammate-side permissions.deny: ["Edit(*)", "Write(*)"] to short-circuit the forward before it starts — but this is a crippling workaround that forces all writes to be proxied through the Lead via SendMessage, doubling round-trips and defeating the point of Agent Teams.

Impact on real-world usage

This makes Agent Teams effectively unusable for automation scenarios:

  • Lead is constantly interrupted with forwarded approvals, becoming a bottleneck
  • Long-running teammates (auditors, background monitors) deadlock when Lead is idle or off
  • The user-configured bypassPermissions setting is silently dropped for teammates, violating the principle of least surprise — if the user is trusted enough to grant Lead bypass, that trust should cascade to the teammates the Lead itself spawns

Related open issues

This bug cluster is tracked across several open issues with overlapping scope: #24307 (Delegate Mode), #43406 (Edit tool), #45291 (.claude writes), #25254 (deadlock), #25520 (invisible prompts in VS Code). Consolidating these under a single "teammate permission inheritance" umbrella and shipping a proper fix — or at minimum exposing an explicit opt-in flag that honors bypassPermissions transitively — would unblock a significant amount of real-world Agent Teams usage.

Reproduction

  1. Install @anthropic-ai/claude-code@2.1.114
  2. Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true and permissions.defaultMode: "bypassPermissions"
  3. Start Lead with claude --dangerously-skip-permissions
  4. Spawn any teammate via Agent tool
  5. Ask the teammate to Edit any file — the "Waiting for team lead approval" dialog appears

Hope this helps prioritize. Happy to provide hook_raw_input.log excerpts or a fresh reproduction trace if useful.

renatorroliveira · 3 months ago

Is there any hopes of getting this fixed?

therealbill · 3 months ago
Is there any hopes of getting this fixed?

I'm rapidly losing any hope of that. This has been around in various tickets since February and most seem to just get auto-closed.

cryptiklemur · 2 months ago

Kinda feels like this agent team feature is just getting forgotten..... Do the developers who made this feature even use it?

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →