I keep my Flutter projects inside WSL because Windows disk IO over /mnt/c/ is terrible. Git operations drag, scripts crawl, and agents get stuck. Native ext4 inside WSL is the only way to actually work.

But yesterday I needed to build a Windows desktop target for a new app.

If you run flutter run -d windows from inside the WSL terminal, it obviously fails because WSL is a Linux environment. It doesn't see Windows devices.

So you open PowerShell, navigate to the WSL network share (\\wsl.localhost\Ubuntu\home\evgenii\projects\my_app), and run it there. And it immediately crashes:

CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
Error: No pubspec.yaml file found.

Flutter relies on cmd.exe under the hood for Windows builds, and CMD absolutely refuses to use a UNC network path as a working directory.

Instead of moving files, you can trick Windows into seeing the UNC path as a local drive using a Directory Symlink.

Open PowerShell (as Administrator, unless you have Windows Developer Mode enabled) and link a local path to your WSL path:

New-Item -ItemType SymbolicLink -Path "C:\wsl_projects\my_app" -Target "\\wsl.localhost\Ubuntu\home\evgenii\projects\my_app"

If you prefer classic cmd.exe, the syntax is:

mklink /D "C:\wsl_projects\my_app" "\\wsl.localhost\Ubuntu\home\evgenii\projects\my_app"

(The /D flag is required because it's a directory link, not a file).

Now, open PowerShell and navigate to your local link:

cd C:\wsl_projects\my_app
flutter run -d windows

Because your terminal's current working directory starts with C:\, cmd.exe is perfectly happy. It compiles the native Windows executable without complaining, but all the actual file reads and writes are piped directly to the fast WSL filesystem underneath.

Problem solved without ruining your Linux dev setup.