Back to Blog

Claude Code Makes Auto Mode the Default: Decide Before August 14

Claude Code makes auto mode the default on Pro, Max and Team from August 14 and adds cross-session messaging and self-hosted runners. What a team should decide first.

Umut Korkmaz

Published: 4 min read

Anthropic's Claude Code week 32 digest covers August 3–7 and releases v2.1.220 through v2.1.224. Sessions can now message each other, cloud sessions can run on your own infrastructure, and auto mode becomes the default permission mode for new sessions on Pro, Max and Team plans starting August 14. That last one looks like a settings change, but it changes who approves what your agent does, and it lands in six days.

Auto mode by default moves the approval step to a model

Manual mode asks before most edits, shell commands and network access. In auto mode, a separate classifier model reviews those actions instead of you. Per the permission modes docs, it blocks anything that goes beyond your request, targets infrastructure it does not recognize, or looks driven by hostile content Claude read. The default block list includes download-and-execute like curl | bash, sending sensitive data to external endpoints, production deploys and migrations, force pushes, and granting IAM or repo permissions. Local file work in the working directory, installing dependencies declared in your lock files or manifests, and read-only HTTP requests are allowed.

Per the digest, if you set a default mode yourself, it stays unless you accept a one-time switch prompt, and a default your organization manages does not change. And on those plans the classifier calls no longer count toward usage limits. The docs are blunt: auto mode reduces prompts but does not guarantee safety.

What I would decide before August 14

The worst outcome is a team drifting into auto mode because nobody chose. On Monday I would settle three things.

  • Pick the default on purpose. If your team should stay on Manual, set permissions.defaultMode to default in managed settings, so it does not flip. Administrators can also turn auto mode off organization-wide with permissions.disableAutoMode set to "disable".
  • Check branch protection. In auto mode, pushing to any branch of the current repository, including the default branch, runs without a prompt unless the content trips a block rule. Deploy-target branches like production or gh-pages are judged separately. The remote's own branch protection still applies, so make sure it actually exists.
  • Put hard lines in rules, not chat. The classifier treats "don't push" in conversation as a block signal, but it re-reads that from the transcript, and context compaction can drop the message. For a hard guarantee, the docs point to a deny rule.

For a repo that touches payments, I would keep a human checkpoint on pushes, since explicit ask rules still prompt in auto mode:

{
  "permissions": {
    "ask": ["Bash(git push *)"]
  }
}

Also run claude auto-mode defaults to read the full rule lists, and list trusted repos, buckets and services in autoMode.environment. Everything beyond the working directory and the remotes configured when the session started counts as external, so routine work that touches it can get blocked.

Sessions can now talk to each other

With v2.1.224 on macOS and Linux, Claude finds your other sessions with ListAgents and sends text with SendMessage, either because you asked or on its own when a change in one session affects what another is doing. What crosses over is text Claude writes, never your conversation history or files, and /list-agents shows which sessions are reachable.

I run several coding agents in parallel every day, and the human usually ends up as the message bus between them. This removes some of that, but it also opens a new input channel, so it is good that since v2.1.222 the classifier checks each SendMessage in auto mode before dispatch, per the changelog. I would still treat an incoming message as a hint to verify, not an order.

Self-hosted runners answer "it needs our network"

Self-hosted environments, in public beta on Team and Enterprise, run Claude Code cloud sessions on your own machines or containers through claude self-hosted-runner. When someone picks that environment while starting a session from claude.ai, the mobile or desktop apps, or claude --cloud, the session runs inside your network with access to internal services. An Owner has to turn on Allow self-hosted environments first.

Per the quickstart, runner hosts are Linux or macOS, need outbound HTTPS to api.anthropic.com, claude.ai and your git host, and clone with whatever git credentials the host already has. The environment secret is shown once and expires after 365 days, and a runner exits by design when its sessions finish, so production needs an orchestrator. Treat these hosts like CI runners: scoped credentials, controlled egress, a fresh filesystem per restart.

Smaller changes worth reading

  • Worktree isolation now also blocks Bash commands and git redirects that reach the main checkout, including from subagents.
  • A Bash command can no longer hide part of itself from permission checks, and tab or invisible-Unicode padding no longer hides text in the approval dialog.
  • A repository's checked-in settings can no longer turn on Remote Control auto-connect.

My take

Auto mode is a reasonable default for most day-to-day work, and the block list is more considered than a blanket allow. But it is a trust decision that belongs to whoever owns the repo, not to a prompt someone clicks through. Pin the default, confirm branch protection, move real boundaries into rules, and treat runner hosts as production infrastructure.

Sources

Primary references used for this post.

  1. code.claude.com/docs/en/whats-new/2026-w32 (opens in a new tab)
  2. code.claude.com/docs/en/permission-modes (opens in a new tab)
  3. code.claude.com/docs/en/self-hosted-environments-quickstart (opens in a new tab)
  4. code.claude.com/docs/en/changelog (opens in a new tab)

About the author

Umut Korkmaz

Lead Software Engineer

I'm a senior software engineer in Istanbul. Here I write about the tools and releases I've shipped to production myself, and what they taught me along the way.

Picked by shared topics.