Hi everyone! Sharing a detailed analysis of a common issue where conversation history disappears from the sidebar on Windows. Below is a high-level explanation of why it happens, a technical breakdown, and a permanent workaround you can apply.
1. High-Level Overview
The Issue
Conversations are visible in the sidebar upon initial loading, but disappear immediately after they are clicked or opened. The underlying conversation data remains intact on disk, but the IDE filters the entries out of the active sidebar panel.
The Cause
This issue is caused by a mismatch in how the frontend and backend components of the IDE represent Windows drive-letter paths:
- The Frontend UI: Represents the active workspace folder URI using percent-encoding for the colon (e.g.,
file:///c%3A/...), which is the standard serialization format in VS Code. - The Sync/Agent Backend: Saves and updates conversation metadata in the database using a raw colon (e.g.,
file:///c:/...).
Because the frontend expects %3A in-memory while the database contains : for updated conversations, the sidebar renderer fails to match the conversation to the active project workspace and filters it out.
2. Cross-Platform Analysis
While the symptoms of this bug primarily manifest on Windows due to drive-letter path serialization, the architecture must remain robust across all platforms:
-
Path Formatting:
- Windows: Uses drive letters with colons (
C:), which triggers the percent-encoding mismatch between%3A(frontend) and:(backend). - macOS & Linux: Use standard Unix paths starting with
/(e.g.,/Users/...or/home/...). Since these paths contain no drive-letter colons, they do not experience this encoding discrepancy.
- Windows: Uses drive letters with colons (
-
Case Sensitivity:
- Filesystem casing rules vary by operating system (e.g., Linux is case-sensitive, while Windows and macOS are case-insensitive). Raw string-level comparison fails to account for these differences.
3. Recommended Fixes
A permanent, cross-platform fix can be implemented using one of the following two approaches:
Approach A: Standardize Backend URI Serialization (Recommended)
Unify the URI format generated by the backend sync engine (jetskiAgent). Instead of manually constructing the URI string by prepending file:/// to the path, use the standard vscode-uri module’s URI.file() serialization:
// Correct backend serialization:
const uri = URI.file(absolutePath).toString();
// Properly encodes Windows drive-letter colons to %3A,
// while formatting Unix-style paths correctly for macOS/Linux.
Approach B: Use Canonical URI Comparison in the Frontend
Instead of performing a direct string-equality check (===), the frontend should use VS Code’s standard canonical URI utilities (e.g., extUri.isEqual(uri1, uri2)). These services automatically normalize:
- Percent-encoding differences (
%3Avs:). - Platform-specific case-sensitivity rules (such as matching uppercase/lowercase drive letters on Windows or handling case-insensitivity on macOS).
- Trailing slash normalization.
// Robust comparison using VS Code's extUri utility:
this.extUri.isEqual(uriA, uriB);
4. Temporary Workaround
Until an official patch is released, the workaround consists of:
- Normalizing Configurations: Updating all
storage.jsonandworkspaceStoragepaths to use percent-encoded%3Acolons. - Applying JS Patch: Modifying the Protobuf decoder function
hR(t, e)inworkbench.desktop.main.jsto automatically replacefile:///c:/withfile:///c%3A/during deserialization:function hR(t,e){ const res=yOt(e,Bku(t)); if(res&&Array.isArray(res.workspaces)){ for(const w of res.workspaces){ if(w&&typeof w.workspaceFolderAbsoluteUri === "string"){ w.workspaceFolderAbsoluteUri = w.workspaceFolderAbsoluteUri.replace(/file:\/\/\/([a-zA-Z]):/g, "file:///$1%3A"); } } } return res; } - Registering New Checksum: Recalculating the SHA-256 hash of the modified JS file and updating the
checksumskey inproduct.jsonto prevent the IDE’s integrity check from triggering an “installation corrupt” warning.