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.

Commencez par retracer l’initialisation du chat d’agent sans workspace et la manière dont il sélectionne le contexte d’exécution, puis examinez les chemins de session-store.db et la gestion de listSessions/session-state décrites ici. Comparez le comportement avec Remote - WSL et l’issue associée #4216. Le travail est terminé lorsque les sessions prises en charge par WSL utilisent le contexte de distribution prévu ou exposent clairement un transfert, et que l’historique des sessions est découvrable de part et d’autre de la frontière.