Resuming the session you had yesterday
find it across every agent, then reopen it in the right one
Every agent can resume its own last session. None of them can tell you which session you want, and none of them can see the one you had in a different tool — which is where the answer usually is.
Find it first
deja "connection pool exhausted"
Search runs over every agent's transcripts on the machine at once, and each hit carries the harness it belongs to and its session id. That is the step the tools themselves cannot do: claude --resume lists Claude's sessions, codex resume lists Codex's, and neither knows the other exists.
Without an id in hand, run deja with no arguments. The full-screen search opens on the sessions behind your uncommitted change and the recent ones in this project; type to search, ↵ to read a session, r to reopen it in its agent, or o to continue it in a different one.
Then reopen it
deja resume <id>
It prints the command that reopens that exact conversation, including the directory it has to run in when the tool scopes its session list by working directory:
cd '/path/to/project' && grok --resume 01a03433-0c67-7331-8eb1-cd6173d4c8f9
Thirty-five of the forty-one harnesses deja indexes can be reopened this way. The other six are refusals with a reason rather than silence: aider appends to a transcript file and has no notion of reopening one conversation; Zed, VS Code Copilot Chat, Cherry Studio and JetBrains AI Assistant reopen from their own UI rather than a terminal; and neither of DeepSeek Harness's two apps takes a session id. Roo Code and Kilo Code split: what their CLI wrote resumes, what the editor wrote reopens there. Reasonix splits the same way: a session its CLI started in a workspace resumes, one from the desktop app reopens from the app's sidebar. The format registry records which is which, and why.
A transcript the agent has since deleted stays searchable in deja, and resume says so instead of printing a command that fails. deja resume <id> --write-back writes it back into the agent's store from what deja indexed, in the agent's own format, and then prints the command; on the interactive screen such sessions sit under the Deleted tab, and R does the same. The file holds the conversation, user and assistant turns; tool calls and their output stay in deja. Where the agent keeps sessions in a database, or the index lacks something its format needs, it says what is missing and deja show still has the session. The same goes for a project directory that is gone: where the agent finds a session only from there, resume refuses; where it reopens one from anywhere, the cd is left out and a line on stderr says where it will run. pi, gjc, Kimchi and Senpi offer to fork such a session instead, and prime-agent takes it only with --fork. The stderr line says that too.
When resuming is the wrong tool
Reopening a session brings back the whole conversation, including the parts that were wrong before they were right. Often what you want is the conclusion, not the road to it:
deja ctx <id-prefix>
That returns the session as a digest — what was decided, which files it touched, which commands ran — small enough to paste into a session you are already in. Finding a session covers the search side in more detail.
The part that is not about this
The index covers every agent's transcripts on the machine — each in its own format — including sessions from before deja was installed. Indexing and search are local: BM25 over the transcripts, credentials stripped as the index is built (privacy).
Getting started · Finding a session · Switching agents
Found this useful? Star deja-vu on GitHub.