[FEATURE] Reverse permission hierarchy

Preflight Checklist

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

Problem Statement

Right now I'm in heavy plannings and discussions about making agentic coding a main component of the way our teams develop. To fully protect our developers, projects and proprietary data, we are trying to take steps to achieve it.

From reading the documentation of claude code, a specific entry caught my attention:

Rules are evaluated in order: deny -> ask -> allow. The first matching rule wins, so deny rules always take precedence.

See: https://code.claude.com/docs/en/permissions#manage-permissions

This is sadly the wrong way to do it. As it stands, permissions are usually granted in the following way:

• deny all
• ask for a few
• allow some rare cases

For example, for us, we do:

• encapsulate all commands claude can use in gradle tasks. This assures us that he will not run away with some weird combination of calls
• allow things like WebFetch for specific pages, i.e. baeldung, framework docs etc
• deny everything

The current implemented order means that we have a huge problem: We need to deny all in a very granular way, which makes it easy to miss things. In our current setup, we'd have to not deny ./gradlew, or ask about ./gradlew, otherwise we couldn't let it run autonomously for some tasks, vastly undermining the potential we could otherwise gain.

Proposed Solution

The proposal is to reverse this order. This way, it is possible to:

• deny Bash(./gradlew *)
• ask Bash(./gradlew tofuPlan)
• allow Bash(./gradlew npmInstall)

So we would be protected against claude writing a custom ./gradlew tofuApply that suddenly deploys new nodes in production without our specific approval.

Alternative Solutions

No other options available, sadly

Priority

Critical - Blocking my work

Feature Category

Configuration and settings

Use Case Example

As a company, trying to broadly deploy this in a secure sense, we'd like to be able to create generic lists of permissions. Our projects follow the same patterns 95% of times, so this would be a no brainer.

So we'd define pre-configured commands agents can execute, denying everything otherwise. Per project then, they could add specific commands via the project settings. With the setup right now, we'd end up in an endless chase of commands to deny to not reduce the efficiency of claude code.

Additional Context

_No response_