WSL ou Windows nativo para agentes de código?

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

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.

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.

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 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:

* 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 e, para o resumo completo, a página do 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ó.