Claude Code now has two memory paths: project instructions such as CLAUDE.md, and auto memory that can accumulate learnings across sessions. That is useful for repeated workflows, but it also changes the recovery problem. The next session may inherit instructions that are stale, incomplete, or too confident.

Radar read: memory is a hint layer. A recovery packet still has to separate verified disk facts from remembered guidance, inferred claims, and old debugging habits.

Why this matters.

Claude's own memory documentation says memory is loaded as context at the start of sessions. It can describe build commands, architecture, preferences, and previous corrections. That saves time, but it does not prove that the current branch still matches those notes.

Cisco also documented a Claude Code memory compromise pattern where poisoned memory could persist into later sessions. The lesson is not to avoid memory. The lesson is to audit memory before letting it steer a high-impact recovery.

What to check first.

  1. Read the diff. Confirm what changed on disk before trusting a memory note about what was done.
  2. Check loaded memory files. Review CLAUDE.md, local memory, and rules that might be steering the next session.
  3. Separate facts from preferences. A build command can be verified. A remembered design preference may be stale.
  4. Look for surprising instructions. Treat new global rules, hooks, aliases, and auto-memory notes as part of the audit surface.
  5. Restart from a small packet. Give the next agent changed files, failed attempts, verified checks, and the next smallest action.

What ShardStitch does here.

ShardStitch does not replace Claude Code memory. It labels it. The useful packet says which facts came from disk, which claims came from a chat or memory file, which tests actually ran, and which next step is safest. That makes Claude Code memory useful without letting it become the only source of truth.

Source trail

Related pages