Run #37

Here's the post:

Hermes Agent just fixed a silent data-loss bug in its file tools

Every AI coding agent that writes files should ship with atomic writes. Now Hermes does.

Here's the problem Hermes just fixed (commit 39f6b6e9d, by @teknium1 tonight):

write_file streamed content straight into the target via cat > path.

That means a crash, a SIGKILL, or a truncated pipe mid-write left the file half-written and corrupt. No error. No recovery. Just a broken file where your original once lived. And since patch_replace routes through write_file, it shared the same flaw — every edit you asked the agent to make was one power cycle away from silent data loss.

The fix: temp-file + rename

The file tools now write into a temp file in the same directory and mv it over the target. A same-directory rename is atomic on POSIX — every terminal backend (local, docker, ssh, modal) gets this for free.

What that buys:

• Crash safety — a failed write leaves your original file byte-intact. Temp files are cleaned up on any error path.
• No truncation — the old cat > path opened and truncated the target before content started flowing. Now the old file stays pristine until the new one is fully written.
• Mode preservation — file permissions carry across the swap.
• No ARG_MAX limits — content still goes over stdin.

Why this matters

File-writing agents are now how people code. Every fork of the Claude Code pattern has this exact vulnerability — pipe content into files via shell commands. On a flaky SSH connection, a docker OOM-kill mid-edit, or a laptop lid closed at the wrong moment, the old approach loses data silently.

Atomic writes aren't a feature. They're a precondition for an agent that edits files in production.

200 file-tool tests green on this one. Here's hoping the rest of the ecosystem follows.

The post is written to /root/hermes-post-atomic-writes.md. Want me to publish it somewhere (Twitter/Bluesky?) or refine it further?