Claude Code Permissions
Claude Code can read files, edit code, and run commands on your computer. Permissions decide which of those actions happen automatically and which ones wait for your approval. A clear grasp of permissions lets you work quickly without losing control of your project.
Why Permissions Exist
Think of Claude Code as a skilled contractor working in your house. You hand over the keys to some rooms and keep other doors locked. Permissions are those keys. Each action Claude Code wants to take passes through a gate, and the gate either opens, asks you, or stays shut.
Claude Code wants to act
↓
[ PERMISSION GATE ]
↓ ↓ ↓
ALLOW ASK DENY
(runs) (you (blocked)
decide)
The Approval Prompt
A prompt appears when Claude Code needs approval for an edit or a command. The prompt shows the exact change or command. You choose to approve once, approve for the rest of the session, or decline and give new direction.
Read each prompt before you approve it. A prompt that shows a delete command or a file outside your project deserves extra attention.
Permission Modes
A mode sets the default behavior for the whole session. Press Shift+Tab to cycle through the modes. The current mode appears near the prompt line.
| Mode | Behavior | Best For |
|---|---|---|
| Default | Asks before edits and most commands | New projects and careful work |
| Accept Edits | Applies file edits without asking; still asks for risky commands | Trusted tasks with many small edits |
| Plan | Reads and proposes; changes nothing | Large or unclear tasks |
| Auto | A safety checker reviews each action and approves the safe ones | Long tasks with fewer interruptions |
| Bypass | Skips the permission layer entirely | Isolated test machines only |
Available modes vary by version and setup. Run /help in your own installation to confirm what your copy offers.
Rules: Allow, Ask, and Deny
Modes set the baseline, and rules refine it. A rule names a tool and an optional pattern. Run /permissions to view and edit rules inside a session.
ALLOW Bash(npm run test) → runs without asking ASK Bash(git push *) → always asks first DENY Read(./.env) → never allowed
Deny rules protect secrets. A rule that blocks reading the .env file keeps passwords and keys out of the conversation.
Saving Rules in a Settings File
Rules live in a settings file so every session follows them. The project settings file sits at .claude/settings.json.
{
"permissions": {
"allow": ["Bash(npm run test)", "Bash(npm run lint)"],
"deny": ["Read(./.env)"]
}
}
Commit this file to version control and the whole team shares the same safety rules.
A Safe Starting Routine
- Begin in Default mode while you learn the tool.
- Allow harmless commands such as test and lint runs.
- Deny access to secret files.
- Switch to Accept Edits once you trust the task.
- Return to Default mode when the work changes character.
Mistakes to Avoid
- Approving every prompt without reading it.
- Using Bypass mode on a computer that holds personal files.
- Writing rules so broad that they allow every command.
- Forgetting that CLAUDE.md instructions guide Claude but do not enforce limits. Permission rules enforce limits.
Permissions in a Daily Session
Imagine a developer fixing a failing test. Claude Code asks to run the test command. The developer approves it for the whole session because the command is harmless. A later request to delete a folder triggers a new prompt, and the developer declines with a note: "Keep that folder; fix the import instead." Claude Code adjusts. The session stays fast for safe actions and careful for risky ones. This balance defines good permission habits.
Key Points
- Permissions control which actions run, ask, or stay blocked.
- Shift+Tab cycles through permission modes.
- Allow, ask, and deny rules refine the mode for specific tools.
- Deny rules protect secret files.
- A shared settings file gives every teammate the same protection.