Microsoft’s Windows Subsystem for Linux has evolved from a curiosity into a developer powerhouse, and the ability to seamlessly browse Linux files from File Explorer is one of its most practical features. Two simple commands—typing \\wsl$ into the address bar or running explorer.exe . from a WSL terminal—unlock a safe, supported bridge between the two file systems. First introduced with the Windows 10 May 2019 Update and refined in Windows 11, these techniques have turned a once-hacky workaround into a robust, documented workflow. Here’s everything you need to know to master hybrid development without risking file corruption or permission headaches.

The two-method file access recipe

Getting at your Linux files from Windows boils down to one of two approaches, both of which work identically across WSL1 and WSL2 on modern builds.

Open the current WSL directory in File Explorer

Inside any running WSL distribution, navigate to the directory you want to inspect—for example, cd /home/user/myproject— and run:

explorer.exe .

Windows immediately launches a File Explorer window rooted at that exact Linux folder. The translation happens under the hood: WSL hands Explorer a routed path that renders the Linux file system as if it were a standard Windows folder tree.

Browse all distros from File Explorer

Alternatively, open File Explorer and type \\wsl$ into the address bar. You’ll see a folder for each installed distribution—Ubuntu-22.04, Debian, etc.—presented like network shares. Double-click any distro to navigate its entire root file system. For convenience, you can drag \\wsl$ to Quick Access or right-click a distribution folder and choose “Map network drive…” to assign a persistent drive letter. This method gives Windows-native tools (Notepad, Photoshop, even command-line utilities) safe read/write access to WSL files.

Why Microsoft’s approach is safe

In the early WSL days, adventurous users poked directly into hidden AppData directories where WSL stored its virtual disks. That path frequently led to corrupted ext4 metadata and broken permissions—a quick way to destroy a Linux environment. Microsoft explicitly warns against low-level tinkering with %LOCALAPPDATA%\Packages\... folders.

The \\wsl$ provider and the explorer.exe bridge avoid these pitfalls by presenting a translated view of the Linux file system. When a Windows application creates, edits, or deletes a file through \\wsl$, the 9P file server that underpins WSL intercepts the operation and performs the necessary metadata syncs to keep Linux permissions, ownership, and timestamps coherent. This design means you can safely use Windows tools to work on Linux files without corrupting your distro—provided you stick to the supported access methods.

Choosing the right home for your project files

Performance and safety depend heavily on where you park your working files. Microsoft’s own guidance, reinforced by heavy community testing, recommends two distinct patterns.

Keep files on Windows if your primary editors are Windows-native

If you spend most of your time in Visual Studio, Notepad, or Office and only occasionally invoke Linux commands, store projects on the Windows drive (e.g., C:\Users\YourName\Documents). Access them from WSL via /mnt/c/.... The cross-OS translation layer introduces some I/O overhead, but for ad-hoc Linux tasks it’s negligible. Meanwhile, Windows apps enjoy native performance.

Keep files inside WSL for heavy Linux I/O

When your workflow revolves around frequent Linux builds, package installs (think npm install or apt-get), or Git operations on thousands of small files, place the entire working tree inside the WSL file system (/home/<user>/project). Use \\wsl$ or explorer.exe . to reach those files from Windows when needed. This arrangement lets the Linux kernel handle disk I/O without the performance tax of the 9P translation layer, yielding dramatically faster compile times and install speeds.

Tools that play nice: Notepad, VS Code, and beyond

Notepad’s gradual evolution from a line-ending-challenged relic to a UTF-8-aware editor is a small but meaningful quality-of-life improvement. Starting with Windows 10 Insider builds and now in all supported releases, Notepad handles Unix (LF) and classic macOS (CR) line endings gracefully. That means quick edits to shell scripts or config files opened via \\wsl$ won’t inadvertently inject carriage returns.

For serious development, Visual Studio Code’s Remote – WSL extension remains the gold standard. It runs the UI on Windows but executes all language servers, debuggers, and terminal sessions inside the WSL environment. This sidesteps cross-filesystem performance penalties entirely while preserving a fully native GUI editing experience. The extension essentially puts the best of both worlds on your screen at once.

