Describe the bug
When sessionSync.level = "local" (user chose "Keep on this device only"), the session_store_sql tool is still injected into every agent's system message and remains callable — but returns 0 rows for all tables. There is no indication to agents that the cloud store is empty because sync is disabled — agents can't distinguish this from a user who genuinely has no session history.
The local ~/.copilot/session-store.db has all the data (600+ sessions, 5,000+ turns), but the system message directs agents to use session_store_sql for session history queries, so they conclude there's no history.
Steps to reproduce
- Select "Keep on this device only" when prompted for session storage (config:
sessionSync: [{ origin: "*", level: "local" }])
- Use the CLI — sessions accumulate in
~/.copilot/session-store.db
- In any session, ask "what did I work on this week?" or have an agent query
session_store_sql
- Agent gets 0 results and reports no session history
Expected behavior
When cloud sync is disabled, one of:
- Don't expose
session_store_sql — if the cloud store won't have data, don't offer the tool
- Have
session_store_sql query the local DB — the schemas are compatible (sessions, turns, checkpoints, session_files, session_refs exist in both)
- At minimum, annotate the tool description so agents know the cloud store won't have data when sync is disabled, and can fall back to the local DB
The above are suggestions — the team likely has better ideas for the right approach given the broader session storage architecture.
Actual behavior
session_store_sql is injected unconditionally with no awareness of the sessionSync config
- Returns 0 rows for all queries — agents can't distinguish "no sessions" from "sync disabled"
- The system message actively encourages agents to use this tool for temporal queries ("what did I work on?", "find prior sessions", etc.)
Impact
- Automated agents (maintenance tasks, briefings, session digests) that query
session_store_sql silently get wrong results
- The
/chronicle feature and any built-in session history features are effectively broken for local-only users
- No error or warning — just empty results that look like valid "no data" responses
Environment
- Copilot CLI: 1.0.24
- OS: Windows 11
- Config:
sessionSync: [{ origin: "*", level: "local" }]
- Local session-store.db: 105 MB, 613 sessions, 5,342 turns (healthy)
- Cloud session store: 0 rows across all tables
Workaround
Query ~/.copilot/session-store.db directly via Python/sqlite3. The schema is compatible. This requires every consumer of session data to implement fallback logic.
Describe the bug
When
sessionSync.level = "local"(user chose "Keep on this device only"), thesession_store_sqltool is still injected into every agent's system message and remains callable — but returns 0 rows for all tables. There is no indication to agents that the cloud store is empty because sync is disabled — agents can't distinguish this from a user who genuinely has no session history.The local
~/.copilot/session-store.dbhas all the data (600+ sessions, 5,000+ turns), but the system message directs agents to usesession_store_sqlfor session history queries, so they conclude there's no history.Steps to reproduce
sessionSync: [{ origin: "*", level: "local" }])~/.copilot/session-store.dbsession_store_sqlExpected behavior
When cloud sync is disabled, one of:
session_store_sql— if the cloud store won't have data, don't offer the toolsession_store_sqlquery the local DB — the schemas are compatible (sessions,turns,checkpoints,session_files,session_refsexist in both)The above are suggestions — the team likely has better ideas for the right approach given the broader session storage architecture.
Actual behavior
session_store_sqlis injected unconditionally with no awareness of thesessionSyncconfigImpact
session_store_sqlsilently get wrong results/chroniclefeature and any built-in session history features are effectively broken for local-only usersEnvironment
sessionSync: [{ origin: "*", level: "local" }]Workaround
Query
~/.copilot/session-store.dbdirectly via Python/sqlite3. The schema is compatible. This requires every consumer of session data to implement fallback logic.