Running Claude Code on Windows

What is actually different on Windows

Very little of the work changes. A coding agent reads and writes files and runs commands, and none of that cares which operating system it is on. What changes is everything around the agent. It is worth naming the specific things rather than repeating that Windows is awkward.

The shell is not the shell you read about

Most guides, examples and configuration advice are written for a POSIX shell such as bash or zsh. Anthropic recommends installing Git for Windows so Claude Code's Bash tool has a real bash to run. Without it, Claude Code falls back to PowerShell, where quoting rules and most Unix commands differ from the ones those guides assume. Setting up Git Bash, or a Linux environment under WSL, removes a whole category of confusing failures.

Paths contain spaces and backslashes

C:\Users\Your Name\projects\… breaks scripts written on the assumption that paths hold no spaces and use forward slashes. This bites hardest with a clean install on a machine whose username has a space in it, which is most of them. It is fixable, and it is worth fixing once at the start rather than after an agent has mysteriously failed to find a file four times.

Long file paths

Windows historically limited a path to around 260 characters, and a node_modules tree is more than capable of exceeding that. The fix is the long-path setting. Switch it on early and you avoid a class of install errors that look like the package manager's fault and are not.

Line endings

Git on Windows will happily convert line endings and produce a diff where every line changed. Set the line-ending behaviour on day one, or your first commit looks like a rewrite of the whole repository.

WSL, or not

WSL is the most predictable route. It gives you a real Linux environment, the shell every guide assumes, and no path-separator surprises. If your project's tooling is Linux-native, whether that means containers, shell scripts or a build pipeline, WSL is usually the least surprising choice.

WSL is not the right answer for every project, and it introduces a boundary of its own. Performance is poor when a project lives on the Windows filesystem and the tooling runs inside Linux. You also end up with two filesystems, two sets of credentials and two places your code might be. For a project that is Windows-native through and through, working on Windows directly is simpler. Pick the environment your project already assumes, and then stay in it.

Whatever you choose, write it down. Most of the time lost to this is not the setup. It is rediscovering, weeks later, which shell the working project actually uses.

The harder problem: several sessions at once

One agent in one terminal is fine on any platform. The moment you want five, the terminal stops being a good user interface for the job. Five might be a long refactor, a test pass, two research tasks and something waiting on a decision.

What goes wrong

• Two agents, one directory. Nothing stops a second agent writing the same file as the first. You end up with one agent committing the other's half-finished edit, or running the test suite while the other is mid-rewrite. The commit that results mixes two changes that were never meant to be one.
• You cannot see what is running. With several terminal windows, the useful information is spread across windows you have to visit: which one is blocked, which failed, which finished ten minutes ago.
• Tab chaos. Windows Terminal tabs can ring a bell when Claude finishes, but a bell does not tell you which session is blocked and which is done.
• Nothing survives a restart. Claude Code keeps each transcript, so claude --resume reopens a session where it left off. What you do by hand is reopen every terminal and resume each one.

Doing it by hand

The manual approach is a git worktree per session: a separate working directory on its own branch, so the sessions cannot collide. Each one also gets its own terminal. That works, and if you only occasionally run two things at once it is the cheapest answer. It turns into work of its own at around four or five sessions, because you are now doing the scheduling and the bookkeeping yourself.

Using something built for it

The alternative is an app whose job is the parallelism. Omniscio is ours. It has a native Windows build, and it shows every session's live status in one place, with the blocked and failed ones floating to the top. It can give each session its own git worktree, so two agents cannot edit the same file; worktree isolation is off until you turn it on. Every harness is in the picker from day one: Claude Code, Codex, OpenCode, Devin, Pi and Hermes. So are the model providers behind them, Gemini, DeepSeek, Kimi, GLM, MiniMax, Cursor and more. Switch on the ones you want in Settings, with the key or sign-in for each.

The AI Manager handles the reading. Plain Speak rewrites a finished reply into a card you can take in at a glance. It is on by default, and you can switch it off in Settings. Quick Launch (Ctrl+Space) starts a new session from anywhere, and the phone view takes a long run with you when you leave the desk. The phone view is off by default; switch it on in Settings.

If you would rather keep the terminal, keep it. Omniscio runs the same agents on the same machine, so you can move one session at a time.