Skills/subagents do not inherit user-level permissions from settings.json

[thomast73]

User-level permissions configured in ~/.claude/settings.json under permissions.allow are not being inherited by skills/subagents. All bash commands require permission prompts when executed within a skill, even though those same commands are auto-approved when used in the main conversation.

Steps to Reproduce

1. Configure user-level permissions in ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(test)",
      "Bash(git rebase)",
      "Bash(mvn verify)",
      "Bash(grep)",
      "Bash(head)",
      "Bash(lsof)",
      "Bash(sleep)",
      "Bash(tail)",
      "Bash(echo)"
    ]
  }
}

2. Restart Claude Code to load permissions
3. Verify permissions work in main conversation (e.g., ls command runs without prompt)
4. Run a skill that uses these commands
5. Observe: All bash commands prompt for permission despite being in the allow list

Expected Behavior

Skills should inherit user-level permissions from settings.json. Commands in the permissions.allow list should be auto-approved without prompting.

Actual Behavior

Skills prompt for permission on every bash command. Example commands that prompted:

• test -f pom.xml
• grep with head pipeline
• git rebase team/master
• mvn spring-boot:run
• lsof commands
• sleep and tail commands

Environment

• Claude Code version: 2.1.12
• OS: macOS 26.2 (25C56)
• Settings file: ~/.claude/settings.json

Workaround

Select option 2 to create workspace-level permissions, but this defeats the purpose of user-level permissions.

Impact

Significantly degrades user experience when using skills, requiring manual approval of dozens of commands.

[github-actions]

Found 3 possible duplicate issues:

1. Built-in Plan agent ignores parent settings.json permissions and repeatedly prompts for pre-approved tools #10906
2. [BUG] Sub agents can't use tools properly: Permission to use xxx has been auto-denied in dontAsk mode even with --dangerously-skip-permissions #11934
3. [BUG] Background agents cannot run Bash commands - auto-denied without prompting user #18172

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

[thomast73]

Additional Evidence: Workspace Permissions Not Matching in Skills

I've discovered that workspace-level permissions in .claude/settings.local.json are not matching commands even when they should, specifically in skills/subagents.

Commands That Prompted (Without Option 2)

These commands prompted with only "Yes" or "No" options - no workspace-level "don't ask again" option:

1. Maven command with redirection and background execution:

   mvn spring-boot:run -pl app > /tmp/tls-server.log 2>&1 & echo $\!

   Should match: Bash(mvn spring-boot:run:*)

2. For loop with variable assignment:

   SPRING_JAVA_PID=""; for i in {1..60}; do SPRING_JAVA_PID=$(pgrep -P 36034 -f java 2>/dev/null); if [ $? -eq 0 ] && [ -n "$SPRING_JAVA_PID" ]; then echo "Server Java process found: $SPRING_JAVA_PID"; exit 0; fi; sleep 1; done; echo "Timeout: No Java process found"

   Should match: Bash(for i in {1..60}:*)

Command That Offered Option 2

This command correctly offered workspace-level approval:

kill 36074 2>/dev/null; sleep 2; lsof -i :5000 -t 2>/dev/null && echo "Server still running" || echo "Server stopped"

No pattern in workspace permissions - so it correctly offered to add one.

Current Workspace Permissions

.claude/settings.local.json contains:

{
  "permissions": {
    "allow": [
      "Bash(mvn spring-boot:run:*)",
      "Bash(pgrep:*)",
      "Bash(for i in {1..60}:*)",
      "Bash(lsof -i :5000:*)",
      ...
    ]
  }
}

Analysis

The patterns should match but don't, suggesting:

1. Redirects (>, 2>&1), pipes, and background operators (&) may break pattern matching
2. Variable assignments at the start of commands (SPRING_JAVA_PID="") may prevent matching
3. The :* wildcard syntax in workspace permissions behaves differently than expected

This appears distinct from the duplicate issues mentioned (#10906, #11934, #18172), as this is specifically about workspace permission pattern matching in skills/subagents, not about permissions being ignored entirely.