ManifoldAgent incident ledger
← Back to tableAll incidents timeline

Suggest a change

About Claude Code runs terraform destroy on DataTalks.Club production infrastructure

Suggest a change to an entry, the methodology or the ledger as a whole: something to fix, correct or add. We read every suggestion, and check corrections against their sources.

DataTalks.Club· Claude Code

Claude Code runs terraform destroy on DataTalks.Club production infrastructure

Claude Code, working through Terraform for Alexey Grigorev, destroyed the production infrastructure behind the DataTalks.Club course platform, including its database and snapshots.

On 26 February 2026 Alexey Grigorev, founder of DataTalks.Club, was adding a second site to his AWS Terraform setup with Claude Code. His Terraform state was on his old computer, so the first plan wanted to recreate everything; he stopped it, then had Claude clean up the duplicates. When he moved an archive of the old Terraform folder across, Claude unpacked it over the current state, then ran terraform destroy, which removed the course platform's database, network, cluster and automated snapshots, covering 2.5 years of records. AWS support restored a snapshot about 24 hours later. Grigorev wrote it up on 6 March, blaming his own over-reliance on the agent, and no longer lets it run commands.

Updated 19 Oct 2026

First incident action to disclosure
8 days
First incident action to discovery
0 days
Noticed first by
The handler
Caught
The damage

What happened

  • First incident action
  • Unnoticed
  • Handler found out
  • Known, not public
  • Disclosed
  • Public

  1. 26 Feb 2026

    First incident action

    Grigorev lets Claude Code plan and apply Terraform for a new site on the shared setup

    He was adding AI Shipping Labs to the Terraform setup that already ran the DataTalks.Club course platform. Claude advised a separate setup; he declined to save a few dollars a month. His state file was still on his old computer, so Terraform saw nothing and began creating duplicates. He stopped it, but some resources already existed.

  2. 26 Feb 2026

    Claude Code runs terraform destroy against the real production state

    While Claude was cleaning up duplicates, Grigorev moved an archive of the old Terraform folder to the new machine. He says he did not notice Claude unpack it over the current state file. Claude then ran terraform destroy and removed the VPC, the RDS database, the ECS cluster, load balancers, the bastion host and the automated snapshots.

    Reports differ

    What the human approved. Grigorev says he did not stop the destroy and did not notice the state swap. Tom's Hardware says Claude ran the destroy once he had uploaded the state file, as if by its own choice. The Rootly interview says he approved the destroy.

    • 'So I didn't stop the agent from running terraform destroy.' He did not notice Claude unpacking the archive.
    • Claude used the uploaded state file to run a destroy intending to rebuild the setup.

  3. 26 Feb 2026

    Handler found out · 0 days in

    Grigorev finds the database gone and no usable snapshot

    He expected a 2 AM nightly snapshot and found none in the console; an event log showed a 00:24 backup that could not be opened. Roughly 1.94 million rows in one table, and 2.5 years of course data, were at stake.

  4. 27 Feb 2026

    AWS support confirms the deletion and finds a snapshot on its side

    Grigorev upgraded to AWS Business Support, got a reply in about 40 minutes, and was told the database and snapshots were deleted by the API request. AWS found a snapshot not visible in his console.

  5. 27 Feb 2026

    AWS restores the snapshot about 24 hours after the deletion

    The platform came back after Grigorev rebuilt the database from the restored snapshot and checked the row count.

    Reports differ

    Restore timing. The post's own times are approximate and the 24 hour mark falls near 11 PM, while it lists the platform back around 10 PM.

    • 'Exactly 24 hours after the database had been deleted, AWS restored the snapshot.'
    • Data restored 'within about a day'.

  6. 6 Mar 2026

    Disclosed · 8 days after the first incident action

    Grigorev publishes his post-mortem

    'How I Dropped Our Production Database and Now Pay 10% More for AWS' on his newsletter, listing the changes he made.

  7. 7 Mar 2026

    Tom's Hardware covers the incident

    Syndicated on Yahoo Tech on 7 March 2026.

    Reported

