Chapter 23. Where Memory Lives When the Session Ends

What a session figured out goes in a file outside the session: for me that is the Codex Claude Memory Vault, a directory in Google Drive that either machine can reach, holding handoffs, decisions, and maps of the estate. An agent reads it top-down before it touches a repo, and writes a dated handoff back on the way out. A session dies with its context window. The commits survive and the deploys survive, but the judgment that produced them evaporates: which fix got tried first and abandoned, why the port moved, what the next step was supposed to be. On an operation with two computers and more than one agent lineage, that judgment has to land somewhere every machine can reach, or each new session opens by re-deriving the last one. The vault is the spine that runs between machines when everything else about a session is gone.

The vault is also where the hierarchy of truth from chapter 6 takes its operational test. A memory system that documents itself is subject to the same drift as any other artifact, and mine has already documented itself wrong.

The two vaults: Codex Claude Memory Vault and Suede-Vault

I run two durable memory homes, one in Google Drive for agent continuity and one at ~/code/Suede-Vault for company source of truth, and mixing them up wastes real time.

The Drive vault is the continuity layer: what an agent reads on the way in and writes on the way out. The Suede-Vault is the Obsidian vault that doubles as the Suede Labs AI source of truth, and it travels as a git repo on the personal account. When I say “second brain,” “Obsidian,” or “SoT,” those three terms resolve to one destination: the Suede-Vault. An agent that treats them as three places goes hunting for two that don’t exist.

The two vaults even number their directories the same way with different separators. The Drive vault writes 05_handoffs/ with underscores; the Suede-Vault writes 05-Sessions/ with hyphens. The difference is enough to make a guessed path fail, which matters more than it sounds like it should, because on this filesystem a failed lookup does not mean what it means on a local disk.

What a cold agent reads first, in order

An agent starting cold on Suede work reads the vault before it touches a repo. The read runs top-down: the start-here note, the agent protocol, the project’s own note, the newest handoff for that project, and any decisions that handoff links. The written order is 00_START_HERE/00_START_HERE.md, then the vault AGENTS.md, then 06_agents/Agent_Update_Protocol.md, then the project note under 03_projects/, then the newest handoff under 05_handoffs/, then any decisions those link under 04_decisions/.

The shape of that order carries the logic. General rules come first because they apply to whatever the task turns out to be. The project note narrows to one surface. The newest dated handoff is the highest-resolution layer and the shortest-lived one, so it reads last and wins ties on recency. Decisions sit apart from handoffs on purpose: a handoff claims “this was true at the end of my session,” while a decision claims durability, and the bar for writing one is higher. The convention is explicit: a durable decision only gets written under 04_decisions/ once I have confirmed it is a stable rule. An agent does not promote its own conclusion to a decision.

An agent that skips the bootstrap doesn’t fail loud. It fails the way the redundant fix fails: it spends an hour rediscovering a constraint the last session already wrote down, or it re-proposes something a decision already killed. The cost is invisible inside the session and obvious across ten of them.

Why a hardcoded home path breaks the mirror on the second machine

The canonical vault path as written in my instructions targets a home directory of /Users/jason. This machine’s home is /Users/jasoncolapietro. The standing rule is to substitute the equivalent path, and that one-segment difference has already produced a real failure.

The Suede-Vault carries a mirror of Claude’s own memory at 04-Memory/claude-memory/MEMORY.md, refreshed by a script. The script targets a home path spelled -Users-jason. On this machine the real segment is -Users-jasoncolapietro, so the script found nothing to mirror and the file stopped refreshing on 2026-07-13. It raised no error. It sat stale for ten days until a 2026-07-23 audit caught it. Nothing about the file looked wrong; it read as a current memory snapshot that happened to be missing everything recent.

A memory mirror wired to a hardcoded home path fails without a sound on the second machine, and staleness has no error state. Multi-machine paths are a failure surface, not a detail, and the check is not “does the file exist” but “when did it last change.”

Two Google Drive failures that look like a missing vault

Google Drive is a streaming mount, and it fails in two distinct ways that both look like “the vault is missing.” Each needs its own check, and applying the wrong one wastes the session.

The first is lazy loading. On 2026-05-24, broad scans such as find -maxdepth 3 did not find the vault subdirectory at all. Drive does not materialize a subdirectory to a scan until something pokes it by name. The rule that came out of it:

# Address the exact path. A broad scan proves nothing here.
ls "$VAULT"

On a lazy-loading network filesystem, absence from a scan is not evidence of absence. Address the literal path you care about before concluding anything is missing.

