Agent sessions anchor to the Windows host instead of WSL, and session state is split across two session-store.db files

Describe the bug

On a Windows host where all development happens inside WSL2, agent chat sessions initialize on the Windows side rather than in the WSL distro. This mirrors #4216 (same fragmentation reported for SSH dev containers) but for WSL, which is a far more common setup.

Two distinct problems result:

1. Wrong execution context. A workspace-less chat gets a Windows scratch CWD and Windows-hosted tooling, even though the user's toolchain, runtimes, dotfiles, and repos live in WSL. Invoking WSL from the session lands in /mnt/c, not the Linux filesystem.
2. Split session state. Windows and WSL each maintain a separate ~/.copilot root with its own session-store.db. A conversation started on one side is not visible or resumable from the other, so a discussion cannot be handed off to a WSL-backed workspace — it must be restarted as a new session with a manually re-pasted context summary.

Affected version

Not resolvable — no copilot binary is on PATH on either the Windows host or in WSL, as this is the VS Code-embedded agent surface rather than a standalone CLI install. ~/.copilot/logs confirms it is nonetheless this project:

[INFO] Starting CLI in server mode (stdio)
[INFO] Starting CLI in stdio mode (Rust JSON-RPC engine)
[INFO] CLI server ready (stdio mode, Rust JSON-RPC engine)

Steps to reproduce the behavior

1. On Windows 11 with WSL2 (Ubuntu) installed, open a workspace-less Copilot agent chat from VS Code.

2. Ask the agent for its current working directory. It reports a Windows path:

   C:\Users\<user>\.copilot\chats\<session-uuid>
   

3. Have the agent invoke WSL. It lands in the drvfs mount rather than the Linux home:

   $ wsl.exe -d Ubuntu -e bash -lc 'printf "cwd=%s\n" "$PWD"'
   cwd=/mnt/c/Users/<user>/.copilot/chats/<session-uuid>
   

   Any Linux tooling therefore defaults to /mnt/c, which is materially slower for dependency-heavy projects and file watchers, and has different permission/symlink/case semantics than ~.

4. Enumerate both state roots. They are separate, and not even structurally equivalent:

   # Windows: %USERPROFILE%\.copilot
   chats/  ide/  installed-plugins/  instructions/  logs/  session-state/
   config.json  session-store.db  session-store.db-shm  session-store.db-wal
     -> session-state entries: 6
     -> chats entries: 9
   
   # WSL: ~/.copilot
   ide/  installed-plugins/  logs/  session-state/
   config.json  session-store.db  session-store.db-shm  session-store.db-wal
     -> session-state entries: 0
   

   The Windows root has chats/ and instructions/ directories that the WSL root lacks entirely.

5. Confirm the boundary itself is otherwise healthy — a file written in WSL is immediately readable from Windows, so this is not a connectivity or permissions limitation:

   $ wsl.exe -d Ubuntu -e bash -lc 'echo hello-from-wsl > ~/probe.txt'
   $ Get-Content \\wsl.localhost\Ubuntu\home\<user>\probe.txt
   hello-from-wsl
   

Expected behavior

• When the user's development environment is WSL, the agent session should be able to initialize inside the WSL distro — or at minimum offer an explicit, discoverable way to target it — the same way Chat does under Remote - WSL.
• Session history/state should be discoverable across the boundary, so a chat can be handed off to a WSL workspace session without losing continuity.

Any one of these would substantially help, roughly in order of preference:

1. Let an agent session target a WSL distro as its execution context, so tools run natively in Linux with a ~-rooted CWD.
2. Make session state discoverable across the boundary, so a Windows-side chat can be resumed or explicitly handed off to a WSL session.
3. Failing both, surface the anchoring clearly in the UI so the mismatch is obvious up front rather than discovered midway through a task.

Additional context

Environment

• Operating system: Windows 11 (host)
• CPU architecture: x86_64
• WSL: Ubuntu, WSL2, kernel 6.18.33.2-microsoft-standard-WSL2 (a docker-desktop WSL2 distro is also present)
• Shell: PowerShell on the host; bash in WSL
• VS Code: 1.134.0 (110a328ea54b42367b803ec53ee0bf52ef26b419, x64)

Impact

• The agent cannot reach WSL-installed toolchains, runtimes, or language servers without every command being manually wrapped in wsl.exe -d <distro> -e bash -lc '...'.
• Shell state (cd, exports, virtualenv activation) does not persist across wrapped invocations, so multi-step Linux work is fragile.
• Windows and WSL have separate Git configs, credentials, SSH agents, and package caches, so results differ depending on which side ran the command.
• Discussion or triage done in a Windows-anchored chat cannot be continued in a WSL workspace session; context must be manually re-established.

Related issues

• #4216 reports the same host-vs-remote fragmentation for SSH dev containers. This is the WSL case; a shared fix for "respect the workspace's remote context" would likely cover both.
• #3652 (area:sessions, area:platform-windows) shows the session layer already struggles across the WSL boundary — listSessions taking 40–80s plus Failed to create database... unable to open database file looks like the same split-state design surfacing as a perf/IO bug.
• #3528 and #3515 show session CWD/anchoring is fragile more generally.
• #3212 (canonical vs symlink paths on WSL) is the related path-translation friction.

Beginne damit, die Initialisierung des Agent-Chats ohne Workspace und die Auswahl des Ausführungskontexts nachzuverfolgen. Untersuche anschließend die hier beschriebenen Pfade von session-store.db sowie die Verarbeitung von listSessions/session-state. Vergleiche das Verhalten mit Remote - WSL und dem zugehörigen Issue #4216. Als abgeschlossen gilt die Aufgabe, wenn von WSL unterstützte Sitzungen den vorgesehenen Distro-Kontext verwenden oder eine Übergabe klar sichtbar machen und der Sitzungsverlauf über diese Grenze hinweg auffindbar ist.