Memory files gain claudeCodeItem metadata, with recall stripping built in but not yet active

What

Claude Code keeps memory files, which are Markdown (.md) notes it saves and reads back in later conversations. This build adds groundwork for tagging those notes with a new metadata block called claudeCodeItem. The block is stored in the file's frontmatter, the short YAML section at the top of the file.

• claudeCodeItem holds an id, a state (legacy, pending, acked or suppressed), consent, account, src, a scope (person, repo or unknown), promoted and ids.
• Writes to memory files now validate this metadata before saving it. Some writes are refused, for example when the model copies an id that was already recorded, or when item keys are present.
• Every write entry point returns early when the hook object te is null, so none of this does anything unless that object is set.
• Reading a memory file back (recall) goes through a new function, K9. Its first step reads the file and returns straight away, so the code after it never runs.
• That unreachable code would remove the claudeCodeItem block from a recalled file, hold back its headers, and report when a file had to be skipped because its block could not be taken out.

In this build, recall still reads memory files as before, limited by a maximum number of lines and bytes.

Why

For now, nothing changes in how memory files are read, and the new write checks only act when the hook object is set. The sweep agent read the shape of the metadata (account, consent, scope) as groundwork for syncing memory items to an account or a shared store, with the header meant to be hidden from Claude when it recalls a note. That is its reading, not something the code confirms. If you look inside your memory files, you may start to see a claudeCodeItem block in the frontmatter once this is switched on.