--- title: "35 sessions and no map" canonical: https://dxdev.com/blog/2026-05-01_35-sessions-no-map/ datePublished: 2026-05-01 --- Thirty-five Claude Code sessions in roughly 21 hours, all against the same repo on main. I did not notice I was past a reasonable number until I had no reliable way to answer a basic question: which of these are still doing something useful, and which ones have I just left open. The longest that day, `a3f71c2e`, ran 390 prompts over seven hours on session persistence and vault integration. A different session, `d84b09f1`, opened at 11:50 PM specifically to recover work from a previous session that had lost context mid-conversation. A third, `c6e25a47`, ran from 6:06 PM to 3:16 AM, 288 prompts, claimed label "Review and execute content system architecture plan." That label sounds organized in retrospect. Also present: three sessions named "(untitled)." Each ran 1 prompt. Six tokens out. The output was `echo ok`. Probe sessions, throwaway sessions. Before I had any registration hook, they registered as active in my mental model because they were open windows. I had no other model. ## what a missing map actually costs The problem with losing track of sessions is not that any single one goes wrong. It is that you start making decisions from stale reality. A session from this morning told you one thing about a config. The session from this afternoon went a different direction. You cannot tell which conclusion is canonical because you cannot tell which session finished and which one you minimized at 11 AM and never reopened. I had been running AI work like browser tabs: open many, close some, assume the visible ones are still relevant. That assumption breaks around session five or six. By thirty-five it is a fiction. The subtler cost is vault drift. I keep a vault, a directory of markdown files that represents ground truth for decisions, architecture, and active work. Sessions read from vault and write back to it. When they run in parallel without tracked writes, you get context from 9 AM served to a session that opened at 4 PM. The vault reflects something. Not necessarily the current thing. Because Claude Code treats vault content as authoritative, a stale vault does not surface as an error. It surfaces as confident, reasonable-sounding output calibrated to a state that no longer exists. Between 9:02 and 10:57 AM, four sessions worked on the same Playwright MCP setup problem. The last one ran 98 prompts, longer than the first three combined, with no record of what the earlier sessions had already resolved. Nothing malfunctioned. There was just no handoff mechanism. The cache_read token totals for the day ran into the hundreds of millions across all 35 sessions. That is the cost of parallel sessions without shared registration: each one re-ingests and re-derives what another already resolved, because none of them can see the others. ## the typo that forced the question At 10:20 AM I started session `b2f940c8` with a prompt that had three typos in two sentences. I will not reproduce it directly, but the content was: I want a dashboard, I want to get in sync with vault, I want to see what sessions are open and what they are actually doing. The typos are the only reason I am mentioning the exact session. They mean this was not planned. The idea arrived faster than my hands could keep up. That session ran 41 prompts and 26 minutes. It did not finish anything. It established what the dashboard needed to answer: which sessions are active, what task each one claimed, which repo and branch, when each one last touched anything real. Forty-one prompts to name the problem. The build session, `a3f71c2e`, opened at 11:03 AM and ran until 6:53 PM. Something else landed that morning I had not anticipated. Session `5e6d82af`, nine minutes at 9:34 AM, began with an observation that logged events kept losing their time component: just a date, no time. A small detail, but load-bearing. When you have 35 sessions in a day, a manifest entry that says "2026-05-01" without a time tells you nothing about sequencing. The convention got tightened: logged events always carry both. ## session state as infrastructure The fix was a SessionStart hook, a shell command that fires every time Claude Code opens a new session. It writes a manifest file at `vault/sessions////.md`: a YAML block with session id, start time, station (desktop, a secondary machine, or whatever terminal opened it), working directory, repo, and branch. Later beats update the manifest: set a label, mark the session active or idle or closed, write a heartbeat timestamp. The vault-side dashboard regenerates from those manifests. It is a markdown file rebuilt by a script, showing current sessions grouped by repo, status, and last-active time. It does not tell me what a session is thinking. It tells me session `d84b09f1` claimed "Recover prior session work" at 11:50 PM, on a recovery branch, last active at 1:59 AM. That resolution matters when you need to decide whether to reopen it or cut a fresh context. A Claude Code session is now an infrastructure unit, not a disposable chat window. It has an identity, a claimed task, a lifetime. When I opened a session from Termius on my phone at 1:30 PM, `4c90e3b2`, the hook captured the device signature. That session is labeled "Termius CLI session from phone" and is distinguishable from the desk sessions that surrounded it. Before the hook, it was just another window with no origin. There is a health audit built on top of the manifests, scheduled on a recurring cadence. It surfaces stuck-active sessions that have not touched anything in hours, claimed repos that do not match the vault record, heartbeat gaps wider than the session's stated task warrants. Scheduled audits do not replace attention. They make attention cheaper. The three `echo ok` sessions are still in history. The dashboard did not make them worth more. It made them visible enough to close. ## what you cannot fix retroactively Building the registration infrastructure inside the same session cluster that exposed the need meant the fix ran in parallel with the problem for most of the day. Session `a3f71c2e`, the 390-prompt vault integration run, was itself one of the 35 I was trying to get a handle on. It is on the manifest now: closed, labeled, pointing at the right repo and branch. The seven hours it ran before the manifest existed are just log entries, recoverable only through transcript exports and `git log`. There is no retroactive hook. The manifest tells you about sessions going forward. What changes is the floor: every session from that point carries an id, a station, a label, a close timestamp. When something drifts, I can open the session manifest folder for that date and trace which sessions were active during the drift window, what each one claimed, and when each one last wrote anything. On May 1st I had 35 sessions I could not audit that way. The typo-filled prompt in `b2f940c8` at 10:20 AM is where that ended. You cannot run multi-session AI work on memory and good intentions. The session is the infrastructure unit, and an unregistered one does not exist.