A code comment character silently deleted a variable assignment, and the line after it turned del /F /Q "%WORK%" into del /F /Q "" — which doesn't fail, it deletes everything in the working directory.
What the source says
GitHub issue #92328, filed September 5, 2026 against Claude Code 2.1.224 (Opus) on Windows 11 with the OEM codepage set to 932 (Japanese locale): Claude's Write tool generated a .cmd helper script as UTF-8 with LF-only line endings — the tool's default output format, not a conversion of an existing file. cmd.exe doesn't parse batch files as UTF-8; it reads them against the system's OEM codepage. Under CP932, the final byte of a trailing full-width Japanese period ("。", UTF-8 bytes E3 80 82) in a rem comment is read as a CP932 lead byte, which consumes the newline immediately following it. That merged the comment line into the next line, set "WORK=C:\Temp\work.i64", so the set command never executed and WORK stayed unset.
The next line, del /F /Q "%WORK%", expanded with the unset variable to del /F /Q "" — which deletes every file in the current working directory rather than erroring or no-op'ing. Because the working directory was the repository root, 1,068 files were removed (subdirectories survived — del without /S isn't recursive); 123 existed nowhere else and were unrecoverable.
The reporter backed this with a hex dump of the offending line, an NTFS USN journal excerpt showing 1,068 FILE_DELETE records with zero matching RENAME records (ruling out a Recycle Bin move), and a deterministic reproduction: the identical file saved with CRLF line endings instead of LF does not trigger the bug. The issue is tagged has repro and high-priority, and StupidLLM's corpus marks it verified and reproducible on that basis.
What it doesn't establish
This is one report on one machine configuration. The trigger needs three things to line up: a non-UTF-8 OEM codepage (here, Japanese CP932), a multibyte trailing character in a generated comment, and LF-only line endings from the Write tool — it doesn't show how often Claude generates batch files with non-ASCII comments, or how common non-UTF-8 OEM codepages are among Windows users running Claude Code. The issue was open with no maintainer response as of publication, so there's no confirmation yet of the fix or its scope.
Why it's worth tracking anyway
Most destructive-agent incidents in this database come from a model choosing a broad or unscoped command. This one didn't: the batch script's logic was correct end to end, and the agent never decided to delete anything. The failure sits entirely in serialization — a text encoding mismatch between the tool that wrote the file (UTF-8) and the interpreter that read it (an OEM codepage), silently eating a newline and, with it, a variable assignment. %WORK% expanding to nothing and del /F /Q "" deleting everything instead of failing loudly is the second silent step that turned a parsing quirk into data loss.
If your agentic tooling generates Windows batch scripts, this is a case for auditing what encoding and line endings those scripts land on disk with — not just what commands they contain.
Top comments (0)