Claude Code YOLO Mode: Scripting Your Way Past the “Auto Mode Not Available” Wall
When Claude Code displays "Auto mode not available for this model," you can replicate its permissive behavior by scripting direct edits to the settings.json file, which controls tool permissions. This approach temporarily grants Claude unrestricted execution rights, bypassing confirmation prompts and restoring uninterrupted workflow during intensive refactoring sessions where constant approval dialogs break concentration.
Updated June 2026 to cover Auto mode GA, the classifier architecture, and a new script for tuning classifier false positives.
When Claude Code displays “Auto mode not available for this model,” you can replicate its permissive behaviour by scripting direct edits to the settings.json file, which controls tool permissions. This approach temporarily grants Claude unrestricted execution rights, bypassing confirmation prompts and restoring uninterrupted workflow during intensive refactoring sessions where constant approval dialogs break concentration. Since this post was first published, the situation has changed considerably. Auto mode went generally available across all paid plans and the underlying classifier architecture is now documented. This rewrite incorporates both the original YOLO script and a new classifier configuration script for the more common situation: Auto mode is available, but the classifier keeps blocking things it should not.
Claude Code has six permission modes that control how often it stops to ask you before acting, and they form a spectrum from maximally cautious to fully open.
| Mode | What runs without asking | Best for |
|---|---|---|
default | Reads only | Sensitive work, getting started |
acceptEdits | Reads, file edits, common filesystem commands | Iterating on code you will review after |
plan | Reads only | Exploring a codebase before changing it |
auto | Everything, with background classifier checks | Long tasks, reducing prompt fatigue |
dontAsk | Only pre-approved tools | Locked-down CI pipelines |
bypassPermissions | Everything without exception | Isolated containers and VMs only |
The original YOLO script in this post sets defaultMode to acceptEdits and clears the deny list. That is still valid and useful in the right context. It is now one of several options depending on your situation, and for most users on current paid plans it is no longer the first thing to reach for.
Auto mode and the classifier
Auto mode, available from Claude Code v2.1.83 and across all paid plans as of April 2026, replaces the per-action human prompt with a background classifier. Before each tool call executes, a separate Sonnet 4.6 model evaluates the pending action against your conversation context and either allows it or blocks it, with Claude receiving the block reason and attempting an alternative approach. The classifier trusts your working directory and your repo’s configured remotes, treating everything else as an external destination until you tell it otherwise.
Out of the box the classifier blocks downloading and executing code (the classic curl | bash pattern), sending sensitive data to external endpoints, production deploys and migrations, mass deletion on cloud storage, IAM or repo permission changes, modifications to shared infrastructure, irreversible destruction of files that existed before the session, and force pushes or direct pushes to main. It allows local file operations in your working directory, installing dependencies declared in lock files or manifests, reading .env and sending credentials to their matching API, read-only HTTP requests, and pushing to the branch you started on or one Claude created.
The critical design detail is that the classifier reads from your conversation transcript, not from arbitrary file content. Tool results are stripped before the classifier sees them, which means hostile content in a file Claude reads cannot manipulate the classifier directly. Your CLAUDE.md is included in what the classifier sees, so project instructions factor into its decisions. If the classifier blocks the same action three times consecutively, or twenty times total in a session, Auto mode pauses and Claude Code resumes prompting. Approving one action manually resets the consecutive counter and restores Auto mode. In non-interactive mode with the -p flag, repeated blocks abort the session entirely.
The right starting point for most people is to enable Auto mode first, either with claude --enable-auto-mode, by cycling to it with Shift+Tab, or by setting it as your default in ~/.claude/settings.json:
{
"permissions": {
"defaultMode": "auto"
}
} This setting must go in the user-level file, not in your repo’s .claude/settings.json. Claude Code deliberately ignores auto as a default in project-level settings so a checked-in repo cannot grant itself Auto mode. If the classifier keeps blocking routine operations, the problem is almost always that it is missing context about your infrastructure, and the fix is the configuration script below rather than bypassing Auto mode entirely. If Auto mode is unavailable because you are on Bedrock, Vertex, or Foundry, or running an older model version that does not support the classifier, the YOLO script is the right tool. If you are in a fully isolated container or VM and want to remove all friction with no safety net, bypassPermissions via --dangerously-skip-permissions is the explicit mode for that, though it will not start under root or sudo.
The YOLO script
This script writes directly to settings.json, setting defaultMode to acceptEdits, clearing the deny list, and whitelisting the full tool set. It takes a backup before writing and refuses to run a second time until you revert, which prevents silently losing your configuration on a repeated run. The effect is equivalent to what Auto mode does but without any classifier layer beneath it.
cat > ~/claude-yolo-mode.sh << 'EOF'
#!/usr/bin/env bash
# ============================================================
# claude-yolo-mode.sh
# Enable / disable Claude Code no-prompts mode via settings.json.
#
# Usage:
# bash claude-yolo-mode.sh # enable
# bash claude-yolo-mode.sh revert # restore previous settings
#
# ENABLE sets defaultMode=acceptEdits and clears the deny list
# so Claude can run any tool without asking for approval.
# A backup of your current settings is saved first.
#
# REVERT restores settings.json from the backup.
#
# Security note: in YOLO mode Claude can read, write, and delete
# files and run shell commands without prompting you. Only use
# this when you trust what you are asking Claude to do.
# ============================================================
set -euo pipefail
SETTINGS="$HOME/.claude/settings.json"
BACKUP="$HOME/.claude/settings.json.yolo-backup"
enable_yolo() {
if [ ! -f "$SETTINGS" ]; then
echo " $SETTINGS not found. Is Claude Code installed?"
exit 1
fi
if [ -f "$BACKUP" ]; then
echo " Backup already exists at $BACKUP"
echo " YOLO mode may already be on, or a previous revert failed."
echo " Run: bash claude-yolo-mode.sh revert"
exit 1
fi
echo " Backing up current settings to $BACKUP"
cp "$SETTINGS" "$BACKUP"
echo " Writing YOLO settings..."
python3 - "$SETTINGS" <<'PYEOF'
import json, sys
path = sys.argv[1]
with open(path) as f:
d = json.load(f)
if "permissions" not in d:
d["permissions"] = {}
d["permissions"]["defaultMode"] = "acceptEdits"
d["permissions"]["allow"] = [
"Bash", "Edit", "Write", "Read",
"WebFetch", "WebSearch", "Bash(*)"
]
d["permissions"]["deny"] = []
d["skipAutoPermissionPrompt"] = True
with open(path, "w") as f:
json.dump(d, f, indent=4)
print(" defaultMode -> acceptEdits")
print(" deny list -> cleared")
print(" allow list -> Bash(*), Edit, Write, Read, WebFetch, WebSearch")
PYEOF
echo ""
echo " YOLO mode ON. Open a new Claude Code window to pick up the change."
echo " When you are done: bash claude-yolo-mode.sh revert"
}
revert_yolo() {
if [ ! -f "$BACKUP" ]; then
echo " No backup found at $BACKUP"
echo " Either YOLO mode was never enabled or the backup was already restored."
exit 1
fi
echo " Restoring settings from backup..."
cp "$BACKUP" "$SETTINGS"
rm "$BACKUP"
echo ""
echo " Settings restored. Open a new Claude Code window to pick up the change."
}
case "${1:-enable}" in
enable) enable_yolo ;;
revert) revert_yolo ;;
*)
echo "Usage: bash claude-yolo-mode.sh [enable|revert]"
exit 1
;;
esac
EOF
chmod +x ~/claude-yolo-mode.sh bash ~/claude-yolo-mode.sh # enable
bash ~/claude-yolo-mode.sh revert # restore The classifier configuration script
This is the more common situation now that Auto mode is widely available. The classifier is blocking operations that are routine for your environment because it does not know your infrastructure. Pushing to your GitHub org, writing to a company bucket, or hitting an internal API all look like potential exfiltration until you tell it otherwise. This script walks through your infrastructure interactively and writes an autoMode.environment block to your user settings file. It also exposes show, defaults, and reset subcommands so you can inspect and undo what it writes.
cat > ~/claude-configure-automode.sh << 'EOF'
#!/usr/bin/env bash
# ============================================================
# claude-configure-automode.sh
# Configure the Claude Code Auto mode classifier with your
# trusted infrastructure so it stops blocking routine operations.
#
# Usage:
# bash claude-configure-automode.sh # interactive setup
# bash claude-configure-automode.sh show # print current effective config
# bash claude-configure-automode.sh defaults # print classifier defaults
# bash claude-configure-automode.sh reset # remove autoMode block from settings
#
# This writes to ~/.claude/settings.json only.
# It does not touch project-level settings files.
# ============================================================
set -euo pipefail
SETTINGS="$HOME/.claude/settings.json"
ensure_settings_exists() {
if [ ! -f "$SETTINGS" ]; then
echo " $SETTINGS not found. Is Claude Code installed?"
exit 1
fi
}
show_config() {
ensure_settings_exists
if command -v claude &>/dev/null; then
echo " Effective classifier configuration:"
claude auto-mode config 2>/dev/null || echo " (claude auto-mode config requires Claude Code v2.1.83+)"
else
echo " claude CLI not found in PATH. Printing raw settings instead:"
python3 -c "
import json, sys
with open('$SETTINGS') as f:
d = json.load(f)
am = d.get('autoMode', {})
if am:
print(json.dumps({'autoMode': am}, indent=2))
else:
print(' No autoMode block found in settings.')
"
fi
}
show_defaults() {
if command -v claude &>/dev/null; then
echo " Classifier defaults:"
claude auto-mode defaults 2>/dev/null || echo " (claude auto-mode defaults requires Claude Code v2.1.83+)"
else
echo " claude CLI not found in PATH. Install or update Claude Code to use this command."
fi
}
reset_config() {
ensure_settings_exists
python3 - "$SETTINGS" <<'PYEOF'
import json, sys
path = sys.argv[1]
with open(path) as f:
d = json.load(f)
if "autoMode" in d:
del d["autoMode"]
with open(path, "w") as f:
json.dump(d, f, indent=4)
print(" autoMode block removed. Classifier will use defaults.")
else:
print(" No autoMode block found. Nothing to remove.")
PYEOF
}
interactive_setup() {
ensure_settings_exists
echo ""
echo " Claude Code Auto Mode: Classifier Configuration"
echo " ================================================"
echo ""
echo " This adds trusted infrastructure context to the classifier"
echo " so it stops blocking routine operations in your environment."
echo ""
echo " Press Enter to skip any field you do not need."
echo ""
read -rp " Your organisation or project name: " ORG_NAME
read -rp " Primary use case (e.g. software development, infra automation): " USE_CASE
read -rp " Source control org URL (e.g. github.com/your-org): " SCM_URL
read -rp " Cloud provider(s) (e.g. AWS, GCP, Azure): " CLOUD
read -rp " Trusted buckets or storage paths (e.g. s3://your-bucket): " BUCKETS
read -rp " Trusted internal domains (e.g. *.internal.yourco.com): " DOMAINS
read -rp " Key internal services (e.g. Jenkins at ci.yourco.com): " SERVICES
read -rp " Additional context (e.g. regulated industry, compliance requirements): " EXTRA
python3 - "$SETTINGS" \
"$ORG_NAME" "$USE_CASE" "$SCM_URL" "$CLOUD" \
"$BUCKETS" "$DOMAINS" "$SERVICES" "$EXTRA" <<'PYEOF'
import json, sys
path = sys.argv[1]
org = sys.argv[2].strip()
use = sys.argv[3].strip()
scm = sys.argv[4].strip()
cloud = sys.argv[5].strip()
buck = sys.argv[6].strip()
dom = sys.argv[7].strip()
svc = sys.argv[8].strip()
extra = sys.argv[9].strip()
env_entries = []
if org or use:
line = "Organisation: " + org
if use:
line += ". Primary use: " + use
env_entries.append(line)
if scm:
env_entries.append("Source control: " + scm + " and all repos under it")
if cloud:
env_entries.append("Cloud provider(s): " + cloud)
if buck:
env_entries.append("Trusted buckets: " + buck)
if dom:
env_entries.append("Trusted internal domains: " + dom)
if svc:
env_entries.append("Key internal services: " + svc)
if extra:
env_entries.append("Additional context: " + extra)
with open(path) as f:
d = json.load(f)
existing_am = d.get("autoMode", {})
existing_env = existing_am.get("environment", [])
merged_env = existing_env.copy()
for entry in env_entries:
if entry not in merged_env:
merged_env.append(entry)
if "autoMode" not in d:
d["autoMode"] = {}
d["autoMode"]["environment"] = merged_env
with open(path, "w") as f:
json.dump(d, f, indent=4)
print("")
print(" autoMode.environment written with " + str(len(merged_env)) + " entries:")
for e in merged_env:
print(" - " + e)
PYEOF
echo ""
echo " Settings saved to $SETTINGS"
echo " Open a new Claude Code window to pick up the changes."
echo " Run 'bash claude-configure-automode.sh show' to review the effective config."
echo " Run 'bash claude-configure-automode.sh reset' to remove the autoMode block."
echo ""
echo " If specific patterns are still blocked, add custom allow rules to"
echo " the autoMode.allow array in $SETTINGS."
echo " See: https://code.claude.com/docs/en/auto-mode-config"
}
case "${1:-interactive}" in
interactive) interactive_setup ;;
show) show_config ;;
defaults) show_defaults ;;
reset) reset_config ;;
*)
echo "Usage: bash claude-configure-automode.sh [interactive|show|defaults|reset]"
exit 1
;;
esac
EOF
chmod +x ~/claude-configure-automode.sh The four commands are straightforward. The interactive setup asks about your org name, source control URL, cloud provider, trusted buckets, internal domains, key services, and any additional context, then writes an autoMode.environment array to ~/.claude/settings.json. show prints your effective classifier configuration via claude auto-mode config. defaults prints the full built-in block and allow rule lists so you can safely customise them. reset removes the autoMode block entirely and returns the classifier to its defaults.
bash ~/claude-configure-automode.sh # interactive setup
bash ~/claude-configure-automode.sh show # effective config
bash ~/claude-configure-automode.sh defaults # built-in rule lists
bash ~/claude-configure-automode.sh reset # remove autoMode block The classifier reads the environment entries as natural language, not as regex or glob patterns. Write them the way you would describe your infrastructure to a new engineer joining the team. A configured settings file looks like this:
{
"permissions": {
"defaultMode": "auto"
},
"autoMode": {
"environment": [
"Organisation: Acme Corp. Primary use: software development",
"Source control: github.com/acme-corp and all repos under it",
"Cloud provider(s): AWS",
"Trusted buckets: s3://acme-build-artifacts",
"Trusted internal domains: *.internal.acme.com",
"Key internal services: Jenkins at ci.acme.com"
]
}
} If specific patterns are still being blocked after adding environment context, the autoMode block supports two additional arrays. autoMode.allow adds exceptions to the block rules for patterns your infrastructure already guards against, and autoMode.soft_deny adds block rules for risks specific to your environment that the defaults do not cover. There is a significant trap here: setting either array replaces its entire default list rather than appending to it. If you set soft_deny with a single custom entry without first copying in the full defaults, you silently discard all of Anthropic’s built-in block rules including force push protection, mass deletion blocks, and exfiltration detection. Always run claude auto-mode defaults first, copy the full lists into your settings file, and then add your rules. For actions that must be blocked regardless of user intent or any configuration, use permissions.deny in managed settings, which runs before the classifier and cannot be overridden by developer-level settings.
The comparison
The YOLO script and Auto mode both eliminate the per-action approval prompt. The difference is what happens behind that removed gate.
| YOLO script | Auto mode | |
|---|---|---|
| Mechanism | Writes directly to settings.json | Classifier evaluates each tool call at runtime |
| Human gate removed | Yes | Yes |
| Safety layer retained | No | Yes (classifier) |
| Prompt injection resistance | No | Yes (tool results stripped from classifier input) |
| Available on Bedrock/Vertex/Foundry | Yes | No |
| Requires specific model version | No | Yes (Sonnet 4.6, Opus 4.6 or later) |
| Survives session restart | Yes, until reverted | Depends on defaultMode setting |
| Backup and revert mechanism | Built in | reset command in classifier script |
Auto mode with classifier configuration is the right default for most users on supported plans because it keeps a safety layer in place while removing friction. Auto mode with custom allow entries handles cases where the classifier repeatedly flags a specific known-safe pattern that environment context alone does not resolve. The YOLO script remains the right tool when Auto mode is unavailable because of the provider, the model version, or an admin policy, and it is also reasonable for isolated containers or throwaway environments where you have already accepted the risk profile explicitly. bypassPermissions is for fully isolated VMs and containers with no external access, and it is not a production tool.
The broader point
The permission model in Claude Code exists because an AI agent that can freely execute shell commands in your home directory is a meaningful risk surface. The question is not whether to have a gate, but what kind and where. The YOLO script removes the gate entirely. Auto mode moves the gate from you to a classifier. Classifier configuration tells the classifier what is inside your fence so it stops treating your own infrastructure as hostile. These are different tools for different situations, and understanding which one fits your context is more useful than defaulting to the most permissive option available. Revert or reset when the task is done, and the scripts in this post are built around that assumption.
Andrew Baker is Group CIO at Capitec Bank. He writes about AI tooling, cloud infrastructure, and engineering culture at andrewbaker.ninja.