When things go wrong: troubleshooting the most common WSL file access issues

The integration is reliable for most, but community threads and GitHub issues reveal a handful of recurring snags. Here’s how to handle them.

  • \\wsl$ or explorer.exe . shows nothing
    Confirm WSL is running: wsl -l -v. If the distribution is stopped, start it with wsl or launch it from the Start menu.
  • File Explorer says “not accessible” even though WSL is active
    Restart WSL: run wsl --shutdown and then reopen your distribution. If the issue persists, map the distribution as a network drive (right-click the distro under \\wsl$ and choose “Map network drive…”). Many users report this bypasses intermittent Explorer bugs.
  • explorer.exe . opens Documents instead of the WSL directory
    Ensure you’re inside a valid Linux path (not a /mnt/c location) and that the WSL session is alive. The command should target the current Linux directory, not a Windows one.
  • \\wsl$ disappears after a Windows feature upgrade
    This classic hiccup stems from the provider order for the 9P network provider getting shuffled. The simplest fix: disable the “Windows Subsystem for Linux” optional feature, reboot, re-enable it, and reboot again. In stubborn cases, check for pending Windows updates or, as a last resort, adjust the PROVIDERORDER registry key—but the toggle-and-reboot approach resolves most instances.

These workarounds are pulled straight from support threads and confirmed by Microsoft’s own WSL team. Keep them in your back pocket for the rare occasion Explorer and WSL stop shaking hands.

Advanced configuration for power users

Taming resource usage with .wslconfig

If WSL’s utility VM (visible as vmmem in Task Manager) balloons during heavy builds or Docker operations, create a %USERPROFILE%\.wslconfig file:

[wsl2]
memory=4GB
processors=2

After saving, run wsl --shutdown and restart. This caps memory and CPU, preventing the VM from consuming every last resource on your machine.

Persistent shortcuts for rapid access

  • Drag \\wsl$ into Quick Access so a single click opens your distro list.
  • Map a distribution root to a drive letter (e.g., W: for Ubuntu) for tools that stubbornly require a drive letter.

GPU and USB passthrough: know the limits

WSLg brings native GUI app support, and usbipd allows USB device forwarding, but low-level PCIe hardware or specialized drivers may still require a full VM or native Linux. Treat passthrough as powerful but bounded by vendor support.

Enterprise-grade WSL: security and management considerations

Organizations rolling out WSL to developer workstations should factor in a few extra layers.

  • Update cadence
    WSL kernel updates and WSLg components may arrive through Windows Update or the Microsoft Store. In regulated environments with strict patch management, include WSL in your update rings to avoid version drift.
  • Permissions and audit
    The \\wsl$ provider translates Linux permissions into Windows ACLs on the fly, but endpoint security tools may treat files accessed through a network-like namespace differently. Validate your DLP and auditing solutions against a test system before broad deployment.
  • Unsupported workflows
    Any deployment automation that scripts direct manipulation of the ext4 VHD files inside AppData must be reworked. Those actions can corrupt the distro and are explicitly unsupported. Stick to \\wsl$ or in-WSL operations.

Knowing when WSL isn’t enough

For all its strengths, WSL is not a universal replacement for a full VM or bare-metal Linux. Consider stepping up to Hyper-V or dual-booting when you need guaranteed bare-metal performance for latency-sensitive tasks, direct low-level hardware access (peculiar PCIe cards, proprietary USB drivers), or an environment completely isolated from Windows Update’s influence. WSL covers the vast majority of developer use cases, but engineering teams with specialized hardware should evaluate the trade-offs honestly.

The verdict: a productivity win for hybrid development

The arrival of \\wsl$ and the explorer.exe bridge transformed a fragile hack into a polished, supported workflow. Developers can now keep their Linux toolchains humming while editing files with Windows-native applications—no copying, no context switching, no corruption. The recommended playbook is straightforward: place files where the dominant I/O happens, use \\wsl$ or explorer.exe . for cross-OS access, and stay away from the raw AppData guts. Tuck away the troubleshooting steps for the occasional hiccup, and you’ll enjoy a seamless hybrid environment that genuinely boosts productivity.