Claude Code Stopped Asking Permission This Week

I opened a Claude Code session on Friday to fix a bug in a client's repo and noticed something was off about ten minutes in: it hadn't asked me for anything. Not "can I edit this file," not "can I run this command." It read three files, wrote a fix, ran the test suite, and told me it was done. On Tuesday, that same sequence would have stopped me four separate times.

Nothing broke. Anthropic flipped a default. On August 14, auto mode became the built-in starting mode for every Claude Code session on Pro, Max, and Team plans. If you use Claude Code and haven't touched your settings, your sessions changed under you this week whether you noticed or not.

What actually changed

Claude Code has always had a permission system. In the old default (Anthropic now calls it Manual mode), Claude stops and asks before most file edits, shell commands, or network calls. You read the diff, you hit approve, work continues. That's the mode most of us learned the tool on.

Auto mode replaces you with a second model. Anthropic calls it the classifier, and by default it runs on Sonnet 5 regardless of which model is doing your actual work. Before each tool call fires, the classifier looks at it and decides: routine, or does a human need to see this. Routine actions run immediately. Anything it flags as irreversible, destructive, or aimed outside your project gets kicked back to you as a normal prompt.

Same five actions, top to bottom: read a file, edit it, run tests, commit, push. Manual mode stops you at every single one. Auto mode runs the first four without a word and only stops you where it actually matters, like a push to a branch that looks like a deploy target.

Why Anthropic thinks this is safer, not riskier

My first reaction was the obvious one: fewer prompts sounds like less oversight. Anthropic's own data argues the opposite, and it's worth sitting with because it names a real habit I recognized in myself.

They ran a study with 1,053 paid testers, planting genuinely harmful actions in normal-looking sessions and measuring who caught them.

Thirteen point six percent. That's the number that reframed this for me. It's not that people are careless, it's that a permission prompt loses its meaning the two-hundredth time you see it. You stop reading the diff and start pattern-matching on "this looks like the last nine." Anthropic's testers approved 97% of prompts, which means the prompt had become theater long before the study measured it. A classifier that's actually reading the action every time, instead of skimming it the way a tired human does at 4pm, catches more of the real problems. I believe it, because I've caught myself rubber-stamping exactly like that.

What it still refuses to do, no matter what

The part that made me comfortable running this on a client repo is the default deny list, which doesn't bend for anyone's phrasing:

• Downloading and running code (curl | bash and its cousins)
• Sending anything from your repo to an external endpoint
• Production deploys and database migrations
• Force pushes, or any rewrite of remote history
• git reset --hard, git clean -fd, or anything else that discards uncommitted work
• Committing a change that would leak a secret when CI or a deploy pipeline actually runs it
• Disarming a safety flag, like a command run with --insecure

These sit ahead of the classifier's judgment call. Vague instructions like "clean this up" don't unlock them. If I actually want one of them, I have to say so directly: "force-push this branch" works, "tidy up the branch" doesn't. That distinction between general intent and stated intent is the whole safety model in one sentence, and it's the same discipline this course teaches for prompting anything agentic: say the specific thing, don't wave at it.

There's also a circuit breaker if the classifier gets it wrong repeatedly: three denials in a row, or twenty in one session, and Claude Code drops back to asking you for everything until you clear it.

What I set up before trusting it

Two changes, both in ~/.claude/settings.json, both took under five minutes.

First, I told it what "internal" means for my own work, since the classifier only trusts your current repo and its remotes by default. Everything else, including my other repos, reads as external until I say otherwise:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/kevgary and everything under it",
      "Trusted internal domains: *.claudecamp.ai"
    ]
  }
}

Second, I added one hard checkpoint of my own. Auto mode already allows pushes to the branch I'm working on, but I still want to see a pull request before it opens, every time, no exceptions:

{
  "permissions": {
    "ask": ["Bash(gh pr create *)"]
  }
}

That ask rule runs ahead of the classifier and can't be talked out of firing. It's the one line that turns "I trust the defaults" into "I trust the defaults, plus the one thing I specifically want eyes on."

The practical takeaway

If you've never opened a Claude Code settings file, you don't need to start now. The built-in defaults already lean conservative, force pushes and production deploys are blocked regardless of what you configure, and that's true whether you're shipping a side project or running client work. Run claude auto-mode config once to see exactly what's active in your session, and if a routine action keeps getting flagged, that's usually the classifier missing context about your setup, not a bug. Add it to environment and move on.

What actually changed this week isn't that Claude Code got more permissive. It's that the review moved from a person who stopped reading the diffs to a model that reads every one. Worth five minutes to see what it's checking before you let it run unattended on something that matters.