The Problem
Windows Subsystem for Linux creates permission chaos when developers switch between PowerShell and Ubuntu terminals. Files accessible in one environment throw "permission denied" in the other. The usual fixes - chmod 777, sudo, restarting WSL - either fail or create security risks.
One developer lived with this for two years, working around it with GitHub Codespaces and running everything as root. The actual solution took five minutes.
The Fix
Open a terminal. Switch to WSL (wsl or ubuntu). Navigate to your project directory. Type code . to launch VS Code from within the WSL environment.
This ensures VS Code attaches to the WSL filesystem properly, not through the /mnt mount layer where permission problems originate. Tools and dependencies installed in WSL become visible. Permission errors disappear.
Why This Matters
WSL's convenience comes with architectural compromises. When you access Windows drives via /mnt, the DrvFS layer defaults to 0777 permissions - everything executable, nothing secure. Git treats files as modified when they're not. Linux permissions don't persist between sessions.
The recommended fix involves editing /etc/wsl.conf to add mount options like metadata,umask=22,fmask=11. This persists Linux metadata on NTFS files through extended attributes. It works, mostly.
The Real Question
History suggests WSL suits development and testing, not production workloads. Enterprise teams shipping Linux applications should consider: full Linux VMs offer stability WSL can't match. Dual-boot eliminates the translation layer entirely.
Docker on WSL2 exacerbates mount volatility - permissions change spontaneously during sessions, according to ongoing GitHub discussions. Microsoft's own documentation acknowledges the limitations, recommending WSL's native filesystem for Linux-only operations.
Trade-offs
The code . workaround is elegant but reveals WSL's fundamental constraint: it's a Windows feature pretending to be Linux, not Linux. For quick scripts and CLI tools, good enough. For containerized workloads or anything requiring reliable file ownership, the cracks show.
Developers have been running everything as root to avoid these issues. That should worry security teams more than it apparently does.