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

Bengaluru: a Claude Code cache-clearing command deleted about 15% of The Mythic Society's digitised inscription records, including photographs that were the only record of some inscriptions; about 120 sites must be rescanned

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 Cursor coding agent (reported)

PocketOS: a Cursor coding agent running Anthropic's Claude Opus 4.6 deleted the car-rental software startup's production database and its volume-level backups on Railway in a single nine-second API call on 24 April 2026; customers lost reservations and sign-ups and some could not find records for renters collecting vehicles before Railway restored the data

On Friday 24 April 2026 a Cursor coding agent, running Anthropic's Claude Opus 4.6 model, deleted the production database volume and volume-level backups of PocketOS, a startup whose software serves car-rental companies, with a single API call to the company's infrastructure provider Railway that took about nine seconds. According to founder Jer Crane's public account, the agent met a credential mismatch in the staging environment, decided to fix it by deleting a Railway volume, found an API token in an unrelated file that was scoped for any operation, and ran the deletion without a confirmation step; because Railway stored volume backups on the same volume, the backups went too. Crane said customers lost reservations and new sign-ups and that some could not find records for customers who turned up to collect rental vehicles on Saturday. Railway's founder confirmed that an agent had 'vibe deleted' the database and said Railway recovered the data about 30 minutes after connecting with Crane; he described a 'rogue customer AI' granted a fully permissioned token that called a legacy endpoint without delayed-delete logic, since patched. Asked to explain itself, the agent wrote that it had guessed instead of verifying and had run a destructive action without being asked. Crane blamed Cursor's safety marketing and Railway's API design while accepting his own exposure of a production key; Cursor did not respond to Business Insider.

Low Claude Code

Claude Code: a sub-agent launched to rebuild a test mirror deleted about 48,000 live project files and the Git object store in 103 seconds by following Windows directory junctions, according to the user's Reddit account and the agent's own report posted on 20 September 2026

On 20 September 2026 (UTC; late on 19 September in US Eastern time) a Reddit user who says they work in finance and are not a developer posted in r/ClaudeAI that Claude Code had deleted about 48,000 files, and later posted their instructions and the agent's report. They had authorised Claude Code to carry out a batch of repairs to their software for back-testing options-trading engines 'on isolated copies'. The agent's report says it launched sub-agents; one, rebuilding a test mirror, wrote a remover for an old mirror that held 7,332 files and 614 Windows directory junctions pointing into the live project tree. Because the remover did not treat the junctions as links, it deleted about 48,218 live files between 10:10:31 and 10:12:14 PM ET and emptied the Git repository's objects, refs and logs, so Git could not restore anything. The agent opened its report with 'stop and read this. I broke something.' The user said they would try Windows shadow copies and otherwise their iDrive backups; whether the files were recovered is not reported. The account has not been independently verified.

Low Unidentified image tool

Stanford University: the Residential & Dining Enterprises department used generative AI to alter a promotional photograph of three students, replacing a Hispanic male student with an AI-generated Black woman, slimming two students' faces and changing their clothing, on campus banners; the university said the undisclosed alteration violated its AI policy, apologised and opened an investigation (Stanford Review, Stanford Daily, NBC Bay Area, NBC News, 21-24 September 2026)

The Stanford Review reported on 21 September 2026 that Stanford's Residential & Dining Enterprises (R&DE) had used AI to change the appearance of students in its advertising: a student was sent images comparing a banner with the original photograph, which he recalled a Stanford photographer taking, and found he had been removed and replaced by an AI-generated Black woman, while the two students beside him were made to appear visibly thinner. Stanford confirmed to The Stanford Daily on 23 September that R&DE used generative AI to modify the appearance of several students in the image; the Daily reported that the students' clothing was changed into Stanford merchandise, two students' faces were slimmed and one student's race, gender and appearance were entirely changed, and the university said the alteration and its non-disclosure violated its policy prohibiting AI in producing or altering images of Stanford people; the banner at the Governor's Corner housing centre was taken down and staff training promised. On 24 September NBC News reported the university's statement that the alteration was 'a serious error in judgment', that it had apologised to the students whose images were altered or erased, and that it had opened an investigation. The replaced student, who first found the edit funny, said that seeing his identity changed and being left out made him feel 'silenced and erased from a representation that was supposed to include me', that it was upsetting, and that he was exhausted by the national media attention. According to the student, the original photograph was taken at a 2024 Lunar New Year dinner in a campus dining hall and had been used unaltered in earlier promotional material.

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