The user asked for a landing page. Something deleted their login keychain.
What the source says
GitHub issue #93408 on anthropics/claude-code, filed September 10, 2026: a user was building a website — a landing page with a scroll-driven canvas animation referencing a video in ~/Downloads — using the Claude desktop app's Claude Code integration (v2.1.260) on macOS, working out of a project folder under ~/Desktop. They approved the macOS permission prompts the app presented: Files and Folders, Documents, and Media & Apple Music.
Over roughly five minutes (22:43–22:48 SGT, per sequential directory-modification timestamps), the contents of ~/Desktop outside the active project were deleted, along with ~/Music, ~/Movies, ~/Pictures, ~/Public, ~/Sites, part of ~/Downloads, ~/.ssh, the .zsh_history file, and ~/Library/Keychains outright. macOS subsequently reported the login keychain missing and signed the user out of iCloud. ~/Documents was the one major folder left untouched. None of it went to Trash.
Here's the part that makes this harder to write off as just another rm -rf story: the local session transcripts under ~/.claude/projects for the affected sessions contain no Bash tool calls at all — only bridge-session bookkeeping. There is no local record of which command, tool, or code path actually did the deleting. The reporter filed a support ticket with Anthropic and handed over the affected session IDs so the company could pull server-side transcripts, since the client-side audit trail was empty.
The issue is labeled area:bash, area:desktop, area:sandbox, bug, data-loss, high-priority, and platform:macos. As of publication it's open, with no confirmed root cause and no visible maintainer response.
What it doesn't establish
This is a single user report, not an independently reproduced failure — nobody outside the reporter (and, privately, whoever at Anthropic pulls the server-side logs) has confirmed what actually executed. "Verified" in this database's sense means the incident is checked against the primary source, the GitHub issue itself — it does not mean the deletion mechanism has been confirmed. Approving a macOS permission prompt is not, on its own, evidence that the desktop app's own logic performed the deletion in the way the user assumes; it's evidence the app had access to do so. Whether the actual cause was a scoping bug in a file-operation tool, a shell command that isn't showing up in the transcript for some other reason, or something else entirely is exactly what the missing audit trail leaves unanswered.
Why it's worth tracking anyway
This database already has more than one "coding agent deleted way more than it was asked to" entry — an errant ~/ on the end of an rm -rf, a $HOME reassignment, a full-drive wipe from a single-file delete request. What's different here isn't the blast radius, it's the visibility gap. In every one of those other cases, there was at least a command to point at — a specific string you could read and see exactly where it went wrong. Here, the tool that's supposed to log what it did recorded nothing, on a session where something clearly ran and deleted a login keychain. An agent's destructive potential is usually discussed as a permissions problem — what should it be allowed to touch. This case is a logging problem: even after the fact, with the user's full cooperation and Anthropic's own support process engaged, there may be no answer to what actually happened.
Top comments (0)