Where did my OpenCode session go? Finding and resuming sessions

An OpenCode session is a saved conversation: the messages, the tool calls, their output, and the directory the work happened in. Closing the terminal does not delete it. Sessions are written to a local SQLite database, and most "my session disappeared" cases are a question of which project or directory the picker is showing, not a deleted transcript.

Run opencode --version first; 1.x is V1 and 2.x is V2, and the project model differs.

Checked against OpenCode's documentation on 27 October 2026.

Status, 27 October 2026: migrated V1 non-git sessions can stay under the global project and disappear from the V2 picker; the report is open and was reopened on 23 October 2026 (#49827), with session move as the workaround. A separate open report covers sessions whose directory no longer exists (#55035, updated 14 October 2026).

Where the sessions live#

Both lines use a SQLite database, normally ~/.local/share/opencode/opencode.db. Check the database path first:

# V2
opencode debug paths db

# V1
opencode db path

OPENCODE_DB can move the database, and a relative value resolves under the data directory.

V2 also runs a shared background server by default. The server owns sessions, configuration, and tool execution. opencode service status shows it; opencode api get /api/info checks it is healthy. A client connected to another server with --server, or paired to one with opencode pair, sees that server's sessions instead.

What the list actually lists#

opencode session list lists top-level sessions in the current project, newest first, 100 by default. Child sessions are not in that list. Use --max-count to widen it and --format json to see the recorded directory and project:

opencode session list --max-count 500
opencode session list --max-count 20 --format json

The project is an identity for a working directory. A Git repository follows its worktree, the checkout root; a non-git directory gets its own project in V2. V1 used one global project for non-git directories.

In V2, /sessions (or Ctrl+X L) lists sessions, and Ctrl+O opens recent sessions and projects; on V1 use /sessions or Ctrl+X L. The picker is scoped to the current project and directory.

--continue is narrower than people expect. In V2 it picks the newest top-level session whose recorded directory is the current one, paging through the list until it finds a match. Start OpenCode in the directory where the work happened, or pass the ID directly.

The commands people mix up#

The V2 full-screen TUI does not list a root --fork flag; fork from run or mini.

--session takes a session ID, the ses_... value from the list. In V2, the flag is documented as "continue, or create if it does not exist". A mistyped ID therefore creates a new empty session instead of failing. Copy the ID from opencode session list --format json rather than retyping it.

--fork copies the session into a new one and leaves the original alone. opencode session delete <id> deletes the session and its child sessions; there is no trash to restore from.

Why it is not in the picker#

It belongs to another project#

Start where the session started, or use the TUI's all-sessions view. opencode session list only shows the current project. --format json shows each session's directory.

In V2, a new session starts in the TUI's launch directory by default. Set session.new_location to inherit in cli.json if you want it to follow the active session.

It was migrated from V1 in a non-git directory#

V1 stored non-git sessions under project_id = 'global'. V2 creates a per-directory project and the picker filters to the current project, so those rows remain in the database but do not appear. GET /api/session returns them, and Ctrl+X L can show them under the global project.

The repair is the session move API, one session at a time:

opencode api post /api/session/<sessionID>/move \
  --data '{"directory":"/absolute/path/to/the/session/directory"}'

It rebinds the session to that directory's project and writes the path the picker expects. Back up first; repeat for each affected session. A fix exists for future imports; migrated databases still need repair.

The directory was renamed or deleted#

V1 stored an absolute directory path and did not relink it when the directory moved. Fixed for the V2 rewrite on 2 September 2026 (#23248). If a V2 session's directory no longer exists, opening it shows "Session location unavailable" and offers to move it. Recreating it makes the session openable; export still works either way (#55035).

It is a child session#

Subagent work — a separate agent the parent session starts for a scoped job — runs in child sessions. opencode session list lists top-level sessions only, so a child never appears there. Open the parent and use the TUI's child navigation: in V2, down enters the subagent picker; on V1, press Ctrl+X then down. Right and left move between children, and up returns to the parent.

There are more than 100#

The V2 list defaults to 100; add --max-count 500 or filter the JSON by directory or date. A 2026 V1 report said the TUI picker showed only recent sessions while older rows remained; it was closed without a fix for the reported date cutoff (#13877), and a related child-session fix landed in #33931. The CLI list is the wider view on that line.

You are looking at a different server or database#

Check the database path (V2: opencode debug paths db; V1: opencode db path) in the shell that starts the client, and opencode service status for the shared server. A --server flag, a container, a different OPENCODE_DB, or a second install can each point at a different store. In WSL, a Windows client and a Linux CLI can resolve different homes; check both with opencode debug paths.

Check you got the right session#

Resume it, then confirm the state before continuing. Ask for the last decision, the current branch and commit, and the next action; compare them with git status and git log -1. If the session was compacted, the transcript is summarized and the older turns are dropped; the exact command may be gone. The compaction guide covers what survives.

opencode session export <id> (V1: opencode export <id>) writes the transcript as JSON. --sanitize redacts sensitive transcript and file data. The export is the safe way to read a session without a client, even when the directory is gone.

Move it, back it up, or leave it#

Sessions are local; copying one database over another is not a documented merge. To continue elsewhere, export and import it. In V2:

opencode session export ses_abc123 > session.json
opencode session import session.json --directory ~/code/project

On V1, the same block is opencode export [id] and opencode import <file>.

For a whole-machine backup, use SQLite's backup command, not a copy of a live database file:

# V2
sqlite3 "$(opencode debug paths db)" ".backup '/tmp/opencode-backup.db'"

# V1
sqlite3 "$(opencode db path)" ".backup '/tmp/opencode-backup.db'"

V2's uninstall keeps session data and config; V1's removes both unless you pass --keep-data and --keep-config. Run opencode uninstall --dry-run first.

To move work to another agent or machine, a short handoff file beats the transcript: the goal, decisions, failed attempts, open items, and changed files. The handoff guide has the shape.

Where to go next#

• OpenCode guides — instructions, permissions, and the rest of the set.
• Why OpenCode ignores your AGENTS.md — if the resumed session is missing its rules.
• Context compaction — if the session lost the middle of the work.
• Hand off work between Claude Code and Codex — if the work has to move machines.