Simon Willison wrote up Claude Code’s auto mode last week, and it’s worth unpacking in some depth. On the surface it looks like a minor configuration addition. Underneath, it represents a more complete answer to a question the tool has been implicitly asking since launch: how much autonomy should an AI coding agent have, and how should that vary by context?
To understand why auto mode matters, you need to understand what the existing two modes were doing and where they fell short.
The Two Extremes
Claude Code shipped with default mode and bypassPermissions. The names describe the behavior pretty well, but the gap between them is wider than it sounds.
In default mode, every tool call that touches something consequential stops and waits for your approval. File writes, bash commands, anything that can’t be trivially undone: all of it surfaces a prompt before execution. This is the right behavior for interactive sessions where you’re sitting in front of the terminal and can evaluate each proposed action. But it does not compose well with automation. If you’re running Claude Code from a script, or wiring it into a CI pipeline, or using -p for non-interactive invocations, default mode means the process blocks indefinitely on prompts that nobody is there to answer.
bypassPermissions solves the automation problem by removing all permission checks. Anthropic’s documentation has been clear that this mode exists specifically for sandboxed environments where the runtime itself provides the safety boundary. You run it in a container with no network access and a disposable filesystem, and the permission layer that Claude Code would otherwise provide is redundant because the environment is already constrained. The expectation is that you never use bypassPermissions on a machine you care about.
Between these two options, the practical situation for many developers looked like this: interactive work in default mode, and automation requiring either a proper sandbox setup (reasonable but operationally heavy) or running with bypassPermissions on a machine that isn’t actually sandboxed (not reasonable, but easier to do by accident than it should be).
What Auto Mode Does
The auto permission mode is configured in ~/.claude/settings.json or in a project-level .claude/settings.json:
{
"permissions": {
"defaultMode": "auto"
}
}You can also pass it at invocation time:
claude --permission-mode auto -p "run the test suite and fix any failures"In this mode, Claude Code applies its own judgment about which operations require explicit approval and which do not. Read operations proceed without prompting. Tool calls that modify state, touch files outside the working directory, or run commands with potentially broad effects still surface for review. The heuristics are not arbitrary: they map onto the same distinction between reversible and irreversible operations that the explicit permissions.allow and permissions.deny configuration uses.
Here is how that looks in a concrete settings.json that approximates what auto mode provides by default:
{
"permissions": {
"allow": [
"Read(*)",
"Bash(git log *)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(npm test)",
"Bash(npm run lint)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(curl *)",
"Bash(wget *)"
]
}
}Auto mode does this categorization implicitly, without requiring you to enumerate rules yourself. For read-heavy exploration and test runs, it runs uninterrupted. For writes and shell operations with side effects, it pauses.
Why This Matters for Automation
The practical value is in the scenarios that live between fully supervised and fully autonomous. Consider a script that runs Claude Code on a pull request to generate a code review summary, or a Discord bot command that invokes Claude Code to check a config file and report back. These are genuinely non-interactive, but they are also not running in a hardened sandbox. The developer running them knows the context, the files involved are bounded, and the risk profile is nothing like giving bypassPermissions to an agent running against a production repo.
Auto mode gives these workflows a reasonable default. The agent can read files, diff branches, run the test suite, and compose its response without stopping to ask. A command that tries to modify files or run an unfamiliar shell command surfaces a prompt that, in a non-interactive context, becomes a logged rejection rather than a hanging process. You get the automation benefit without accepting the full bypassPermissions risk surface.
For my own use building Discord bots, this is the mode that makes the most sense for Claude Code integrations that respond to commands. A user asking the bot to summarize recent test failures doesn’t need the bot to pause mid-task; they also should not be implicitly authorizing arbitrary filesystem writes.
The Permission Model as Risk Communication
There’s a subtler point worth making about how these three modes work together. The existence of bypassPermissions without an intermediate option created a false binary: either Claude Code behaves safely for interactive use, or it’s in the mode designed for throwaway sandboxes. Developers who needed some degree of automation without a proper sandbox had to either accept the friction of default mode or quietly reach for bypassPermissions in contexts it was not designed for.
The Anthropic model card and usage policies describe a general principle of keeping humans appropriately in the loop for consequential AI actions. bypassPermissions doesn’t violate this principle when used correctly, but its binary nature created pressure toward overuse. auto mode makes the risk communication more granular: it says “Claude Code can proceed with low-risk operations autonomously, but the boundary is explicit and consistent.”
This is a familiar pattern in security-conscious systems. File permissions in Unix distinguish read from write from execute for exactly this reason: you want to grant minimal capabilities, not a binary between full access and no access. Claude Code’s permission model is evolving toward the same graduated approach.
Comparison with Other Tools
Cursor handles autonomy through a different mechanism: its agent mode has configurable step limits and asks for confirmation when it wants to run terminal commands, but there is no explicit permission mode concept. Aider uses --yes to skip confirmation prompts entirely, which is closer to bypassPermissions than to a graduated model. GitHub Copilot’s agent mode in VS Code shows a running list of proposed actions and requires a single final approval, which is closer to Claude Code’s default but less granular.
None of these have the equivalent of bypassPermissions as a documented, officially-supported mode with explicit guidance about safe use contexts. That reflects something about Claude Code’s design intent: it is built to be scripted and automated, and the permission model has to serve that use case directly rather than treating automation as an edge case.
Configuration Worth Knowing
A few specifics that are useful in practice. The permissions.allow and permissions.deny arrays support glob-like patterns on tool names and their arguments. Bash commands can be filtered by their content:
{
"permissions": {
"allow": ["Bash(git *)", "Bash(npm test)"],
"deny": ["Bash(git push *)"],
"defaultMode": "auto"
}
}This lets you build on top of auto mode’s defaults with additional project-specific constraints. A repository where you never want Claude Code to push to remote, for instance, can encode that as a deny rule that overrides whatever auto mode would otherwise allow.
Project-level settings in .claude/settings.json take precedence over user-level settings in ~/.claude/settings.json, which means teams can commit a settings file that enforces consistent constraints regardless of individual developer configuration.
The Takeaway
Auto mode is not a dramatic feature, but it fills a real gap. The default / bypassPermissions binary was pushing developers toward using the more permissive mode in contexts where they did not actually want or need full bypass. Having a third option that approximates safe-by-default autonomous operation makes the overall model more honest about the risk surface at each level.
For anyone already using Claude Code in scripts or automated workflows, it is worth replacing bypassPermissions with auto and evaluating whether the remaining permission prompts point at operations you genuinely want to review. They probably do.