Access Linux Files from Windows with WSL: Two Simple Tricks (WSL$ and explorer.exe)

Windows 10 and Windows 11 now let you open and work with your Linux files from the Windows desktop with two simple tricks: enter \wsl$ in File Explorer to browse all installed distributions, or run explorer.exe . from inside a WSL shell to open the current Linux directory in Windows File Explorer. (learn.microsoft.com)

Background / Overview​

Windows Subsystem for Linux (WSL) has evolved from a niche developer convenience into a mainstream productivity tool. Microsoft formalized safe, supported bi‑directional file access with the Windows 10 May 2019 update and continued to refine WSL behavior in later Windows 10 and Windows 11 releases. The platform exposes Linux distributions to the Windows host via a special network‑share style namespace at \wsl$, and provides an easy bridge from the Linux shell to File Explorer via explorer.exe. (learn.microsoft.com)
This integration is intentionally pragmatic: it gives Windows GUI tools access to files inside a WSL distro while Microsoft’s runtime keeps permissions and metadata coherent to avoid corruption and weird permission mismatches. But there are rules and performance tradeoffs—understanding them will keep your development workflow fast and safe. (learn.microsoft.com)

---

How it works: the two quick methods​

1) From inside WSL — open the current directory in File Explorer​

• Open your WSL distro (Ubuntu, Debian, etc.).
• Change to the directory you want to inspect: cd ~/projects/myrepo
• Run:
  explorer.exe .

Windows will launch File Explorer showing the current Linux directory. This works whether the distro is running on WSL1 or WSL2; the command hands a translated path to Explorer so the Windows shell can render the Linux filesystem. (learn.microsoft.com)

2) From Windows — browse all distros via the \wsl$ share​

• In File Explorer’s address bar type:
  \wsl$
• You’ll see a folder for each installed distribution (for example, Ubuntu‑22.04 or Debian). Open a distro to view its root filesystem as if it were a network share.
• For quick access, drag \wsl$ to Quick Access, or map a distro to a drive letter via “Map network drive…”.

This exposes each distro as a network resource and is the supported, safe mechanism for Windows applications to read and write files inside WSL. (learn.microsoft.com)

---

Quick, practical examples​

• Open the current WSL directory in Explorer:
• $ cd /home/you/project
• $ explorer.exe .
• Jump straight to all distros from Windows: open File Explorer, type \wsl$ and press Enter.
• Map a distro to a drive letter: right‑click the distro under \wsl$, choose “Map network drive…”, pick a drive letter and finish.

These are the same steps described in popular how‑to guides and Microsoft’s own documentation—simple and repeatable. (learn.microsoft.com)

---

Why this is “safe” and what Microsoft does behind the scenes​

Historically, people tried to read WSL files by navigating into the hidden AppData VHD locations, or by editing files inside the WSL virtual disk directly from Windows. That could corrupt metadata and break Linux permissions. Microsoft’s \wsl$ provider and the Explorer bridge avoid that by presenting a translated view and performing necessary metadata syncs on file operations. In short, the supported approach is safe; poking at distro internals through low‑level AppData paths remains unsafe. (learn.microsoft.com)
Key takeaways:

• Use \wsl$ or explorer.exe . for Windows ↔ WSL interoperability.
• Don’t edit distro internals by browsing the AppData/Local/Packages/<distro>/... VHD or ext4 files directly from Windows—this is unsupported and risky.

---

Best practices: where to place your project files​

There are two mainstream patterns—pick the one that fits your workload.

• If you primarily use Windows GUI editors (Visual Studio, Notepad, Office) and occasionally run Linux commands:
• Keep the files on the Windows filesystem (e.g., C:\Users\<you>\Documents).
• Access them from WSL under /mnt/c/...
• Benefit: Windows tools work natively; small I/O overhead inside WSL.
• If you run frequent Linux builds, package installs (node_modules), or heavy I/O:
• Keep the working tree inside the WSL filesystem (e.g., /home/<you>/project).
• Access the files from Windows using \wsl$ or explorer.exe .
• Benefit: Significantly better I/O performance for Linux‑native workloads.