Agent failures

Destructive actionShow
Map to frameworks

  • Destructive action

    Ran terraform destroy against the production state, deleting the database, infrastructure and snapshots.

How it was found

Found first by the handler, from the damageShow
Found first by
The handler
How
The damage
Found to disclosed
8 days

Grigorev saw the database missing in the AWS console and found no snapshot to restore. Nothing flagged the destroy before it ran. The one check that existed was his own approval, and he says he gave it without noticing that the state file had changed.

What is publicly known

4 of 12 fully publicShow
4 of 12 fully public
ItemPublic?DetailSources
PartialClaude Code. No model name or version appears in the post.
UnknownNo source mentions reasoning settings.
WeakGrigorev's own review of the plan was the check, and he had delegated it. Post-incident he disabled automatic execution and file writes. Whether Claude Code ran in a permission-skipping mode is not stated in the post.
UnknownNot published.
KnownDeploy changes for a second site with Terraform, then remove the duplicate resources Terraform had created. Described step by step in the post.
PartialClaude Code on a new laptop with AWS access, able to run Terraform and the AWS CLI. Permission settings are not fully described.
UnknownNo source describes network setup beyond direct AWS access.
WeakThe post paraphrases the exchange and quotes a few lines; no full session log.
WeakGrigorev found the loss himself. AWS support later confirmed from its side that an API request deleted the database and snapshots.
KnownProduction infrastructure for the course platform deleted, including the RDS database and snapshots; about 1.94 million rows in one table checked after restore. Roughly a day of downtime and about 10% more on his AWS bill.
KnownMissing local state led to duplicates; the state file for production was then unpacked over the working state, and the destroy ran against it. Grigorev names over-reliance on the agent and untested backups.
KnownTerraform and AWS delete protection, backups outside the database and Terraform, remote state in S3, nightly restore test, no automatic agent execution. Self-reported.

Controls that apply

  • Protect

    Ask a person before high-impact or irreversible actions

    Grigorev had delegated plan, apply and destroy to the agent, and says he approved the destroy without noticing the state file had changed. A gate enforced by the environment that showed which state terraform destroy would act on would have put the production database, cluster and snapshots in front of him first.

  • Give agents their own scoped, short-lived credentials

    The agent's AWS access covered the production course platform as well as the new site it was adding. Grigorev now plans separate accounts for development and production, and Tom's Hardware names broad permissions and no production scoping as core failures.

  • Check each action against policy before it runs

    A policy check outside the agent would have held terraform destroy against production, and the unpacking of an archive over the current state file before it. Grigorev's own view is that access boundaries matter more than command filters, so this is a second line rather than the main one.

  • Detect

    Record every agent action, outside the agent

    The commands run, recorded outside the agent, would show the archive being unpacked over the current state file and then terraform destroy, the sequence Grigorev says he did not notice at the time. That record serves the investigation; it would not by itself have held the destroy.

  • Recover

    Keep changes reversible

    terraform destroy removed the RDS database together with its automated snapshots, and Grigorev found no backup he could restore in the console. Backups the agent's AWS access could not delete would have limited the outage; as it was, recovery depended on a snapshot AWS support found on its side about 24 hours later.

  • All controls →

Coverage and commentary

1 statement, 2 articlesShow

What the parties involved said

  • Alexey Grigorev

    Treats it as his own failure: he delegated plan, apply and destroy to the agent. Lists remote state, delete protection, off-Terraform backups and manual review of every plan.

All 3 sources

  1. Primary source

    How I Dropped Our Production Database and Now Pay 10% More for AWS ↗Alexey On Data · 2026-03-06

  2. Press

    Claude Code deletes developers' production setup, including its database and snapshots ↗Tom's Hardware · 2026-03-07

  3. Commentary

    Hey Claude, where's my database? (Humans of Reliability) ↗Rootly

Entry id datatalks-club-terraform-destroy-2026 · overall Confirmed · impact serious