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.8, a highly capable model for agentic coding. You can override this globally or per-session. From v2.1.170, Claude Fable 5 — a new tier above Opus — is also available; switch with /model fable.

Switching Models

Inside a session, use the /model command:

/model
# Select from available models

Fast Mode (Speed, Not a Different Model)

Fast mode is not a model switch. It runs the same Claude Opus 4.8 with a latency-optimized API configuration, delivering roughly 2.5x faster responses at higher per-token cost (about $10 input / $50 output per million tokens, versus the standard $5/$25). Quality and capabilities are identical — it is a speed-for-cost tradeoff, not a cheaper or weaker downgrade. Toggle it on by typing /fast and pressing Tab, or set it persistently in your user settings:

{
  "fastMode": true
}

Fast mode persists across sessions and is best for interactive work where latency matters more than cost (live debugging, rapid iteration). When you toggle it off with /fast again, you stay on Opus 4.8 — use /model to switch to a genuinely cheaper model like Claude Sonnet 4.6.

Setting a Default Model

In settings.json:

{
  "model": "claude-sonnet-4-6"
}

Or via environment variable:

export ANTHROPIC_MODEL=claude-sonnet-4-6

If your team optimizes for velocity and quality over cost, you can set "model": "claude-fable-5" as the default instead — subagents still auto-run on Opus/Sonnet/Haiku, so cost stays contained while the main loop gets maximum intelligence.

When to Use Each Model

Model	Use Case	Trade-off
Claude Fable 5 (/model fable)	Hardest multi-file refactorings, building apps from scratch, long-running tasks	Top capability; 2x Opus cost ($10/$50)
Claude Opus 4.8 (default)	Complex refactoring, architecture decisions, multi-file changes	Most capable below Fable, high token cost
Claude Sonnet 4.6	Quick edits, simple bug fixes, routine tasks	Cheaper (~$3/$15), slightly less capable
Claude Haiku 4.5	High-volume, trivial edits, batch tasks	Cheapest (~$1/$5), least capable

Fast mode is a separate axis from model choice: it speeds up whichever Opus 4.8 you are already on at a higher cost, rather than swapping to a smaller model. Reach for /model (Sonnet 4.6 / Haiku 4.5) when you want to save money, and for /fast when you want speed and quality together.

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.8 and Sonnet 4.6 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	--permission-mode acceptEdits, /config, or "defaultMode": "acceptEdits" in settings.json
Bypass Permissions	Skip all permission prompts	--dangerously-skip-permissions

To start every session in Accept Edits mode without passing the flag each time, set "defaultMode": "acceptEdits" in your settings.json.

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

Caution

MAX_THINKING_TOKENS is honored only on models other than Opus 4.8/4.7. On Opus 4.8 (the Claude Code default) thinking depth is governed by the effort level and this variable is ignored — except MAX_THINKING_TOKENS=0, which still disables thinking on any model.

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

# Persistent env-var values: low, medium, high (default), xhigh, max
export CLAUDE_CODE_EFFORT_LEVEL=medium

Inside a session, run /effort (or open the model picker and use the left/right arrows on the effort slider) to choose low, medium, high (the default on Opus 4.8), xhigh, max, or ultracode. Higher levels deliberate longer and burn more tokens; max sustains deep multi-step reasoning for genuinely hard problems, and ultracode sends xhigh to the model and has Claude orchestrate Dynamic Workflows (parallel subagents) for large tasks. Note that max and ultracode are session-only selections — CLAUDE_CODE_EFFORT_LEVEL accepts low, medium, high, xhigh, and max, but not ultracode.

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