Permissions and Security - Quickstart

Configure Claude Code permissions and sandboxing in under 5 minutes with this quickstart guide. You will learn how to choose the right permission mode, define allow/deny rules in settings.json, and enable protection against prompt injections.

Claude Code permission security is a set of mechanisms (permission modes, allow/deny rules, and sandboxing) that protect your development environment against unauthorized executions. many incidents related to AI agents stem from misconfigured permissions. This guide lets you secure your installation in 5 concrete steps, without unnecessary theory.

What are the prerequisites before configuring permissions?

Before starting, verify that you have the following:

• Claude Code installed (step-by-step installation guide)
• Node.js 18 or higher (only needed for npm-based installs; the native binary does not require Node)
• A terminal with access to the ~/.claude/ directory
• 5 minutes of your time

Run this command to confirm your version:

claude --version

If you do not see a version, consult the installation quickstart to install or update.

Key takeaway: on Linux and WSL2 the sandbox relies on the bubblewrap and socat system packages; on macOS it uses the built-in Seatbelt framework, with nothing to install.

How to choose the right permission mode?

Claude Code offers 6 permission modes via the --permission-mode flag. Each mode defines the level of autonomy granted to the agent. In practice, many use default mode daily.

Launch Claude Code in the desired mode with --permission-mode:

# Default mode
claude

# acceptEdits mode - for everyday development
claude --permission-mode acceptEdits

# Plan mode - analysis before action
claude --permission-mode plan

# In session, use Shift+Tab or Alt+M to cycle through modes

default mode is recommended if you are discovering the tool. It asks for confirmation before every sensitive action, allowing you to understand the agent's behavior. In session, use Shift+Tab or Alt+M to cycle through permission modes. Consult the first conversations tutorial to see these modes in action.

Key takeaway: start in default mode to learn, use Shift+Tab/Alt+M to cycle through modes, then switch to acceptEdits once comfortable.

How to configure allow/deny rules in settings.json in 5 minutes?

Allow/deny rules in settings.json are Claude Code's granular control mechanism. They give you granular control over which commands run without prompting and which are blocked outright, independently of the active permission mode.

Open the global configuration file:

# Create the directory if needed
mkdir -p ~/.claude

# Edit the settings.json file
nano ~/.claude/settings.json

Add this base configuration to secure your environment:

{
 "permissions": {
 "allow": [
 "Read",
 "Glob",
 "Grep",
 "Bash(npm test)",
 "Bash(npm run lint)",
 "Bash(git status)",
 "Bash(git diff)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl * | bash)",
 "Bash(git push --force)",
 "Bash(chmod 777 *)"
 ]
 }
}

In practice, each rule follows the Tool(pattern) format. The * wildcard works like a glob. Here are the most commonly used patterns:

You can also define project-level rules. Create a .claude/settings.json file at the root of your repository for project-specific rules. Project rules are merged with your user (global) rules across scopes. A deny rule at any scope always overrides an allow rule at any other scope, so a user-level deny blocks a project-level allow.

For further configuration, consult the advanced permissions tips that cover complex patterns and edge cases.

Key takeaway: deny rules always take priority over allow rules. Place your critical prohibitions first.

How to enable sandboxing with Seatbelt or bubblewrap?

Sandboxing is an isolation layer that prevents Claude Code from accessing files and networks outside the authorized perimeter. Seatbelt is the native mechanism on macOS, bubblewrap on Linux. It provides OS-level filesystem and network isolation for Bash commands, but it is not a complete isolation boundary.

Which sandbox for which system?

Sandboxing is opt-in. Enable it per project by running /sandbox, or for all projects set "sandbox": { "enabled": true } in ~/.claude/settings.json.

On Linux and WSL2, install both required system packages first:

sudo apt-get install bubblewrap socat

macOS needs nothing installed: it uses the built-in Seatbelt framework.

To inspect sandbox status, run the /sandbox command inside a session. Its Dependencies tab shows what is available and its Config tab shows the resolved settings. For installation diagnostics, use claude doctor.

By default, sandboxed commands can write only to the working directory and its subdirectories; read access defaults to the whole filesystem except paths you deny. Add credential directories like ~/.aws and ~/.ssh to denyRead to block reads.

