← All writing

Post-mortem

A laptop migration deleted my AI's memory

Aug 14, 2026

My AI assistant's learned rules lived where the tool put them by default: on the machine. One migration later, the index pointed at 17 files that no longer existed.

A laptop migration deleted every memory my AI assistant had learned. Root cause: custody. Fix: memory moved into the git-tracked workspace, and a missing body is now a loud FAIL.

An AI tool's default memory path is a quiet bet that you will never change machines. On 2026-06-27, moving my whole setup from a Mac to a Windows PC, I lost that bet.

What actually got lost in the migration?

My assistant's long-term memory is small markdown files: one index with a line per memory, one body file per entry. Each body is a decision rule (when this trigger fires, do that action) distilled from a real mistake. Several of them reference people and properties, so I won't quote any here; the pattern is the story.

The platform's default put those files at ~/.claude/…/memory/, a per-project folder in the home directory. That path is machine-local. It sits outside the synced workspace and outside git's version history. When the new machine came up, the index had survived, and all 17 body files it pointed to were gone. Every link resolved to nothing. No error, anywhere, ever.

The only reason this post-mortem has a recovery section is that the old laptop still existed. All 17 bodies came back from its local store and were committed to git the same day. If that Mac had been wiped first, all of that accumulated judgment would have vanished without a single message saying so.

Here is the critical part, plainly: the default stored my agent's most durable asset in the least durable place on the disk. For a chat toy, that's fine. For an agent running real work, it's a design failure, and it is still the default.

Where should agent memory live?

Inside the workspace, under version control, nowhere else. The repair inverted custody. The canonical store (canonical: the one authoritative copy) now lives in the git-tracked workspace itself, which travels two independent ways: a git remote and cloud file sync. It holds 41 tracked bodies today, up from the 17 recovered.

The machine-local folder wasn't deleted; it was demoted. The file at the old default path is now pointer-only, and its header is written for the next AI agent that lands there: "DO NOT STORE MEMORY HERE," naming this exact incident as the reason. The warning targets the agent rather than me, because the app keeps defaulting new writes to that folder. A rule the tool won't enforce has to be posted where the tool's agent will actually read it.

One sharp edge worth admitting: inversion breaks old assumptions. A maintenance step from before the incident copied the local store over the mirror; run after the repair, it would have overwritten canonical memory with the pointer file. It had to be flagged before any re-enable. Flipping custody means auditing everything that used to copy in the old direction.

What stops the next loss from being silent?

Nothing stops the next loss. Something now makes it loud when it happens. _check-memory-integrity.sh is a deterministic check (same inputs, same verdict, no model judgment) that encodes this exact incident: an index link that resolves to a missing body is a FAIL. The script's own comment reads "this is the exact failure that hit us."

Around that core it watches the quieter rots. A body file missing from the index is a WARN. Uncommitted changes in the memory folder are a WARN, because memory that exists on only one sync layer is halfway to lost. And the index carries hard size caps (warn past 22 KB or 170 lines, fail past 24 KB or 195) so it stays an index instead of swelling into a second policy manual. The whole thing emits one status line, the worst of PASS/WARN/FAIL, and the workspace startup check wraps it at session start and on every push.

The governing rule file is blunt about the limit: the check is evidence only when it runs; its presence enforces nothing. That honesty is load-bearing. This whole system runs on "cannot fail silently," never "cannot fail" — memory is one layer of a larger verification stack.

An agent's memory is configuration, and configuration sitting on a vendor default gets reviewed by exactly no one. If your assistant has learned anything worth keeping, it is worth knowing which disk that learning is on.

So: where does your agent's memory live right now — and if you switched machines tomorrow, what, specifically, would tell you what didn't make it across?

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

@online{ali2026memorymigration,
  author = {Ali},
  title  = {A laptop migration deleted my AI's memory},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-memory-lost-in-migration/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.