10. Path Configuration

PATH conflicts between Windows and WSL2 tooling cause persistent confusion. The Windows PATH variable contains directories searched when you run an executable from CMD or PowerShell. The Linux PATH inside WSL2 is separate. ollama run from WSL2 uses the Linux binary. ollama run from PowerShell uses the Windows binary. If both are installed, they are separate runtimes with separate model storage.

Check Windows PATH:

$env:PATH -split ';'

Check WSL2 PATH:

echo $PATH | tr ':' '\n'

The Windows-side Ollama installer adds C:\Users\YOUR_USERNAME\AppData\Local\Programs\Ollama to the Windows PATH. WSL2 binaries are not in the Windows PATH.

To call the WSL2 Ollama from PowerShell, use wsl:

wsl ollama list

To call the Windows Ollama from inside WSL2, use the full Windows path or rely on the Windows binary being inaccessible from Linux. They are separate unless you explicitly run the Windows executable through Wine or a similar compatibility layer.

For tools that need to run from both sides (Ollama being the most common), either run the WSL2 version exclusively and call it via wsl from PowerShell, or run the Windows version exclusively and call it from WSL2 via the Windows executable path. Mixing them leads to model storage fragmentation.

Add custom directories to the WSL2 PATH:

echo 'export PATH=$PATH:/opt/custom/bin' >> ~/.bashrc
source ~/.bashrc

Add custom directories to the Windows PATH via PowerShell:

$env:PATH += ";C:\custom\bin"
[Environment]::SetEnvironmentVariable("Path", $env:PATH + ";C:\custom\bin", "User")

Local verification checkpoint

Run the smallest example from this chapter in a local workspace and record the package version, runtime, data path, and observed output. If the result depends on model size, vector count, CPU/GPU backend, or available memory, note that constraint beside the exercise so the lesson remains reproducible.