Almost every AI coding agent runs natively on Windows now: Claude Code, Codex, OpenCode, GitHub Copilot, Cursor, Cline and Aider all install from PowerShell or as an app. The difference is the sandbox. Codex and Copilot CLI have a native Windows sandbox; Claude Code’s sandbox needs WSL2, and most others have none, so their commands run with your full user rights.
So the question for an AI coding agent on Windows isn’t “does it run?” but “where do its commands run, and what can they reach?”
Which agents run natively on Windows?
| Agent | Install on Windows | Shell it uses | Sandbox on native Windows | Config |
|---|---|---|---|---|
| Claude Code | irm https://claude.ai/install.ps1 | iex or winget install Anthropic.ClaudeCode | Git Bash plus PowerShell; PowerShell only without Git | No. WSL2 only | %USERPROFILE%\.claude\settings.json |
| Codex (CLI, IDE extension, ChatGPT desktop app) | powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex", or the app from the Microsoft Store | PowerShell | Yes: MXC on recent Windows 11, or an admin-set-up fallback | %USERPROFILE%\.codex\config.toml |
| OpenCode | scoop install opencode, choco install opencode or npm install -g opencode-ai; desktop app for x64 and ARM64 | Not stated in its docs; it recommends WSL | No built-in sandbox | ~/.config/opencode/opencode.json, opencode.json in the project |
| GitHub Copilot CLI | winget install GitHub.Copilot or npm install -g @github/copilot | PowerShell 6 or later | Yes, opt-in: /sandbox enable. Needs a recent Windows 11 update | %USERPROFILE%\.copilot\settings.json |
| Copilot in VS Code | The GitHub Copilot extension | VS Code’s terminal | Local sandboxing in Agent Host sessions | VS Code settings.json |
| Cursor | Installer from cursor.com | Its built-in terminal | Documented for macOS and Linux only | .cursor\ in the project, %USERPROFILE%\.cursor\ |
| Antigravity CLI (Gemini CLI’s successor) | irm https://antigravity.google/cli/install.ps1 | iex | Not stated | Not documented for Windows | Not stated |
| Cline | VS Code extension, npm install -g cline, or the desktop app (Windows in beta) | Your editor’s terminal | None documented | .clinerules\ in the project, Documents\Cline\Rules |
| Aider | powershell -ExecutionPolicy ByPass -c "irm https://aider.chat/install.ps1 | iex" | Your shell, for commands you approve | None | .aider.conf.yml in your home folder, repo root or current folder |
| DeepSeek Harness | npx @deepseek-ai/dsh web (needs Node.js), opens in the browser | Not stated | Windows not documented | Not stated |
| Contenox | Installer from contenox.com | Native | Yes: writes limited to the project; reads can’t be restricted on Windows | The Permissions page in the app |
“Not stated” means the agent’s own docs don’t say, as of November 2026. DeepSeek Harness is a developer preview with breaking changes announced in its README.
Step-by-step pages for the two most common:
- Claude Code on Windows: installers, Git Bash or PowerShell, WSL, settings paths and fixes
- Codex on Windows: desktop app, CLI, sign-in, the Windows sandbox and crash reports
Native or WSL: which should I use?
Run the agent where your toolchain lives.
| Choose native Windows when | Choose WSL2 when |
|---|---|
| The project builds with Windows tools: .NET, MSBuild, Visual Studio, PowerShell scripts | The project expects Linux: Bash scripts, Makefiles, Docker-first setups |
| You want the agent’s desktop app to just work | You want Claude Code’s sandbox, or OpenCode the way its docs recommend |
Your files live on C:\ and other Windows apps use them | Your files can live in the Linux file system |
The tradeoffs that decide it in practice:
File system speed. Files on C:\ are reached from WSL through /mnt/c, which is much slower for the thousands of small reads an agent and npm install do. Microsoft’s rule: store files in the WSL file system if you work in a Linux shell, and on the Windows file system if you work in PowerShell. Keep a WSL project at ~/code/my-app, not /mnt/c/Users/you/my-app. Windows apps reach it at \\wsl$\Ubuntu\home\you\code\my-app.
Two homes, two configs. A WSL agent reads ~/.claude or ~/.codex inside Linux, not %USERPROFILE%. Your rules, MCP servers and sign-in don’t carry over. Codex lets you share one: export CODEX_HOME=/mnt/c/Users/<you>/.codex in ~/.bashrc.
PATH leaks across. By default WSL appends your Windows PATH to Linux’s. An agent in WSL can end up running the Windows node.exe or git.exe when the Linux one is missing, with confusing errors. Install the tools inside Linux, or set appendWindowsPath=false under [interop] in /etc/wsl.conf and run wsl --shutdown.
WSL1 is out. Codex dropped it in version 0.115, and Claude Code’s sandbox needs WSL2. Check with wsl -l -v and convert with wsl --set-version <distro> 2.
The line-ending trap
An agent on Windows and an agent in WSL working on the same checkout disagree about line endings. Windows Git with core.autocrlf=true writes CRLF; Linux tools write LF. The result is a diff where every line of every touched file “changed”, which buries the agent’s real edit and wrecks your review.
Fix it once in the repository, not on each machine. Add a .gitattributes at the root:
* text=auto eol=lf
*.ps1 text eol=crlf
*.bat text eol=crlf
*.cmd text eol=crlfThen check what Git actually stored:
git add --renormalize .
git ls-files --eoli/lf in the first column means the file is stored with LF. A shell script stored with CRLF fails in Bash with $'\r': command not found, a common “the agent broke my script” report.
Other Windows traps
- Antivirus slows everything down. Microsoft Defender scans files as they are written, and
node_modulesalone holds tens of thousands. A Dev Drive (Windows 11, at least 50 GB, admin rights to create) runs Defender in performance mode for that volume, a safer choice than folder exclusions. It doesn’t help WSL projects, which live in their own virtual disk. - Antivirus locks files mid-install. “The process cannot access the file because it is being used by another process” during an install usually means a scan holds the download. Wait, delete the half-finished download folder, and rerun.
- PowerShell’s execution policy blocks npm installs. Agents installed with npm get
.ps1launchers, which a default policy refuses with “running scripts is disabled on this system”. Use the agent’s own installer, call the.cmdlauncher, or runSet-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser. - Network shares prompt or fail. Claude Code always asks before commands that touch
\\server\share, because the lookup can send your Windows credentials to that host. Map the share to a drive letter. - Two installs of the same agent. npm, WinGet and the native installer can all put an agent on PATH. Run
where.exe claude(orcodex,copilot) and keep one. - No sandbox means your whole account. Without one, an agent’s commands can read
%USERPROFILE%\.ssh,.awsand your browser profiles. Turn the sandbox on where it exists, deny those paths in your rules where it doesn’t, or run the agent in WSL2 or a container. See how to sandbox AI coding agents.
Why do OpenCode’s Windows instructions disagree?
OpenCode 1, the version in the main docs, installs natively with Scoop, Chocolatey or npm (opencode-ai) and recommends WSL for the best experience. OpenCode 2’s docs say Windows package managers aren’t supported for it yet and offer zip downloads (opencode-windows-x64.zip, opencode-windows-arm64.zip) instead. Its npm package is @opencode/cli. Check which version a tutorial means before you copy its command.
The desktop app can also drive OpenCode running in WSL: start opencode serve --hostname 0.0.0.0 --port 4096 inside WSL, set OPENCODE_SERVER_PASSWORD first because 0.0.0.0 accepts outside connections, and point the app at http://localhost:4096.
The docs give the global config only as ~/.config/opencode/opencode.json, with no separate Windows path. Inside WSL, that’s the Linux home folder.
Contenox
Contenox is a desktop app built for Windows first. You open a project folder, tell an agent what you want, and approve the risky steps; it can use your ChatGPT subscription, Claude through Claude Code, an API key, or a local model. On Windows, a sandbox limits the agent’s writes to the project folder; reads can’t be restricted on Windows, so its default rules block SSH keys, cloud credentials and browser profiles. Download it.
Related guides
- Claude Code on Windows: full install and setup
- Codex on Windows: desktop app, CLI and the Windows sandbox
- Best AI coding agents: how the agents compare beyond the platform
- Terminal coding agents: what the CLI agents have in common
- Why does my coding agent keep asking for permission?: rules for each agent