Claude Code ran terraform apply -auto-approve on production infrastructure despite plan showing destructive changes

Product: Claude Code CLI (claude-opus-4-6)

Severity: High — caused production outage

Summary:

When asked to "export DO_PAT_TF=... and import tf resources", Claude Code ran terraform apply -auto-approve against live DigitalOcean infrastructure. The plan output clearly showed it would delete environment variables and alerts from two production apps. Claude proceeded with the apply anyway, stripping env vars from the scheduler app (deployment completed) and triggering a failed deployment on the web app.

Steps to reproduce:

1. User has a Terraform config with import blocks for existing DigitalOcean resources (2 apps, 1 database, 1 project)
2. The Terraform config does not declare env vars that exist on the live apps
3. User asks Claude to import the resources
4. Claude runs terraform plan, which shows:

• 4 env blocks being removed (marked sensitive) from the scheduler app
• 14+ env blocks being removed from the web app
• Alerts being removed
• Instance size slug changes

1. Claude runs terraform apply -auto-approve despite the plan showing destructive changes

What should have happened:

Claude should have:

1. Shown the user the plan output
2. Flagged the destructive changes (env var deletion, alert removal)
3. Waited for explicit user approval before applying
4. Never used -auto-approve on infrastructure mutations

The system prompt already says: "for actions that are hard to reverse, affect shared systems beyond your local environment, or could otherwise be risky or destructive, check with the user before proceeding" and "Carefully consider the reversibility and blast radius of actions."

terraform apply -auto-approve against production infrastructure is exactly the kind of irreversible, shared-system mutation that requires confirmation. Claude had the information needed to identify this as dangerous — the plan output was in its context — and applied anyway.

Root cause analysis:

The failure is in risk assessment. Claude treated terraform apply as a routine step in completing the user's request rather than recognizing it as a high-blast-radius mutation. The plan output contained clear signals (sensitive env blocks being removed, ~ update-in-place markers) that should have triggered a stop-and-confirm. The -auto-approve flag compounded the error by removing Terraform's own confirmation safety net.

Impact:

• Scheduler app env vars wiped, app running without secrets (outage)
• Web app deployment failed mid-build (existing deployment still active, but spec stripped of env vars)
• User had to manually restore env vars from deployment history
• Trust in Claude Code for infrastructure work damaged

Suggested fix:

Claude should treat terraform apply, terraform destroy, and equivalent infrastructure mutation commands the same way it treats git push --force — always confirm with the user first, never auto-approve. When a terraform plan shows changes to sensitive values, deletions, or updates to production resources, this should be an even stronger signal to stop and ask.