This recommendation mirrors Microsoft’s guidance and community testing: for heavy Linux I/O keep files inside WSL; for Windows‑centric editing keep files on Windows. (learn.microsoft.com)

---

Tools that behave well (and a useful detail about Notepad)​

• Notepad now supports Unix (LF) and macOS (CR) line endings, so simple edits to shell scripts or config files opened via \wsl$ will not mangle line endings in modern Windows 10/11 builds. Notepad’s EOL support was added in the Windows 10 Insider builds and later rolled out to production — this makes quick edits less risky. (devblogs.microsoft.com)
• Visual Studio Code’s Remote‑WSL extension is still the ideal hybrid experience: keep the editor UI in Windows while running builds and tooling inside WSL. This avoids the cross‑filesystem performance tax for heavy workloads while preserving a native GUI editing experience.

---

Troubleshooting: when \wsl$ or explorer.exe . doesn’t behave​

This integration is rock‑solid for many users, but there are recurring issues reported in community threads and GitHub issues. If you hit problems, try the following:

• Confirm WSL is running:
• wsl -l -v
• Restart WSL:
• wsl --shutdown
• Start your distro again.
• If \wsl$ shows the distro but Explorer says “not accessible”:
• Map the distro as a network drive (right‑click → Map network drive) — many users report this bypasses intermittent Explorer bugs.
• If explorer.exe . opens Documents instead of the WSL path:
• Verify you're in a valid Linux path (not a Windows /mnt path) and that WSL is running.
• If the \wsl$ namespace disappears after a Windows feature upgrade:
• Disable and re‑enable the “Windows Subsystem for Linux” optional feature or install pending Windows updates; some upgrade paths require a feature toggle to refresh provider order keys. This is a documented workaround observed in community and support threads. (github.com)

Community and GitHub threads show a handful of edge cases; mapping the network drive or toggling the WSL feature often resolves transient issues. If problems persist, check status on the WSL GitHub issues page and Windows Update history. (github.com)

---

Advanced tips and configuration​

Limit WSL resource usage​

Create a %USERPROFILE%.wslconfig file with entries like:

• memory=4GB
• processors=2
  Then run wsl --shutdown to apply. This prevents the utility VM (vmmem) from ballooning unexpectedly during heavy builds. Use this when Docker Desktop or long build processes cause high memory usage.

Map \wsl$ to Quick Access or a drive letter​

• Drag \wsl$ into Quick Access for one‑click access.
• Or use “Map network drive…” to assign a persistent drive letter to a distro root, which works well for tools that expect drive letters.

If you need USB or GPU passthrough​

WSL has usbipd and WSLg for GUI and certain hardware scenarios, but vendor driver support matters; for low‑level PCIe or special hardware you may still need a full VM or native Linux. Treat passthrough features as powerful but bounded by driver support.

---

Performance and risks — be deliberate about file placement​

• Performance:
• Accessing Windows files from WSL (via /mnt/c) uses a translation layer that can be slower for many small file operations—particularly npm installs, Docker image builds, and Git operations. Keeping high‑I/O projects inside the WSL filesystem is faster.
• Conversely, accessing WSL files from Windows over \wsl$ is optimized for safe interoperability, but the most performant pattern still depends on which tools do the bulk of the I/O.
• Corruption risk:
• Editing distro internals through unsupported low‑level paths (for example tampering with the ext4 VHD files directly in AppData) has led to corruption in the past. Microsoft explicitly warns against this—use \wsl$ instead.
• Explorer bugs and Windows updates:
• Some Windows updates historically interfered with the provider order for the P9 network provider that backs \wsl$. Users fixed this by toggling the WSL feature or adjusting the PROVIDERORDER registry key, but the safest first step is to try simple toggles and reboots before any registry editing. Community issues and GitHub threads document these cases. (github.com)

---

Enterprise considerations and security posture​

