Agent chaosAs reported·9 Nov 2026
Claude Code can delete the debug log it is writing when log rotation fails, a bug report says
As reported One person’s public account. We couldn’t independently confirm it, and we’ll update this if the facts change.
A bug report says that when Claude Code's debug log passes 10 MiB and the rename to the backup file fails, the tool deletes the backup path, retries, and if that fails too, deletes the live log the session is writing. No error, no message. One GitHub report with reproduction steps; not independently confirmed.
This is one person's account on GitHub, not independently confirmed. The report was filed on 8 November 2026 against Claude Code 2.1.319 on Linux and includes step-by-step reproduction instructions.
What happened
Claude Code can write a debug log to a file you choose. When that log grows past 10 MiB, the tool rotates it: it renames the current file, for example y.txt, to y.1.txt and starts a fresh y.txt.
According to the report, if that first rename fails with any error other than 'file not found', Claude Code deletes whatever sits at the y.1.txt path and tries the rename again. If the second rename also fails, it deletes y.txt, the log the session is actively writing. Nothing records it: there is no line in the log and no message on screen. The next line simply starts a new, empty log.
How it went wrong
The reporter traced the behaviour to the end of the log rotation routine in the 2.1.319 build and quoted the minified code. Both code paths, the plain file-system one and the storage-backend one, have the same shape: after a second failed rename, the fallback is to delete the live log.
To show it, they made a log just under 10 MiB with a marker on its first line and put a directory where the rotated file would go, so the rename had to fail. They then ran a one-line Claude Code prompt with that file as the debug log. Afterwards the 10 MB file was gone, replaced by a 30 KB file holding only that run's later lines. The marker had vanished, while the blocking directory was untouched.
A control file with nothing in the way rotated normally. The reporter also says a regular file made immutable at the backup path gives the same result: the 10 MB live log was deleted and the immutable file kept its contents.
Why it matters
A debug log is often the only record of what an agent did during a session. If the safety net for rotation is 'delete it and carry on', a full disk, a permissions problem or a locked file can silently destroy exactly the evidence you would want after something goes wrong.
Our take
This is our opinion: fallbacks that delete data should be the last resort, not the second step, and should always say so loudly. If you rely on agent logs for audits, ship them somewhere the agent process cannot overwrite.
Never let a cleanup fallback delete the live copy: fail loudly and keep the evidence, especially for agent logs.
