[FEATURE] unit test permissions rules

Resolved 💬 3 comments Opened Mar 27, 2026 by bmillwood-aisi Closed May 2, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • #38771 and #16622 related but (I argue) distinct since it's about seeing the decisions after the fact, whereas this is about testing them before they happen.
  • [x] This is a single feature request (not multiple features)

Problem Statement

I would love to be able to verify what my settings.json allows Claude to run without having to ask Claude to try running the command, especially when I want to deny the command and finding out that my deny didn't work by asking Claude to run it isn't great.

Proposed Solution

I can imagine many possible user experiences that work for me, but here's the one I pick:

Basic case I want:

$ claude --test-permission 'Bash(cat /tmp/x)'
deny

I expect this would also work "automatically", which could be nice for testing rule changes, but I don't consider it essential:

$ claude --allowed-tools Bash --test-permission 'Bash(cat /tmp/x)'
allow

$ claude --allowed-tools 'Bash(cat *)' --disallowed-tools Bash --test-permission 'Bash(cat /tmp/x)'
deny

You could also think about showing why the decision was reached, e.g.

deny, no matching rule

or

deny, matched allow:Bash(cat *) and deny:Bash

But the basic thing above would be enough for me.

(I considered some scheme where it would exit zero or nonzero according to whether the test "passed" or "failed", but I think I don't want anything like that. Just indicate the result and let me handle whether it's the result I wanted.)

Alternative Solutions

I've considered writing something that extracts / replicates the logic from the CLI, but that's obviously unreliable and won't update when the CLI updates.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

I'd add a GitHub Actions workflow to my repository that verified that the settings.json in there allowed (for example) git -C /tmp/git status but denied git -C /tmp/git rm -f * status, proving that the inner * in my Bash(git -C * status) rule matched only one argument.

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