No process ID was actually being parsed here — just whatever digits happened to come first in a filename.
What the source says
GitHub issue #34210 documents a background routine in Claude Code, concurrentSessionCleanup(), that runs on every session start, every autocompact, and periodically thereafter. Its job is to remove stale <pid>.json lock files left behind by dead Claude Code processes in ~/.claude/sessions/. To do that, it lists every file in the directory, strips a trailing .json if one is present, and passes whatever's left to JavaScript's parseInt(name, 10) — without ever checking that the full filename was actually numeric.
parseInt reads only the leading digits of a string and silently discards the rest. So a file named 2026-01-01_notes.md parses as PID 2026. If no process with PID 2026 happens to be running — and the platform isn't WSL, which the code explicitly exempts — the routine calls fs.unlink() on the file directly. No confirmation prompt, no warning, nothing written to a log, and no trash folder to recover it from.
The reporter (michaelk-q) reproduced the bug in three steps: create a digit-prefixed file inside ~/.claude/sessions/, start a second Claude Code session, watch the first file disappear. They filed the issue with the exact vulnerable code path and a one-line fix already spelled out: if (!/^\d+\.json$/.test(file)) continue;. Anthropic labeled the issue bug, data-loss, and high-priority — then closed it with zero comments and no visible maintainer response.
What it doesn't establish
This is a single filed report, not a measured incidence rate across Claude Code's install base. The bug is real, verified, and independently reproducible from the code alone — parseInt's leading-digit behavior isn't in dispute — but there's no data here on how often users actually put digit-prefixed files into ~/.claude/sessions/ in practice, since it isn't a directory most people would think to store personal files in. Severity is scored medium (4.0): the destructive mechanism is unconditional and undetectable in the moment, but the blast radius depends on a user habit — dropping files into an internal tool directory — that the report doesn't establish as common.
Why it's worth tracking anyway
The interesting failure isn't the deletion — it's the closed issue. This is a maintenance routine, not a model making a judgment call, running unconditionally on every session start and autocompact with a fix already handed to the maintainers in the bug report. data-loss and high-priority are Anthropic's own labels on their own tracker. A one-line, code-supplied fix sitting unmerged behind a silent close is the same pattern this database keeps finding elsewhere: destructive-by-default behavior surviving not because it's hard to fix, but because nobody circles back to files like this once they stop making noise.
Top comments (0)