A coding agent session is easy to lose. Not because the agent deletes it: Claude Code, Codex, OpenCode and the rest all write what happened to disk, and most of them keep it indefinitely. It gets lost because each one keeps it in a different place and a different shape, nothing on your machine searches across them, and the moment you sit down at a second computer none of it is there.
This post is the map. Where each agent stores its sessions, what the free viewers and converters can and cannot do with those files, and why "pick this up where I left off" is a harder question than "find the conversation from Tuesday".
Where each agent keeps its sessions#
These locations are what Ondago's own session readers open, checked against the agent versions named in our supported agents page. Vendors move things between releases; when a path here stops matching, the agent's own --help or release notes are the authority.
| Agent | Where | Shape |
|---|---|---|
| Claude Code | ~/.claude/projects/<project-path-as-slug>/<session-id>.jsonl | One JSONL file per session, grouped by the folder you started in. Subagent transcripts sit beside or under the parent session. claude --resume <id> opens one by id. |
| Codex | ~/.codex/sessions/YYYY/MM/DD/rollout-<timestamp>-<uuid>.jsonl | The rollout file is the session: codex resume <id> refuses an id it has no rollout for. A SQLite index beside it (~/.codex/state_*.sqlite, table threads) holds titles and times for the listing. CODEX_HOME moves the whole directory. |
| OpenCode | A SQLite database under its data directory (~/.local/share/opencode/opencode.db on Linux and macOS) | Sessions, messages and parts as rows. The supported way in is the CLI: opencode session list --format json and opencode export <id>. |
| GitHub Copilot CLI | ~/.copilot/session-state/<session-id>/ | An events.jsonl transcript and a workspace.yaml naming the folder. COPILOT_HOME moves it. |
| Antigravity CLI | ~/.gemini/antigravity-cli/ | A conversations/<uuid>.db the agent resumes from, and a readable brain/<uuid>/.system_generated/logs/transcript.jsonl beside it. |
| Cursor | ~/.cursor/projects/ plus the editor’s globalStorage/state.vscdb | Agent transcripts as JSONL under the project tree; the editor’s own state (titles, ordering) in its VS Code style SQLite store under ~/Library/Application Support, %APPDATA% or ~/.config. |
Two things stand out. Nearly everything is JSONL, one JSON record per line, appended as the run proceeds, which is what makes the same file both a transcript to read later and a stream to follow while it is being written. And every store is keyed to this machine: Claude Code files sessions under the absolute path of the folder you launched from, Codex and Copilot record the working directory inside the transcript, Cursor ties them to a workspace. Copy the file somewhere else and the agent that wrote it will not know what to do with it.
Three different jobs people mean by "session management"#
When someone goes looking for a session manager they usually want one of three things, and the tools on offer are good at different ones.
- Find it. Which session was the one where we worked out the migration order? Full-text search across tools, by project, by date.
- Read it later. Replay what the agent did, step by step, to review it, to write it up, or to show somebody.
- Pick it back up. Keep working in that conversation, with that context, from a different computer, from your phone, or in a different agent because the one you started in hit its usage limit.
The first two treat a session as a record. The third treats it as a running piece of work. It is the one that matters most when a deadline is near, and it is the one most tooling skips, because the transcript turns out to be only a third of what a session is.
The viewers and converters, and what they carry#
There is a healthy set of free tools for the first two jobs, and they deserve credit before anything else is said.
- Renderers that turn Claude Code’s JSONL into browsable HTML, one page per project, and editor extensions that open the same files inside VS Code.
- Converters that rewrite one agent’s transcript into another agent’s format, so Codex can read a conversation that started in Claude Code.
- Local archive apps that watch several agents’ stores, index them for full-text search and replay a session step by step, keeping everything on the machine.
- And the oldest approach of all: paste the useful part into Notion or Obsidian and move on.
What all of these carry is the transcript. That is exactly right for finding and reading. For picking a session back up it is not enough, and it helps to be precise about why.
What a session actually consists of#
Open the folder you were working in while the agent ran, and the conversation is one of three things that made up the session.
| Part | What it is | Where the transcript tools leave it |
|---|---|---|
| The conversation | Every message, tool call and result, in the agent’s own format. | Carried. This is what they are built for. |
| The working tree | The files the agent edited and had not committed yet, the branch it was on, and the commit it started from. Half-finished work is the normal state of a session, not an exception. | Left behind. The transcript says a file was edited; it does not contain the file. |
| The harness | Project instructions, hooks, skills, MCP server definitions, permission settings. The things that made the agent behave the way it did in this project. | Left behind. A resumed conversation with a different harness is a different agent reading your old messages. |
Resume the conversation alone on a second machine and the agent remembers deciding to rename a module, but the module is not renamed, the hook that ran your tests after each edit is missing, and the permission it was granted for the deploy script has to be granted again. That is why "copy the JSONL file over" never quite works, and why the converters are honest when they describe themselves as transcript tools.
There is a fourth part worth keeping, which almost nothing records: the approvals. Which commands the agent asked to run, and which ones you said yes to. A session you are reviewing a week later, or handing to a teammate, is far easier to trust with that list beside it.
A worked example: the usage limit mid-task#
The moment this stops being abstract is a familiar one. It is late afternoon, Claude Code is two thirds through a refactor, and the session hits the plan’s weekly limit. The code is in a half-renamed state across eleven files. You have a Codex subscription sitting unused.
With a transcript converter you can hand Codex the conversation. Codex now knows what was discussed. It does not have the eleven half-edited files unless you are on the same machine, it does not have the project instructions Claude Code was following, and it will ask for every permission again. With a session archive you can read back what Claude Code did, which helps, but reading is not continuing.
What the moment calls for is moving the whole session: conversation, working tree and harness together, into an agent that can read them, with a plain statement of what the destination agent can and cannot take over. That is the problem Ondago was built around. ondago lift saves the session as one encrypted bundle, and ondago migrate or the app’s Continue with another agent opens it in Codex, OpenCode or Copilot CLI with a compatibility review first, so the conversation, the uncommitted files and the compatible parts of the setup arrive together. The supported agents page lists which parts travel to which agent.
# on the machine where Claude Code hit its limit
ondago lift
# preview a copy in Codex, read the compatibility report, then run it without -dry-run
ondago migrate SESSION_ID -to codex -dir ~/projects/example-app -dry-runThe same mechanism is what lets a session leave a laptop at all: resume on another computer, continue in the cloud before closing the lid, or answer the agent’s next question from a phone. Each of those is the third job, and each needs all three parts.
What "stays on your machine" does and does not promise#
Local-only is a real privacy property and the archive tools are right to lead with it. Your transcripts contain source code, and the people who have looked find credentials in them more often than anyone would like. A store that never leaves the disk cannot leak from a server.
It also has a ceiling. The moment the session needs to be on your phone, on your other computer, or readable by a teammate, "it never leaves your machine" is no longer the design; something has to carry it. The honest alternative at that point is to encrypt it before it leaves, with keys that only your devices hold, so that whatever carries it holds bytes it cannot open. That is how Ondago is built: a session is sealed on the device that saved it, the service stores the ciphertext and a minimal index, and there is no server-side search or summary because the server has nothing it could search. Our security page walks through what that means for devices, workspaces and cloud runs, including the one place where decryption has to happen, which is the environment where an agent actually runs.
Neither property is a reason to pick a fight with the other. Keep a local archive if searching your own history is the job. Encrypt before you move it if moving it is the job.
Try it on a session you already have#
Ondago reads the stores listed above as they are; nothing has to be exported first. Install the CLI, sign in, and list what is on this computer:
curl -fsSL https://public.ondago.ai/install.sh | sh
ondago login
ondago listThen open one of those sessions on your phone through app.ondago.ai, or save it with ondago lift and pull it on another machine. The Free plan covers this. Download Ondago, or read the CLI install guide first.