Skip to main content
NOPE
Low reported severity

Developer says a hands-free Claude Code session on Opus 5.5 deleted the entire Windows C: drive; 98% recovered from daily backups (first-person, X)

In X posts of 6 and 7 October 2026, a developer writes that Claude Code running Anthropic's Opus 5.5 model "just deleted my entire fucking C drive" during a hands-free session, and that daily backups to a NAS saved the data. In a follow-up the developer says the sessions run for hours unattended with the --dangerously-skip-permissions flag, as they had since Opus 4.6 without such an issue, attributes the deletion to "a simple powershell syntax mangling issue", says 98% of the data has been recovered and that deterministic safeguards have since been built, and accepts the fault as the user's own while arguing that the harness should prevent such a command natively. The head of Claude Code at Anthropic replied that the company recommends and defaults to auto mode for permissions, which "almost certainly would have caught this"; the developer answered that auto mode had felt like babysitting for long unattended sessions. The account is the developer's own. The first post carries a screenshot of a text analysis addressed to the developer, whose author is not stated; it says the session was a Claude Code session in bypass-permissions mode that tried to remove two leftover git worktree folders, quotes the removal command, explains that Windows PowerShell 5.1 read its quoting so that the path became the root of drive C:, and says the session was not running as administrator, so Program Files, Windows and other accounts' files survived. MadRobot wrote that the developer had not shared a command log or screenshots showing what ran.

AI system
Claude Code (reported)
Occurred
6 Oct 2026
Reported
6 October 2026
Event location
Unknown
What the AI did
Acted on the person’s behalf
Reported harm
Property LossOther Material Harm
Whose AI use
Their own AI use
Setting
Work · Everyday life
Evidence
AI involvement reported · Causal attribution alleged · 4 sources, 2 underlying accounts
5 claims: 1 documented, 4 reported. 5 open questions
People reported harmed
1 person

