Configuration: Permissions, Models, and YOLO Mode

You run Claude Code on a production repo for the first time and it asks permission for every single file read, every grep, every test run. Fifteen approval prompts later, you have barely started your task. You know there has to be a better way to configure what Claude can do autonomously versus what requires your sign-off — but the settings system has four different scopes and two different file formats.

This guide shows you how to configure Claude Code’s permissions, model selection, and auto-approve behavior so it works with you, not against you.

What You’ll Walk Away With

• A settings.json with sensible permission rules for your workflow
• Understanding of managed, user, project, and local scopes
• Model configuration that balances quality and speed
• Knowledge of when to use (and when to avoid) bypass-permissions mode

The Settings Hierarchy

Claude Code reads configuration from multiple locations, each with different scope and precedence. From highest to lowest priority:

Scope	File Location	Who It Affects	Shared?
Managed	/Library/Application Support/ClaudeCode/ (macOS)	All users on the machine	Deployed by IT
Local	.claude/settings.local.json	Just you, in this project	No (gitignored)
Project	.claude/settings.json	All collaborators	Yes (committed)
User	~/.claude/settings.json	You, across all projects	No

Higher-scoped settings override lower ones. If a managed policy denies a permission, nothing else can override it. If a project setting denies Bash(curl *), your user settings cannot allow it.

Setting Up Permissions

The permissions system controls what Claude can do without asking. This is the single most impactful configuration for your daily workflow.

The Starter Configuration

Create or edit ~/.claude/settings.json for your personal defaults:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(npm run build)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git status)",
      "Bash(git branch *)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

This lets Claude run your standard dev commands without prompting, while blocking network requests and access to secrets.

Tip

Copy-paste settings for a TypeScript project:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx tsc --noEmit)",
      "Bash(npx prettier --write *)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git status)",
      "Bash(git add *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Permission Rule Syntax

Rules follow the pattern Tool or Tool(specifier) with wildcard support:

Rule	What It Matches
Bash	All bash commands
Bash(npm run *)	Any npm run command
Read(./.env)	Reading the .env file
Read(./secrets/**)	Reading anything under secrets/
Edit	All file edits
WebFetch(domain:example.com)	Fetch requests to example.com

Rules are evaluated in order: deny first, then ask, then allow. The first matching rule wins.

Project-Level Permissions

For team-shared settings, create .claude/settings.json in your repo root:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(make *)",
      "Bash(go test ./...)",
      "Bash(go build ./...)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./config/credentials.json)",
      "Bash(docker push *)"
    ]
  }
}

Commit this file so every team member gets the same base configuration. Individual developers can override with .claude/settings.local.json.

Model Configuration

Claude Code defaults to Claude Opus 4.6, the most capable model for agentic coding. You can override this globally or per-session.

Switching Models

Inside a session, use the /model command:

/model
# Select from available models

Or toggle fast mode, which switches to Claude Sonnet 4.5:

/model fast

Setting a Default Model

In settings.json:

{
  "model": "claude-sonnet-4-5-20250929"
}

Or via environment variable:

export ANTHROPIC_MODEL=claude-sonnet-4-5-20250929

When to Use Each Model

Model	Use Case	Trade-off
Claude Opus 4.6 (default)	Complex refactoring, architecture decisions, multi-file changes	Most capable, highest token cost
Claude Sonnet 4.5 (fast mode)	Quick edits, simple bug fixes, routine tasks	Fast and cheaper, slightly less capable

Tip

Copy-paste prompt to test model performance on your codebase:

Analyze the 3 most complex files in this project. For each,
identify one potential bug or performance issue and propose
a fix. Show me the before and after.

Run this with both Opus 4.6 and Sonnet 4.5 to see where the quality difference matters for your specific codebase.

Permission Modes

Claude Code offers several permission modes that control how much you are prompted during a session:

Mode	Behavior	Activate With
Default	Ask permission for each action	Default behavior
Accept Edits	Auto-approve file edits, ask for bash commands	/config or --permission-mode acceptEdits
Bypass Permissions	Skip all permission prompts	--dangerously-skip-permissions

Bypass Permissions (YOLO Mode)

The --dangerously-skip-permissions flag skips all approval prompts. Claude will read, write, and execute commands without asking.

claude --dangerously-skip-permissions

Caution

Bypass mode is powerful but dangerous. Claude can delete files, run destructive commands, and make irreversible changes. Only use this in disposable environments like CI containers, Docker-based dev environments, or throwaway branches. Never use it on your main branch with uncommitted work.

When to use bypass mode legitimately:

• CI/CD pipelines where Claude runs in a container and all changes go through PR review
• Headless automation with claude -p for scripted tasks
• Exploratory prototyping in a git branch you can discard

To prevent bypass mode entirely (for enterprise security):

// In managed-settings.json
{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Environment Variables

Set environment variables that apply to every Claude Code session:

// In ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "NODE_ENV": "development"
  }
}

These are injected into Claude’s environment when it runs bash commands. Useful for setting up consistent dev environments across your team.

Extended Thinking Configuration

You can make extended thinking the default for all sessions:

{
  "alwaysThinkingEnabled": true
}

Or control the thinking budget via environment variable:

# Limit thinking tokens (default is 31,999)
export MAX_THINKING_TOKENS=10000

# Disable thinking entirely
export MAX_THINKING_TOKENS=0

For Claude Opus 4.6, thinking depth is controlled by the effort level setting instead:

# Values: low, medium, high (default)
export CLAUDE_CODE_EFFORT_LEVEL=medium

Sandbox Configuration

For maximum security, enable sandboxing to isolate bash commands:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"],
      "allowLocalBinding": true
    }
  }
}

When sandboxing is enabled, autoAllowBashIfSandboxed: true means Claude can run any bash command without prompting, since the sandbox prevents filesystem and network access outside your allowed rules.

The Interactive Config Command

The fastest way to explore and modify settings is the /config command inside a Claude Code session:

/config

This opens a tabbed interface where you can view your current settings, modify permissions, toggle features, and see which settings come from which scope.

When This Breaks

“Permission denied” for commands you thought you allowed — Check for conflicting rules. Deny rules are evaluated first and take precedence. A deny rule of Bash(npm *) will block everything npm-related even if you allowed Bash(npm run test).

“Model not available” — If you set a specific model in settings.json and it is not available in your account tier, Claude Code may fail to start. Remove the model override or check your subscription level.

Settings not taking effect — Remember the precedence order. If your user setting is being overridden, check .claude/settings.json (project scope) and .claude/settings.local.json (local scope). Use /config to see the effective merged configuration.

“Cannot read settings file” — Invalid JSON syntax is the usual cause. Run your settings.json through a JSON validator. The $schema property gives you autocomplete and validation in VS Code.

What’s Next

With permissions and models configured, set up your IDE integration so Claude Code works alongside your editor.

IDE Integration VS Code extension and JetBrains plugin

Project Initialization Set up CLAUDE.md for project context