How Claude Code Auto Mode Replaced Permission-Skipping in My Workflow

There's a gap most plan-and-execute workflows hit eventually. Planning quality is high, execution safety is low. You spend a morning building a phase-by-phase plan doc with clear acceptance criteria and clean dependencies. Then you start the implementation run and have to choose between two bad options: approve every tool call by hand, or pass --dangerously-skip-permissions and monitor the terminal anyway, because nothing else is between Claude and whatever it decides to do next.

Claude Code's Auto Mode closes that gap. Instead of removing the permission layer, it routes every tool call through a permission gate that decides what's safe to run, scoped by default to the working directory and the current repo's remotes. The plan doc keeps doing the architectural thinking. The gate takes over the runtime boundary.

What --dangerously-skip-permissions Removes#

--dangerously-skip-permissions does what it advertises. It removes the entire approval layer. Every shell command, file write, network call, and git operation runs without asking. That's the appeal: zero interruptions. It's also the cost. The flag is a sandbox tool. Run it inside a disposable container, a fresh VM, or a scratch worktree, and you're fine. Run it against your real repo on your real laptop, and the safety story becomes "hope nothing weird happens."

The speed was useful. The price of using that speed responsibly was monitoring every command in the terminal, which defeats the point of running an autonomous execution phase at all.

Auto Mode Keeps the Gate, Without the Prompts#

Auto Mode takes a different approach. Every tool call gets classified. Anything irreversible, destructive, or aimed outside your environment gets blocked. Routine work flows through without a prompt, and risky work stops before it runs.

Out of the box, Auto Mode trusts only the working directory and the current repo's configured remotes. That default matters for plan-and-execute work:

• It won't push to a repo that isn't part of the trusted environment
• It won't write to a cloud bucket that isn't on the trust list
• It won't auto-commit, force push, or run curl | bash style commands
• It won't wander outside the working directory to touch unrelated files

When I kick off a planned implementation, the agent is doing work inside one specific repo. Auto Mode's default trust set defines "inside" exactly the way I'd describe it to a teammate. That alignment is the whole reason this works.

Telling the Classifier What "Inside" Means#

Most solo projects need no extra setup. The defaults already know about the repo and its configured remotes, so cloning the repo and running Claude Code inside it is enough.

The configuration knob exists for cases where the defaults are too narrow. If you regularly write build artifacts to a specific S3 bucket, or pull dependencies from your company's internal artifact registry, those destinations look external to Auto Mode and get blocked. You expand trust with the autoMode.environment array in your settings:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/your-org and all repos under it",
      "Trusted cloud buckets: s3://your-build-artifacts",
      "Internal services: artifacts.yourcompany.com, ci.yourcompany.com"
    ]
  }
}

A few things worth knowing:

• Entries are prose, not regex. Write them the way you'd describe your infrastructure to a new hire
• The literal string "$defaults" splices in the built-in entries, so working-directory-and-remotes trust stays in place on top of whatever you add
• Auto Mode reads its config from ~/.claude/settings.json and .claude/settings.local.json, but never from a project's checked-in .claude/settings.json. A cloned repo can't grant itself extra trust
• Run claude auto-mode config to print the effective rules with $defaults expanded in place, so the actual policy is inspectable

For most of my work I add nothing. The defaults cover it.

Pinning Auto Mode as the Project Default#

The piece that turned this from "feature I tried" into "feature I rely on" was making Auto Mode the default for projects where I want full autonomy during the execution phase. You can pass the mode on each invocation, or set it once in .claude/settings.json for a project or ~/.claude/settings.json globally.

Per-project is what I use most. Once a plan doc is solid, I want the implementation phases to run without prompts inside that repo, but I don't want every random scratch project to inherit the same posture by default.

Combined with the phase-based execution from my ai-workflow plugin, the loop is now:

1. Build the plan doc with token-aware phases
2. Iterate on the plan until it's tight
3. Run the implementation phases
4. Inspect the diffs, run tests, commit

Step three is what --dangerously-skip-permissions never made workable. With Auto Mode pinned as the project default, the implementation phases run without prompts and without a flag I'd have to remember to pass on every invocation.

What Hasn't Changed#

Auto Mode's gate runs on Claude's own judgment. That makes the boundary probabilistic, which is a different thing from what a true sandbox guarantees. An AI-driven gatekeeper is not the same thing as a kernel-level sandbox, and treating it like one would be a mistake.

So I still do the things I'd do regardless of which permission mode I'm running. Commit often. Keep secrets out of the working directory by using Doppler. Don't point any agent at production from a laptop. None of that goes away.

What changes is the day-to-day cost of letting the agent execute autonomously. Before, the cost was sustained attention on the terminal. Now the cost is a one-time decision about which destinations to trust, made once per project and inspectable via claude auto-mode config.

A Quick Note on Availability#

Auto Mode is available on Max, Team, Enterprise, and API plans through the Anthropic API. As of May 2026 it's not available on Pro, Bedrock, Vertex, or Foundry — Anthropic adjusts plan availability over time, so check code.claude.com/docs/en/auto-mode for the current list before you plan around it. If your account doesn't see the option, the plan tier is the most likely reason.

Plan-and-Execute, With a Real Gate#

Planning earns its keep when the execution phase that follows can run unattended without giving up safety. --dangerously-skip-permissions broke that contract, because "unattended" came with caveats nobody wanted to think about. Auto Mode keeps the contract by putting a permission check between Claude and every tool call, with a trusted environment that I configure once and inspect when I want to.

For projects where I want full autonomy during execution, Auto Mode is now the project default. The implementation phases finish faster because nothing's blocking on a human prompt. The work finishes safer because Auto Mode is stopping the calls I'd stop by hand.