AI system as recorded: Claude Code (Anthropic's coding agent) running the Claude Opus 5.5 model in a multi-hour hands-free session started with the --dangerously-skip-permissions flag on a Windows machine, where the developer says a mangled PowerShell command deleted the C: drive, per the developer's posts and the screenshot attached to the first post

What Happened

The deletion. The developer's first post, at 23:58 UTC on 6 October 2026, reads: "Opus 5.5 just deleted my entire fucking C drive. Thank GOD I have daily backups running to my Synology NAS, but holy fucking shit. This is insane. If I didn't have these backups running I'd be thoroughly fucking devastated." MadRobot, a news blog that relayed the thread on 7 October, says it had been viewed more than 120,000 times and that the developer "hasn't shared a command log or screenshots showing exactly what ran". The first post does carry an image, described below.

The attached screenshot. The image attached to the first post is a text analysis addressed to the developer; its author is not stated. It says: "It was one of your own Claude Code sessions", that the session "was running in bypass-permissions mode" and at "3:59:51 PM it tried to clean up two leftover git worktree folders" with a cmd /c rmdir /s /q command on a path under the developer's user profile. It explains: "The quoting is wrong for Windows PowerShell 5.1. It doesn't treat " as an escaped quote, so the string closed early", so that "a bare \ means the root of drive C:"; that the command ran a second time for the second folder and both ran "until 4:30:00 PM"; that "It wasn't admin. That's why Program Files, Windows and the other accounts survived"; and that "A safety check had already blocked an earlier version of the cleanup at 3:52 PM. The session then retried it as a separate cmd /c rmdir command that the check didn't catch." The path in the command is not reproduced here.

How the session ran. Replying to Anthropic's head of Claude Code, the developer writes: "I have many multi-hour long sessions running at any given point in time (deliberately) on a hands free basis", and "I've run sessions on this machine with the --dangerously-skip-permissions tag since Opus 4.6 (probably sooner tbh) without this kind of issue surfacing". The developer attributes the loss to a command error: "For a simple powershell syntax mangling issue to cause such a catastrophic problem (on opus 5.5 nonetheless) is wild to me. At a minimum I would expect deterministic hooks to be natively built within the harness itself to prevent such a thing from transpiring."

Recovery and responsibility. The same reply says: "I have built the appropriate deterministic safeguards to prevent this from happening again & have been able to recover 98% of my data", and: "It's nobodies fault but I'm own". The developer adds that other users without daily C drive backups would be less fortunate.

Anthropic's reply. Boris Cherny, who leads Claude Code at Anthropic, replied on 7 October: "Hey that sucks. This is the reason why we recommend (and default to) auto mode for permissions. It almost certainly would have caught this, is there a reason you aren't using it?", linking Anthropic's article on auto mode becoming the default. The developer answered that limited experience with auto mode "can be best described as babysitting" and that such sessions would not stay hands-free for the length of time expected.

Reported harm

The developer says the agent deleted the entire C: drive of a Windows machine during an unattended session; the developer reports recovering 98% of the data from daily backups, with the remaining loss and the recovery effort unquantified; the screenshot the developer attached says the session was not running as administrator and that Program Files, Windows and other accounts survived (first-person account, uncorroborated).

Outcome

Resolved

The developer says 98% of the data was recovered from daily backups to a Synology NAS and that deterministic safeguards have been built to prevent a recurrence. Anthropic made no formal statement; the head of Claude Code replied publicly recommending auto mode, which the developer declined for long unattended sessions.

What remains unknown

  • The developer's country.
  • The author of the analysis in the attached screenshot and the logs it drew on; which files were deleted, since the screenshot says Program Files, Windows and other accounts survived while the posts say the entire C drive.
  • The Claude Code version and the 2% of data not recovered.
  • Whether Anthropic investigated the session beyond the public reply.
  • The developer's local date at the time of the deletion; the first post was made at 23:58 UTC on 6 October 2026.

What the evidence supports

AI involvement: reported. The developer states that Claude Code running Opus 5.5 deleted the entire C drive during a hands-free session started with the --dangerously-skip-permissions flag, and attributes the deletion to a mangled PowerShell command the agent ran; a screenshot the developer attached quotes the rmdir command and attributes the drive-root deletion to a Windows PowerShell 5.1 quoting error (author of the analysis not stated); the agent's own command is the described action and the drive deletion is its described consequence. Anthropic's head of Claude Code replied by recommending auto mode, which the reply said would almost certainly have caught the command; the reply responds to the account without confirming or disputing the deletion. The connection between the agent's action and the loss rests on the developer's own statements, and the logs behind the attached analysis have not been published.

5 claims: 1 documented, 4 reported. What the statuses mean

Reported The developer says Claude Code running Opus 5.5 deleted the entire C drive of the developer's machine, and that daily backups to a Synology NAS saved the data.

Causal attribution. The developer's own account, with a screenshot attached to the first post showing an analysis of unstated authorship that quotes the command; MadRobot says the account "hasn’t been independently checked".

  • x.com(opens in new tab) supports · English
    'Opus 5.5 just deleted my entire fucking C drive'; 'Thank GOD I have daily backups running to my Synology NAS'
  • madrobot.blog(opens in new tab) context · English
    'A developer says Anthropic’s most powerful model wiped his computer’s entire C: drive while working on its own, and only his nightly backups saved him'
Reported The developer says the sessions run for hours unattended with the --dangerously-skip-permissions flag, as they had since Opus 4.6 without such an issue, and attributes the deletion to a PowerShell syntax mangling issue, and a screenshot attached to the first post quotes a folder-removal command whose quoting Windows PowerShell 5.1 resolved to the root of drive C:.

Causal attribution. The developer's own explanation of the session setup and of the cause; the screenshot attached to the first post quotes the command and explains the quoting error, and its author is not stated.

  • x.com(opens in new tab) supports · English
    'I have many multi-hour long sessions running at any given point in time (deliberately) on a hands free basis'; 'I've run sessions on this machine with the --dangerously-skip-permissions tag since Opus 4.6 (probably sooner tbh) without this kind of issue surfacing'; 'For a simple powershell syntax mangling issue to cause such a catastrophic problem (on opus 5.5 nonetheless) is wild to me'
  • x.com(opens in new tab) supports · English
    image attached to the post: 'It was one of your own Claude Code sessions'; 'It was running in bypass-permissions mode'; 'The quoting is wrong for Windows PowerShell 5.1'; 'a bare \ means the root of drive C:'
Reported The developer says 98% of the data has been recovered and that deterministic safeguards have been built, and accepts the fault as the user's own.

Causal attribution. The developer's own account of the recovery.

  • x.com(opens in new tab) supports · English
    'I have built the appropriate deterministic safeguards to prevent this from happening again & have been able to recover 98% of my data'; 'It's nobodies fault but I'm own'
Documented Anthropic's head of Claude Code replied publicly that the company recommends and defaults to auto mode for permissions, which "almost certainly would have caught this", and asked why the developer was not using it.

Causal attribution. The reply is the cited record itself. It is a vendor response and does not confirm or dispute the deletion; Anthropic made no formal statement.

  • x.com(opens in new tab) supports · English
    'This is the reason why we recommend (and default to) auto mode for permissions. It almost certainly would have caught this, is there a reason you aren’t using it?'
  • madrobot.blog(opens in new tab) context · English
    'Boris Cherny, who leads Claude Code at Anthropic, replied that this is exactly why the company recommends its newer permissions setting'
Reported The screenshot attached to the developer's first post says the session was not running as administrator, so Program Files, Windows and other accounts' files survived, and that a safety check had blocked an earlier version of the cleanup before the session retried it as a separate command.

Causal attribution. Analysis of unstated authorship posted by the developer; the logs it drew on were not published.

  • x.com(opens in new tab) supports · English
    image attached to the post: 'It wasn't admin. That's why Program Files, Windows and the other accounts survived'; 'A safety check had already blocked an earlier version of the cleanup at 3:52 PM. The session then retried it as a separate cmd /c rmdir command that the check didn't catch'

Sources

4 sources inspected, from 2 underlying accounts. Sources that repeat one account do not corroborate each other.

How the sources were read, and where the events happened

Read in English on 2026-10-09 through the fxtwitter API copy of the post (full text, 1,028,548 views and 855 replies at fetch time). Replies in the thread other than those cited were not retrieved. Re-read from the saved copy on 2026-10-10. The attached image (a screenshot of text, media.photos[0] in the fxtwitter copy) was read; its command path, which carries the developer's Windows account name and a project folder, is not reproduced. Applies to s1.

Read in English on 2026-10-09 and re-read from the saved copy on 2026-10-10 through the fxtwitter API copy (full text). The developer's reply to Boris Cherny. Applies to s2.

Read in English on 2026-10-09 and re-read from the saved copy on 2026-10-10 through the fxtwitter API copy (full text). Reply by Anthropic's head of Claude Code to the developer's first post. Applies to s3.

Read in English on 2026-10-09 and re-read from the saved copy on 2026-10-10 (direct fetch, 200). The blog relays the X thread and the Cherny reply and adds Anthropic's published auto-mode figures; it reports no independent checking of the account. Applies to s4.

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

No source states where the developer is; the X profile and the blog give no location. No court proceedings.

Reviewed for publication 2026-10-10: Published under the public-forum rule as a concrete first-person account of a coding agent deleting the user's system drive during an unattended session, with the deletion, the session setup and the recovery attributed to the developer and the vendor's public reply recorded. The source handle appears only in the source URLs; the developer is not named in the record. The AI contribution rests on the developer's statement that the agent's mangled PowerShell command deleted the drive and on the screenshot the developer attached, which quotes the command; the author of that analysis is not stated.

People described

A developer who runs long unattended Claude Code sessions and posts about them on X; no name, country or employer is recorded

People reported harmed in this case

1 person

1 AI participant · 0 other people harmed

One person counted: the developer who ran the session and whose drive was deleted. The thread's view count is an audience figure and is not counted.

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

Tags

#first-person#x-twitter#coding-agent#data-loss#windows#skip-permissions#claude-code#backups

Cite this case

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

APA

NOPE. (2026). Developer says a hands-free Claude Code session on Opus 5.5 deleted the entire Windows C: drive; 98% recovered from daily backups (first-person, X). AI incidents. https://nope.net/incidents/2026-claude-code-opus-5-5-hands-free-skip-permissions-session-deleted-developer-windows-c-drive-first-person

BibTeX

@misc{2026_claude_code_opus_5_5_hands_free_skip_permissions_session_deleted_developer_windows_c_drive_first_person,
  title = {Developer says a hands-free Claude Code session on Opus 5.5 deleted the entire Windows C: drive; 98\% recovered from daily backups (first-person, X)},
  author = {NOPE},
  year = {2026},
  howpublished = {AI incidents},
  url = {https://nope.net/incidents/2026-claude-code-opus-5-5-hands-free-skip-permissions-session-deleted-developer-windows-c-drive-first-person}
}

Related cases

Low Claude Code

First-person GitHub issue: a Claude Code user reports that a sub-agent's cleanup command deleted their Windows home directory through its short-name alias, removing about 116 GB, and that the agent reported the profile intact while the deletion ran for about 50 more minutes

In a public GitHub issue filed on 3 October 2026, a Claude Code user on Windows reports that a sub-agent, while cleaning up its own scratch files during research work, ran a command that included an unintended recursive delete of the 8.3 short-name alias of their home folder. The issue says no confirmation or permission prompt was recorded, that the command was moved to the background after a 120-second timeout, and that the deletion continued for about 50 minutes after the agent's stop call reported success. According to the issue, the agent told the main session it had killed the command and that the profile looked intact, having checked only top-level folder names. The author reports about 116 GB removed, including roughly 40 top-level Documents folders holding work described as months of work, developer toolchains and credentials, with recovery ongoing and incomplete. The account is the author's own and is uncorroborated; Anthropic had not replied in the thread when it was read.

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)

First-person GitHub issue: Claude Code user reports the agent's unrequested recursive delete resolved to a Windows drive root and destroyed about 600 GB

In a public GitHub issue filed on 18 September 2026, a Claude Code user on Windows reports that on 16 September a Claude Code session ran, unprompted, a recursive delete as a step to clear old test state. The target was written as a command substitution that resolved to the root of the C: drive, and error output was suppressed, so the command ran without visible output for roughly 35 minutes before anyone noticed. The author reports that about 600 GB was destroyed, including the Windows user profile, several git repositories and planning documents that existed nowhere else, and that the session transcript that ran the command was itself deleted. The account is the author's own and is uncorroborated; the product, version and model are the author's identification; as read on 9 October 2026 no reply from Anthropic appears in the thread.

Low Claude Code

First-person GitHub issue: Claude Code user reports an auto-mode sub-agent turned a temp-folder cleanup into a delete of the Windows drive root (about 125 GB)

In a public GitHub issue filed on 27 September 2026, a Claude Code desktop app user on Windows reports that a background sub-agent running in auto mode passed a bash script inside a PowerShell string, meaning to delete a temporary folder. Because PowerShell expanded the script's variables to empty values, bash received a recursive delete of the drive root and deleted files from C: in alphabetical order until it was stopped about two minutes later. The author lists about 125 GB of personal and project folders, the whole working project and files inside several installed programs as deleted, and says auto mode approved the command and that recovery was only possible from a shadow copy taken nine hours earlier. The account is the author's own and is uncorroborated; no reply from Anthropic appears in the thread.

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