When your terminal crashes mid-session, how do you pick the work back up?
I run 8 or more sessions at once, so terminal hangs and crashes show up way more often than I'd like. claude --resume looks like it should help, but it doesn't always pull the whole history back. I've stopped relying on it.
Our workaround is small. Every time the agent finishes a reply, a Stop hook writes a little card for that terminal pane, holding my last instruction, the tail of the agent's answer, the working folder, and the path to the full session log. It's a plain text file that gets overwritten on each run, so it costs zero tokens, and cards older than 7 days get cleaned up on their own.
Opening a new session in the same pane or folder triggers a SessionStart hook that reads the latest card and drops it into the agent's context. That way the new session already knows where the last one stopped, and it can always go read the full log when it needs more detail. Usually that's plenty.
For anything that has to outlive a single session, like decisions or mistakes, we put it in the project's memory files. That's the only place I trust the next session to look.
What do you do when a session dies on you? How do you pick things back up?
Replies
Same problem, different shape of fix: I decided the session must never be the only place where state lives, so three places hold it. Git, with a rule in the notes file that says commit and push when a stage is done, without asking, so a crash costs at most the current stage. The project notes, one file per area, with the rule that a non obvious finding goes in there the moment it is learned and not into a commit message, so the next session reads why before touching the area. And a small memory folder outside the repo, one fact per file with a one line index loaded at start, for the things that are not code: what I corrected, which account owns which project, which deploy is a test. When a session dies I open a new one and say in one sentence what I was doing; the rest it reads. The gap mine has is exactly what your card covers, the last instruction and the tail of the answer, and the append only point above is well taken: a notes file an agent is allowed to tidy is a notes file that will be tidied.
@gbasovv that line about the notes file is exactly it.. the three places idea is good.. git is the one that saved me most
@gbasovv Our setups are really close. We've got the same kind of memory folder, one fact per file with a one-line index that loads at the start, and that's where my corrections and which account owns which project end up too.
The card is there because I'd never remember which of my 8 or more panes was doing what. Nice touch with the one-sentence restart, I might steal that ☺️
@hisashispace Steal away. The one detail that makes the sentence work: it says where things stand, not what to do next. "The function is deployed, the screen that calls it is not started" sends the new session to read the diff and continue. "Finish the screen" sends it to redo the first step, because it cannot tell what is already there. I rarely run more than two sessions at once, so your card solves a problem I have less of, but the day I have four panes I will want exactly that.
@gbasovv Where things stand, not what to do next. That's a really useful way to put it, and the deployed function example makes it click. I'll write my restart sentences that way from now on. Thanks George ☺️
Similar idea. Mine is one file per repo rather than a card per pane. The agent appends to it at the end of every session. It says what got done, what's half done and what's next. It's append only. An agent once tidied it up and a week of context went with it. A crash still loses the last stretch. So it also commits after every step and the git log is the fallback.
@neelagiri_chettiyar Ouch, losing a week of context to a cleanup hurts.
We have something close to yours too. Each project gets a monthly work log that's built automatically from the session logs, mostly what I asked for and anything that went out to production. We used to have the agent keep a progress file by hand, but it kept forgetting to update it, so we dropped that.
Using the git log as the fallback makes sense. It doesn't forget.
the one sentence restart thing is underrated. where things stand beats what to do next bc the next step is usually the thing the agent was getting wrong before the crash anyway. curious if the card ever goes stale tho, like if the last reply was the agent confidently doing the wrong thing you'd be loading the bad state right back into the new session
@hitensethiya It can, yeah. The card is just my last instruction and the tail of the agent's answer, so if the agent was confidently wrong, that comes back with it. What helps is that my instruction is on the card too, so the new session sees what I actually asked for, and the path to the full log is there if it needs more.