Should I use native Windows or WSL for Claude Code?

Decide by where your repos and toolchain live. If your project builds with PowerShell, MSVC, or Windows-native Node, run Claude Code natively — the agent should live where the commands work. If your stack assumes bash, make, or Docker via WSL, install Claude Code inside the WSL distro. The failure mode to avoid is the mixed marriage: agent on one side, repo on the other, with /mnt/c path translation and file-watcher pain in between.

Why does claude not work in PowerShell after install?

It's almost always PATH: npm's global bin directory isn't on it. Run npm config get prefix, confirm that folder is in your PATH, then reopen the terminal. If you use nvm-windows or Volta, make sure the shim directory wins over stale entries.

Do line endings break Claude Code on Windows?

Not Claude Code itself — your diffs. With core.autocrlf misconfigured, an agent edit can turn into a whole-file CRLF rewrite that buries the real one-line change. Set core.autocrlf to input (or use a .gitattributes) before letting any agent loose on a Windows checkout.

Guide

Claude Code on Windows: native vs WSL, and the gotchas nobody mentions

Q: Does Claude Code run natively on Windows?

Yes — Claude Code supports native Windows: install Node LTS, run npm install -g @anthropic-ai/claude-code in PowerShell or Windows Terminal, then claude to sign in. Native needs a Git for Windows install for full functionality. The WSL route remains fully supported and is often smoother for Unix-flavored tooling.

Andrew Mercer July 23, 2026 · 6 min read

Claude Code on Windows: native vs WSL, and the gotchas nobody mentions

"Does Claude Code work on Windows?" stopped being an interesting question a while ago — yes, natively, no WSL required. The interesting question is the one after it: native or WSL? Pick wrong and you'll spend your week debugging path translation instead of shipping. Here's the decision in one rule, the install for both routes, and the three gotchas that actually bite. (For the general cross-platform walkthrough, see how to install Claude Code — this post is the Windows-specific deep end.)

The one rule: the agent lives where the commands work

Claude Code spends its life running your commands — tests, builds, linters. So install it in the environment where those commands natively succeed:

Windows-native stack (PowerShell scripts, MSVC, Windows Node, .NET) → native Claude Code. The agent's shell is your shell; every command behaves the way it does for you.
Unix-flavored stack (bash scripts, make, Docker-in-WSL, most web tooling) → Claude Code inside WSL. Treat the distro like a Linux box: install Node there, install Claude Code there, keep the repo there.

The setup that generates the misery you've read about is the hybrid: agent on native Windows, repo inside WSL (or vice versa). Every file access crosses the /mnt/c bridge — slow I/O, confused file watchers, paths that mean different things to different processes. Don't build your workflow across the moat.

Route A: native Windows

# PowerShell or Windows Terminal
npm install -g @anthropic-ai/claude-code
claude   # opens browser sign-in on first run

Prerequisites: Node LTS and Git for Windows (Claude Code leans on git and the bash tooling it bundles). If claude comes back "not recognized," it's PATH — see the FAQ. From there the loop is identical to macOS: cd into a repo, describe the task, approve what it proposes.

Route B: WSL

# inside your WSL distro (Ubuntu etc.)
npm install -g @anthropic-ai/claude-code
claude

Same commands, Linux semantics. Two rules make WSL painless: keep repos in the Linux filesystem (~/projects, not /mnt/c/Users/...) for I/O speed and working file watchers, and launch from the distro's shell (Windows Terminal profiles make this one keypress).

The three gotchas that actually bite

PATH after global npm install. The classic. npm config get prefix tells you where the shim landed; that directory must be on PATH, and version managers (nvm-windows, Volta) must not shadow it with a stale entry.
Line endings. With core.autocrlf wrong, one agent edit becomes a 2,000-line CRLF diff and your reviewer's afternoon is gone. git config --global core.autocrlf input or a .gitattributes, before the first session.
Windows Defender vs agent I/O. Real-time scanning of node_modules makes every install and build the agent runs feel underwater. An exclusion for your dev directory (a standard, documented practice) gives the agent — and you — normal speed.

Frequently asked questions

Does Claude Code run natively on Windows?

Yes — Node LTS plus npm install -g @anthropic-ai/claude-code in PowerShell, with Git for Windows installed. WSL remains fully supported as the alternative route.

Should I use native Windows or WSL?

Install the agent where your commands succeed: Windows-native toolchain → native; bash/make/Docker stack → inside WSL. Avoid the hybrid where agent and repo sit on opposite sides of /mnt/c.

Why isn't claude recognized after install?

PATH. Check npm config get prefix, ensure that directory is on PATH, reopen the terminal, and watch for version-manager shims shadowing it.

Do line endings break anything?

They break your diffs: misconfigured core.autocrlf turns a one-line agent edit into a whole-file rewrite. Set it to input or ship a .gitattributes first.

Where Backgrind fits

Backgrind runs the same claude you just installed — native or WSL — in an always-on-top overlay on Windows, so the agent stays glanceable over your editor, browser, or a borderless-fullscreen game, and pings you only when it needs a decision. If you went the WSL route, the overlay doesn't care: it wraps the CLI wherever it lives. There's a live demo if you want the feel of it before installing anything.