How to Access GitHub Copilot Chat History Across Devices in VS Code: Storage Paths, Remote-SSH Architecture, and Sync Options - Devuly | Smart Analytics for Developers & Projects

This article explains why GitHub Copilot Chat history in VS Code does not naturally sync across devices. The core reason is that most Copilot Chat state is stored locally in workspaceStorage. You will also see the paths for Windows, macOS, and Linux, how Remote-SSH separates the local UI from remote execution, and three practical approaches: export, parsing, and cloud sync. Keywords: VS Code, Copilot Chat, workspaceStorage.

Table of Contents

The technical specification snapshot is straightforward

Parameter	Details
Core topic	Accessing GitHub Copilot Chat history across devices in VS Code
Related software	Visual Studio Code, GitHub Copilot Chat, Remote-SSH
Languages involved	Python, Shell
Runtime model	Local UI + remote workspace execution
Key paths	`%APPDATA%\\Code\\User\\workspaceStorage` and equivalents
Storage format	`json`, `jsonl`
Core dependencies	VS Code, Copilot extension, Remote-SSH, optional Syncthing/OneDrive
Reference sources	GitHub Community, VS Code Copilot-related issues

Copilot Chat history is stored locally by default, not on the remote host

The most common misunderstanding is this: if you connect to a Linux server through Remote-SSH, Copilot Chat history should also live on that server. In practice, it does not. Copilot Chat is primarily a UI-side extension, and its session state is usually stored in the local VS Code user directory rather than on the remote Linux host.

This directly explains a common behavior: if you connect to the same server from two Windows PCs, the Copilot Chat history you see still does not match across them. The problem is not on the server. Each local machine maintains its own separate cache.

# Windows
%APPDATA%\Code\User\workspaceStorage

# macOS
~/Library/Application Support/Code/User/workspaceStorage/

# Linux
~/.config/Code/User/workspaceStorage/

These paths show the main location where Copilot Chat state is stored. If you want cross-device sync, this is where the process begins.

Remote-SSH fundamentally decouples the local interface from remote execution

The key design of Remote-SSH is not to move the entire VS Code application to the remote machine. Instead, it keeps the interface local and moves code execution and language services to the remote environment. The editor, chat panel, menus, and most interactions you see are still rendered by the local VS Code instance.

Because of that, Copilot Chat, as an extension with strong UI interaction, is more likely to store session state locally. In contrast, workspace extensions such as Python and Go often run on the remote host to analyze code, invoke interpreters, and support debugging.

You can understand information location and visibility like this

Information type	Runtime or storage location	Visible to other users on the same host
Copilot Chat history	Local machine	No
GitHub sign-in credentials	Local machine	No
UI settings such as themes and icons	Local machine	No
Terminal command history	Remote host	Partially visible
Source code files	Remote host	Visible if the account is shared
Workspace extensions such as Python/Go	Remote host	Visible if the account is shared

This layered model matters because it determines both where to look for records and whether someone else can see your chat content.

Workspace directory names are hashes, and chat data usually lives under the chatSession subdirectory

Under workspaceStorage, you will not see direct project names. Instead, you will find a set of alphanumeric directory names. Each one maps to a workspace ID. Inside those directories, you can often find data related to project paths, remote identifiers, and chat sessions.

If you used Copilot Chat heavily on a given day, you can usually find newer json or jsonl files in the corresponding workspace’s chatSession directory. These files can become very large. Sizes from tens of megabytes to well over one hundred megabytes are common.

# List the newest session files by modification time in the target directory
ls -lht | head

# Filter files by date range
find . -maxdepth 1 -newermt "2024-01-01" ! -newermt "2024-02-01" -ls

These commands help you quickly locate recently active chat cache files, which is useful for manual inspection and archiving.

There are three practical ways to export and back up Copilot Chat history

The first method is the most direct: right-click in the chat window and choose Copy or Copy All. The former usually copies only the current response, while the latter exports the entire session. The advantage is speed, and the content is often already in Markdown, which makes it easy to archive immediately.

The second method is more structured: run Chat: Export Session... from the Command Palette. This exports the currently open chat session as a JSON file. Note that it always exports only the currently active session, so for batch export you need to switch sessions one by one.

