The first decision when you set up a coding agent on Windows: WSL or native Windows? A year ago the answer was almost always WSL, because most agents didn’t run well on Windows. Today Claude Code, Codex, Gemini CLI and Copilot CLI run natively in PowerShell, so the answer depends on the project.
The short answer
| Situation | Recommendation |
|---|---|
| .NET, C#, Unity, Windows desktop app | Native Windows |
Code on the C: drive, editor on Windows | Native Windows |
| Linux-specific tools, shell scripts, Makefiles | WSL 2 |
| Docker-heavy development | WSL 2 |
| You want Claude Code’s sandbox | WSL 2 |
| You’ll use a tmux-based tool | WSL 2 |
| Corporate machine where WSL is blocked | Native Windows |
Pros of native Windows
Short setup. Claude Code installs with a one-line PowerShell script, Codex and Gemini CLI with npm. Every command is in installing coding agents on Windows.
Fast file access. The code is on the C: drive and the agent runs on Windows; no filesystem bridge in between.
The Windows toolchain. dotnet, MSBuild, the Visual Studio compilers and Windows-specific SDKs are right there. Calling them from WSL is possible but a hassle.
Codex’s Windows sandbox. Codex runs on native Windows with its own sandbox.
Cons of native Windows
No Claude Code sandbox. Claude Code’s filesystem and network isolation isn’t supported on native Windows; it is in WSL 2. You work with permission rules instead.
No tmux. tmux has no native Windows build. Tools that depend on it (such as Claude Squad) don’t run on native Windows.
Shell differences. Most agents are used to writing bash commands. Claude Code uses Git Bash if Git for Windows is installed and PowerShell otherwise; other agents may use PowerShell or cmd.exe. Bash habits such as rm -rf, export or && behave differently in PowerShell.
Path and line-ending issues. Backslash paths, the 260-character limit and CRLF line endings trip up edit tools now and then. The settings below fix most of it.
Pros of WSL 2
Actual Linux. The bash commands agents write run as is; make, grep, sed and Linux packages are ready to go.
Claude Code’s sandbox. Claude Code’s isolation works in WSL 2, so you can run it more safely with fewer approvals.
tmux and terminal tools. tmux, Claude Squad and similar tools work in WSL as they do on Linux.
Cons of WSL 2
/mnt/c is slow. Accessing Windows files from WSL 2 is noticeably slower than accessing files in the Linux filesystem. Microsoft’s own docs also recommend keeping projects on the Linux side. Clone the repo under ~/ and open it from your Windows editor via the \\wsl$\ path.
Two separate environments. Node, Python, git credentials and agent logins are separate on each side. You may have to sign in to an agent once inside WSL and once on Windows.
Memory. The WSL 2 virtual machine uses memory; with several agents and a Docker stack running at once, you may need to cap it in .wslconfig.
Mixing them: the same repo from both sides
The most common mistake is keeping the repo on Windows and running one agent from WSL and another from Windows. The result: one writes files with LF, the other with CRLF; diffs get noisy, some edit tools report “text not found”, and file permissions look changed.
If you’re going to use both environments:
- Keep each repo on one side only, and run that repo’s agents from the same side.
- Add a
.gitattributesto the repo:
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.ps1 text eol=crlf- On the Windows side, set
git config --global core.autocrlf falseandgit config --global core.longpaths true, and let.gitattributeshandle line endings.
Parallel agents: possible on both sides
To run several agents at once, you use separate git worktrees on either side.
- In WSL there’s tmux and tools built on it, such as Claude Squad.
- On native Windows there are Windows Terminal panes, or a desktop app that shows agents in a grid. AgentVera runs natively on Windows; it opens 18 agents side by side per project and collects approval requests in a single queue. It doesn’t manage agents inside WSL directly; you can open them in a Terminal agent with a command such as
wsl claude.
For details, see the guide to managing coding agents on Windows, and for the full summary, the Windows page.
Wrapping up
If you’re starting a new project and it isn’t tied to Windows, WSL 2 is still the option with the fewest surprises. If your code is already on Windows, your editor is on Windows, or the project relies on the Windows toolchain, native Windows is now perfectly good; there’s no longer a reason to move your agents to WSL. Whichever you pick, keep each repo on one side.