# WSL ou Windows nativo para agentes de código?

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

Rodar Claude Code e Codex no WSL 2 ou no Windows nativo? Velocidade, sandbox, tmux, CRLF, a lentidão do /mnt/c e qual opção faz sentido para cada tipo de projeto.

**Resumo:**

- Se o código está no drive C: e o projeto é específico do Windows (.NET, Unity, app desktop), o Windows nativo é mais simples e mais rápido.
- O WSL 2 é melhor para projetos que dependem de ferramentas Linux, trabalho com muito Docker e o sandbox do Claude Code; manter o código no sistema de arquivos Linux é essencial, porque o /mnt/c é bem mais lento.
- Dá para misturar os dois, mas editar o mesmo repositório pelos dois lados gera problemas de final de linha (CRLF) e de permissões.

Ao instalar um agente de código no Windows, a primeira decisão é esta: WSL ou Windows nativo? Um ano atrás, a resposta era quase sempre WSL, porque a maioria dos agentes não funcionava direito no Windows. Hoje Claude Code, Codex, Gemini CLI e Copilot CLI rodam nativamente no PowerShell; a resposta agora depende do projeto.

## Resposta curta

| Situação | Recomendação |
|---|---|
| .NET, C#, Unity, app desktop para Windows | Windows nativo |
| Código no drive `C:`, editor no Windows | Windows nativo |
| Ferramentas próprias do Linux, scripts de shell, Makefiles | WSL 2 |
| Desenvolvimento com muito Docker | WSL 2 |
| Você quer o sandbox do Claude Code | WSL 2 |
| Você vai usar uma ferramenta que depende do tmux | WSL 2 |
| Máquina corporativa, WSL proibido | Windows nativo |

## Vantagens do Windows nativo

**Instalação curta.** O Claude Code se instala com um script de PowerShell de uma linha; Codex e Gemini CLI, com npm. Todos os comandos estão em [como instalar agentes de código no Windows](/pt/blog/install-coding-agents-on-windows/).

**Acesso rápido a arquivos.** O código está no drive `C:` e o agente roda no Windows; não há ponte de sistema de arquivos no meio.

**Toolchain do Windows.** `dotnet`, MSBuild, os compiladores do Visual Studio e os SDKs específicos do Windows ficam ao alcance direto. Chamá-los a partir do WSL é possível, mas trabalhoso.

**Sandbox do Codex para Windows.** O Codex roda no Windows nativo com seu próprio sandbox.

## Desvantagens do Windows nativo

**Sem o sandbox do Claude Code.** O isolamento de sistema de arquivos e de rede do Claude Code não é suportado no Windows nativo; no WSL 2, é. No lugar dele, você trabalha com [regras de permissão](/pt/blog/claude-code-skip-permissions/).

**Sem tmux.** O tmux não tem versão nativa para Windows. Ferramentas que dependem dele (como o Claude Squad) não rodam no Windows nativo.

**Diferenças de shell.** A maioria dos agentes está acostumada a gerar comandos bash. O Claude Code usa o Git Bash se o Git for Windows estiver instalado; senão, o PowerShell; outros agentes podem usar o PowerShell ou o `cmd.exe`. Hábitos do bash como `rm -rf`, `export` ou `&&` se comportam de outro jeito no PowerShell.

**Problemas de caminho e de final de linha.** Caminhos com barra invertida, o limite de 260 caracteres e finais de linha CRLF às vezes confundem as ferramentas de edição. As configurações mais abaixo resolvem a maior parte.

## Vantagens do WSL 2

**É o próprio Linux.** Os comandos bash que os agentes geram rodam como estão; `make`, `grep`, `sed` e os pacotes Linux já estão à mão.

**Sandbox do Claude Code.** No WSL 2, o isolamento do Claude Code funciona; dá para rodar com mais segurança e menos aprovações.

**tmux e ferramentas de terminal.** tmux, Claude Squad e ferramentas parecidas rodam no WSL como estão.

## Desvantagens do WSL 2