The second failure is the daemon being down. On 2026-06-08, ls on vault directories worked while file content reads timed out with Operation timed out / ETIMEDOUT. Directory metadata is cached on disk, so listings succeed with the Google Drive app not running; the FUSE mount cannot hydrate file bytes without the daemon. The filesystem was half-alive: structure present, contents unreachable. The diagnostic:

pgrep -f "Google Drive"       # empty means the daemon is down
open -a "Google Drive"        # then wait ~15s for streaming to come up
# retry reads with a short backoff; each file hydrates on first read

Network health proves nothing about the daemon. A clean ping to google with reads still timing out is the signature of this failure, not a refutation of it.

One contradiction in my own records belongs here rather than swept under the prose. The index line for the vault memory states “Reads AND writes verified working without the Drive app installed,” while the body of the same memory records content reads timing out when the app or daemon is not running. App-not-installed and daemon-not-running may be different states with different behavior, but the two statements sit unreconciled in the sources. When they collide in practice, I trust the dated incident over the summary line, which is the same rule this whole chapter runs on.

The handoff write procedure, and the fallback when Drive is down

A handoff that fails to write is worse than no handoff, because the session that wrote it believes the memory exists. The write procedure assumes the filesystem is hostile:

1. ls the 05_handoffs/ path first.
2. If it succeeds, write to the vault.
3. If it returns ENOENT, try once more: Drive may need the poke to materialize the directory.
4. If it still fails, drop to the Dropbox fallback at /Users/jasoncolapietro/Dropbox/My Mac (Jasons-MBP.hsd1.fl.comcast.net)/Downloads/ and let the file get synced into the vault when Drive returns.

That fallback path has the machine’s hostname baked into the folder name, Comcast residential, Florida. It is ugly and it works, and Codex handoffs have parked there through Drive outages waiting to be carried home.

Naming carries the rest of the discipline, because two agent lineages write into the same directory. Claude handoffs are YYYY-MM-DD-claude-suede-<short-task>.md with no -handoff suffix; Codex agents write YYYY-MM-DD-codex-<short-task>-handoff.md. When the convention was recorded on 2026-05-24, the directory held 2 prior Claude entries. The date prefix means a bare ls -1 reads as a timeline, and the agent token means provenance survives without opening the file. A dated filename is the cheapest metadata system that cannot drift, because it cannot be edited apart from its content.

Where the vault ranks against git and the live URL

Chapter 6 set the hierarchy: git holds the truth about code, the live URL holds the truth about deployed behavior, and the current terminal holds the truth about this session. The vault ranks below all three. It orients the work; it does not adjudicate it. A handoff that disagrees with git log is wrong. A project note that disagrees with the live endpoint is stale. The vault’s word is never the last word, and 2026-07-23 is the day that rule proved itself against the vault I trust most.

The Suede-Vault, the source of truth itself, documented itself wrong. Two files inside it, 04-Memory/claude-memory/obsidian_vault.md and vault_save_infrastructure.md, describe the older setup: a vault at ~/Documents/Suede-Vault, a Suede-AI org remote, and vault-save tooling. A 2026-07-05 session had superseded all three on this machine. The vault lives at ~/code/Suede-Vault, the remote is the personal suede-vault-backup, and no vault-save or vault-refresh tooling exists here, nor a /vault-save slash command. The two files were never updated to match. As of the audit, the drift is known and not yet reconciled.

An agent trusting those docs hunts for a directory that does not exist on this machine and waits on a command that will never run. The operating rule ignores the vault’s self-description and states the current reality: on any “second brain” update, write to ~/code/Suede-Vault with plain file edits plus git add, git commit, git push. Session updates go in a dated file under 05-Sessions/ and get linked from the hand-maintained top-level Index.md, which is the vault’s map. The audit that found the drift is itself filed that way, at 05-Sessions/2026-07-23-estate-status-and-gaps-second-brain-sync.md, which means the record of the vault being wrong about itself is stored by the convention that fixed it.

The general form: dated handoffs beat undated docs. A dated note claims to be true on its date and nothing more, and a reader can weigh it against everything newer. An undated doc claims to be true now, and “now” is when it rots. The two stale vault files carried no expiry and no timestamp a reader would check, so they stayed authoritative-looking for 18 days after the 2026-07-05 session that obsoleted them. The dated session note that corrected them cannot pull the same trick on a future reader; its own filename confesses its age.

That is the whole design, and it is smaller than it sounds. The vault does not need to be right about everything. It needs to make the next session cheaper to start, and honest about when each piece of it was last true. Truth lives in the repos, the live URLs, and the terminal in front of me. The vault’s job is to remember where I left the keys.