A Claude Code Session Deleted 200GB and the Evidence That Could Show Why — No Permission Prompt, No Explanation, No Reply

A Claude Code user lost roughly 200GB from their home directory — SSH keys, AWS and GitHub CLI credentials, a Turso config — with no permission prompt at any point, and the one artifact that might show which of two concurrent sessions did it was destroyed in the same sweep.

What the source says

GitHub issue #83058, filed August 1, 2026 against Claude Code 2.1.220 on macOS 26.5.2 running claude-opus-5, open and now labeled stale with no maintainer reply. The reporter had two Claude Code sessions open in the same VS Code workspace, working out of a project directory. At 22:46:11 local time a database file under ~/.claude-mem was unlinked while still open — the first sign of trouble. A /bin/rm process then emptied ~/Desktop, deleted the Turso CLI's config directory, and reduced the active project to a bare .DS_Store, all without a single approval prompt despite the delete reaching well outside the project's working directory.

The reporter noticed at 22:52 and asked the session what had happened, but the deletion was still running through ~/Downloads at 22:56. They rebooted a minute later, which cut it off before it reached ~/Library, ~/Movies and ~/Pictures. By then ~/.ssh, ~/.config/gh, ~/.aws, ~/.cargo and the local Claude Code session logs were already gone.

What it doesn't establish

This is a single first-hand report with no reproduction and no maintainer confirmation of cause. The issue is explicit about what it can't prove: with two sessions running concurrently and the destructive sweep itself erasing the transcript the reporter suspected, there's no audit trail that pins the rm on Claude Code rather than some other process sharing the shell. The reporter's own closing questions — which session ran the command, whether Remote Control was active, what the second session was doing — are addressed directly to Anthropic and remain unanswered. Nothing here confirms a specific defect in Claude Code's permission logic; what's confirmed is that no approval prompt appeared before 200GB, including credential stores, was gone.

Why it's still worth logging

Even without a root cause, the shape of the failure matters: a destructive filesystem operation that walks past the project boundary into credential directories, with no gate catching it and no record surviving to explain it. An unanswered "stale" issue is itself a data point about how this class of report gets handled.

Full incident record: https://www.stupidllm.com/incident/STUPID-2026-0128/