**`/mnt/c` é lento.** A partir do WSL 2, acessar arquivos do Windows é bem mais lento do que acessar os do sistema de arquivos Linux. A [própria documentação](https://learn.microsoft.com/pt-br/windows/wsl/filesystems) da Microsoft recomenda manter os projetos do lado Linux. Clone o repositório em `~/` e abra-o no editor do Windows pelo caminho `\\wsl$\`.

**Dois ambientes separados.** Node, Python, credenciais do git e logins dos agentes ficam separados de cada lado. Talvez você precise fazer login no agente uma vez dentro do WSL e outra no Windows.

**Memória.** A máquina virtual do WSL 2 consome memória; com alguns agentes e uma stack Docker rodando ao mesmo tempo, pode ser preciso impor um limite com o `.wslconfig`.

## Misturar: o mesmo repositório pelos dois lados

O erro mais comum é manter o repositório no Windows e rodar um agente pelo WSL e outro pelo Windows. Resultado: um grava o arquivo com LF, o outro com CRLF; os diffs ficam barulhentos, algumas ferramentas de edição dizem “texto não encontrado” e as permissões dos arquivos parecem ter mudado.

Se for usar os dois ambientes juntos:

- Mantenha cada repositório **de um lado só** e rode os agentes daquele repositório pelo mesmo lado.
- Adicione um `.gitattributes` ao repositório:

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

- No lado do Windows, configure `git config --global core.autocrlf false` e `git config --global core.longpaths true`; deixe os finais de linha por conta do `.gitattributes`.

## Agentes em paralelo: possível dos dois lados

Para rodar vários agentes ao mesmo tempo, você usa git worktrees separados nos dois lados.

- **No WSL** há o tmux e ferramentas construídas sobre ele, como o Claude Squad.
- **No Windows nativo**, painéis do Windows Terminal ou um app desktop que mostra os agentes numa grade. O AgentVera roda nativamente no Windows; abre 18 agentes lado a lado por projeto e junta os pedidos de aprovação numa única fila. Ele não gerencia diretamente agentes dentro do WSL; você pode abri-los num agente Terminal com um comando como `wsl claude`.

Para mais detalhes, veja o guia [agentes de código no Windows](/pt/blog/coding-agents-on-windows/) e, para o resumo completo, a [página do Windows](/pt/windows/).

## Concluindo

Se você está começando um projeto novo e ele não depende do Windows, o WSL 2 ainda é a opção com menos surpresas. Se o seu código já está no Windows, o seu editor está no Windows ou o projeto depende da toolchain do Windows, o Windows nativo agora dá conta muito bem; não sobra motivo para levar os agentes para o WSL. Seja qual for a escolha, mantenha cada repositório de um lado só.

## Perguntas frequentes

**Devo rodar o Claude Code no WSL ou no Windows nativo?** No Windows nativo, se o projeto é específico do Windows e o código está no drive C:. No WSL 2, se o projeto depende de ferramentas Linux ou se você quer usar o sandbox do Claude Code. O sandbox não existe no Windows nativo.

**Por que o agente de código fica lento no WSL?** Muito provavelmente o código está em /mnt/c, ou seja, no sistema de arquivos do Windows. A partir do WSL 2, acessar arquivos do Windows é bem mais lento do que acessar arquivos no sistema de arquivos Linux. Clone o repositório em ~/.

**O tmux funciona no Windows?** Não nativamente; só dentro do WSL, do Cygwin ou do MSYS2. Por isso ferramentas que dependem do tmux, como o Claude Squad, pedem o WSL no Windows. No Windows nativo, dá para usar painéis do Windows Terminal ou um gerenciador de agentes.

**O AgentVera consegue gerenciar agentes dentro do WSL?** Não diretamente. O AgentVera roda nativamente no Windows e inicia os agentes instalados no Windows. Um agente do WSL pode rodar num agente Terminal com um comando como wsl claude; assim você tem um painel de terminal, mas não os recursos específicos do agente, como retomar a sessão.

---

**Sobre o AgentVera.** AgentVera é um app desktop para macOS, Windows e Linux, desenvolvido pela Solviera Teknoloji. Ele roda 18 agentes de programação com IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) lado a lado, por projeto, em terminais reais com as instalações e logins de CLI do próprio usuário. O plano gratuito tem agentes ilimitados. Baixar: https://agentvera.dev/pt/download/ · Preços: https://agentvera.dev/pt/pricing/