Stop the Claude YOLO – Settings.json

The "YOLO Mode" Problem

Too many developers are running Claude Code with --dangerously-skip-permissions or tapping "approve all" on every prompt. That flag exists for a reason—the word "dangerously" is right there in the name. We’ve seen Claude accidentally delete project files, overwrite .env secrets, run rm -rf in the wrong directory, and execute sudo commands that modified system files. A proper settings.json file lets you work at full speed without any of that risk.

What This Guide Covers

• Where your settings.json file lives (Mac, Windows, & Linux)
• The difference between user, project, and local settings
• A copy-and-paste safe settings.json you can use today
• What every rule does and why it’s there
• How to customize it for your specific stack
• The commands you should never auto-approve
• How to disable bypass permissions mode entirely

Step 1: Find Your Settings File

Claude Code reads settings from a hierarchy of files. For your global defaults, you want the user settings file:

• macOS & Linux: ~/.claude/settings.json
• Windows (PowerShell): %USERPROFILE%\.claude\settings.json
• WSL: ~/.claude/settings.json (same as Linux — it’s your WSL home directory)

Don’t have a ~/.claude/ directory yet? Create it: mkdir -p ~/.claude (Mac/Linux) or mkdir "$env:USERPROFILE\.claude" (Windows PowerShell). Claude Code creates this automatically on first run, but you can set it up ahead of time.

Step 2: Understand the Hierarchy

Claude Code merges settings from multiple files. Higher-priority files override lower ones. Here’s the order (highest priority first):

Priority	File	Purpose
1 (highest)	managed-settings.json	Enterprise/admin policies. Can’t be overridden.
2	CLI flags	Temporary per-session overrides.
3	.claude/settings.local.json	Your personal project overrides (gitignored).
4	.claude/settings.json	Shared project settings (committed to git).
5 (lowest)	~/.claude/settings.json	Your global user defaults. This is what we’re editing.

Key insight: Rules merge across files—they don’t replace. If your user settings allow Bash(git:*) and your project settings add Bash(npm run test:*), both rules apply. Within a single file, evaluation order is always: deny → ask → allow. Deny rules always win.

Step 3: The Safe Settings File

Copy and paste this into your ~/.claude/settings.json. It auto-approves common safe development commands while blocking anything that could damage your system, leak secrets, or modify files outside your project.

🚫 DENY Rules — Always Blocked

These are evaluated first and override everything else, even allow rules. 101 rules across 5 categories:

• Destructive System Commands: rm -rf, sudo, su, chmod 777, chown, shutdown, reboot, halt, poweroff, init, mkfs, fdisk, dd, mount/umount, eval, exec
• Network & Remote Access: ssh, scp, rsync, sftp, ftp, nc/ncat/netcat, nmap, telnet, iptables, ufw, curl|bash, wget|bash
• System-Level Package Installs: brew install, apt install, yum install, npm install -g, pip install
• Destructive Git Operations: git push, git reset --hard, git clean -f
• Secrets & Credentials: .env, .pem, .key, id_rsa — read, write, and edit all blocked

✅ ALLOW Rules — Auto-Approved

162 rules covering common safe development operations, organized by category:

• File Operations: Read, write, and create files within your project
• Safe Git: git status, git diff, git add, git commit, git log, git branch, git checkout — push/reset/clean stay in deny
• Shell Utilities (read-only & safe ops): ls, cat, grep, find, pwd, echo, which
• JavaScript / Node Ecosystem: npm run, npx, node, yarn (non-global installs)
• Python Ecosystem: python, pytest, pip install -r (requirements file installs only)
• Rust, Go, & Build Tools: cargo build, go build, make
• Safe File Permissions & Cleanup: chmod with non-777 patterns

🔒 CRITICAL: Bypass Mode Disabled

The settings file explicitly sets "bypassPermissionsMode": false and "dangerouslySkipPermissions": false. This prevents any session-level override from enabling YOLO mode, even if someone runs Claude Code with the flag directly.

Understanding the Patterns

Every rule in the file follows a pattern format: Bash(command:*) for shell commands, Read(*) for file reads, Write(*) for file writes. The asterisk is a wildcard that matches any arguments following the prefix.

Why we don’t allow Bash(*): Allowing Bash(*) means Claude can run any shell command—it bypasses all deny rules. Even with deny rules in place, a wildcard allow creates ambiguity and race conditions in rule evaluation. Always use specific patterns rather than wildcards for shell access.

Customize for Your Stack

The provided file covers the most common development stacks. To add rules for your specific environment, add them in the "allow" array. Examples:

• Ruby/Rails: Add Bash(bundle exec:*), Bash(rails:*)
• Docker: Add Bash(docker build:*), Bash(docker-compose up:*)
• AWS CLI (read-only): Add Bash(aws s3 ls:*), Bash(aws describe:*)

Pro Tip: Use Project-Level Settings Too. For project-specific tools, add a .claude/settings.json in your repo root. Rules merge—your project additions stack on top of your global safe defaults. This way teammates get consistent permissions without overwriting your personal config.

Install It (60 Seconds)

1. Open your terminal
2. Create the directory (if needed): mkdir -p ~/.claude
3. Download the settings.json file: ⬇ Download settings.json — unzip and move the file to ~/.claude/settings.json
4. Restart Claude Code
5. Verify with /permissions: Run this command inside Claude Code to confirm your deny and allow rules are active

Never Auto-Approve These

Regardless of what project you’re on, these commands should always require human approval:

• rm -rf — especially with paths containing variables
• sudo or su — any privilege escalation
• Any command piped to bash or sh from a network source
• git push --force or git reset --hard
• Any read or write to .env, .pem, .key, or SSH key files
• Global package installs (npm install -g, pip install outside a venv)

Frequently Asked Questions

What is Claude Code’s settings.json and why do I need it?

The settings.json file is Claude Code’s permission configuration—it defines which shell commands, file operations, and system actions Claude can run automatically versus which ones require your explicit approval. Without it, Claude either asks about everything (slow) or—worse—you approve everything blindly (risky). A well-configured settings.json gives you speed and safety at the same time.

What is YOLO mode in Claude Code and how do I disable it?

YOLO mode refers to running Claude Code with the --dangerously-skip-permissions flag or enabling dangerouslySkipPermissions: true in settings, which bypasses all permission checks. The safe settings.json in this guide explicitly sets both bypassPermissionsMode and dangerouslySkipPermissions to false, preventing any accidental or intentional bypass of the permission system.

Will these settings slow down my Claude Code workflow?

No—the 162 allow rules cover the vast majority of normal development tasks: file reads/writes, standard git operations (status, diff, add, commit, log), Node/Python/Rust/Go build commands, and safe shell utilities. You’ll only see approval prompts for genuinely risky operations, which is exactly when you want to be asked.

How do I add rules for my specific tech stack?

Add entries to the "allow" array using the pattern format Bash(command-prefix:*). For example, Ruby developers add Bash(bundle exec:*) and Bash(rails:*). For project-specific rules, add a .claude/settings.json file to your repo root—rules merge, so your global safe defaults remain intact.

What happens if Claude tries a blocked command?

Claude Code will surface the permission request to you rather than executing automatically. You can approve it one-time, add it to your allow list if it’s a legitimate recurring need, or deny it. The deny rules cannot be overridden by Claude—only by you manually editing the settings file.