To resolve common sandboxing issues, consult the common permission errors page that details solutions for the most frequent blockers.

Key takeaway: sandboxing is your safety net. Enable it with /sandbox and keep it on in production, even when you use bypassPermissions mode.

How to protect against prompt injections in 5 minutes?

Protection against prompt injections is a mechanism that prevents malicious content (files, web pages, API results) from hijacking Claude Code's behavior. Prompt injections remain the number one attack vector against AI agents.

Configure the protections in your settings.json:

{
 "permissions": {
 "deny": [
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(bash)",
 "Bash(bash *)",
 "Bash(sh)",
 "Bash(sh *)",
 "Bash(eval *)"
 ]
 }
}

A critical detail: Claude Code matches permission rules per subcommand. It splits a compound command on the separators &&, ||, ;, |, |&, &, and newlines, then matches each subcommand independently against your rules. A deny pattern that itself contains a pipe, such as Bash(curl | bash), never matches, because the running command curl x | bash is split into curl x and bash and neither matches the literal pattern. Never embed a pipe inside a single Bash() rule. Instead, deny the dangerous interpreter directly (Bash(bash), Bash(sh)) and the download tools (Bash(curl ), Bash(wget *)), so the curl x | bash attack is blocked on the bash subcommand.

Here are the most common injection vectors and how Claude Code blocks them:

1. Booby-trapped files: a .md or .txt file containing hidden instructions. Normal mode shows you the content before execution.
2. Command results: a curl command that returns execution instructions. Denying curl, wget, bash, and sh blocks the download-and-execute chain on each individual subcommand.
3. Compromised dependencies: a package.json with malicious postinstall scripts. Add Bash(npm install *) to deny and use Bash(npm install --ignore-scripts) in allow.
4. External MCP context: an MCP server injecting instructions. Consult the MCP quickstart to secure your connections.

SFEIR Institute best practices for AI agent security include systematically verifying results before execution. You will find concrete examples of secure conversations that illustrate how to identify an injection attempt.

Key takeaway: combining plan mode, deny rules, and sandboxing provides layered defense-in-depth against prompt-injection attempts.

How to verify everything is working?

Claude Code gives you three dedicated checks. Run each one:

If any check shows a warning, revisit the corresponding step. For complex cases, the complete permissions and security guide covers each parameter in detail.

Then confirm a blocked command is properly rejected. Run /permissions to verify your deny rules are loaded, then ask Claude to run a specific denied command in an interactive session and confirm it is blocked:

# In an interactive session, confirm a denied command is refused
/permissions

If a denied command runs anyway, your deny rules are not loaded. Check the settings.json file path.

To master the slash commands that facilitate permission navigation, consult the slash commands tutorial and the associated examples.

Key takeaway: use /permissions and /sandbox to confirm your security state, and re-run them after every settings.json modification.

What are the recommended settings for your profile?

Your ideal configuration depends on your context. Here are the typical profiles and associated settings:

In practice, the "Solo developer" profile covers the majority of daily use cases. Copy this complete configuration to get started:

{
 "permissions": {
 "allow": [
 "Read",
 "Write",
 "Glob",
 "Grep",
 "Bash(npm *)",
 "Bash(git *)",
 "Bash(node *)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl * | *)",
 "Bash(git push --force *)",
 "Bash(eval *)",
 "Bash(chmod 777 *)"
 ]
 }
}

To deepen Claude Code security, SFEIR Institute offers the one-day Claude Code training. You will practice permission configuration on real cases, with labs dedicated to sandboxing and allow/deny rules.

If you want to go further, the AI-Augmented Developer training (2 days) covers secure integration of AI agents into your complete workflow, and the AI-Augmented Developer - Advanced training (1 day) covers advanced security strategies for CI/CD pipelines.

Key takeaway: adapt your permissions to your context: too restrictive slows productivity, too permissive exposes you to risks.

What's next?

You have secured Claude Code in 5 minutes. Here are the next steps to go further:

1. Explore the complete permissions and security guide to master advanced configurations
2. Consult the permissions tips to optimize your allow/deny rules
3. Avoid the pitfalls listed in common permission errors
4. Configure your MCP servers securely with the MCP quickstart
5. Practice with conversation examples to test your rules in real conditions