[FEATURE] Granular permission profiles for Claude Code — alternative to binary skip-permissions

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

Summary

--dangerously-skip-permissions is binary. There is no middle ground between "approve every action manually" and "trust everything unconditionally." This creates a real workflow problem for developers who want speed and control.

This is a feature request for a granular permission model that lets users define exactly what Claude Code is and isn't allowed to do autonomously.

---

Current Behavior

| Mode | Result |
|---|---|
| Default | Every action triggers an approval prompt — slow, breaks flow |
| --dangerously-skip-permissions | Full autonomy, no guardrails — Claude can access anything on the system |

There is nothing in between.

---

Problem in Practice

The core problem is not file creation — creating new files is a normal and expected part of coding and should not require confirmation. The real issue is directory scope breaches: Claude silently leaving the defined working directory and operating on files or resources elsewhere.

Observed failure modes under skip-permissions:

1. Out-of-scope directory access
Claude accesses files outside the project directory without any instruction to do so — including cloud-synced storage like OneDrive or Google Drive, which on Windows and macOS appear as regular filesystem paths and are not blocked by default.

2. Destructive autonomy on uncertainty
During a session, Claude encountered a problem it couldn't resolve. Instead of stopping and asking how to proceed, it autonomously reverted the entire existing changeset — without confirmation, without warning. The user's work was gone before they had any chance to intervene.

This illustrates that the problem has two dimensions:

• Too much reach — Claude operates outside the defined scope
• Destructive decisions made silently — Claude acts irreversibly when uncertain, instead of asking

Both would be addressed by a proper scope-lock model.

Proposed Solution

A permission profile system that allows fine-grained control over what Claude Code can do autonomously.

Option A: CLI Flags

# Restrict to a specific directory — anything outside requires confirmation
claude --permissions=scoped:/src/services

# Auto-approve within scope, ask before anything outside or irreversible
claude --permissions=ask-on-scope-breach

Option B: CLAUDE.md-based Scope Lock

Allow permissions to be defined per-project in CLAUDE.md:

## Permissions

### Allowed without confirmation
- Read and edit any file within project directory

### Always ask first
- Access anything outside the project directory
- Cloud storage (OneDrive, Google Drive, iCloud, network drives)
- External API or network calls
- Destructive or irreversible actions (revert, delete, reset)

### Working scope
/src/services/ — anything outside this path: always ask

Key distinction vs. existing issues: The scope lock must explicitly cover cloud-synced directories. On Windows and macOS, OneDrive and Google Drive mount as regular filesystem paths — a simple local path restriction does NOT prevent access to them unless cloud storage is explicitly excluded.

Option C: Named Permission Profiles (CLI)

claude --profile=strict      # hard scope lock, ask on any breach
claude --profile=standard    # current default behaviour
claude --profile=full        # current skip-permissions behaviour

### Alternative Solutions

_No response_

### Priority

Medium - Would be very helpful

### Feature Category

CLI commands and flags

### Use Case Example

*Setup:** Enterprise .NET project in `/home/user/projects/example-api/`. OneDrive is mounted at `/home/user/OneDrive/`.

**Task given to Claude:** Refactor the data synchronization service in `/src/services/`.

**Expected behavior:**
- ✅ Read and edit files inside the project directory
- ✅ Create new service files inside the project
- ✅ Run `dotnet build`, `git status`, `git diff`
- ❌ Access `/home/user/OneDrive/` → ask first
- ❌ Run `git revert` or `git reset` → ask first
- ❌ Modify files outside the project directory → ask first
- ❌ Revert changes if problem occurs→ ask first

**What actually happens today under `--dangerously-skip-permissions`:**
All of the above — including the ❌ items — run silently without any prompt.

**With a scope lock (`--permissions=scoped:/home/user/projects/example-api/`):**
Claude works freely inside the project, but anything outside immediately triggers a confirmation — regardless of how confident Claude is that it's the right move.


### Additional Context

## Why This Matters

The goal is not to slow down development — file creation and editing within scope should remain fully autonomous. The goal is a **hard boundary** at the project directory, so Claude never silently reaches outside it.

This is especially important in enterprise and production codebases, and in regulated environments (banking, healthcare, legal) where data access needs to be controlled and auditable.

---

## Related Issues

Several existing issues touch on parts of this problem — but none cover the full scope, particularly regarding external system resources:

| Issue | Focus | Gap |
|---|---|---|
| #21397 | Path-scoped Edit/Write via `.claude/settings.json` | Local paths only, closed as duplicate |
| #26316 | Command-scoped permissions for slash commands | Scoped to custom commands, not general sessions |
| #11073 | Cycleable "don't ask again" scope levels | UI improvement only, no structural scope-lock |

**What's missing in all of them:**

None address access to **external system resources** — cloud storage (OneDrive, Google Drive, iCloud), network drives, or any resource outside the local filesystem. This is a critical gap.

A path-scoped permission model that only covers local files does not prevent Claude Code from accessing mounted cloud storage, which on most systems (Windows, macOS) appears as a regular directory and is not blocked by local path restrictions.

---

## Observed Security Incident

This feature request is directly motivated by a real incident: during a session scoped exclusively to modifying local project files, Claude Code autonomously accessed OneDrive and downloaded files — with no instruction, no prompt, and no user confirmation under `--dangerously-skip-permissions`.

A separately filed security issue covers this incident in detail. This feature request proposes the structural fix.
https://github.com/anthropics/claude-code/issues/35513

---

## Summary

> The permission model should reflect how developers actually think about risk:
> not **"trust everything"** vs **"approve everything"**,
> but **"trust within defined boundaries."**

The easiest first step would be CLAUDE.md-based scope locks — no new CLI infrastructure needed, just parsing a config that most users already have in their projects.