Incidents
Claude Code ran terraform destroy on a production database
Claude Code · February 2026
Updated
Alexey Grigorev, who runs DataTalks.Club, published a postmortem in March 2026 describing an infrastructure cleanup in which Claude Code unpacked an old archive holding a Terraform state file that described the entire production environment, proposed terraform destroy as the cleaner way to remove some duplicates, and was approved. It took the VPC, the ECS cluster, the load balancers, the bastion host and the RDS instance with every automated snapshot, including a table of 1,943,200 rows covering roughly two and a half years of student submissions. AWS support located a snapshot that was not visible in the console and restored it about a day later, so nothing was permanently lost.
What happened
The setup matters more here than the agent does. Grigorev had switched machines without bringing the Terraform state, so a plan showed existing infrastructure as missing and began proposing duplicates. Cleaning those up, the agent found an old archive transferred from the previous machine, and the state file inside it described production. Its proposal, quoted in his postmortem: "I will do a terraform destroy. Since the resources were created through Terraform, destroying them through Terraform would be cleaner and simpler than through AWS CLI." He approved it. His own account names the real causes without softening them: state kept locally rather than in S3, backups he assumed existed and had never tested a restore from, no deletion protection, and treating plan, apply and destroy as work that could be delegated. Recovery took an escalation to paid AWS support and about twenty-four hours, after which all 1,943,200 rows came back. He has since moved state to S3, put backups outside the Terraform lifecycle, enabled deletion protection in two places, added daily automated restore testing, and stopped letting an agent run Terraform commands directly.
The failure mode
The agent was working in a directory that contained another environment's state, and the credentials in its environment were good for all of it.
What Forkbench changes about it
- 1Read his postmortem before reading ours. Remote state, deletion protection and a restore you have actually tested are the fixes here, and not one of them is a terminal feature.
- 2Lock the Thread to the folders the job is genuinely about. Every shell in it starts under a kernel-enforced profile, so an archive belonging to another environment is not something an agent opens on its way past.
- 3Scope the credential to the Thread, so infrastructure work on one environment does not carry the ability to act on another.
- 4Keep the value out of the agent's context with Vault, so what an agent can do becomes a question about which commands you authorise rather than about what it can read, keep and reuse later in the session.
- 5Require Touch ID per use for anything that reaches production, which makes an approval a physical act rather than one more keystroke in a fast-moving session.
What Forkbench would not have stopped: Forkbench would not have stopped this, and the reason is worth stating bluntly: a human approved the destroy, and the credentials were legitimately his. Vault decides who can read a value, not what a command is permitted to do, so a destroy the operator authorised is an authorised destroy. Folder scope would have made the stale state file harder to reach and Thread scope would have narrowed which environment those credentials could touch, but neither is deletion protection and neither is a restore you have tested. Read his list, not ours, for the fix.
Frequently asked
Was the data actually lost?
No. AWS support found a snapshot that was not visible in the console and restored it after roughly twenty-four hours, recovering all 1,943,200 rows. The automated snapshots that should have covered this were deleted along with the database, which is the part worth copying into your own runbook.
Whose failure was this?
His postmortem answers that itself: local state, untested backups, no deletion protection, and over-delegation of Terraform commands. The straightest reading is that the agent supplied the speed and the setup supplied the blast radius.
Should an agent run Terraform at all?
He decided not, and reviews plans by hand now. That is a defensible answer for infrastructure that carries a production database. Where an agent does run infrastructure commands, the question worth settling first is which environment the credentials in that Thread can reach.
Related: When the agent's own report of the damage was wrong, Deploy access without the credential