Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

[Feedback]: Open projects inside WSL on Windows

未關閉
  • 哪裡不對？
#79 0 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

@aliarain 已經在處理了。

開始於 2026年9月24日。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
48/100
Issue 類型
功能
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
bash, linux, powershell, shell
領域
cli, desktop

研究方向

先從報告中描述的 Terminal shell 執行與專案路徑處理開始，使用 \wsl.localhost\... 專案路徑重現此問題。將命令 cwd 與執行環境和 WSL 發行版內容文進行比較。完成的標準是：命令在該發行版中使用轉換後的 Linux cwd 執行；或者，如果完整路由超出範圍，則清楚呈現執行內容文。

由索引模型根據 Issue 內容生成。

描述

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.
主要語言
Shell
星號
85
分支
5
平均合併
2 小時 46 分鐘
30 天內合併 PR
1

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

CommandCodeAI/desktop 的其他 Issue

查看 CommandCodeAI/desktop 的全部 Issue

相似的 Issue

更多 Shell/Bash Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。