Day one closed in the small hours and day two started half an hour later, with a short session that didn't touch the product: it defined how sessions would be named, where they would be recorded, and which script would close them on its own. The problem it solved wasn't one of order but of continuity. Every conversation with Claude Code ends, and I wanted to be able to work across many of them —open one, close it, come back the next day or from another project— without losing what had been decided in the previous one. With some distance, it is one of the sessions that weigh the most of all the ones I have: without it this post wouldn't exist, because the material every post in this log comes from is, precisely, the file of each session.
A short session and a convention
What got written that night fits in four lines. A naming format, YYYYMMDD-VNN_nombre: the date, a counter that restarts at V01 every day, and a goal in two or three words. An index, docs/sessions.md, a Markdown table. A closing hook —a script Claude Code runs on its own every time the model finishes responding— that updates the end time and the status. And a decision on how to find out the session's real identifier, the UUID you need to resume it: take the most recent file in Claude Code's internal sessions directory.
And one more line, almost at the bottom: "session V01 of 08/15 registered retroactively". Day one, which I covered in the previous post, exists as a session because day two wrote it down. The record started by recording backwards.
What the same day already outgrew
That same afternoon, the third session of the day redid half of the design (the second one was opened and closed empty, with no goal: the first record of a session that never was). A single table wasn't enough. Each session got its own file, with a metadata header and fixed sections —goal, decisions, work done, next steps— and the index was reduced to a lightweight list. list_sessions.py appeared, which reads those headers and shows the sessions ordered by activity, along with the instruction that every conversation should start by showing that list and asking: do we resume one or open another? That is where the real goal got stated: that the work could be spread across many sessions without each one starting from scratch.
The detail I like most is in the metadata. The fourth session of the day has the same identifier as the third: the "most recent file" heuristic failed the very day it was written, with two sessions opened almost at once. And the times: the first session of the day has a start time; the next three, only the date; the ones from the day after literally say "(time not available)". The system was born without knowing how to read a clock.
What stayed and what moved
The naming format is today identical, letter by letter, in the template I replicate in every project. There are 426 session files spread across ten projects; 165 of them were opened by the system on its own, using the text of the first message as the name, one for every ticket an agent executed from the terminal without me in the conversation —day two didn't foresee that. The fixed sections of the third session are the same ones in the file of the session I'm writing this in.
What moved is the responsibility. The closing hook stopped living in my user folder and now travels with each project, and it responds to two events: one refreshes the end time on every turn, the other marks the session as closed exactly once, when the conversation ends. The start —list and ask— stopped being a paragraph in the instructions file: a start hook injects real data (tickets, sessions open for more than 48 hours, alerts), a rule propagated from the template defines the protocol, and the global instructions guarantee the minimum if the other two layers are missing. Three layers for what day two solved with a paragraph, because the paragraph diverged in three out of eight projects as soon as it was copied.
And there is something day two couldn't know: that the date in the name would end up being the date of this post. Posts in this log carry the date of their source session, not the day they are written. This one carries August 16. That night's convention decided, without meaning to, the order in which everything else is read.
What it didn't decide is whether this is the right way. Four hundred files, three layers of hooks and rules, a counter that restarts every day: it works, and it is what let me write this. But I built it in one night and kept patching it ever since, without ever comparing it with anything else. If you work with agents across many sessions —how do you keep the record? Is this the best way to manage sessions, or just the one I happened to land on?
Top comments (0)