VS Code Copilot CLI panel shows empty transcript after Remote-SSH reconnect, though session data is intact on disk
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 11.2k
- Forks
- 1.9k
- Avg merge
- 14h 16m
- Merged PRs (30d)
- 6
Description
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.- Running the standalone
copilotCLI 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.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 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the lock and Remote-SSH reconnect sequence, then compare the VS Code panel state with ~/.copilot/session-store.db and ~/.copilot/vscode.session.metadata.cache.json; the standalone copilot CLI and the sqlite3 query provide the intact-history baseline. Done means the VS Code Copilot CLI panel reloads the affected session's turns after reconnect instead of showing an empty transcript.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell, sqlite, vscode
- Domain
- cli, desktop, developer-experience
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100