Codex no Windows: "helper_unknown_error: setup refresh had errors", como resolver
Voltar para o Blog
Artigocodexopenaitroubleshootingagente de programaçãodev toolssegurança

Codex no Windows: "helper_unknown_error: setup refresh had errors", como resolver

Mafra10 de outubro de 20266 min de leitura

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 logCausaSaí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 pacoteVariável CODEX_CLI_PATH apontando para outra cópia do codex.exe
Falha só numa pasta de projeto, outras pastas funcionamEstado do workspace preso àquele caminhoAbrir 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.

Fluxograma: comando falha com setup refresh had errors, abrir o log do sandbox, os error 32 em cua_node leva a atualizar para 26.1007.21434; se não der para atualizar, usar sandbox unelevated no config.toml
Do erro genérico até a saída, em três passos.

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.

  1. Confira a versão em About Codex. Se aparecer 26.1002.x, você está na versão afetada.
  2. Atualize pela Microsoft Store (Biblioteca, depois Obter atualizações) ou pelo terminal:
    winget upgrade --id 9PLM9XGG6VKS -s msstore
  3. Feche o app por completo e abra de novo.
  4. Peça um comando simples e confira no log que a linha runtime read/execute validation failed nã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.

Gostou deste artigo?
Compartilhe conhecimento com sua rede.
// Leia também

Artigos relacionados