[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug: Claude Code auto-memory layer intermittently blanks a memory file's YAML frontmatter (silent data loss)

Summary

Claude Code's auto-memory subsystem re-serialises a project memory file's YAML frontmatter every time the file is edited during a session. Normally this is non-lossy (it adds metadata.node_type: memory, re-quotes strings, and preserves name/description/type). But intermittently it writes the frontmatter back with name: "" and the description/type fields dropped — leaving only metadata.node_type: memory + an originSessionId. The file body is always intact; only the frontmatter is corrupted. It is silent — no error, noticed only on re-read.

Impact / severity

Medium — silent data degradation of memory metadata. A blanked name: breaks [[slug]] cross-links (they resolve by name); a dropped description: removes the recall-relevance hook. Accumulates across sessions: 3 of 268 files corrupted in one project.

Affected component

The per-project auto-memory store (~/.claude/projects/<slug>/memory/*.md) and whatever re-serialises its frontmatter on edit. NOT caused by user Edit/Write tools, git hooks, CI, or project size (the subsystem never reads the codebase).

Environment

Claude Code (CLI), Claude Opus 4.8, Windows 11. Memory store mixes two frontmatter schemas (metadata.type: and metadata.node_type: memory), suggesting a partial schema migration.

What we observed

1. A file with name: metamagic-transformer + a ~2KB description + metadata.type: project was edited several times in quick succession.
2. On next read: name: "", description/type gone, metadata.node_type: memory, and originSessionId re-stamped with the CURRENT session's UUID (only the harness knows that → confirms the harness rewrote it). Body unchanged.
3. We later watched the NON-lossy path live: editing two other files, the re-serialiser ran immediately after each edit and preserved name/description/type. So re-serialise-on-edit is normal; the field-dropping is the intermittent failure.

Steps to reproduce

Not reliable (intermittent). Best-effort: make several rapid successive edits to a file under ~/.claude/projects/<slug>/memory/*.md, then re-read its frontmatter; occasionally name is "" and description/type are gone. Correlated with bursts of rapid edits, NOT with description size (a short-description file was hit; a 2KB one survived a restore).

Expected vs actual

Expected: frontmatter re-serialisation is lossless, or aborts with an error if it can't round-trip. Actual: occasionally persists blank name + dropped fields, silently.

Likely cause (speculative)

A race / transient failure in the re-serialiser during rapid writes — appears to persist a partial/empty parse result.

Suggested fix

Make the on-edit re-serialisation atomic and lossless (parse → validate required keys present → only then write; abort + surface an error on failure). Consider not re-serialising frontmatter the edit didn't change.

What Should Happen?

See above

Error Messages/Logs

Steps to Reproduce

See above

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code version 2.1.128.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_