Four panes, 225 sessions
Four panes fit across my monitor. The board meant to index them peaked at fifty-eight sessions.
Four is the only number in this post I chose. It is what fits across a 49-inch screen in VS Code, and it is about as many threads as I can hold at once. Everything else here got counted afterwards. Each pane is one Claude Code session in the extension panel, running against a devcontainer on a Windows 11 machine with Docker Desktop underneath. Across every transcript on the box, 99.7% of my activity is in that panel rather than a terminal.
Four is what I can see. It is not what exists. I start a session while another one is working, because an idea is worth chasing, or a finding wants breaking out on its own, or someone has posted something, or an issue wants a look, and none of them close when I move on. I started 225 sessions across thirty-four days in July and August 2026. A median of 5.5 a day, peaking at 19. Of those, 120 were still taking messages on a later calendar day than the one they began.
I use worktrees heavily, because several streams run at once and the local stack has to sit on whichever branch is checked out. Cleaning them up is the step I miss. There are 161 worktrees registered across the checkouts, against one shared working copy per repository.
Git owns my branches. GitHub owns my pull requests. Linear owns my tickets, and I use it constantly. What it does not hold is work in flight. A ticket says what should happen. It does not say which window it was happening in.
Nothing owned the sessions.
What went wrong
When it goes, it goes all at once. For a while the culprit was an Oculink cable running an external GPU, which threw an intermittent video-driver fault and took the machine down with it. Moving that cable away from the others fixed it. Docker Desktop stopping is separate, I still do not know why it does it, and it is the one that turns up below. Either way, every session dies together.
What I have left afterwards is the Claude Code resume picker. The command is fast. Finding the session is not. Call it half an hour of sifting, though I have never timed it.
The reason is in how the list gets built. Each transcript carries a title generated from the session’s opening prompt. Of my 225, 220 have one and five have none, which show up untitled. There is no summary record in any transcript on the machine, so that title is all I get, and the opening prompt is almost never what the session became.
started (UTC) lines turns tracked stored title 2026-08-17 05:51 877 19 yes Deploy to Production after staging validation 2026-08-17 21:17 596 19 no Prepare and coordinate next release 2026-08-17 21:37 22 2 no Investigate Slack alerts from recent deployments 2026-08-17 21:50 1865 56 no Daily scrum meeting 2026-08-18 00:28 1098 15 no Review Slack thread 2026-08-18 01:49 157 1 no Review Slack thread discussion 2026-08-18 02:10 1023 14 no Merge four PRs and release to production 2026-08-18 04:33 142 2 no Review Slack workspace post for guidance 2026-08-18 05:24 360 8 no Review Slack message and provide advice 2026-08-18 05:57 774 14 no Prepare and coordinate next release
The same title appears there twice, the second one the following morning, and a third row is the
same release work under a different name. Three sessions, one job. Nine of the thirty are named for
where the request arrived rather than the work it became, all of them some flavour of Slack. And the
biggest session in that window ran to 1,865 lines and 56 of my turns and was still going twelve and
a half hours later. It is called Daily scrum meeting.
The picker sorts by recency and titles by first impression. Neither is how I remember work. The half hour is not really the cost either. The cost is sitting there afterwards not quite sure whether I have got everything back.
It does not always go like that. PC restarted... please continue was the whole of what one session
needed from me on 16 July, and it picked up where it had stopped. Nothing was lost that I could
measure.
What I tried first
I built something on 22 July. It took about an hour and ten minutes.
One JSON file per session in a gitignored directory, keyed by the session’s resume id. Each record
holds the mapping from session to work: the pull requests it raised, the Linear ticket, a state I
set by hand, and a next action. Pull request state, CI and deploy status are deliberately not
stored. They get re-read on every view, and where a deploy state cannot be established the board
prints unknown rather than guessing. The skill sits in a public dotfiles repository, and its
commit history is the record of everything that follows. It has a record of its own, opened 52
minutes before the first commit and archived as done.
Then it sat. Four records on 22 July, one on 24 July, nothing for the next thirteen days. I had built the thing and not formed the habit, which is the least interesting way this went wrong and also the first.
That changed on 6 August. At 05:19 I went back to the session that had built it a fortnight earlier and typed:
For each current session I am going to start using our WIP tracker. What prompt do I provide
That took most of the day. I opened 47 sessions in turn between 04:30 and 09:20 and registered each one, holding most of them for two to five minutes. The board grew as I went, and every figure here is a real render logged in a transcript at the time: 4, 5, 8, 9, 20, 40, 43, 47, 48, 51, 53, 55, 58.
Seven commits landed that morning. Two were defects I hit while doing the backfill, and both of them were the tracker failing the way the sessions did.
The first was registration. Registering a second session got treated as a duplicate of the first, which reads as an error rather than the normal case. Fixed at 05:56, and not fixed completely: two records in the directory today still carry the same resume id.
The second was the branch. Each record captured the git branch of the session that wrote it, and at 06:23 one of the sessions I was registering told me this:
The auto-captured branch is wrong, and not fixably so. It recorded
docs/credential-rotation-runbook. Minutes earlier the same checkout readfix/svc-a-staging-log-permissions— another session moved it between my two commands. Neither is this session’s branch; mine wasfix/preview-media, merged and gone.
My repository checkouts are one working copy per repo, shared by every session, with those 161 worktrees hanging off them. The branch in a record was whichever session had touched the checkout last. It only surfaced because that session happened to run the same command twice and got two different wrong answers minutes apart. One reading would have given it a single plausible wrong branch name and no reason to doubt it. Seven minutes and one commit to fix. Nothing had acted on the bad value.
The other five that morning were features rather than fixes. Four were scaffolding for the habit: a flag on the board for any record with no next action, a guided cleanup pass, a set of short spoken prompts to use instead of commands, and a command to print those prompts as a cheatsheet. Four of the seven, in other words, went on making the habit easy to perform. The fifth is the one I come back to below. Another landed the next day, for the commonest moment of all, which is having done more work and wanting the record to catch up.
The sweep finished at 13:28. Then Docker carked it. How many sessions that took, I cannot say. One killed before I reached it left no record, and looks exactly like one I never got to.
What worked, and what it cost
The board existed, and it showed me something I had not known.
WIP — 58 active session(s) · 2026-08-06 13:23 UTC ... 🚀 Credential rotation runbook — merged — verify & archive svc-a#263 (merged CI✓) · main:unknown ▶ get a review on svc-a#263, then merge to main ↳ claude --resume 31fbc1d6-... · /workspace ... 🚀 Credential rotation runbook — merged — verify & archive svc-a#263 (merged CI✓) · main:unknown ▶ PR #263 merged to main — docs-only, nothing to deploy; archive once confirmed no follow-up ↳ claude --resume e5129529-... · /workspace @ docs/credential-rotation-runbook
Same pull request, two sessions, two next actions that disagree about what state it is in. That is not a tracker bug. That is two of my sessions doing one piece of work, on one screen, for the first time. I did not know until the board told me, and it is not the only time two of my sessions have worked the same thing without either of them noticing.
The split between the re-read fields and the ones I type held in the direction I expected. Eight of my currently active records have all their pull requests merged, and four of those carry a hand-set state contradicting it, two saying blocked and two awaiting review. The re-read fields either resolved or admitted they could not. The ones I typed went stale.
Building it cost four hours and eight minutes of my active time across seven calendar days, 34 turns in one session. Filling it in that once ran from 05:24 to 13:22 of a single day.
Five days later Docker went again.
11:37:27 Docker crashed and I lost the Claude sessions I have opened. I want to
find the ones below and resume them... can you give me the command or
how to do so
1. Planning the next release
2. Production release workflow
3. Demo tenant setup
11:41:16 Docker crashed, had to resume. Where are we at?
11:41:58 Docker crashed, had to resume. Where are we at?
11:42:32 Docker crashed, had to resume. Where are we at?
11:43:26 Docker crashed, we had to resume. Where are we at?
11:45:32 Docker crashed, we had to resume. Where are we at?Seventeen sessions were alive when it went. Nine took another message afterwards. Eight never did. I do not know what those eight cost. Anything that mattered will have been picked up somewhere else; some of the rest is gone, and I cannot tell which part.
None of the seventeen had a record in the tracker. It had been sitting there three weeks with 27 records in it and I did not open it. What I did instead is in that first prompt: I typed out three session names from memory, and then went and found them with grep.
No embedded summaries in the transcripts — I’ll identify them by their first user prompt instead.
The reason none of the seventeen was tracked is the capture rate.
window sessions with a record rate whole history (15 Jul – 18 Aug) 225 63 28.0% started before 6 August 108 60 55.6% started on or after 6 August 117 3 2.6% started on or after 11 August 80 1 1.2%
Fifty-six of the 64 records were created on 6 August, between 05:24 and 13:22. Outside that day and the day I built the skill, four records have ever been created: one on 24 July, two on 9 August, one on 17 August. So the 55.6% is not a habit that worked and then lapsed. It is the backfill projected backwards onto sessions that had started weeks before it. From 2 August onward my daily capture rate is zero on 22 of 25 days.
The obvious objection to 28% is that plenty of those sessions were never meant to be tracked. Dropping everything with a single turn of mine lifts it to 31.2%. Requiring that a file was written lifts it to 33.3%, and drops the tracked count from 63 to 53, because a good deal of this work is review and triage rather than editing. The most generous cut I tried, three turns or more, reaches 34.8%. No threshold I can defend moves it far.
And the part built for exactly that situation has never run. Continuing a piece of work in a fresh session, rather than hunting down the old one, is something I described at 06:49 on 6 August in almost those words, and it shipped twelve minutes later. No record in the directory or the archive has ever been through it.
Every record I have carries a next action, which sounds like discipline and mostly is not: the tool asks for one at registration and renders it on every row, so a record without one is close to unreachable. For 33 of the 63 records whose session has since gone quiet, I last edited the record before that session’s final message. The work carried on. The note stayed where it was.
My records have a median working life of 34 minutes. Sixty-three per cent I never touched again after the hour I created them. Of the 27 still active, 26 have had no session activity for at least a week. The 37 that reached the archive are where the finished work went.
What I would do differently
I would not make the capture depend on me remembering. A stop hook, so stepping away from a session writes the record without being asked, and a scheduled sweep to close out records whose pull requests have all merged. Both were named as the planned second version on 22 July, before any of this was measured, and I have built neither.
My transcripts come to 1.1 GB across 222 files. The records that index them come to 264 KB. On 11 August I searched the 1.1 GB.