The Windows Subsystem for Linux (WSL) runs a genuine Linux environment — shell, package manager, toolchain — inside Windows, without dual-booting or a heavyweight virtual machine. It is excellent for command-line work. The graphical side, though, has limits: Linux GUI apps run through WSLg, a rootless-Wayland bridge, and some of them behave awkwardly — a detached window with no native clipboard or file-dialog integration, sluggish repaints, and the occasional file-watching glitch.

Obsidian is a good example. It organises notes in a vault (the parent folder of your knowledge base) and lets markdown files cross-reference one another like wiki hyperlinks. It ships for every major platform — Windows, Linux, macOS, mobile — but launching the Linux build inside WSL is a clunky experience for exactly the WSLg reasons above.

The fix is simple, and it generalises to any GUI app: run the app natively on Windows, and keep editing the files from the WSL terminal. Here is the setup, using Obsidian as the worked example.

Tap a button to move the vault and watch which app reads it natively — and which one reaches across the slower 9P bridge.

Setup

1. Install the app on Windows

Install the Windows build of Obsidian normally — download it from obsidian.md, or from PowerShell:

PowerShell

winget install Obsidian.Obsidian

2. Put the vault on the Windows filesystem

Copy an existing WSL vault onto the Windows drive (replace YourName with your Windows username):

WSL terminal

cp -r ~/vault /mnt/c/Users/YourName/Documents/vault

…or clone it fresh from your remote repository:

WSL terminal

cd /mnt/c/Users/YourName/Documents && git clone https://github.com/YourName/vault.git

3. Open the vault natively in Windows

In Windows Obsidian choose Open folder as vault and point it at C:\Users\YourName\Documents\vault. The app now runs as a first-class Windows program — fast rendering, a working clipboard, native file dialogs.

You still edit from the WSL terminal whenever you like, because the files live under /mnt/c, which WSL reads and writes directly:

WSL terminal

cd /mnt/c/Users/YourName/Documents/vault && nvim .

(Note the leading slash on /mnt — a common typo. If you are not editing in Neovim yet, you are missing out.)

4. Add a shortcut alias

Typing the full /mnt/c/... path every time gets old. Add an alias and reload your shell config:

WSL terminal

echo 'alias vault="cd /mnt/c/Users/YourName/Documents/vault && nvim ."' >> ~/.bashrc
source ~/.bashrc

From then on, running vault anywhere in WSL jumps straight to the right place on the Windows filesystem and opens the editor. A companion worth knowing: explorer.exe . opens the current WSL directory in Windows Explorer.

Which side should the files live on?

The rule of thumb is: store files on the same OS as the app doing the heavy I/O. Cross-OS file access in WSL goes over the 9P protocol, which is noticeably slower than native access — so the choice is a genuine trade-off.

Vault location Windows Obsidian WSL terminal Best when
/mnt/c/... (Windows FS) Native, fast Reads over 9P (slower) Obsidian is your primary tool — the GUI app stays fast
~/... (WSL FS), opened via \\wsl.localhost\Ubuntu\home\you\vault Reads over 9P (slower) Native, fast You live in the terminal and rarely touch the GUI

For a notes vault either way is fine — the files are small and the latency is unnoticeable. The distinction matters far more for heavy workloads (large repositories, node_modules, build trees), where keeping files on the app's own OS is a real performance win.

That's the whole trick: native app, terminal editing, files on the side that does the most work. The same pattern rescues any Linux GUI tool that feels second-class under WSLg.