Desde 07/10/2026, quem usa o app do Codex no Windows com o sandbox elevated viu todo comando falhar antes de começar. Um Get-Location inofensivo volta com Failed to create unified exec process: helper_unknown_error: setup refresh had errors, e o Node REPL cai junto com trusted Node process exited unexpectedly. A issue #51601 passou de 119 comentários em três dias.
A boa notícia: a correção já saiu. A mensagem, porém, é genérica e aparece por mais de um motivo. Este guia mostra como achar a causa real no log e qual saída serve para cada uma.
O que significa "setup refresh had errors" no Codex?
Significa que o ajudante do sandbox do Windows (codex-windows-sandbox-setup.exe) falhou ao preparar as permissões antes de rodar o seu comando, e o Codex recusou a execução. O erro em si não diz qual passo falhou; quem diz é o log do sandbox.
Antes de cada comando, o Codex roda esse ajudante para conferir as permissões (ACLs) das pastas que o agente vai usar. Se qualquer passo obrigatório falhar, o comando nem começa. Por isso o sintoma é sempre o mesmo, com duração de 0 ms, não importa se você pediu um git status ou um build.
Onde ver a causa real do erro?
No arquivo %USERPROFILE%\.codex\.sandbox\sandbox.<data>.log. A última falha também fica resumida em %USERPROFILE%\.codex\.sandbox\setup_error.json. No PowerShell, isto mostra as últimas linhas relevantes:
Select-String -Path "$env:USERPROFILE\.codex\.sandbox\sandbox.*.log" -Pattern "os error|failed" | Select-Object -Last 20
Se você usa o CLI, codex doctor --summary também aponta quando o provisionamento do sandbox registrou falha.
Uma linha costuma confundir: failed to grant non-inheriting read-attributes ACE on user profile ... (os error 32); continuing setup. Ela termina em continuing setup, ou seja, não é fatal. Procure a linha que vem depois.
Qual linha do log corresponde a qual causa?
| Linha no log | Causa | Saída |
|---|---|---|
runtime read/execute validation failed ... cua_node\...\node_repl.exe ... (os error 32) | Regressão do ajudante que veio com o app 26.1002.x (CLI embutido 0.162.0-alpha.2) | Atualizar o app para 26.1007.21434 ou mais novo |
setup refresh failed to launch helper Access denied (os error 5) | O ajudante não consegue ser executado a partir da pasta WindowsApps do pacote | Variável CODEX_CLI_PATH apontando para outra cópia do codex.exe |
| Falha só numa pasta de projeto, outras pastas funcionam | Estado do workspace preso àquele caminho | Abrir o mesmo repositório por uma junção (mklink /J) |
O caso de outubro é a primeira linha, e é o que o resto deste guia resolve.

Por que o os error 32 aparece desde 07/10?
Porque o ajudante novo passou a validar as permissões de cada arquivo do runtime cua_node abrindo o arquivo com acesso MAXIMUM_ALLOWED, e o Windows recusa esse pedido em arquivo que está em uso. O código os error 32 é ERROR_SHARING_VIOLATION.
O detalhe que trava tudo: quem está usando esses arquivos é o próprio Codex. O app mantém node_repl.exe e codex-computer-use-swift.exe rodando a partir dessa pasta. Usuários na issue relataram que encerrar esses processos só move a falha para o próximo arquivo aberto (uma DLL), e que o app recria o processo em menos de um segundo. Reiniciar o app ou o Windows não resolve.
A OpenAI corrigiu isso no PR #51822, incorporado em 07/10/2026: MAXIMUM_ALLOWED ficou restrito a pastas, e arquivos passam a ser abertos só com READ_CONTROL | WRITE_DAC quando uma mudança de ACL é necessária.
Como resolver o os error 32 no app do Codex?
Atualize o app para a versão 26.1007.21434 (build 13901) ou mais nova. Vários usuários confirmaram na issue, em 09 e 10/10/2026, que comandos, Node REPL e o controle do navegador voltaram a funcionar com o sandbox elevated intacto, sem nenhum passo extra.
- Confira a versão em About Codex. Se aparecer 26.1002.x, você está na versão afetada.
- Atualize pela Microsoft Store (Biblioteca, depois Obter atualizações) ou pelo terminal:
winget upgrade --id 9PLM9XGG6VKS -s msstore - Feche o app por completo e abra de novo.
- Peça um comando simples e confira no log que a linha
runtime read/execute validation failednão voltou.
E se não der para atualizar agora?
Troque temporariamente o sandbox para o modo unelevated no %USERPROFILE%\.codex\config.toml:
[windows]
sandbox = "unelevated"
Os valores aceitos para essa chave, segundo o schema de configuração do repositório, são elevated, unelevated e mxc. Feche todas as instâncias do app (inclusive as que ficam escondidas no Gerenciador de Tarefas) e abra de novo. Na issue, quem fez essa troca relatou comandos e edições de arquivo funcionando, com recuperação parcial em alguns casos.
Isso é paliativo, não correção. O modo unelevated usa um token restrito e, pela documentação do próprio código, suporta um conjunto menor de políticas de sistema de arquivos que o elevated. Volte para elevated assim que atualizar.
O Codex CLI instalado pelo npm também é afetado?
Pode ser. Um usuário relatou o mesmo os error 32 com o @openai/codex@0.161.0 global, com o app desktop instalado na mesma máquina. Conferimos o código em 10/10/2026: a correção do PR #51822 está no main, na 0.162.0-alpha.17.2 em diante e na série 0.163.0-alpha, mas não está nas versões estáveis 0.162.0 nem 0.162.1, que é a latest no npm hoje.
Enquanto não sai uma estável com o fix, as saídas no CLI são o mesmo sandbox = "unelevated" acima ou uma versão alpha que já tem a correção:
npm install -g @openai/codex@0.163.0-alpha.5
codex --version
Versão alpha pode trazer outras mudanças. Se o seu fluxo depende de estabilidade, prefira o paliativo no config.toml e acompanhe as releases do repositório.
Como resolver as outras causas do mesmo erro?
os error 5 ao lançar o ajudante. Num relato de agosto de 2026 no fórum da OpenAI, o ajudante falhava ao ser executado a partir da pasta WindowsApps do pacote. A saída que funcionou foi apontar o Codex para outra cópia do executável antes de abrir o app:
setx CODEX_CLI_PATH "%USERPROFILE%\.codex\plugins\.plugin-appserver\codex.exe"
Confira antes se esse arquivo existe na sua máquina, e remova a variável quando uma versão nova do pacote voltar a lançar o ajudante normalmente.
Falha presa a uma pasta. Se outras pastas funcionam e só um repositório quebra, outro relato do fórum resolveu abrindo o mesmo repositório por uma junção do Windows, como se fosse um caminho novo:
mklink /J D:\CodexWorkspaceAlias D:\Projetos\meu-repositorio
Perguntas rápidas
Rodar os comandos sem sandbox resolve? Roda, mas tira a proteção de todo comando do agente e pode ser recusado se a sua política de aprovação for granular. Use o unelevated antes disso.
Preciso mexer em permissões com icacls? Não. Um usuário aplicou permissão de leitura e execução em 2.702 arquivos do runtime e a falha ficou idêntica: o problema é abrir o arquivo em uso, não a permissão que ele tem.
Se você quer um agente de programação que roda direto no terminal, sem app de desktop segurando arquivos do próprio runtime, a Verboo Code funciona como CLI e oferece tokens ilimitados.



