Where did my Copilot CLI session go? Finding, resuming and recovering sessions

A session is one conversation with GitHub Copilot CLI, plus the state around it: the working directory, the approvals you gave, and the mode you were in. Closing the terminal does not delete it. Copilot CLI writes the conversation to disk as it goes, and by default syncs a copy to your GitHub account.

That is why most "my session is gone" cases are not deletions. The list is showing a different slice of history, /clear abandoned the session, or its event log no longer parses. This guide separates those cases and shows how to get the conversation back.

Run copilot --version first. The paths and commands below are from the 1.0.104 reference (27 October 2026); the session picker and the /session commands have changed several times this year.

Checked against GitHub's Copilot CLI documentation on 27 October 2026.

Status, 27 October 2026: an open report says a CLI session file still cannot be opened by VS Code Copilot Chat (#2000, open, updated 26 October 2026). An open request asks for an unscoped view in the /resume picker because a session from another directory can look missing (#4554, open, updated 24 August 2026).

Where a session lives#

The complete record of each local session is a directory named after its session ID:

~/.copilot/session-state/<session-id>/
  events.jsonl
  ...plans, checkpoints, tracked files

events.jsonl is the transcript: one JSON event per line, covering your prompts, Copilot's replies, tool calls, and tool output. The same reference documents the second piece: ~/.copilot/session-store.db, a SQLite index over the same sessions that powers history search and /chronicle.

The index is the part you can lose; it is rebuilt from the session directories, so the directories are what matter for recovery.

COPILOT_HOME replaces the whole path, not just the settings. If it is set in one terminal and not another, they see different session libraries. Check it in the shell that starts Copilot:

echo "$COPILOT_HOME"

The folder name is the session ID. /session id prints and copies it, the exit summary shows it, and /session shows details including the log path.

The three lists, and why they disagree#

Copilot CLI has three ways to see sessions.

The sidebar is the narrowest: recent local sessions, oriented around your current directory. The Sessions tab is the full library: press <kbd>/</kbd> to search names, branches, directories, repositories and session IDs, and <kbd>a</kbd> to cycle local, remote and all. The picker sits between them, sorted by relevance — how well a session matches your current directory — by default. Press <kbd>s</kbd> to cycle relevance, created, name, and last used, or open the Sessions tab and search.

From the shell, the same choice looks like this:

# Most recent in this directory, falling back to the most recent anywhere
copilot --continue

# Open the picker
copilot --resume

# Go straight to one session by ID, ID prefix, or exact name
copilot --resume=<session-id>
copilot --resume="checkout refactor"

--continue is the flag that surprises people. It does not mean "the last session anywhere" unless there is no match in the current directory. Start it where the work happened, or pass an ID.

--resume conflicts with --continue and with --connect. A bare --resume needs a terminal: in a script, a non-TTY -i, or piped input, the CLI exits with an error rather than silently starting a new session when several exist. Pass --resume=<id> or use --continue.

The two lookup flags are easy to mix up:

• --resume=<value> matches an ID, an ID prefix, or an exact session name. Name matching is case-insensitive and falls back to the auto-generated summary if no explicit name matches.
• --session-id <uuid> matches only an exact ID. If nothing matches and the value is a valid UUID, it creates a new session. A retyped ID with one wrong character can therefore look like a resume and behave like a fresh start.

Give a session a name at launch with copilot --name "checkout refactor", or rename it inside with /rename.

Why your session is not in the list#

You started from another directory#

The sidebar is scoped to the current directory, and the picker ranks by relevance to it. A session from another checkout is usually still there, just low in the list or absent from the sidebar. Open the Sessions tab, or resume it by ID from anywhere. The picker gives no sign that scoping is happening, which is why an unscoped view is an open request.

Early-2026 builds also failed to record Git metadata for new sessions, so the repository filter hid them; 1.0.18 fixed it on 4 April 2026, and the issue closed on 7 April (#2446, closed as completed). Update before assuming data loss.

You ran `/clear`#

/clear and /new both start a new conversation, but they are not interchangeable. The 1.0.11 changelog says /clear "abandons the current session entirely", while /new starts fresh and keeps the old one backgrounded in the sidebar. The current reference lists /clear, /new and /reset together, and an open report says the help text still does not make the difference clear (#3569, open, updated 18 July 2026).

If you might want the conversation again, use /new, then look for the old session in the Sessions tab. /exit saves the session and leaves it resumable. The destructive gesture is <kbd>x</kbd> twice in the sidebar, which permanently deletes the session whether or not it was running.

You are looking at a different Copilot home#

COPILOT_HOME moves the session directory. So does running under a different user, in a container, or on the other side of WSL. Check echo "$COPILOT_HOME" and ls ~/.copilot/session-state in the shell that launches Copilot.

It was a prompt-mode run#

A prompt-mode run is the non-interactive form: you pass one prompt with copilot -p, Copilot finishes it, and the process exits. Those sessions are saved too, and the exit summary prints a copilot --resume=SESSION-ID hint. In a script or CI job that output is easy to lose. Log the hint, or name the run with --name.

You actually deleted it#

Pressing <kbd>x</kbd> twice in the sidebar permanently deletes a local session, running or not. /session delete deletes the current session and starts a new one; on a synced session it asks whether to delete the GitHub copy too. /session delete-all and /session prune only touch local copies. The delete guide has the full command set.

Find a session by what you remember#

If you know a phrase from the conversation but not the session, search the event logs directly. They are plain files, and this works even when the picker does not show the session:

grep -rl "stripe webhook" ~/.copilot/session-state/*/events.jsonl

Each result ends in <session-id>/events.jsonl; the directory name is the ID you can give to --resume. For a rougher sort by modification time:

ls -lt ~/.copilot/session-state | head

Inside a session, /chronicle search <term> searches all recorded session content, not just summaries.

Once you have a candidate, check it before you continue. /session info shows the details, /session id copies the ID, and /session files lists temporary files created during the session, such as artifacts Copilot made that should not be saved to the repository; it is not a list of the files you changed. Use git status and git diff for the changed files, and compare the branch and last commit with git log -1. If the session was compacted, older turns have been summarized; /session checkpoints shows the saved summaries, which are reading aids, not file-restore points. The compaction guide covers what survives.

When the session file is damaged#

A crash or a power loss can leave a half-written line in events.jsonl. On older builds the resume failed with:

Failed to resume session: Error: Session file is corrupted (line 7103: SyntaxError...)

Update to 1.0.88 or later. 1.0.66 (30 June 2026) added recovery of corrupted session history on load, 1.0.86 (17 September 2026) allowed resuming sessions whose transcripts contain recoverable corruption, and the issue was closed as resolved in 1.0.88, so a build older than that is the first thing to rule out (#1864, closed as completed 26 September 2026).

If the current build still refuses the session:

1. Stop and copy. Back up ~/.copilot/session-state/<session-id>/ before editing anything. Keep the original untouched while you experiment on the copy.
2. Read the line named in the error. A crash commonly leaves the final line incomplete; removing only that partial last line from the copy is the usual repair.
3. Check whether it is a schema problem, not damage. Sessions written by an older build can be rejected after an upgrade when the event format tightens; a compaction-event case from 1.0.35 was closed as completed in April 2026 (#2899, closed 23 April 2026). Updating is the fix.
4. Rebuild the index, not the log. /chronicle reindex rebuilds session-store.db from session-state/ and syncs session data. Use it after moving or restoring session directories, or deleting the index. It cannot repair a malformed event log.

If the session will not load, the transcript is still readable: events.jsonl is line-delimited JSON, so message text opens in any editor. That is enough to salvage decisions, commands and file names.

One cross-surface limit: VS Code Copilot Chat has rejected CLI session files, with an error naming an unexpected ephemeral value (#2000, open, updated 26 October 2026). Use /share to export instead of dropping events.jsonl into another tool.

After a crash or a restart#

1.0.81 (27 August 2026) added a startup prompt offering to restore sessions that were still open when the CLI process went away, including a turn that was in progress. 1.0.83 (4 September 2026) turned that prompt off by default while the dialog is reworked. Current builds make it opt-in:

COPILOT_ENABLE_INTERRUPTED_SESSION_RESTORE=1 copilot

If you remember seeing the restore prompt and then it disappeared after an update, that is why. The session was still on disk; the prompt is the part that changed.

Fork it, export it, or move it#

/fork (alias /branch) copies the current conversation into a new session and leaves the original alone. It works while the agent is running, and /fork worktree puts the copy in a new Git worktree — a separate checkout of the same repository — branched from HEAD. The fork is a normal session, so it appears in the same lists and resumes separately.

To get the conversation out of the CLI, use /share:

/share file ./handoff.md
/share html
/share gist

/share file writes Markdown; with no path it uses copilot-session-<session-id>.md in the current directory. /share html writes an interactive HTML file. For a programmatic run, copilot -p... --share=./session.md writes the export after the run. Exporting a resumed session used to write only the latest run; 1.0.83 fixed that, so a current build exports the whole transcript.

For a whole-machine backup, copy ~/.copilot/session-state/ while the CLI is closed. The backup guide covers the same job across agents. After restoring those directories on another machine, run /chronicle reindex to rebuild the index. Sessions sync to your account by default; --sync-session=off disables that for a run. Syncing is not sharing: a synced session is visible only to you unless you share it.

Where to go next#

• Copilot CLI guides — instructions, permissions, agents and the rest of the set.
• Back up coding-agent sessions — what to copy before an upgrade.
• Clear or delete coding-agent session history — the destructive commands, and what they leave behind.
• Context compaction — if the session resumed but the middle of the work is missing.
• Hand off work between Claude Code and Codex — if the conversation has to become a note for another agent or machine.