[Feedback]: Open projects inside WSL on Windows

What problem are you trying to solve?

I open a project that lives inside WSL (Ubuntu 24.04) from Command Code Desktop on Windows. The app opens the \\wsl.localhost\... path fine — reading files, glob, grep, and edits all work over the UNC path. But the agent's shell side runs on Windows, not inside the distro, so the two halves disagree about where the project is and what can run in it.

Environment: Desktop 0.1.31, Windows 11 (build 26200), WSL 2 distro Ubuntu 24.04 (kernel 6.18.33.2-microsoft-standard-WSL2), project opened at \\wsl.localhost\Ubuntu-24.04\home\<user>\projects\<project>.

Three things go wrong.

1. Shell calls start in the wrong directory. Shell commands are spawned as Windows cmd.exe / Windows PowerShell 5.1, not the WSL shell. Every cmd.exe launch cannot enter a UNC path:

CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

The harness then discards that fallback cwd (it resolves outside the project), so shell commands do not start in the project at all. There is no way to make cmd.exe use the UNC path as cwd — it is a documented limitation of the tool, not of this app.

2. The project's toolchain does not exist on the Windows side.

tool	Windows	WSL (Ubuntu 24.04)
php	not found	PHP 8.4.21
composer	not found	2.9.7
node	C:\nvm4w\nodejs\node.exe	v24.16.0

So every command the project actually depends on — test runner, build, migrations, dev server, git hooks — has to be hand-wrapped as wsl.exe -d Ubuntu-24.04 -- bash -lc '<command>' before it means anything. An agent cannot reliably infer that on its own: it sees Windows-style paths and a UNC root, and has no way to know a Linux path (/home/<user>/projects/<project>) refers to the same tree.

3. The mismatch is silent until something fails. Because file operations work, the project looks correctly opened. The divergence only surfaces later, as a command that reports "not found" for a tool the project obviously uses, or one that quietly runs in the wrong directory. That makes the failure expensive to diagnose — the initial state looks healthy.

Net effect: a WSL project is half-open. File-operating tasks work; anything that compiles, tests, runs, or touches git hooks does not.

What would improve it?

Detect when the opened project is a WSL path (\\wsl.localhost\<distro>\... or \\wsl$\<distro>\...) and run the agent on the WSL side for that project — shell commands execute inside the distro with the cwd translated to the corresponding Linux path, so the toolchain, environment variables, and paths all match what the project expects. Functionally the equivalent of wsl.exe -d <distro> --cd <linux-path>.

If switching execution wholesale is out of scope, then at minimum:

• translate the UNC project path to its Linux path and use that as the cwd for shell calls,
• route shell execution through the distro instead of cmd.exe / Windows PowerShell,
• show which OS the agent is running commands on, so the mismatch is visible instead of silent.

A remote or headless mode — CLI running inside WSL, desktop app connecting to it — would also solve this. I mention it as an alternative shape, not a preference; the ask is that the project's execution context matches where the project actually lives.

What do you do today?

I wrap every command by hand:

wsl.exe -d Ubuntu-24.04 -- bash -lc 'cd /home/<user>/projects/<project> && php artisan test'

That means the agent and I both maintain two mental models of the same project, and any command the agent runs directly is wrong until I correct it.

Product area

Terminal

Related

• CommandCodeAI/command-code#869 — the same request filed against the CLI repo ("WSL Project Folder in Windows app"). This issue is the desktop-repo counterpart, with the reproduction details that issue lacks.
• openai/codex#18332 — "codex desktop cannot open or create project in wsl" (open). Same gap on the same platform.
• anomalyco/opencode#28303 — OpenCode desktop project picker missing deeper WSL folders (closed). Same class of problem in the desktop project picker.

Start with the Terminal shell-execution and project-path handling described in the report, reproducing the issue with a \wsl.localhost\... project path. Compare the command cwd and execution environment with the WSL distro context. Done means commands run in the distro with the translated Linux cwd, or the execution context is clearly surfaced if full routing is out of scope.