In 2010, I published a book about making Windows and Linux talk to each other over a network. Back then, sharing a folder between the two was a weekend project with a config file and a lot of patience. Sixteen years later, Windows ships Linux inside itself and you install it with one command. It has never been so easy to use the terminal on Windows, even running some Linux apps inside it.
So here is the answer for anyone setting up Claude Code on Windows in 2026: WSL is no longer required. Claude Code runs natively on Windows 10 version 1809 and later. Install it inside WSL 2 when your project depends on Linux tooling, or when you want sandboxed command execution, which per Anthropic's setup documentation works on WSL 2 and nowhere else on Windows.
Most of the WSL guides still circulating were written when that choice did not exist. Some of them state outright that Anthropic ships no native Windows build. That isn’t true anymore.
This is a follow-up to the Claude Code macOS setup post, and most of that configuration carries over unchanged.
What WSL actually is
WSL 2 is a real Linux kernel running in a lightweight virtual machine that Microsoft ships with Windows. Your Linux filesystem lives inside a virtual hard disk formatted as ext4. Windows drives get mounted into that Linux environment under /mnt/, so your C: drive appears as /mnt/c.
That last detail is responsible for most of the performance complaints you will read about WSL. More on it below.
Should you use WSL or native Windows for Claude Code?
Pick based on where your project lives and whether you need sandboxing. Anthropic's setup documentation lays out the three options directly:
| Option | Requires | Sandboxing | Use when |
|---|---|---|---|
| Native Windows | Nothing; Git for Windows optional | Not supported | Windows-native projects and tooling |
| WSL 2 | WSL 2 enabled | Supported | Linux toolchains, sandboxed execution |
| WSL 1 | WSL 1 enabled | Not supported | Only if WSL 2 is unavailable |
The honest recommendation: if your build chain or your deploy scripts assume Linux, run Claude Code where the project actually runs. A WordPress plugin that ships to a LEMP server behaves differently under PowerShell than it does under bash, and you will spend your session debugging the gap instead of the code.
If you build .NET applications or anything else with Windows tooling in the loop, install natively and skip this entire article. Both installs can coexist on the same machine, so an experiment costs you nothing but disk space.
How to install WSL 2 on Windows
Open PowerShell as Administrator and run one command:
wsl --install
That enables the required Windows features and installs Ubuntu as the default distribution, with WSL 2 as the default version. Restart when it asks. On first launch, the Ubuntu terminal asks for a username and password, which are separate from your Windows credentials and used for sudo inside Linux.
Confirm what you ended up with:
wsl -l -v
The VERSION column needs to read 2. If it reads 1, convert it:
wsl --set-version Ubuntu 2
Claude Code needs Windows 10 version 1809 or newer, or Windows Server 2019 or newer, on a 64-bit machine with at least 4 GB of RAM. The installer itself wants roughly 512 MB of free memory to complete, which is worth knowing if you are doing this on a work laptop with 40 browser tabs open.
Installing Claude Code inside WSL
Run the Linux installer from inside the WSL terminal, never from PowerShell or CMD:
curl -fsSL https://claude.ai/install.sh | bash
This is the same native installer used on macOS and Linux, and it has no Node.js dependency at all. It drops the binary at ~/.local/bin/claude and updates in the background on its own.
Then verify:
claude --version
claude doctor
claude --version prints something like 2.1.211 (Claude Code). claude doctor runs a read-only diagnostic of your install and settings without starting a session, and it is the first thing to run whenever something behaves strangely.
If the shell reports claude: command not found, the install directory is missing from your PATH:
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
You do not need Git for Windows here. That applies to native Windows installs, where it enables the Bash tool. Inside WSL you already have bash.
One prerequisite that catches people at the login screen: Claude Code requires a Pro, Max, Team, Enterprise, or Console account. The free Claude.ai plan does not include it.
Keep your projects off /mnt/c
This is the setting that decides whether WSL feels fast or broken, and it is not in settings.json. Store your repositories in the Linux filesystem at /home/<user>/project, not at /mnt/c/Users/<user>/project.
Microsoft's own WSL documentation recommends against working across operating systems with your files. Every read of a file under /mnt/c crosses the boundary between the Linux VM and the Windows filesystem, and that crossing has a cost paid per operation. Claude Code reads a lot of files. It searches your codebase and greps for symbols before it writes a single line.
Put a repository on /mnt/c and the searches get slow enough that results come back incomplete while everything reports itself as healthy. The failure is silent. You get a Claude Code session that seems inexplicably worse at finding things than it was on your colleague's Mac.
Clone into ~/projects/ and the problem disappears. To open that directory in Windows File Explorer when you need to:
explorer.exe .
If you genuinely need the files on the Windows side for a Windows-native editor, that is the signal to reconsider and install Claude Code natively instead.
Why Claude Code login fails the first time in WSL
The first claude run opens a browser for authentication, and in WSL that browser opens on the Windows host. The redirect it sends back cannot reach the callback server listening inside the Linux VM, so the login appears to stall.
The fix, per Anthropic's installation troubleshooting guide: complete the sign-in, and the browser shows a login code instead of redirecting. Paste that code into the terminal prompt.
If the browser never opens at all, point WSL at your Windows browser:
export BROWSER="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
If pasting into the prompt does nothing, which happens because Windows Terminal paste bindings vary, use the command that reads the code from standard input:
claude auth login
The Node.js trap that only happens in WSL
WSL imports the Windows PATH by default, so Linux commands can silently resolve to Windows executables. Run which node inside WSL and check the output. A path beginning with /mnt/c/ means your Linux shell is calling the Windows Node.js installation, and installs will behave in ways that make no sense.
This only affects you if you installed Claude Code through npm inside WSL, where the symptom is exec: node: not found. Install Node through your distribution's package manager or nvm, and add the nvm loader to ~/.bashrc so it wins the PATH race:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
The simpler path is skipping npm entirely. The native installer downloads a binary that never invokes Node at runtime, which removes this whole category of problem. If you do use npm, the package has required Node.js 22 or later since v2.1.198.
Resist the temptation to fix PATH bleed by setting appendWindowsPath = false in /etc/wsl.conf. Anthropic's troubleshooting guide flags this explicitly: it breaks your ability to call Windows executables from WSL, including the browser trick above.
WSL 1 and the Exec format error
If claude prints cannot execute binary file: Exec format error, you are on WSL 1. The native binary's program headers changed in a way the WSL 1 loader cannot handle, tracked as issue #38788 in the Claude Code repository.
Convert the distribution from PowerShell:
wsl --set-version Ubuntu 2
If some constraint forces you to stay on WSL 1, you can invoke the binary through the dynamic linker by adding a shell function to ~/.bashrc:
claude() {
/lib64/ld-linux-x86-64.so.2 "$(readlink -f "$HOME/.local/bin/claude")" "$@"
}
That works, though it patches a known regression and is not a supported configuration. WSL 1 also gets no sandboxing.
What carries over from the macOS setup
Everything above this line is Windows-specific plumbing. Everything below it is identical to any other platform, which is the actual argument for WSL: once you are inside, you are on Linux.
oh-my-zsh installs with the same script. /terminal-setup configures Shift+Enter and the @ file picker the same way, and /statusline builds the same cost and rate limit display. The Claude Code settings worth changing are the same ones, and the Claude Code workflow tips apply without modification.
The only difference is which file you edit. On WSL you are usually in bash, so aliases go in ~/.bashrc rather than ~/.zshrc, unless you install zsh and set it as your login shell:
alias cc="claude"
alias ccc="claude --continue"
So which one should you install?
The decision comes down to two questions. Does your project assume Linux? Install inside WSL 2. Do you need sandboxed command execution? WSL 2 is the only option on Windows that supports it.
Otherwise, install natively from PowerShell, add Git for Windows if you want the Bash tool, and get on with your work. The native path has fewer moving parts, and fewer moving parts means fewer things that break quietly.
And if you install WSL 2 and take one thing from this article, make it the filesystem rule. Every other problem here announces itself with an error message. That one just makes Claude Code worse and never tells you why.
If you are standardizing a development environment across a team where some machines run Windows and others do not, and the drift is starting to cost you sprints, that is the kind of decision I get called in to make.