Claude Code Security: Commands and Setup

Claude Code runs with your user’s permissions. Every file it reads, every shell command it executes, and every MCP server it connects to operates within the same access boundary as your account.

Secure configuration is not optional. It is the difference between a productive agentic tool and an uncontrolled process with access to your codebase and credentials.

Key Takeaways

• The permission system has three rule types: Allow, Ask, and Deny. Deny overrides Ask, Ask overrides Allow.
• Four permission modes set the session-wide posture: Default, plan, auto-edit, and bypass. Never use bypass in sensitive environments.
• The /permissions command shows your current rules and their source: Run it before every new session.
• .claudeignore is your file-level access control: Configure it before your first session, not after.
• Managed settings enforce team-wide policy: Project settings override user settings for specific rules.
• /security-review runs a built-in security scan on your current context: Use it before committing Claude Code-generated code.

The Claude Code Permission System

Anthropic’s own research found that developers approve 93% of Claude Code permission prompts without careful review. The permission system exists to move security decisions out of the moment and into configuration, where they can be deliberate.

Claude Code uses three rule types that apply in a strict precedence order:

Rules are configured in settings.json files using the format Tool or Tool(specifier). A bare tool name like Bash matches every Bash call. Adding a specifier in parentheses narrows the match.

Examples:

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm test)",
      "Bash(git status)",
      "Bash(git diff)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(curl | sh)",
      "Bash(cat ~/.ssh/*)",
      "Bash(cat ~/.aws/*)"
    ]
  }
}

Where Settings Files Live

Rules apply at different scopes depending on which file they are in.

Evaluation order: Project settings are evaluated first, then user settings. A deny rule in project settings cannot be overridden by an allow rule in user settings.

For team-wide security policy, put your deny rules in .claude/settings.json and commit it to the repository. Every developer on the project gets the same protections.

The Four Permission Modes

Permission modes set the session-wide posture. They determine what happens when no specific rule matches a tool call.

Plan mode is the safest option for untrusted repositories or sensitive codebases. Use it when you want Claude to analyze or explain code without any risk of modification.

Set the mode at session launch:

claude --permission-mode plan    # Read-only exploration
claude --permission-mode auto    # Auto-approve edits (use with established rules)

The /permissions Command

Run /permissions inside any Claude Code session to see your current active rules and which file they came from.

/permissions

This shows:

• All active Allow, Ask, and Deny rules
• The source file for each rule (project, user, or local)
• The current permission mode

Run this at the start of any sensitive session to confirm the configuration is what you expect before any work begins.

Setting Up .claudeignore

.claudeignore controls which files Claude Code can read. It uses gitignore syntax.

Create it at your project root and commit it before any developer runs Claude Code on the project.

Minimum required entries:

# Credential files
.env
.env.*
.env.local
.env.staging
.env.production

# Private key material
*.pem
*.key
*.p12
*.pfx

# System credential stores
~/.ssh/
~/.aws/credentials
~/.aws/config
~/.config/

# Application secrets
config/secrets.*
secrets/
.secret

# Token files
*.token
auth.json
credentials.json

Project-specific additions:

After the base entries, add paths specific to your application: database seed files with real data, internal API documentation with credentials embedded, local configuration files engineers use for testing.

Common gap: Teams add .env but forget variant files (.env.staging, .env.production, .env.test) and certificate files (*.pem, *.key). Audit all patterns, not just the obvious ones. The full .claudeignore checklist is in the Claude Code security audit.

The /security-review Command

Claude Code includes a built-in /security-review slash command that runs a security scan on your current context.

/security-review

This command asks Claude to review the current state of your project for:

• Hardcoded credentials in recently modified files
• OWASP Top 10 vulnerabilities in generated code
• Dependency vulnerabilities in packages introduced during the session
• Overly permissive file operations

Run it before committing any session’s output to your repository. It is not a substitute for SAST in your CI pipeline, but it catches common issues before they reach code review.

Deny Rules: What Every Project Needs

These deny rules should be in every project’s .claude/settings.json. They block the commands most likely to cause irreversible damage or expose credentials.

{
  "permissions": {
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(rm -rf $HOME)",
      "Bash(git reset --hard origin*)",
      "Bash(git push --force*)",
      "Bash(curl | sh)",
      "Bash(wget | sh)",
      "Bash(cat ~/.ssh/*)",
      "Bash(cat ~/.aws/*)",
      "Bash(cat .env*)",
      "Bash(psql*prod*)",
      "Bash(mysql*prod*)",
      "Bash(DROP TABLE*)",
      "Bash(TRUNCATE TABLE*)"
    ]
  }
}

