Claude Code on Windows: Install, Verify and Fix the Common Errors

Yes. Claude Code on Windows works natively, with no WSL, no virtual machine and no dual boot. You need Windows 10 build 1809 or later, or Windows Server 2019 or later, running on x64 or ARM64 hardware with 4 GB of RAM or more. Supported shells are Bash, Zsh, PowerShell and CMD. The fastest way in is the desktop app from claude.com/download, which runs Claude Code without a terminal. You also need a Pro, Max, Team, Enterprise or Console account.

That last line catches more people than any technical requirement does. The install itself will complete perfectly on a free account, because installing software and having access to it are separate things. If everything looks correct and you still cannot get a session going, check the plan before you touch anything else.

For a lot of Windows users the honest recommendation is to stop reading after the desktop app. It installs like any other Windows application, it does not ask you to think about shells or PATH variables, and it is the version most people should be using day to day. The terminal install is optional and you can add it later without undoing anything you have already done.

Choose native Windows unless you specifically need sandboxing or you already work inside WSL. Native Windows needs nothing extra installed, and Git for Windows is optional rather than required. WSL 2 needs WSL 2 enabled on the machine before you start. The one genuine functional difference is sandboxing: it is supported on WSL 2, and it is not supported on native Windows or on WSL 1.

On native Windows, where sandboxing is not available, the control you actually rely on is the permission system - what Claude Code is allowed to run without asking you first. That is worth setting up deliberately rather than by clicking through prompts, and we walk through it in [claude code permissions explained](/blog/claude-code-permissions-explained). It matters more on Windows precisely because you do not have the sandbox as a second layer.

There are two routes and the desktop app is the default one. Download it from claude.com/download and it installs like any other Windows application, with no terminal, no package manager and no PATH to reason about. If you also want the command line version, there are three installers to pick from: the native script, WinGet, or npm.

Start with the app. It is the version that gets used, because it is the version that opens without a decision attached to it. We covered what it does and does not give you in [the Claude Code desktop app](/blog/claude-code-desktop-app), and the short version is that it lets you use Claude Code without the terminal entirely.

Once it is installed, the setup that matters is not the installer at all, it is what you do in the first hour of your first project. [Claude Code day one setup](/blog/claude-code-day-one-setup) covers that part, and it is identical on Windows and macOS.

No. Git for Windows is optional on native Windows and Claude Code works fine without it. What changes is how shell commands run. With Git for Windows installed, Claude Code uses Git Bash for the Bash tool. Without it, Claude Code runs shell commands through the PowerShell tool instead. Both are supported. Installing Git is worth it mainly if you want the Bash behaviour to match tutorials written on macOS or Linux.

If Git for Windows is installed and Claude Code cannot find Git Bash, point it at the executable directly. Set CLAUDE_CODE_GIT_BASH_PATH in your settings.json to the full path, for example C:\\Program Files\\Git\\bin\\bash.exe. Notice the doubled backslashes. settings.json is JSON, and a single backslash is an escape character in JSON, so a path copied the way Windows displays it will not parse and the setting will look like it was ignored.

This is the single most Windows-specific thing in the whole setup, and it is worth understanding rather than copying. Any Windows path you put into any JSON settings file has the same rule. If a setting that takes a path appears to do nothing, count the backslashes before you assume the setting is broken.

Almost always because a command written for one shell was pasted into the other. PowerShell and CMD are different shells with different syntax, and Windows opens both of them in similar looking windows. Two specific error messages tell you exactly which shell you are in. The fix is not to change the command, it is to change the window you are typing into.

You can check which shell you have before you paste anything. The PowerShell prompt begins with PS, as in PS C:\. The CMD prompt is the same path without it, so just C:\. That two-letter difference is the entire diagnosis, and it saves the loop of running the same failing command again slightly differently.

One more thing worth ruling out: neither native install command needs Administrator rights. If you hit a permissions error, opening an elevated prompt and trying again is not the intended fix and usually is not the problem either. Read the first line of the error rather than the whole block, and match it against the table above.

Run claude --version. If Claude Code is installed and reachable it prints a version string, something along the lines of 2.1.211 (Claude Code). If you want more detail, run claude doctor, which prints read-only diagnostics about your install and your settings without starting a session. Read-only is the useful part: you can run it as often as you like while troubleshooting and it will not change anything underneath you.

Removing it again is equally plain, and knowing how is also how you learn where things went. Uninstalling from PowerShell on Windows removes $env:USERPROFILE\.local\bin\claude.exe and $env:USERPROFILE\.local\share\claude. Those two paths are the binary and its data, and checking whether they exist is a quick way to confirm a native install actually landed.

Less than people expect, and the differences all sit at the edges rather than in the work. The install commands differ. Sandboxing is available on WSL 2 and not on native Windows or WSL 1. Shell commands run through Git Bash or the PowerShell tool depending on whether Git for Windows is installed. The sessions themselves - how you talk to Claude Code, what it reads, what it asks permission for - are the same product.

The practical upshot is that Windows is a first-class place to run this, and most of the friction people report is one of three things: the wrong shell during install, a path written without escaped backslashes, or an account tier that does not include Claude Code. None of those are Windows being difficult. They are just the three places Windows differs enough to catch you once.