Encoding mismatch let a Claude Code batch script delete 1,068 files

What happened

A GitHub issue filed on September 5, 2026 against Claude Code 2.1.224 (Opus) documents how a Windows batch script generated by the tool deleted 1,068 files from a user's repository. According to a dev.to write-up of issue #92328, the environment was Windows 11 with the OEM codepage set to 932, the Japanese locale — and the damage came not from a reckless command but from a punctuation mark.

How a period ate a newline

Per the dev.to post, Claude Code's Write tool emitted a .cmd helper script encoded as UTF-8 with LF-only line endings, its default output format rather than a conversion of an existing file. cmd.exe does not parse batch files as UTF-8, though; it reads them against the system's OEM codepage.

Under CP932, the final byte of a trailing full-width Japanese period in a rem comment — bytes E3 80 82 in UTF-8 — is treated as the lead byte of a multibyte character and consumes the newline immediately after it. That fused the comment line with the next line, set "WORK=C:\Temp\work.i64", so the assignment never executed and WORK remained undefined.

The line after that, del /F /Q "%WORK%", expanded the empty variable into del /F /Q "". Instead of failing or doing nothing, that command deletes every file in the current working directory. Since the working directory was the repository root, 1,068 files were removed. Subdirectories survived because del without /S is not recursive, but 123 of the deleted files existed nowhere else and are unrecoverable.

The evidence behind the report

The dev.to article notes that the reporter backed the claim with a hex dump of the offending line and an NTFS USN journal excerpt showing 1,068 FILE_DELETE records with zero matching RENAME records, which rules out a Recycle Bin move. There is also a deterministic reproduction: saving the identical file with CRLF line endings instead of LF does not trigger the bug. The issue carries "has repro" and "high-priority" labels, and StupidLLM's corpus marks it verified and reproducible on that basis.

What the report does not establish

This is one report on one machine configuration. The failure needs three conditions to line up: a non-UTF-8 OEM codepage, a multibyte character at the end of a generated comment, and LF-only line endings from the Write tool. The issue says nothing about how often Claude generates batch files containing non-ASCII comments, or how common non-UTF-8 OEM codepages are among Windows users of Claude Code. As of publication the issue was open with no maintainer response, so neither a fix nor its scope has been confirmed.

Why it matters

Most destructive-agent incidents happen because a model picks a command that is too broad or unscoped. This one is different: the script's logic was correct from start to finish, and the agent never decided to delete anything. The failure lives entirely in serialization — a text-encoding mismatch between the tool that wrote the file and the interpreter that read it, which silently ate a newline and, with it, a variable assignment. The second silent step was %WORK% expanding to nothing and del /F /Q "" deleting everything rather than failing loudly.

For anyone whose agentic tooling generates Windows batch scripts, the takeaway is to audit the encoding and line endings those scripts land on disk with — not just the commands they contain.