Rule patterns are matched against the literal command string. Bash(git push --force*main) will not match git push --force-with-lease origin main because the prefix differs. Test your deny rules against real command strings before relying on them.

Ask Rules: Required Confirmation for High-Risk Operations

Ask rules force a confirmation prompt for commands that are sometimes legitimate but deserve a second look. These should not be denied outright, but they should not run silently.

{
  "permissions": {
    "ask": [
      "Bash(git push*)",
      "Bash(npm publish*)",
      "Bash(*deploy*)",
      "Bash(*migration*)",
      "Bash(psql*)",
      "Bash(kubectl*)"
    ]
  }
}

Ask rules override Allow rules for the same tool call. A command in both Allow and Ask will always trigger a prompt.

Allow Rules: Removing Friction for Safe Commands

Allow rules let Claude Code run specific, known-safe commands without prompting. Build your allow list from the commands your team runs dozens of times per day.

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git log --oneline*)",
      "Bash(cat src/*)",
      "Bash(ls *)"
    ]
  }
}

A narrow allow list is better than a broad one. “Allow all Bash” is a fundamentally different policy from “allow the specific commands your project needs.” Start narrow and expand based on friction, not the other way around.

Managed Settings for Enterprise Teams

Enterprise Claude Code deployments can use managed settings to enforce policy across all developer machines without relying on individual configuration.

Managed settings work by distributing a centrally controlled settings.json that takes precedence over individual user settings for specific rules. Security teams can:

• Block bypass mode (--dangerously-skip-permissions) across all sessions
• Enforce deny rules that cannot be overridden by developer user settings
• Require specific hooks to be active in every session
• Route all Claude Code traffic through an enterprise proxy or LLM gateway

For teams managing Claude Code at scale, managed settings combined with OpenTelemetry export for audit logging covers most enterprise governance requirements.

Security Setup Checklist

For the full eight-domain security audit covering hooks, MCP servers, secrets, and CI/CD controls, see the Claude Code security audit checklist.

Want Production-Grade Claude Code Security Configuration?

Individual setup is manageable. Team-wide permission policy, managed settings, hook enforcement, and audit logging across dozens of developers is a different scope of work.

Phos AI Labs is an embedded AI consulting firm for small and mid-market businesses.

We identify the right AI problems, build the strategy, handle implementation, and train your team until AI is how the business actually runs.

• Strategy before systems: We establish which workflows Claude Code should own and what security controls each one requires before configuration begins.
• AI Foundations that hold: We install the operating context, decision rules, and configuration standards your team runs on for years.
• Real team training: We build security fluency inside your actual workflows, not in generic compliance sessions.
• Private AI Workspace: We design a company-wide AI environment built around your knowledge base and existing stack.
• AI Implementation: We rebuild the workflows that matter most with security and governance built in from the start.
• Honest judgment, every time: We tell you which controls matter for your specific environment.
• We stay until it compounds: We are not done when the configuration is delivered. We are done when the team runs it reliably.

400+ engagements. Clients include Zapier, Coca-Cola, Medtronic, Dataiku, and American Express.

For certified Claude Code development with security-first configuration from day one, LOW/CODE Agency is one of the first Anthropic partners worldwide with 10+ CCA-F certified developers on staff.

If you want your Claude Code security configuration to hold, talk to the team at Phos AI Labs.

Frequently Asked Questions

What is the difference between Allow, Ask, and Deny in Claude Code permissions?

Deny blocks a tool call entirely with no prompt. Ask forces a confirmation prompt. Allow permits the call without any prompt. Deny overrides Ask, and Ask overrides Allow when rules conflict.

What is the safest Claude Code permission mode for untrusted repositories?

Plan mode. It allows Claude to read, search, and reason about a codebase but blocks all edits, writes, and shell commands. Use it when exploring an unfamiliar or potentially malicious repository.

How do I see my current Claude Code permissions?

Run /permissions inside a Claude Code session. It shows all active Allow, Ask, and Deny rules and which settings file each rule came from.

What is the /security-review command?

A built-in slash command that scans your current session context for hardcoded credentials, OWASP Top 10 vulnerabilities in generated code, and dependency issues. Run it before committing any Claude Code session output.

Should Claude Code permission rules go in the project or user settings?

Security-critical deny rules belong in .claude/settings.json (project settings) committed to the repository. This ensures every developer on the project gets the same protections regardless of their personal user settings.

What is bypass mode and when is it safe to use?

Bypass mode disables all human review gates. Only safe in isolated containers where you fully control all input. Never use it in CI/CD pipelines that process external input.