The session list became a database problem.
VS Code 1.139 stores lightweight session and chat metadata in a central catalog. Earlier builds opened each conversation database while building the list. The release notes say the new path measured 0.1 seconds for the first listing and 0.15 seconds for refresh on a development machine with about 645 sessions. The prior path measured 1.3 seconds and 0.6 seconds in the same test.[1]
Those numbers are one vendor test on one machine. They are still a clean architecture clue. List operations should read list-shaped data.
The transcript did not get flattened.
VS Code says full conversation content remains isolated in each session and chat database. The catalog carries the metadata needed for listing. Old sessions migrate in the background.[1]
Open the catalog to find the job. Open the transcript to inspect the job.
This split protects two useful properties. The list stays fast as history grows. Each session remains a distinct evidence record instead of becoming one giant shared blob.
Attention belongs in the index.
The same release adds compact rows, in-place renaming, progress summaries, and automatic expansion when a session needs input or approval.[1] That is more than a density pass. It names the fields a session catalog should carry: identity, workspace, active work, progress, and human attention state.
If the operator must open a transcript to learn that a job is blocked, the index is missing an operational field.
Persistence moved outside the window.
VS Code's Agent Host is a dedicated process that owns sessions. Multiple windows can connect to one host. The host can also run remotely, while clients monitor and steer the same live session.[2]
That boundary makes the catalog more than interface cache. It becomes the operator's map to work that can outlive the window where it started. Client tools may still route through a connected client, so durable session state does not mean every capability remains available after a window closes.
Use one database per job on purpose.
SQLite documents local application storage as a different problem from a shared client-server database. It also describes separate database files for separate subdomains as a way to limit contention.[3] That supports the broad storage pattern, not VS Code's implementation details.
A session store should make deletion, export, repair, and retention legible per job. A catalog should be disposable enough to rebuild from those stores. If deleting the index destroys the work, it was never just an index.
Run the migration like a pit stop.
- Write the minimum catalog schema. Keep identifiers, labels, timestamps, workspace pointers, progress, and attention state.
- Keep transcript bodies, tool output, patches, and bulky evidence out of list reads.
- Backfill in the background. Measure missing, duplicate, and stale catalog rows while old stores remain authoritative.
- Prove that a deleted catalog can be rebuilt. Compare rebuilt rows against the session stores.
- Measure cold list, warm refresh, attention update, transcript open, and rebuild time on your own history.