session-recovery

name	session-recovery
description	Find and resume interrupted Copilot CLI sessions using session_store queries
domain	workflow-recovery
confidence	high
source	earned
tools	[{"name":"sql","description":"Query session_store database for past session history","when":"Always — session_store is the source of truth for session history"}]

Context

Squad agents run in Copilot CLI sessions that can be interrupted — terminal crashes, network drops, machine restarts, or accidental window closes. When this happens, in-progress work may be left in a partially-completed state: branches with uncommitted changes, issues marked in-progress with no active agent, or checkpoints that were never finalized.

Copilot CLI stores session history in a SQLite database called session_store (read-only, accessed via the sql tool with database: "session_store"). This skill teaches agents how to query that store to detect interrupted sessions and resume work.

Patterns

1. Find Recent Sessions

Query the sessions table filtered by time window. Include the last checkpoint to understand where the session stopped:

SELECT
  s.id,
  s.summary,
  s.cwd,
  s.branch,
  s.updated_at,
  (SELECT title FROM checkpoints
   WHERE session_id = s.id
   ORDER BY checkpoint_number DESC LIMIT 1) AS last_checkpoint
FROM sessions s
WHERE s.updated_at >= datetime('now', '-24 hours')
ORDER BY s.updated_at DESC;

2. Filter Out Automated Sessions

Automated agents (monitors, keep-alive, heartbeat) create high-volume sessions that obscure human-initiated work. Exclude them:

SELECT s.id, s.summary, s.cwd, s.updated_at,
  (SELECT title FROM checkpoints
   WHERE session_id = s.id
   ORDER BY checkpoint_number DESC LIMIT 1) AS last_checkpoint
FROM sessions s
WHERE s.updated_at >= datetime('now', '-24 hours')
  AND s.id NOT IN (
    SELECT DISTINCT t.session_id FROM turns t
    WHERE t.turn_index = 0
      AND (LOWER(t.user_message) LIKE '%keep-alive%'
           OR LOWER(t.user_message) LIKE '%heartbeat%')
  )
ORDER BY s.updated_at DESC;

3. Search by Topic (FTS5)

Use the search_index FTS5 table for keyword search. Expand queries with synonyms since this is keyword-based, not semantic:

SELECT DISTINCT s.id, s.summary, s.cwd, s.updated_at
FROM search_index si
JOIN sessions s ON si.session_id = s.id
WHERE search_index MATCH 'auth OR login OR token OR JWT'
  AND s.updated_at >= datetime('now', '-48 hours')
ORDER BY s.updated_at DESC
LIMIT 10;

4. Search by Working Directory

SELECT s.id, s.summary, s.updated_at,
  (SELECT title FROM checkpoints
   WHERE session_id = s.id
   ORDER BY checkpoint_number DESC LIMIT 1) AS last_checkpoint
FROM sessions s
WHERE s.cwd LIKE '%my-project%'
  AND s.updated_at >= datetime('now', '-48 hours')
ORDER BY s.updated_at DESC;

5. Get Full Session Context Before Resuming

Before resuming, inspect what the session was doing:

-- Conversation turns
SELECT turn_index, substr(user_message, 1, 200) AS ask, timestamp
FROM turns WHERE session_id = 'SESSION_ID' ORDER BY turn_index;

-- Checkpoint progress
SELECT checkpoint_number, title, overview
FROM checkpoints WHERE session_id = 'SESSION_ID' ORDER BY checkpoint_number;

-- Files touched
SELECT file_path, tool_name
FROM session_files WHERE session_id = 'SESSION_ID';

-- Linked PRs/issues/commits
SELECT ref_type, ref_value
FROM session_refs WHERE session_id = 'SESSION_ID';

6. Detect Orphaned Issue Work

Find sessions that were working on issues but may not have completed:

SELECT DISTINCT s.id, s.branch, s.summary, s.updated_at,
  sr.ref_type, sr.ref_value
FROM sessions s
JOIN session_refs sr ON s.id = sr.session_id
WHERE sr.ref_type = 'issue'
  AND s.updated_at >= datetime('now', '-48 hours')
ORDER BY s.updated_at DESC;

Cross-reference with gh issue list --label "status:in-progress" to find issues that are marked in-progress but have no active session.

7. Resume a Session

Once you have the session ID:

# Resume directly
copilot --resume SESSION_ID

Examples

Recovering from a crash during PR creation:

1. Query recent sessions filtered by branch name
2. Find the session that was working on the PR
3. Check its last checkpoint — was the code committed? Was the PR created?
4. Resume or manually complete the remaining steps

Finding yesterday's work on a feature:

1. Use FTS5 search with feature keywords
2. Filter to the relevant working directory
3. Review checkpoint progress to see how far the session got
4. Resume if work remains, or start fresh with the context

Anti-Patterns

• ❌ Searching by partial session IDs — always use full UUIDs
• ❌ Resuming sessions that completed successfully — they have no pending work
• ❌ Using MATCH with special characters without escaping — wrap paths in double quotes
• ❌ Skipping the automated-session filter — high-volume automated sessions will flood results
• ❌ Assuming FTS5 is semantic search — it's keyword-based; always expand queries with synonyms
• ❌ Ignoring checkpoint data — checkpoints show exactly where the session stopped