DEV Community

Bill Wilson
Bill Wilson

Posted on

Claude Code Auto Mode: Never Let It Touch Production Without Reading This

Last week, Claude Code deleted 2.5 years of production data with a single Terraform command. It hit the front page of Hacker News. Tom's Hardware picked it up. Medium posts started appearing within hours.

Today, Anthropic is shipping Auto Mode - the feature that lets Claude Code execute commands without asking for confirmation.

Let that sink in for a second.

The AI that just demonstrated it can wipe a production database is getting a mode that removes the "are you sure?" prompt. If you're running Claude Code anywhere near production infrastructure, this guide is the difference between a productive Tuesday and an incident postmortem.

What Actually Happened

The details matter. A developer was using Claude Code to manage Terraform infrastructure. Claude Code decided to run terraform destroy on a resource, and the developer confirmed the action. The result: 2.5 years of production data, gone.

This wasn't a bug in Claude Code. It worked exactly as designed. The AI identified what it thought was the correct action, presented it to the user, the user confirmed, and the command executed. The problem is that "correct" from Claude's perspective and "correct" from a business perspective are very different things.

With Auto Mode, that confirmation step disappears. Claude Code makes the decision AND executes it.

The Four Layers of Protection You Need

Auto Mode isn't inherently dangerous - it's dangerous without boundaries. Here are the four layers every team should implement before enabling it.

Layer 1: Terraform Delete Protection

This is the most immediate fix. If Claude Code can't destroy resources, the worst-case scenario drops from "data loss" to "unnecessary resource creation" (which costs money but is recoverable).

# In every critical resource block
resource "aws_db_instance" "production" {
  # ... your config ...

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket" "user_data" {
  # ... your config ...

  lifecycle {
    prevent_destroy = true
  }
}
Enter fullscreen mode Exit fullscreen mode

This is one line per resource. If Claude Code - or any tool - tries to terraform destroy a protected resource, Terraform itself blocks the operation. The AI never gets the chance to delete anything.

Do this today. Right now. Before you finish reading this article. Every production database, every S3 bucket with user data, every stateful resource gets prevent_destroy = true.

Layer 2: AWS Permission Boundaries

Claude Code runs with whatever AWS credentials are in the environment. If those credentials can delete RDS instances, Claude Code can delete RDS instances. In Auto Mode, it might.

Create a permission boundary that explicitly denies destructive operations:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDestructiveActions",
      "Effect": "Deny",
      "Action": [
        "rds:DeleteDBInstance",
        "rds:DeleteDBCluster",
        "s3:DeleteBucket",
        "dynamodb:DeleteTable",
        "ec2:TerminateInstances",
        "lambda:DeleteFunction",
        "ecs:DeleteCluster",
        "ecs:DeleteService"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowEverythingElse",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Attach this as a permission boundary to the IAM role or user that Claude Code uses. Even if Claude Code asks to delete a database, AWS says no. The boundary is enforced at the IAM level - no application code can override it.

Critical: create a separate IAM user or role specifically for Claude Code. Don't give it your admin credentials. Don't give it the CI/CD role. A dedicated role with a permission boundary. This takes 10 minutes in the AWS console.

Layer 3: Kill Switch Pattern

Auto Mode runs until it's done or until you stop it. You need a way to stop it instantly.

The simplest kill switch is a file-based sentinel:

#!/bin/bash
# kill-switch.sh - Drop this in your project root

KILL_FILE=".claude-stop"

if [ -f "$KILL_FILE" ]; then
    echo "KILL SWITCH ACTIVE - Claude Code operations halted"
    echo "Remove $KILL_FILE to resume"
    exit 1
fi
Enter fullscreen mode Exit fullscreen mode

Add this check to any wrapper script that invokes Claude Code. When you need to stop everything, create the file:

touch .claude-stop  # Everything stops
rm .claude-stop     # Resume operations
Enter fullscreen mode Exit fullscreen mode

For teams, put the kill switch in a shared location (S3 bucket, Redis key, feature flag service). One person can halt all Claude Code operations across the org.

Layer 4: Staged Rollout

Don't enable Auto Mode across your whole codebase on day one. Start small:

Week 1: Auto Mode on test/staging environments only. Watch what it does. Read the logs.

Week 2: Auto Mode on non-critical production services (marketing site, docs, internal tools). Still watching.

Week 3: Auto Mode on production services with full protection layers (permission boundaries, delete protection, kill switch). Human reviews every session's output.

Week 4+: Gradual expansion based on what you've observed. Some teams will never enable Auto Mode for infrastructure management, and that's the right call.

What Auto Mode Is Actually Good For

I'm not saying don't use Auto Mode. I'm saying use it where the blast radius is contained:

  • Code generation and refactoring - the worst case is bad code that doesn't compile. Fixable.
  • Test writing - bad tests fail. They don't delete data.
  • Documentation - if Claude writes wrong docs, you edit them. No production impact.
  • Local development - your laptop, your test database, your sandbox. Go wild.

Auto Mode is not for:

  • Infrastructure management (Terraform, Pulumi, CloudFormation)
  • Database migrations on production
  • Anything that touches production credentials
  • CI/CD pipeline modifications

The Bigger Picture

The Terraform incident wasn't Claude Code's fault. It was an environment design failure. Claude Code was given production credentials, pointed at production infrastructure, and asked to make changes. It did exactly what any tool would do with that access.

Auto Mode raises the stakes because the confirmation gate is gone. But the real lesson is older than Auto Mode: don't give automated tools unrestricted access to production. This applies to Claude Code, GitHub Actions, Jenkins, Terraform Cloud, and every other tool that can execute commands on your behalf.

The teams that get hurt by Auto Mode will be the ones who skip the boundary setup because "I'll get to it later." Later is too late when your database is empty.

Set up the permission boundaries. Enable delete protection. Deploy the kill switch. Then - and only then - turn on Auto Mode.

This article was written with AI assistance. All technical claims, code, and architectural decisions were validated by the author.

Top comments (0)