Describe the bug
After the local machine is locked (e.g. stepping away briefly) and VS Code's Remote-SSH connection drops and later reconnects, the Copilot CLI chat panel in VS Code shows the current/recent session as empty (no turns), giving the impression that chat history was lost.
This is not actual data loss. I confirmed the underlying data is fully intact:
~/.copilot/session-store.db (SQLite) still contains all turns for the affected sessions in the turns table, with complete user_message and assistant_response text.
- Running the standalone
copilot CLI in a terminal against the same session shows the full history correctly.
- Only the VS Code panel's view of the session appears empty/reset after the reconnect.
This has happened repeatedly (3 times in one day) immediately following machine lock -> SSH reconnect cycles.
Affected version
GitHub Copilot CLI 1.0.80
Steps to reproduce the behavior
- Open a VS Code window connected via Remote-SSH to a remote Linux host.
- Start a Copilot CLI chat/agent session in VS Code and have a multi-turn conversation.
- Lock the local machine long enough for the Remote-SSH connection to drop (observed even after a short lock).
- Unlock the machine and let VS Code reconnect to the remote host.
- View the Copilot CLI chat panel for the session that was active before the lock.
- See: the panel shows an empty/reset transcript, even though
~/.copilot/session-store.db on the remote host still has all turns for that session (verified directly via sqlite3 ~/.copilot/session-store.db "SELECT * FROM turns WHERE session_id='<id>'"), and the standalone copilot terminal CLI shows the full history for the same session.
Expected behavior
After a Remote-SSH reconnect, the VS Code Copilot CLI panel should reload the session transcript from the on-disk store (~/.copilot/session-store.db), the same way the standalone terminal copilot CLI does, instead of showing an empty/reset conversation.
There appears to be a stale or invalidated in-memory/cache state on the VS Code extension/agent-host side (possibly related to ~/.copilot/vscode.session.metadata.cache.json) that isn't correctly rehydrated from the durable on-disk session store after a connection drop.
Additional context
- Operating system (remote host): Ubuntu 24.04.4 LTS (Noble Numbat)
- Connection type: VS Code Remote-SSH
- Integration: VS Code "agent host" plugin (
agent-host-copilotcli)
- Impact: Users mistakenly believe their conversation history and context are lost after every lock/reconnect cycle, disrupting long-running remote development work, even though no data is actually destroyed.
Describe the bug
After the local machine is locked (e.g. stepping away briefly) and VS Code's Remote-SSH connection drops and later reconnects, the Copilot CLI chat panel in VS Code shows the current/recent session as empty (no turns), giving the impression that chat history was lost.
This is not actual data loss. I confirmed the underlying data is fully intact:
~/.copilot/session-store.db(SQLite) still contains all turns for the affected sessions in theturnstable, with completeuser_messageandassistant_responsetext.copilotCLI in a terminal against the same session shows the full history correctly.This has happened repeatedly (3 times in one day) immediately following machine lock -> SSH reconnect cycles.
Affected version
GitHub Copilot CLI 1.0.80
Steps to reproduce the behavior
~/.copilot/session-store.dbon the remote host still has all turns for that session (verified directly viasqlite3 ~/.copilot/session-store.db "SELECT * FROM turns WHERE session_id='<id>'"), and the standalonecopilotterminal CLI shows the full history for the same session.Expected behavior
After a Remote-SSH reconnect, the VS Code Copilot CLI panel should reload the session transcript from the on-disk store (
~/.copilot/session-store.db), the same way the standalone terminalcopilotCLI does, instead of showing an empty/reset conversation.There appears to be a stale or invalidated in-memory/cache state on the VS Code extension/agent-host side (possibly related to
~/.copilot/vscode.session.metadata.cache.json) that isn't correctly rehydrated from the durable on-disk session store after a connection drop.Additional context
agent-host-copilotcli)