Command Palette export is better for machine processing

The exported JSON is often large, but it is much more structured. That makes it better suited for cleanup, Markdown conversion, knowledge base indexing, or even retrieval augmentation in other AI systems.

import json
from pathlib import Path

# Extract Copilot-exported turn records and format them into readable text
def format_chat_log(chat_log: dict) -> str:
    turns = chat_log.get("providerState", {}).get("turns", [])  # Read conversation turns
    blocks = []
    for turn in turns:
        request = turn.get("request", {}).get("message", "")  # User prompt
        response = turn.get("response", {}).get("message", "")  # AI response
        blocks.append(f"## Question\n{request}\n\n## Answer\n{response}")
    return "\n\n".join(blocks)

file_path = Path("chat.json")
chat_log = json.loads(file_path.read_text(encoding="utf-8"))  # Read exported JSON
formatted = format_chat_log(chat_log)
Path("formatted_chat_log.md").write_text(formatted, encoding="utf-8")  # Write Markdown output

This script converts an exported Copilot JSON session into Markdown that is easier to read and archive.

The real challenge of cross-device sync is not export, but ongoing consistency

Manual copying can solve a one-time migration, but it does not solve long-term maintenance. In real-world workflows, developers often work across multiple session windows in parallel. After several days, it becomes hard to tell which session is the newest and which one is the most complete. The result is fragmented conversation history.

That is why a more practical goal is not to export once in a while, but to continuously sync the local workspaceStorage directory, or filtered chatSession files, to a central location such as OneDrive, Dropbox, or a Syncthing-managed directory.

A sync layer is better than a Git repository layer

Git is not a good fit for serving as the central repository for Copilot Chat history. The reason is simple: individual session files can be large, change frequently, and provide very little value in diffs. In contrast, cloud sync folders or LAN-based sync tools are much better suited to this kind of binary-like or large-JSON workload.

# Example: create a local backup before putting workspaceStorage under a sync strategy
cp -r "$APPDATA/Code/User/workspaceStorage" "$APPDATA/Code/User/workspaceStorage.bak"

This step is not the sync process itself. It is a required risk-isolation step before enabling any sync tool.

The currently practical solution combines export-based archiving with directory-level sync

If stability is your priority, a two-layer approach works best. In the first layer, use Export Session or Copy All to create readable archives. In the second layer, use Syncthing or a cloud drive to sync the raw cache directory. The first layer solves readability. The second layer solves continuity.

If your goal is to restore native chat state on another device inside the Copilot UI, the problem becomes much more complex. At this stage, community practice still mostly relies on manually copying session files into the matching workspace directory on the target machine. Success rates and compatibility depend on the exact VS Code and Copilot versions involved, and there is no official guarantee.

The conclusion here is very clear

Copilot Chat history does not automatically carry across devices, and this is not fundamentally an SSH problem. It is a local state problem. What you actually need to manage is the local workspaceStorage directory, the corresponding hashed workspace directories, and the chatSession files inside them.

FAQ

Q1: Why are Copilot Chat histories not synced when I connect to the same Linux server from two computers?

Because chat history is mainly stored in each machine’s local VS Code user directory rather than on the remote server. Remote-SSH shares the workspace and execution environment, not local UI state.

Q2: What is the safest backup method?

In the short term, the safest method is to use Chat: Export Session... to export JSON and then convert it to Markdown with a script. In the long term, the safest method is directory-level sync for workspaceStorage combined with versioned backups.

Q3: Can I directly import chat history from one device to another and keep using it inside the Copilot window?

In theory, you can try copying the relevant chatSession files and workspace directory, but this is not an officially supported or stable workflow. A more reliable approach is still to export the content, archive it as knowledge, and then retrieve and reuse it on the new device as needed.

Core summary: This article systematically explains where GitHub Copilot Chat stores data in VS Code under both local and Remote-SSH scenarios, how the runtime model works, and why cross-device sync remains difficult. It also provides actionable guidance for identifying workspaceStorage paths, locating chatSession files, and implementing export, formatting, and cloud-sync workflows.