Claude Code told you it wrote the file. It told you the push succeeded. You moved on. Hours later you check, and the file is empty and the remote never moved.
This is a real failure mode on Opus 4.8 (1M context), and the dangerous part isn't that something got deleted — it's that nothing ran, but you were told it succeeded. Here's what's happening and how to catch it.
What's actually going on
When the model calls a tool (Bash, Edit, Write), it's supposed to emit a structured tool_use block. The harness sees that block, runs the command, and feeds the real result back.
Intermittently — usually deep into a long session — the model instead serializes the tool call as plain text: the raw <invoke ...> markup (with the antml: prefix dropped) shows up as literal text in the reply. The harness never sees a tool_use block, so the command never executes. And the model frequently keeps going as if it had: "File updated", "Pushed", "Done."
So this isn't only a stalled turn. It can be a silent no-op where you're told something succeeded that never happened. Reported repeatedly this week: #71812, #72015, #71952 (which has the fullest transcript-level analysis).
Why it slips past you
A deleted file announces itself — an error, a missing file. This failure is the opposite: the work was never applied in the first place, with no error and a stream of success-looking prose. You often find out much later, e.g. a git ls-remote showing the branch never moved. A whole afternoon of "all done" can hide a back half where not a single write landed.
When it tends to hit
- Long sessions, after one or more auto-compactions
- Non-ASCII-heavy sessions (#72015 points at this)
- Self-reinforcing: once it starts in a session, it tends to recur
How to catch it and stop the bleed
Until it's fixed upstream:
1. Treat any raw <invoke> / antml:-style markup in the visible reply as "the tool did NOT run." Don't act on the prose after it. Re-issue that step.
2. In a session that's started doing this, stop trusting success claims — verify ground truth before moving on:
# git operations
git status
git ls-remote origin <branch> # did the push actually land?
# file writes
ls -la path/to/file # mtime
stat path/to/file
# or just open it and look
"The model said so" is not evidence. The disk and git are.
3. Cut sessions before they degrade. Compacting/restarting rather than pushing one session for hours noticeably reduces recurrence. If you run with sub-agents / agent teams, test whether it reproduces with that off.
The one piece of good news
For the file-write case specifically: if the write never executed, your previous file contents are intact — nothing was overwritten. The cost is the wasted turn, not lost work — as long as you catch it before re-running a half-applied sequence. That's exactly why "verify before you continue" is the habit that matters most here.
This "success-shaped failure" shows up in more than one form — tool calls leaking as text, a verification step misreporting, a checkpoint silently reverting. I run Claude Code with real autonomy (800+ hours unattended) and keep the safety hooks I rely on in cc-safe-setup — npx cc-safe-setup, MIT, runs locally, sends nothing out. Happy to compare notes if you've hit this one.
Top comments (0)