Codex no Windows com WSL: "Failed to create unified exec process: No such file or directory", como resolver

Você liga o "agente em WSL" no app do Codex para Windows e, a partir daí, nenhum comando roda. Nem pwd, nem git status. Todos falham antes de o shell abrir, com esta mensagem:

exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

Não é o seu Bash, nem o seu projeto, nem o WSL. É um conflito entre dois processos do próprio Codex que dividem a mesma pasta temporária no disco do Windows. Até 07/10/2026 a issue #49731 segue aberta e sem correção oficial, mas existe uma saída que vários usuários confirmaram: tirar essa pasta do disco do Windows com um mount --bind.

O que causa "Failed to create unified exec process: No such file or directory"?

O arquivo que falta é o codex-linux-sandbox, o executável que o Codex usa para rodar cada comando dentro do sandbox no Linux. Ele some porque um processo do Codex do lado Windows apaga a pasta onde o processo do lado Linux guardou esse executável.

O mecanismo está no código-fonte do Codex, em codex-rs/arg0/src/lib.rs, e foi descrito na issue por quem reproduziu o bug sem o app:

• Todo processo do Codex cria uma pasta própria em $CODEX_HOME/tmp/arg0/codex-arg0XXXXXX, com um arquivo .lock travado enquanto ele está vivo.
• Ao iniciar, todo processo roda uma faxina (janitor_cleanup) nessa pasta: tenta travar o .lock de cada subpasta e, se consegue, assume que ela foi abandonada e apaga tudo.
• No modo WSL, o agente Linux e o codex.exe do Windows usam o mesmo CODEX_HOME, em C:\Users\<você>\.codex, que o Linux enxerga como /mnt/c/Users/<você>/.codex.
• Uma trava de arquivo feita dentro do WSL num arquivo em /mnt/c é invisível para o Windows. O codex.exe consegue a trava, acha que a pasta do agente Linux está abandonada e apaga junto o codex-linux-sandbox.

O app sobe esse codex.exe segundos depois de abrir. Por isso reiniciar não resolve: a pasta nova do agente é apagada de novo logo em seguida.

Como confirmar que é esse bug?

Olhe o conteúdo da pasta arg0 pelo Prompt de Comando do Windows:

dir /s %USERPROFILE%\.codex\tmp\arg0

Se só aparecem .lock, apply_patch.bat e applypatch.bat, sem nenhum codex-linux-sandbox, é este caso. Os arquivos .bat são da pasta do processo Windows; a do agente Linux já foi apagada.

Outro sinal: com tty ligado, o mesmo comando falha com um erro mais específico, que mostra o caminho que sumiu:

Unable to spawn /mnt/c/Users/<você>/.codex/tmp/arg0/codex-arg0<id>/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)

Quais versões do Codex têm o problema?

Os relatos na issue #49731 cobrem do pacote 26.928.2636.0 até o 26.1002.6548.0, publicado em 06/10/2026, que um usuário confirmou ainda com o bug em 07/10. O agente Linux embutido nesses pacotes vai da codex-cli 0.159 à 0.160.1.

Versão do app (Windows)	Situação relatada na #49731
26.917.9434.0	Funcionava (relato de um usuário, Windows 10 + Debian)
26.928.2636.0 a 26.928.3736.0	Com o bug
26.930.x (incluindo 26.930.41038)	Com o bug
26.1002.6548.0	Com o bug em 07/10/2026

Como resolver com mount --bind?

A ideia é fazer o caminho tmp/arg0 apontar para uma pasta no disco do Linux. Ali as travas de arquivo funcionam entre processos Linux, e o codex.exe do Windows não apaga mais o helper do agente. O resto do CODEX_HOME (config, sessões, regras) continua onde está.

1. Crie a pasta no Linux, dentro do WSL, com o seu usuário:

mkdir -p /home/<usuario-linux>/codex-arg0-local

2. Faça o mount sobreviver a reinícios. Edite o /etc/wsl.conf (sudo nano /etc/wsl.conf) e adicione:

[boot]
command = mount --bind /home/<usuario-linux>/codex-arg0-local /mnt/c/Users/<usuario-windows>/.codex/tmp/arg0

Use caminhos absolutos, sem ~: o comando de boot roda como root. Se o seu wsl.conf já tem uma seção [boot] com systemd=true, só acrescente a linha command nela.

3. Feche o app do Codex e reinicie o WSL, no PowerShell:

wsl --shutdown

Abra o Codex de novo. Para conferir que o mount está ativo, rode no WSL:

findmnt /mnt/c/Users/<usuario-windows>/.codex/tmp/arg0

Quem aplicou relata que os comandos voltam a rodar e que o sandbox continua valendo (escrita fora do projeto segue bloqueada). Para desfazer, apague a linha do wsl.conf e rode sudo umount /mnt/c/Users/<usuario-windows>/.codex/tmp/arg0.

Montei e ainda falha. E agora?

Provavelmente o agente já estava rodando quando você montou e continua procurando a pasta antiga. Um usuário relatou exatamente isso ao montar com o app aberto. Por isso o passo 3 importa: com o mount no boot e o wsl --shutdown, o mount existe antes de o Codex subir o agente, e a pasta nova já nasce no lado Linux.

O que não resolve?

Tudo isto foi testado por quem relatou o bug na issue, sem efeito:

• Reiniciar o Windows ou o app, e abrir um chat novo.
• Reinstalar o Codex, ou remover e reinstalar o Ubuntu.
• Instalar o bubblewrap e desligar unified_exec em [features] no config.toml.
• Recriar a pasta apagada pelo lado do WSL: o Windows deixa a pasta em estado de exclusão pendente enquanto o .lock está aberto, e o mkdir no Linux devolve File exists.

Aprovar cada comando para rodar fora do sandbox funciona, mas é a saída errada: você perde exatamente a proteção que o sandbox existe para dar.

Não tenho sudo no WSL. Tem outra saída?

Tem: trocar o agente para o modo nativo. Em Settings, no seletor de agente, mude de WSL para Windows native e reinicie o app, porque a troca só vale depois do reinício, segundo a documentação oficial do app para Windows.

No modo nativo, a mesma documentação recomenda deixar o projeto no disco do Windows e acessar pelo WSL via /mnt/<drive>/. Um usuário relatou que abrir pelo agente nativo um projeto em \\wsl.localhost falha com helper_unknown_error, então mover o projeto faz parte da troca. Quando a OpenAI corrigir a #49731, você volta para o agente em WSL.

Isso afeta o Codex CLI dentro do WSL?

Pode afetar. A documentação oficial sugere export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex no WSL para o CLI e o app dividirem a configuração. É exatamente a condição do bug: a reprodução sem o app, na issue, usa o CLI Linux com esse CODEX_HOME e mostra que um simples codex.exe --version no Windows já apaga a pasta do processo Linux em execução. Se o seu CLI no WSL começou a falhar com o mesmo erro, o mesmo mount --bind resolve.