[BUG] Auto-memory silently rewrites user frontmatter (nests unknown top-level keys under `metadata:`); default dir collides with existing content

Environment: Claude Code 2.1.217 — VS Code extension, macOS 15 (Darwin 25.5.0)

Summary

With auto-memory enabled (the default), any file written via the Write tool into the auto-memory directory has its YAML frontmatter silently re-serialized under Claude Code's own schema. CC adds keys (node_type/type/originSessionId/modified, nested under metadata:) and moves any unrecognized top-level key underneath metadata:. There is no notice that user-authored structure was reorganized.

This breaks external tooling that reads those top-level keys. In my case a custom triggers: list — read by a UserPromptSubmit hook that routes memories into context — got relocated to metadata.triggers, my minimal YAML parser couldn't see it there, and every affected memory became silently invisible ("dark memory") until I noticed and patched my parser.

Two distinct issues

1. Silent frontmatter mutation. Reorganizing user-authored frontmatter (relocating unknown top-level keys under metadata:, injecting CC-managed keys) with no notice is surprising and breaks any reader that keys off the original top-level structure. At minimum this should be documented; ideally unknown keys are preserved in place.

2. Default-path collision. autoMemoryDirectory defaults to ~/.claude/projects/<sanitized-cwd>/memory/ — a conventional spot where users and tools already keep hand-authored content. Auto-memory claims that directory by default and starts rewriting files in it. For cwd = /Users/ryan, the sanitized dir is exactly ~/.claude/projects/-Users-ryan/memory/, which is where my existing memory system already lived, so auto-memory began intercepting writes to files it didn't create.

Repro

1. Auto-memory enabled (default).
2. Write tool → a file in ~/.claude/projects/<sanitized-cwd>/memory/ with a custom top-level key, e.g.:

```yaml
---
name: my_note
triggers:

• foo
• bar

---
body
```

1. Read the file back → triggers is now nested under metadata:, and CC-managed keys (node_type, originSessionId, modified) have been added.

Scope of the trigger (verified by probe): fires only on the Write tool targeting the memory dir. The same content written via shell/Bash, or written to any non-memory path, is left untouched. So it's the auto-memory Write-interception specifically, not a filesystem watcher.

Impact

Any workflow that stores structured, tool-consumed frontmatter in the default memory location is at risk of silent breakage — the file still exists and still passes a lint, but a downstream reader that expected a top-level key now finds it moved. Failure is silent: no error, no diff shown, no warning that the frontmatter was rewritten.

Workaround

~/.claude/settings.json:

{ "autoMemoryEnabled": false, "autoDreamEnabled": false }

Stops CC from managing/rewriting the directory. Effective after a CC restart. (Note: per #63903 this may not suppress the memory preamble; and autoDreamEnabled is undocumented per #76186.)

Suggested fixes

• Preserve unknown top-level frontmatter keys in place rather than relocating them under metadata:. If CC needs its own namespace, keep it additive and leave user keys untouched.
• Surface the rewrite — a one-line notice when auto-memory re-serializes a file it's ingesting, so silent mutation of external content is at least visible.
• Don't silently adopt a populated directory — if autoMemoryDirectory already contains files CC didn't author, warn before managing it (adjacent to #68368).

Related

• #25947 — store project memory files in a project-local .claude folder
• #48465 — allow MCP servers to replace the auto-memory backend
• #68368 — warn when auto-memory starts empty while populated stores exist for other paths
• #76186 — undocumented autoDreamEnabled + no recall-only mode
• #63903 — autoMemoryEnabled=false doesn't suppress the memory preamble