It Deleted the Home Directory. Nothing Local Says What Ran.

The report is short on mechanism and long on consequence, and both of those facts matter.

anthropics/claude-code issue 93408, opened 10 September 2026, describes a user asking Claude Code's desktop app to build a website: a landing page with a scroll driven canvas animation, referencing a video that lived in ~/Downloads. Building that page meant the app needed to read from folders outside its own project directory, and macOS asked the user to approve that, through its own Files and Folders, Documents, and Media and Apple Music permission prompts. The user approved them. Within about five minutes, on the reporter's own account, most of the home directory was gone.

What the reporter's own account describes

Between roughly 22:43 and 22:48 SGT (14:43 to 14:48 UTC) on 10 September 2026, the report states that the following were deleted or emptied: everything in ~/Desktop other than the active project folder; ~/Music, ~/Movies, ~/Pictures, ~/Public and ~/Sites, which macOS then silently recreated empty, as it does with several of its own standard folders; part of ~/Downloads; the entire ~/Library/Keychains directory, including the login keychain, after which macOS reported Keychain Not Found and the user separately lost their iCloud sign in under System Settings; and all of ~/.ssh, every key and configuration file in it. ~/Documents is reported untouched. Nothing went to the Trash. Directory modification timestamps are reported to show a sequential pass across roughly five minutes, not a single instant, and ~/.zsh_history was itself reduced to two lines.

What is not established

The reporter states they cannot identify what actually executed, and this record takes that at face value rather than filling the gap. Local session transcript files under ~/.claude/projects for the three sessions active around the incident are reported to contain only bridge-session bookkeeping and queue-operation stubs. No Bash tool invocation is recorded in any of them. The desktop app's own session history is reported to show the affected sessions as empty. Shell history was itself truncated to two lines, so it offers no independent record either. The reporter's own stated request to Anthropic is to pull server-side transcripts for the three affected sessions and identify the command that ran, precisely because nothing locally available does.

This record cannot go further than the reporter's own evidence allows, and it will not manufacture a mechanism to make the story more legible. It does not know whether a Bash tool call happened and was not recorded locally, whether some other tool or a background process was responsible, whether the desktop app's own file-access layer behaved differently from what its documentation describes, or whether the .last-cleanup artifact is connected to the deletions at all. As of this record's own 12 September 2026 verification, the issue is open, carries the labels area:bash, area:desktop, area:sandbox, bug, data-loss, high-priority and platform:macos, has no assignees, and carries no maintainer comment, no stated root cause and no linked pull request.

What a permission prompt actually grants

Set the mechanism aside for a moment, because the incident raises a question that holds regardless of how it eventually turns out to have executed. macOS's own Files and Folders, Documents, and Media and Apple Music prompts ask a user to grant an application the technical ability to read (and, depending on the entitlement, write) within a class of locations. That is a reachability decision. It says nothing on its own about which specific files within that reach an application is expected to touch, and nothing about whether deletion, as opposed to reading a video file to reference in a webpage, was ever part of what the user pictured themselves approving. A user who grants Media and Apple Music access so an agent can read one video file has not, by that act, indicated any view at all about whether the login keychain or an SSH directory should be reachable for deletion, and those two locations are not normally covered by the same consumer-facing permission category a user would associate with letting an app see their Pictures folder.

Nothing in the reporter's account suggests the user was asked to approve, or understood themselves to be approving, a deletion outside the project's own working folder. If broad filesystem reachability did turn out to be part of what let this happen, whatever the specific mechanism, that would be a familiar shape: a technical grant of reach substituting for a decision nobody made about the narrower thing that actually happened. This record does not assert that is what occurred here, because the reporter's own evidence does not establish it. It states the distinction because the incident is a clean illustration of why the distinction matters independent of this one case's own eventual explanation.

Where this does and does not connect to existing coverage

This is not the same shape as this desk's own coverage of a Claude Code session that ran terraform destroy against production infrastructure. That incident had a fully legible mechanism: a specific command, proposed by the agent and not stopped by the user, that Terraform itself had already described in advance. This incident has no equivalent record at all of what ran. It is closer in shape, though not in evidence, to an agent deleting a database and its backups in nine seconds and to Replit's agent deleting a user's data, incidents this desk has already covered where a destructive action reached further than a human account had prepared for; this one adds a distinct wrinkle neither of those carried, an audit trail that itself does not exist.

This desk's own living coverage of Claude Code's permission model documents that Anthropic states its auto-mode classifier blocks, by default, mass deletion on cloud storage and irreversibly destroying files that existed before the session. This record notes that documented protection without claiming it bears on this incident one way or the other: nothing in the reporter's account establishes whether the desktop app's destructive action passed through that classifier, or whether a classifier ran at all. Recording that connection, and declining to resolve it, is the more honest position than picking a side the evidence does not support.

What this record is asking readers to take from it

Not a conclusion about what Claude Code did. A statement about what is currently known, which is less than the severity of the outcome makes it tempting to assume. A user approved permission prompts that made a class of files reachable. Something then deleted content well outside what the task at hand required, including two of the most sensitive locations in a macOS home directory. Nobody, as of this record's own verification, including the person who experienced it, has a record of the command that did it. That last fact is not a footnote to the incident. It is the reason this record exists rather than a shorter one naming a cause.