WSL ging onderuit en nam Claude Code mee, midden in een turn. Ik was een kleine twee uur bezig met iets wat ik niet opnieuw wilde bedenken.
Dus deed ik het voor de hand liggende. Terminal open, terug naar de map, claude --resume.
De sessie stond er niet bij.
Ik liep het lijstje helemaal na, tot onderaan en langs titels die ik niet meteen herkende. Weg. En dat terwijl het transcript van die hele twee uur een paar mappen verderop op schijf stond, helemaal intact.
Over dat gat gaat dit stuk.
Het transcript is een bestand. De sessie was een proces
Dat zijn twee verschillende dingen, en in de manier waarop we over agent-sessies praten lopen ze bijna altijd door elkaar.
Claude Code schrijft elke turn op het moment zelf naar een JSONL-bestand onder ~/.claude/projects/, één map per project waarin je hem ooit geopend hebt. Aan dat bestand wordt alleen toegevoegd, en wat er eenmaal op schijf staat trekt zich niets aan van wat er met het schrijvende proces gebeurt. Sluit de terminal af, laat WSL crashen, trek de stekker eruit: wat er al staat blijft staan.
De picker is iets anders. Dat is een functie van een client die nu draait, en die bestaat om je te laten oppakken wat je bewust hebt neergelegd. Als het werkt is het gewoon goed, en op 2.1.269 neemt claude --resume een zoekterm aan en doet daar ook echt iets mee.
Maar het is een gemak dat een gezonde client je biedt. Ik behandelde de picker als herstelgereedschap, en dat is een andere taak. Zodra wat er crashte ook het enige is dat je kan laten zien wat er kwijtraakte, heb je een single point of failure met je middag erin.
Waarom mijn sessie uit dat lijstje weg was, kan ik je niet vertellen. Ik kreeg het niet gereproduceerd, en het transcript van die sessie is ongeschonden.
Er staat overigens wel degelijk crash-schade op deze schijf. Vijf bestanden: één leeg transcript, en vier waarvan het laatste blok uit NUL-bytes bestaat, daar waar een write het niet meer gehaald heeft. Alle vijf zijn subagent-transcripts, en geen ervan is een sessie die ik had kunnen hervatten. De schade is dus echt, en ze zit ver van de sessie die ik kwijt was.
Wat ik wel kan vertellen: het bestand was er en de client bood het niet aan, en ik ga er niet meer van uit dat die twee feiten altijd samengaan.
Wat een crash achterlaat
Claude Code houdt een register van lopende sessies bij in ~/.claude/sessions/, één klein JSON-bestand per proces, met daarin een session-id en de map waarin het draaide.
Op dit moment staan er op deze machine 262 van die bestanden, en tien daarvan zijn niet eens te lezen. De 252 die dat wel zijn hebben allemaal een session-id en een werkmap, maar nog maar 62 ervan een status. Bij 248 bestaat het proces waar ze naar verwijzen niet meer. En 30 daarvan staan nog op busy: sessies die midden in een turn zaten toen er gebeurde wat er gebeurde, zonder dat er nog iets achter die PID zit.
Het is een beeld van wat een crash op je schijf achterlaat. Of daar iets tussen zit dat mijn eigen verdwenen sessie verklaart, weet ik niet. Processen gaan halverwege onderuit en de administratie blijft liggen, met een toestand erin die al niet meer klopt.
De transcripts eronder zijn er veel beter aan toe. Tien van de 262 sessiebestanden zijn onleesbaar. Vijf van de 1.422 transcripts. Toevoegen aan een bestand is saai werk, en saai is precies het punt.
De sessies die Claude Code je niet aanbiedt
Tijdens het tellen liep ik tegen het grotere gat aan.
Op deze machine staan 1.422 transcript-bestanden onder ~/.claude/projects/, samen 1.165 MB. Daarvan zijn er maar 196 sessies op het hoogste niveau, de vorm die überhaupt een resume-pad heeft, goed voor 626 MB verdeeld over 72 projectmappen.
De andere 1.226 bestanden, 539 MB, zijn subagent-transcripts. Die staan in een map subagents/ naast de sessie die ze opstartte, één per agent die eropuit gestuurd is.
Claude Code biedt je er nooit één aan. Het zijn geen sessies waar je je aan kunt koppelen, ze hebben geen resume-commando, en vanuit de client gezien zijn ze een implementatiedetail.
Daar gebeurt ook een enorm deel van mijn echte werk. Elke keer dat ik een review over vier agents uitzet, of een zoekvraag aan een explore-agent geef in plaats van er mijn eigen context aan op te maken, komt de redenering in zo'n bestand terecht. Tegenover elke sessie waar ik zelf aan het stuur zat, staan er zes subagent-transcripts.
Dit is het deel waar je het hardst tegenaan loopt zodra je met meerdere agents werkt. Hoe meer je uitbesteedt, hoe groter het deel van je geschiedenis dat in bestanden zit die je client behandelt als iets wat jou niet aangaat. Hervatten kun je ze niet, en erin kijken lukt alleen als je het pad uit je hoofd kent.
Wat me terugbracht
De reparatie was saai, en zo wil je een reparatie hebben.
Ik draaide nekyia index, dat de transcript-stores leest die al op schijf staan en wat veranderd is vastlegt in een lokale SQLite-index. Daarna zocht ik erin. De sessie kwam naar boven zoals een bestand naar boven komt in grep, want niets in dat pad vraagt ook maar iets van een draaiende Claude Code.
Twee dingen maakten het verschil tussen werken en alleen maar iets vinden.
Het eerste is dat het alle projectmappen tegelijk leest, projects/*/*.jsonl, niet alleen die waar je op dat moment in staat. Na een crash kom je niet per se op dezelfde plek terug, en "welke van die 72 mappen was het" is een vraag die ik over mijn eigen middag niet kon beantwoorden.
Het tweede is dat het uit de index weet wat de oorspronkelijke werkmap van een sessie was, en claude --resume <id> dus in díe map start en niet in de map waar je het commando typte. Een id op zichzelf zet je ergens willekeurig neer. Voor een resume heb je het id en de bijbehorende map samen nodig.
Uiteindelijk vond ik hem met nekyia blame, dat recente sessies opsomt die een bepaald bestand aangeraakt hebben. Hoe ik iets twee uur eerder geformuleerd had wist ik niet meer, maar ik wist precies welk bestand ik aan het bewerken was toen het scherm verdween. Zoeken op wat ik aan het doen was won het van zoeken op de woorden die ik gebruikt had, en na een crash is dat meestal de asymmetrie waar je het mee moet doen.
Ik schreef eerder over agent-geschiedenis doorzoeken over clients heen als de sessies gewoon oud zijn, wat dezelfde index in een rustiger rol is. Bij herstel houdt het op een gemak te zijn.
Wat het niet terughaalt
Het transcript is het gesprek, en daar houdt het op.
Hervatten geeft je terug wat je vroeg, wat eruit kwam en welke bestanden er veranderd zijn. Het geeft je niet de tool-state, de snapshots van je bestanden, de shell die je open had, of wat het proces in het geheugen vasthield toen het omviel. Bij clients waarvan ik niet kon verifiëren of je er precies op kon aanhaken, is de eerlijke uitkomst een handover-brief die in zijn eerste regel zegt dat hij een brief is, en die eerste regel staat er niet voor niets.
Wat ik terugkreeg was de redenering: waarom ik het zo aanpakte, welke aanpak ik eerst geprobeerd en weggegooid had, en welke bestanden ik aangeraakt had. Die twee uur werk kwamen er niet mee terug. De laatste tien minuten heb ik zelf overgedaan.
Dat is een eerlijke ruil, en het is de moeite waard om daar precies over te zijn. Een tool die beweerde de hele toestand van je machine terug te zetten, zou dezelfde fout maken als een agent die vol zelfvertrouwen de verkeerde function signature opgeeft. Het ziet er goed uit tot je erop gaat staan.
Het is nog pre-release, inmiddels 0.0.19. Je installeert het vanuit de repository en nog niet van npm, en er staat een uitgebreider verhaal over wat het doet. De index over de sessies van deze machine is 52 MB, draait lokaal, doet geen enkele netwerkcall en bewaart geen tool-output.
Duurzaamheid zit in het formaat
De crash leerde me dat ik mijn vertrouwen één laag te hoog had gelegd.
Je agent-geschiedenis is duurzaam omdat het om tekst op een bestandssysteem gaat waar alleen aan toegevoegd wordt. Ze is bereikbaar omdat een programma dat formaat leest. Als het enige programma dat het leest ook het programma is dat kan crashen, dan is de duurzaamheid echt en de bereikbaarheid niet, en dat verschil merk je op een goede dag niet.
Dit is hetzelfde patroon als het argument om memory-bestanden eerlijk te houden in plaats van volledig, en om de context van een lopende sessie bewust te beheren. Dat zijn disciplines voor de sessie waar je in zit. Dit is de vraag wat daarvan overblijft als die sessie voorbij is.
Controleer het voordat je het nodig hebt. Zoek uit waar jouw client zijn transcripts wegschrijft, en zoek vandaag uit of iets anders dan die client ze kan lezen. Dat antwoord is goedkoop zolang er niets stuk is, en het is het enige wat je wilt hebben op het moment dat er wel iets stuk is.
Bij mij waren het twee uur. Het was een week geworden als die bestanden er niet hadden gestaan.