# WSL vs native Windows for coding agents

URL: https://agentvera.dev/en/blog/wsl-vs-native-windows-coding-agents/ · Published: 2026-11-01

Should you run Claude Code and Codex in WSL 2 or on native Windows? Speed, sandboxing, tmux, CRLF, slow /mnt/c access and which setup fits which kind of project.

**In short:**

- If your code lives on the C: drive and the project is Windows-specific (.NET, Unity, a desktop app), native Windows is simpler and faster.
- WSL 2 is better for projects built on Linux tooling, Docker-heavy work and Claude Code’s sandbox; keeping code in the Linux filesystem is a must, as /mnt/c is noticeably slower.
- You can mix the two, but editing the same repo from both sides leads to line-ending (CRLF) and permission problems.

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](/en/blog/install-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](/en/blog/claude-code-skip-permissions/) 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](https://learn.microsoft.com/en-us/windows/wsl/filesystems) 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 `.gitattributes` to the repo:

```gitattributes
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.ps1 text eol=crlf
```

- On the Windows side, set `git config --global core.autocrlf false` and `git config --global core.longpaths true`, and let `.gitattributes` handle 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](/en/blog/coding-agents-on-windows/), and for the full summary, the [Windows page](/en/windows/).

## 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.

## Frequently asked questions

**Should I run Claude Code in WSL or on native Windows?** Native Windows if your project is Windows-specific and your code is on the C: drive. WSL 2 if your project depends on Linux tooling or you want Claude Code’s sandbox, which isn’t available on native Windows.

**Why is my coding agent slow in WSL?** Most likely your code sits under /mnt/c, on the Windows filesystem. Accessing Windows files from WSL 2 is noticeably slower than accessing files in the Linux filesystem. Clone the repo under ~/.

**Does tmux work on Windows?** Not natively; it only runs inside WSL, Cygwin or MSYS2. That’s why tmux-based tools such as Claude Squad need WSL on Windows. On native Windows you can use Windows Terminal panes or an agent manager.

**Can AgentVera manage agents inside WSL?** Not directly. AgentVera runs natively on Windows and starts agents installed on Windows. You can run an agent in WSL by opening a Terminal agent and running a command such as wsl claude; you get a terminal pane, but not agent-specific features such as session resume.

---

**About AgentVera.** AgentVera is a desktop app for macOS, Windows and Linux, built by Solviera Teknoloji. It runs 18 AI coding agents (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) side by side, per project, in real terminals with the user's own CLI installs and logins. The free plan has unlimited agents. Download: https://agentvera.dev/en/download/ · Pricing: https://agentvera.dev/en/pricing/