• Update and change control:
• WSL components (kernel, WSLg) may be delivered through Windows Update and the Microsoft Store, so enterprises should include WSL in their update plans—especially where regulated update cadences are enforced.
• Permissions and audit:
• Files accessed via \wsl$ are handled by the WSL provider, which translates permissions appropriately. Still, audit policies and endpoint security tools might treat files accessed via network namespace differently—validate your security tooling on a test system before broad deployment.
• Unsupported edits:
• Any workflow or deployment automation that relies on editing the raw VHD or AppData internals should be reworked; those approaches are unsupported and can break the distro unexpectedly. Use the supported \wsl$ mechanism instead.

---

When you should still use a VM or dual‑boot​

WSL is excellent for day‑to‑day development, GUI Linux apps (via WSLg), and mixed workflows—but it is not a one‑size‑fits‑all replacement for full virtual machines or a native Linux install.
Consider a full VM or bare‑metal Linux if you need:

• Guaranteed bare‑metal performance for latency‑sensitive workloads.
• Low‑level hardware or driver access (special PCIe cards, unusual USB devices with proprietary drivers).
• An environment that must not be affected by Windows update cadence or WSL kernel changes.

WSL fills the majority of developer use cases, but some edge scenarios still favor VMs or native Linux.

---

Checklist: quick reference to access WSL files safely​

• From WSL shell, run explorer.exe . to open the current directory in File Explorer. (learn.microsoft.com)
• From Windows, type \wsl$ in File Explorer to browse installed distros. (learn.microsoft.com)
• For heavy Linux I/O, store projects inside WSL; for Windows‑centric edits, store projects on Windows and access them from /mnt.
• Don’t edit distro internals by poking the ext4 VHD inside AppData—use \wsl$ or WSL tools.
• If \wsl$ fails after an update, toggle the WSL optional feature, reboot, and try mapping the distro as a network drive if needed. (github.com)

---

Strengths — what this integration gets right​

• Seamless two‑way workflow: developers can run Linux tooling while editing files in familiar Windows GUI apps without copying or constant context switching.
• Supported, safe file access: the \wsl$ provider is designed to avoid the common corruption paths that earlier hacks caused.
• Practical parity across WSL1 and WSL2: the explorer.exe bridge and \wsl$ namespace are available on modern Windows builds and behave consistently for both WSL versions. (learn.microsoft.com)
• Modern text tool compatibility: Notepad and major editors now handle Unix newline conventions, reducing friction for quick edits. (devblogs.microsoft.com)

---

Risks and limitations — what to watch for​

• Cross‑filesystem performance pitfalls for heavy I/O tasks; choose filesystem placement deliberately.
• Occasional Explorer integration bugs after Windows updates; have simple recovery steps ready (wsl --shutdown, toggle feature, map network drive). (github.com)
• Hardware passthrough and vendor driver boundaries—WSL is not a silver bullet for specialized hardware access.

---

Final verdict​

The arrival of \wsl$ and the explorer.exe . bridge turned a once‑fragile hack into a practical, supported workflow that materially improves developer productivity on Windows. For most users, the recommended pattern is clear: choose the filesystem location that suits your dominant workflows, use \wsl$ or explorer.exe . for interoperability, and avoid unsupported direct edits to distro internals. Microsoft’s documentation and numerous community threads corroborate these best practices; they also point to a small set of reliable workarounds for the occasional Explorer glitch. (learn.microsoft.com)
If you follow these rules—store heavy Linux projects inside WSL, keep Windows‑edited files on the Windows side when appropriate, and rely on the \wsl$ provider for Windows access—you’ll get the convenience of a hybrid Windows + Linux workflow with minimal risk and excellent performance.

---

Conclusion
Accessing WSL files from Windows has never been easier or more robust: explorer.exe . and the \wsl$ namespace give developers and power users a supported, flexible bridge between operating systems. Use them, but use them with intention—place files where the workload performs best, rely on supported paths, and keep simple recovery steps in your toolkit for the rare time Explorer and WSL misbehave. (learn.microsoft.com)

---

Source: How-To Geek How to Access Your Linux (WSL) Files in Windows 10 and Windows 11