Skip to content

[FEATURE] Allow specifying tool permissions in agents and plugins #10093

Closed as not planned

Description

@dherman

Preflight Checklist

  • I have searched existing requests and this feature hasn't been requested yet
  • This is a single feature request (not multiple features)

Problem Statement

When sharing a custom agent or plugin in a marketplace, I want to be able to establish sensible permissions both to ensure the safety and proper level of automation.

As far as I know, it's only possible to set permissions like this either in my user settings or in the settings in the directory I'm working in, but it's not possible to create settings that are scoped to the plugin. This seems like it would be an important way to allow plugin authors to tune the balance of automation and safety for their functionality.

Proposed Solution

Allow a settings.json file to be included in either of the following directories:

  • A plugin's directory
  • A custom agent's directory

Settings provided by the file are scoped to the entity (plugin or agent) associated with that directory.

Settings can include "permissions".

For security, permissions that have been explicitly limited in an outer scope cannot be loosened ("deny" -> { "ask", "allow" } or "ask" -> "allow") in an inner scope.

It might be worth allowing subagent permissions to be set in the document's front-matter for convenience (instead of in a separate settings.json file), but I don't know if the syntax would be too unwieldy.

Alternative Solutions

My current workaround is to document in the plugin's README optional instructions for configuring the settings in ./.claude/settings.json.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

I've been developing a git utility plugin that assists in rewriting a PR branch's commit history for code review. The custom agents and skills in the plugin have enough guardrails that it's safe to allow Read/Write/Edit and most git commands by default. But the plugin should never do things like talk to a git remote.

So it would be appropriate to set the permissions to e.g.:

{
  "permissions": {
    "allow": [
      "Read(*)",
      "Write(*)",
      "Edit(*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git checkout:*)",
      "Bash(git rev-parse:*)",
      "Bash(git merge-base:*)",
      "Bash(npm *)",
      "Bash(yarn *)",
      "Grep(*)",
      "Glob(*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git rebase:*)",
      "Bash(git reset:*)",
      "Bash(rm:*)"
    ]
  }
}

Additional Context

I have an example plugin with several subagents at https://github.com/dherman/claude-plugins/tree/main/plugins/historian -- it would benefit from being able to specify these permissions.

Activity

  1. github-actions commented on Dec 8, 2025

    @github-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.

  2. colinboey commented on Dec 9, 2025

    @colinboey

    Another concrete use case: I have a VC deal analysis agent that needs to visit arbitrary company websites during due diligence. Currently I must either manually approve each domain or enable global WebFetch auto-approval. Agent-level permissions would let me scope WebFetch(domain:*) to just this agent while maintaining stricter controls elsewhere.

  3. github-actions commented on Jan 11, 2026

    @github-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.

  4. github-actions commented on Jan 19, 2026

    @github-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.

  5. locked as resolved and limited conversation to collaborators on Jan 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions