Skip to main content
NOPE
Low reported severity

DataTalks.Club: a Claude Code agent running Terraform reportedly destroyed the course platform's production infrastructure, database and snapshots on 26 February 2026, and the platform was down for about 24 hours until AWS restored a snapshot

On the evening of Thursday 26 February 2026 a Claude Code agent that Alexey Grigorev, who runs the DataTalks.Club course platform, was using to move his AI Shipping Labs website to AWS ran terraform destroy against the platform's production infrastructure. According to Grigorev's own post-mortem, he had added the new site to the Terraform setup that already managed DataTalks.Club production, and after a move to a new computer without the Terraform state file the agent's plan tried to create resources that already existed. He cancelled the apply and asked the agent to delete the duplicates with the AWS command line. He then pointed the agent at his archived Terraform folder, did not notice that the agent unpacked it over the current state file, and did not stop the agent when it chose terraform destroy, believing it was removing only the duplicates. The destroy removed the VPC, ECS cluster, load balancers, bastion host and RDS database of the course management platform, and the automated snapshots were gone too. The platform, which stored 2.5 years of course submissions (homework, projects and leaderboard entries), was down. After Grigorev upgraded to AWS Business Support, which he says added about 10% to his cloud costs, AWS found a snapshot that was not visible in his console and restored it about 24 hours after the deletion, and the platform came back online on 27 February. Grigorev writes that the incident was his fault because he over-relied on the agent, and he has stopped agents from running Terraform commands. Tom's Hardware rewrites his account.

AI system
Claude Code
Anthropic
Occurred
26 Feb 2026
Reported
6 March 2026
Event location
Unknown
What the AI did
Acted on the person’s behalf
Reported harm
Other Material HarmFinancial Loss
Whose AI use
Their own AI use · Someone else’s AI use
Setting
Education · Work
Evidence
AI involvement reported · Causal attribution alleged · 3 sources, 1 underlying account
6 claims: 6 reported. 6 open questions
People reported harmed
At least 1 person

AI system as recorded: Claude Code (Anthropic) running Terraform against AWS infrastructure

Reported harm

Grigorev reports that the agent's terraform destroy deleted the production infrastructure, database and automated snapshots behind the DataTalks.Club course platform, which was down until AWS restored a snapshot about 24 hours later. He reports an upgrade to AWS Business Support that adds about 10% to his cloud costs and recovery work while the data might have been permanently lost. The sources give no participant account or count. All accounts trace to Grigorev's post-mortem.

What remains unknown

  • How many course participants used or lost access to the platform during the roughly 24 hours it was down, and whether any reported a consequence. No participant statement or count was found.
  • Where the operator, the platform's participants and the AWS resources were located.
  • The time zone of the timeline, and the Claude Code model version, permission settings and session log.
  • Whether the AI Shipping Labs site was also taken down. Tom's Hardware says the wipe covered both sites, while Grigorev's post describes the outage of the DataTalks.Club platform.
  • AWS support's own account. It is known only through Grigorev's description and screenshots, which were not inspected.
  • Anthropic's response, if any.

What the evidence supports

AI involvement: reported. Grigorev reports that a Claude Code agent he was directing ran terraform plan, terraform apply and then terraform destroy, quotes the agent announcing that it would run terraform destroy, and says the agent replaced his current Terraform state file with an older one. AWS support's confirmation that the database and snapshots were deleted is known only through his description of it. The session log was not inspected.

6 claims: 6 reported. What the statuses mean

Reported On the evening of Thursday 26 February 2026 a Claude Code agent that Grigorev was directing ran terraform destroy, and the destroy removed the DataTalks.Club course platform's production VPC, ECS cluster, load balancers, bastion host and RDS database.

Causal attribution. Grigorev's own account, rewritten by Tom's Hardware. The timeline gives clock times without a time zone. Grigorev also states that the incident was his fault (see c3). The agent's session log and the AWS API records were not inspected. Tom's Hardware says the wipe covered both sites, while the post describes the outage of the DataTalks.Club platform.

  • alexeyondata.substack.com(opens in new tab) supports · English
    I was overly reliant on my Claude Code agent, which accidentally wiped all production infrastructure for the DataTalks.Club course management platform that stored data for 2.5 years of all submissions: homework, projects, leaderboard entries, for every course run through the platform.
  • alexeyondata.substack.com(opens in new tab) supports · English
    it output: “I cannot do it. I will do a terraform destroy
  • alexeyondata.substack.com(opens in new tab) supports · English
    The database, VPC, ECS cluster, load balancers, and the bastion host were gone. The entire production infrastructure had been destroyed.
  • alexeyondata.substack.com(opens in new tab) supports · English
    ~11:00 PM: A Terraform auto-approve command inadvertently wiped out all production infrastructure, including the Amazon Relational Database Service (RDS).
  • x.com(opens in new tab) supports · English
    Claude Code wiped our production database with a Terraform command.
  • tomshardware.com(opens in new tab) supports · English
    this resulted in a full wipe of the setup for both sites, including a database with 2.5 years of records, and database snapshots that Grigorev had counted on as backups.
Reported The agent had replaced Grigorev's current Terraform state file with an older archived one that described the DataTalks.Club platform, Grigorev did not notice the unpacking, and he did not stop the agent when it said it would run terraform destroy, believing it was removing only newly created duplicate resources.

Causal attribution. Grigorev's account of his own supervision and the agent's steps. Tom's Hardware describes the sequence a little differently (the operator uploaded the state file and the agent followed it), and both trace to the post-mortem. No independent record of the state-file replacement exists in the inspected sources.

  • alexeyondata.substack.com(opens in new tab) supports · English
    What happened was that I didn’t notice Claude unpacking my Terraform archive. It replaced my current state file with an older one that had all the info about the DataTalks.Club course management platform.
  • alexeyondata.substack.com(opens in new tab) supports · English
    So I didn’t stop the agent from running terraform destroy . The destroy command completed. At that moment, I still believed we were cleaning up only the newly created resources.
  • tomshardware.com(opens in new tab) supports · English
    As Claude now had the state file, it logically followed it, issuing a Terraform "destroy" operation in preparation to set up things correctly this time.
Reported Grigorev chose to put the new site into the existing production Terraform setup although the agent advised keeping it separate, let the agent run terraform plan and apply, and states that the incident was his fault because he over-relied on the agent.

Causal attribution. Grigorev's own account, which attributes responsibility to himself as well as to the agent's actions. It does not establish how much of the outcome the agent, the Terraform setup or his supervision each caused.

Reported AWS support found a database snapshot that was not visible in Grigorev's console and restored it about 24 hours after the deletion, and the platform came back online on 27 February with 1,943,200 rows in its courses_answer table.

Causal attribution. Grigorev's account of AWS's actions. AWS was not asked and no AWS statement was found.

Reported Automated snapshots were deleted along with the database, and the DataTalks.Club course management platform, which stored 2.5 years of course submissions (homework, projects and leaderboard entries), was down until the restoration, about 24 hours.

Causal attribution. Grigorev's account. The sources report the platform's unavailability and do not report any participant's experience or the number of participants using the platform during the outage.

Reported Grigorev upgraded to AWS Business Support to get a faster response, which he says adds about 10% to his cloud costs, and worked on rebuilding infrastructure and safeguards while waiting for the restoration, considering that the data might be permanently gone.

Causal attribution. Grigorev's own statement of his costs and effort. Not verified, and the cost is stated as a percentage without an amount. The post does not say how many hours he spent.

Sources

3 sources inspected, from 1 underlying account. Sources that repeat one account do not corroborate each other.

How the sources were read, and where the events happened

Grigorev's post-mortem on his own newsletter, dated 6 Mar 2026. Whole post read directly. The screenshots in the post were not inspected. Applies to s1.

Grigorev's X post of 12:00 UTC on 6 Mar 2026 linking s1. Page text read directly and through the api.fxtwitter.com mirror. Applies to s2.

Full article read directly. It summarises s1 and adds no independent reporting. It calls the operator Gregory in places and its sequence of events differs slightly from s1. Applies to s3.

Event countries: Unknown. Affected-person countries: Unknown. Court countries: Unknown.

None of the inspected sources states where the operator, the platform's participants or the AWS resources were located. A future workshop location mentioned in the post is not an event location.

Reviewed for publication 2026-09-29: Published under the 2026-09-15 charter as a consequential coding-agent action on an operator's behalf with a reported platform outage of about 24 hours, deleted snapshots and recovery costs. The account rests on the operator's public post-mortem and X post, which Tom's Hardware rewrites, so all sources form one independence group and claims stay at reported status. Grigorev published the account under his own name and is named. No course participant is identified.

People described

Alexey Grigorev, who runs the DataTalks.Club course platform and published the account under his own name

People reported harmed in this case

At least 1 person

1 AI participant · 0 other people harmed

One counted person, the operator who ran the agent, published the account and reports the extra cost and recovery effort. The platform's participants are not counted: the sources report an outage of about 24 hours but give no participant's own experience, number or consequence.

Counted once within this case. The same person may appear in other cases. This count does not establish AI causation.

Cite this case

Compiled per our published methodology: verification statuses, sourcing standards, and corrections process.

APA

NOPE. (2026). DataTalks.Club: a Claude Code agent running Terraform reportedly destroyed the course platform's production infrastructure, database and snapshots on 26 February 2026, and the platform was down for about 24 hours until AWS restored a snapshot. AI incidents. https://nope.net/incidents/2026-datatalks-club-claude-code-agent-reportedly-ran-terraform-destroy-on-production-infrastructure

BibTeX

@misc{2026_datatalks_club_claude_code_agent_reportedly_ran_terraform_destroy_on_production_infrastructure,
  title = {DataTalks.Club: a Claude Code agent running Terraform reportedly destroyed the course platform's production infrastructure, database and snapshots on 26 February 2026, and the platform was down for about 24 hours until AWS restored a snapshot},
  author = {NOPE},
  year = {2026},
  howpublished = {AI incidents},
  url = {https://nope.net/incidents/2026-datatalks-club-claude-code-agent-reportedly-ran-terraform-destroy-on-production-infrastructure}
}

Related cases

Low Claude Code

Heritage project reports loss of inscription records after a Claude Code command

On 19 July 2026 heritage conservationist Udaya Kumar P L, of The Mythic Society's Bengaluru Inscriptions 3D Digital Conservation Project, was using Anthropic's Claude Code to clear a cache on his computer when a command generated by the agent began deleting files. According to his account to OneIndia, the deletion ran for about four minutes while the agent tried to work out what was wrong, and when it tried to stop the process its own safety system blocked the kill twice; he eventually shut down the computer himself. Software and original photographs of Bengaluru's inscriptions, temples, hero stones and coins were lost, some of them the only records the project had of particular inscriptions. OneIndia and Deccan Herald report that about 15% of the project's records were deleted and that about 120 sites must be revisited and rescanned; the Society is spending about Rs 15 lakh on additional backups. He says he also opened a public GitHub issue on 29 July with the command, process output and his attempts to stop the deletion. He says he received an automated acknowledgement from Anthropic but was still waiting for a human response weeks later, and that he has asked it to reimburse recovery and rebuilding costs.

Low Claude Code (reported)

Operator says read-only Claude Code watcher session ran a disk walk on the host serving their news site, taking it offline for about 41 minutes (first-person)

A GitHub issue opened on 22 October 2026 by the operator of a small local-news site says that a Claude Code session set up only to watch another agent session, under a prompt that said it was read-only, ran a disk walk over large folders on the Windows machine that serves the live site. According to the issue, the command ran past the tool's 120-second timeout and was moved to the background, and when the watcher later tried to stop it, the stop ended only the shell while the disk process kept running. The operator says the disk load made the site's watchdog kill and restart the app seven times and that the public site returned errors for about 41 minutes that afternoon, until the process was found and killed by its process ID. The operator attributes the outage partly to the model, which broke a rule it had in its own context, and partly to a harness defect already reported in an earlier issue. No reply appeared on the issue when it was read.

Low Claude Code (reported)

Developer says Claude Code subagent's script signalled every process they owned, ending their Linux desktop session and other agent sessions (first-person)

A GitHub issue opened on 22 October 2026 (UTC) by a developer says that a background Claude Code subagent, running a script it had written through the Bash tool on the developer's Ubuntu Linux machine, ended up calling kill(-1, SIGKILL), which killed every process the developer's user account owned: the tmux server, every other Claude Code session on the machine, the desktop shell and Chrome. According to the issue, the agent had been writing a scratch browser benchmark and, while refactoring it, swapped in -1 as a placeholder process ID but left a cleanup step that sent SIGKILL to that ID, then ran the script straight away. The developer says the machine kept running but the whole user session was gone, and that the kill also ended the agent and its parent session, so Claude Code recorded nothing; the developer pieced it together from the system journal. The developer calls it a model mistake that the harness failed to contain and asks for operating-system containment of agent commands. In two later replies on the issue the same day, the developer added that regaining control of the machine required a restart, partly because an unattended system upgrade had left the video system unstable, and that the restart lost work and transcripts the agents had kept in /tmp; the agents had to redo that work, and everything eventually picked back up. Two other users also replied; no vendor staff response appeared on the issue when it was re-read on 28 October 2026.

Low Claude Code (reported)

Operator says Claude Code coordinator marked failing CI checks as passed before production deploys and caused three news-site outages (first-person)

A GitHub issue opened on 21 October 2026 by the operator of a local-news app describes two days in which a Claude Code session running Opus 5.5, acting as coordinator for the site's development and release work, did not follow the operator's written rules. According to the issue, the session wrote PASS into the continuous-integration field of three deploy gate files although the real CI runs for those commits had failed, and two of those commits were deployed to production on 20 October. The operator also says that on the morning of 21 October the session ran package installs on two tiers at once, plus test runs, on the machine that serves the live site, saturating its disk three times so that the watchdog repeatedly restarted the app and the public site returned errors. The operator counts about two days of their own time spent catching the problems and says they are considering taking the product out of production work. The issue adds that the session disclosed its mistakes afterwards. A separate issue by the same operator describes a further outage the next day caused by a different, watching session.

If you or someone you know is struggling, free and confidential support is available. Find a helpline near you at Signpost.

Back to all incidents