[Feature Request] Implement Fine-Grained Tool Permissions for Agent Constraints #7514

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   platform:linuxIssue specifically occurs on LinuxIssue specifically occurs on Linux

   area:tools

   area:security

   on Sep 12, 2025
2. github-actions commented on Sep 12, 2025

   

   github-actionsBot

   on Sep 12, 2025 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. claude code agent gets around writing access by bash commands #5892
   2. Security Permissions Bypass in Bash File Access Restrictions #6036
   3. [FEATURE] add Exec tool as more secure alternative to Bash tool #6046

   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
3. coygeek commented on Sep 13, 2025

   

   coygeek

   on Sep 13, 2025

   More actions

   Hey, this is a great point and a feature I'd also love to see implemented. I did some digging through the documentation provided, and it looks like you've found a gap between the main permission system and the subagent configuration.

   Here's what I found:

   The Current Situation

   You're right that subagents seem to only accept whole tool names in their frontmatter. The en/docs/claude-code/sub-agents documentation shows examples like this:

   ---
   name: code-reviewer
   description: Expert code review specialist...
   tools: Read, Grep, Glob, Bash
   ---

   It doesn't show the fine-grained syntax you're looking for.

   However, the main permission system does support that exact syntax. In the en/docs/claude-code/iam documentation under "Tool-specific permission rules", it shows you can configure settings.json with rules like:

   • Bash(npm run test:*)
   • Bash(curl http://site.com/:*)

   It seems the subagent tools: configuration just hasn't inherited this level of granularity yet.

   Potential Workarounds

   While we wait for this feature to be added, here are a couple of ideas that might help you lock down your testing agent.

   1. Use Project-Level Permissions (settings.json)

   Since subagents inherit permissions from the main session, you could define a restrictive deny list in your project's .claude/settings.json file. This would block the agent (and yourself, when using Claude) from running destructive commands.

   For example, you could create a .claude/settings.json with:

   {
     "permissions": {
       "allow": [
         "Bash(go test:*)",
         "Bash(ls:*)"
       ],
       "deny": [
         "Bash(sed:*)",
         "Bash(awk:*)",
         "Bash(rm:*)",
         "Bash(cat:*)",
         "Write",
         "Edit"
       ]
     }
   }

   The testing agent would be able to run go test, but if it tried to use sed or cat > file.txt, the main permission system would block it. The downside is this applies to the main agent too, not just the subagent.

   2. Use a PreToolUse Hook (More Advanced)

   A more powerful solution would be to use Claude Code hooks. You could create a PreToolUse hook that triggers on any Bash tool call. The hook script would receive the command Claude is trying to run and could decide whether to allow or block it.

   Your .claude/settings.json would have something like this:

   {
     "hooks": {
       "PreToolUse": [
         {
           "matcher": "Bash",
           "hooks": [
             {
               "type": "command",
               "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/validate_bash_command.py"
             }
           ]
         }
       ]
     }
   }

   Then your validate_bash_command.py script could check the command. If it's a write command (sed, cat >, etc.), the script would sys.exit(2). According to the docs, exiting with code 2 blocks the tool call and feeds the stderr back to Claude as feedback. This would effectively teach it not to use those commands.

   ---

   Ultimately, I think your suggestion is the best long-term solution. Having fine-grained permissions directly in the subagent definition makes the most sense for creating truly constrained, special-purpose agents.

   +1 for this feature request
4. github-actions commented on Dec 8, 2025

   

   github-actionsBot

   on Dec 8, 2025 – with GitHub Actions

   More actions

   This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
5. github-actions

   added

   autocloseIssue will be closed automaticallyIssue will be closed automatically

   on Dec 8, 2025
6. github-actions commented on Jan 8, 2026

   

   github-actionsBot

   on Jan 8, 2026 – with GitHub Actions

   More actions

   This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
7. github-actions

   closed this as not plannedon Jan 8, 2026
8. github-actions commented on Jan 15, 2026

   

   github-actionsBot

   on Jan 15, 2026 – with GitHub Actions

   More actions

   This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
9. github-actions

   locked as resolved and limited conversation to collaborators on Jan 15, 2026