Correct direction — crash-midwrite leaving the snapshot store corrupt is a real operational hazard, and temp-file + rename is the right basic pattern. BUT this PR is weaker than the existing atomic-write patterns the codebase already uses. The PR cites hermes_cli/auth.py as the model, so let's compare:

hermes_cli/auth.py (existing, correct):

with open(tmp_path, "w") as handle:
    handle.write(json.dumps(data))
    handle.flush()
    os.fsync(handle.fileno())       # <-- flush data to disk
os.replace(tmp_path, auth_file)
try:
    dir_fd = os.open(str(auth_file.parent), os.O_RDONLY)
    os.fsync(dir_fd)                # <-- persist the rename too
    os.close(dir_fd)
except OSError:
    pass

This PR:

_tmp.write_text(json.dumps(data, indent=2))
_tmp.replace(_SNAPSHOT_STORE)

Path.write_text() does not fsync — it writes to the page cache and returns. replace() then renames, which IS durable for metadata on journaled filesystems, but the data behind the filename may still be in the page cache. If the kernel panics or the machine loses power between these two steps, you can end up with:

• A zero-length target file (rename committed but data pages hadn't been flushed)
• A target file pointing at old data (rename happened with new name, new contents not flushed)

Process-level crashes (SIGKILL, OOM, Python exceptions) ARE handled correctly by the PR as-is — the OS completes the page-cache writes after the process dies. It's only hardware-level crashes (kernel panic, power loss, hard reboot) that expose the bug. Whether that's a meaningful risk depends on how operationally important snapshot IDs are.

Given that the PR description frames this as a crash-recovery fix, it's worth going all the way:

def _save_snapshots(data: Dict[str, str]) -> None:
    _SNAPSHOT_STORE.parent.mkdir(parents=True, exist_ok=True)
    _tmp = _SNAPSHOT_STORE.with_suffix(f".tmp.{os.getpid()}")
    try:
        with open(_tmp, "w") as f:
            f.write(json.dumps(data, indent=2))
            f.flush()
            os.fsync(f.fileno())
        _tmp.replace(_SNAPSHOT_STORE)
    except Exception:
        _tmp.unlink(missing_ok=True)
        raise

Three small additions vs the PR:

1. fsync before rename — ensures data is on disk, not just in page cache
2. os.getpid() in tmp suffix — prevents two processes racing to write the same .tmp file (process A writes, process B overwrites, process A renames B's data)
3. try/finally with unlink — cleans up stale .tmp files when the write fails partway (disk full, perm error, etc.)

Without (1) the fix doesn't deliver its stated goal.
Without (2) concurrent writers corrupt each other. Probably rare in practice for snapshot stores.
Without (3) you accumulate stale .tmp files over time.

Core pattern is correct. Promote to the auth.py level of rigor to actually close the crash-recovery gap.