Use o Codex no Windows com o aplicativo nativo de desktop do ChatGPT, a CLI ou a extensão para IDE.
O aplicativo de desktop do ChatGPT no Windows oferece recursos para os principais fluxos de trabalho, como chats em paralelo, árvores de trabalho, tarefas agendadas, recursos do Git, navegador integrado, prévias de arquivos, plug-ins e habilidades.
O aplicativo pode ser executado diretamente no PowerShell com um sandbox do Windows, sem precisar do WSL ou de uma máquina virtual. Assim, você pode usar o Codex em fluxos de trabalho nativos do Windows, com limites de acesso ao sistema de arquivos e à rede.
Para instalações corporativas, consulte o Guia de implantação no Windows.
O Codex oferece três implementações de sandbox no Windows:
mxc: sandbox recomendado para dispositivos Windows compatíveis. Usa isolamento nativo de processos e dispensa a configuração com aprovação do administrador, a criação de contas adicionais do Windows e o uso de regras de firewall locais.elevated: alternativa legada preferencial quando o MXC está indisponível ou desativado. A configuração exige aprovação do administrador. Os comandos no sandbox são executados sem privilégios de administrador.unelevated: alternativa legada para quando não é possível configurar o sandbox com privilégios elevados e a política da organização permite seu uso. Oferece isolamento de rede mais fraco queelevatede não permite bloquear a leitura de caminhos específicos.
Configurar o sandbox do Windows
O sandbox do Windows aplica as permissões vigentes de sistema de arquivos e de rede aos comandos e aos seus processos filhos. O perfil de permissões determina quais caminhos permitem leitura ou gravação e se o acesso à rede é permitido. A política de aprovação controla, de forma independente, quando o Codex solicita permissão para executar comandos com acesso mais amplo. Consulte Sandbox e aprovações.
Ativar o MXC
Para contas de uso pessoal, o aplicativo de desktop dá preferência automaticamente ao MXC quando o dispositivo é compatível. Para implantações corporativas ou uso independente da CLI, você pode ativar esse mesmo comportamento com a configuração abaixo.
Em config.toml:
[features]
prefer_mxc = trueCom prefer_mxc = true, o Codex usa o MXC para comandos do Windows quando o dispositivo é compatível e a política permite seu uso. Caso contrário, o Codex segue o fluxo existente de seleção e configuração do sandbox legado.
Em empresas onde a compatibilidade ou a política varia entre dispositivos, mantenha windows.sandbox configurado para usar a implementação legada permitida pela organização, elevated ou unelevated, como alternativa.
Os administradores podem distribuir essa configuração como padrão ou tornar features.prefer_mxc = true obrigatório por meio de requirements.toml. Nos dois casos, o Codex pode recorrer a uma implementação legada. Consulte Configuração gerenciada para entender a diferença entre valores padrão e requisitos.
Manter o MXC desativado
Para impedir o uso do MXC na organização, adicione o seguinte ao arquivo requirements.toml gerenciado:
[windows]
allow_mxc = falseIsso bloqueia tanto a seleção automática do MXC quanto a seleção explícita com windows.sandbox = "mxc". As configurações e os requisitos existentes para sandboxes legados continuam em vigor.
Compatibilidade com o MXC
O host já deve ter os recursos necessários do Microsoft Execution Containers (MXC), que a Microsoft está disponibilizando gradualmente para dispositivos com Windows 11. A Microsoft introduziu o isolamento de processos com MXC no Windows 11 24H2 (build 26100.9278) e na versão 25H2 (build 26200.9278). Use o comando abaixo para verificar se o seu dispositivo oferece suporte ao MXC.
A partir da versão 0.162.0 da CLI do Codex, você pode testar o MXC com um único comando sem alterar a seleção de sandbox salva. No diretório do projeto, execute:
codex -c windows.sandbox=mxc sandbox --include-managed-config --permission-profile :workspace -- cmd.exe /d /c echo MXC_OK
$LASTEXITCODEA saída esperada é MXC_OK, com código de saída 0. Esse teste verifica se o comando inicia com o perfil de permissões do espaço de trabalho e os requisitos gerenciados.
A seleção explícita com windows.sandbox = "mxc" falha se os recursos nativos necessários estiverem indisponíveis ou se a política bloquear o MXC.
Observe os seguintes limites de compatibilidade:
- O gerenciamento de rede exige que
allow_local_binding = trueesteja em vigor. O MXC permite conexões nos dois sentidos com serviços na interface de loopback do host. As regras de domínio do proxy continuam valendo para o tráfego que passa por ele, mas o proxy deixa de fazer as verificações adicionais de destinos em redes privadas. - Os processos filhos que ainda estiverem em execução serão encerrados quando o comando em primeiro plano terminar. Teste os fluxos de trabalho que dependem de servidores de desenvolvimento desvinculados do processo que os iniciou.
- Assim como no Linux e no WSL, os padrões glob de bloqueio de leitura se aplicam aos arquivos que correspondem a eles no momento em que cada processo inicia no sandbox. Se outros arquivos que correspondem aos padrões forem criados depois, o processo em execução ainda poderá lê-los caso suas demais permissões permitam o acesso. Shells, scripts, monitores de arquivos e servidores de desenvolvimento de longa duração mantêm essa lista durante a própria execução. A lista não vale para toda a sessão do Codex. Consulte Quando os padrões glob de bloqueio de leitura são avaliados.
Configurar uma alternativa legada
Selecione a implementação alternativa em config.toml:
[windows]
sandbox = "elevated" # or "unelevated"elevated é a alternativa legada preferencial. Essa implementação usa contas de usuário exclusivas do sandbox com privilégios reduzidos, limites de acesso ao sistema de arquivos, regras de firewall e as alterações de política local necessárias para executar comandos no sandbox.
Assim como o MXC, elevated lista os arquivos que correspondem aos padrões glob de bloqueio de leitura quando cada processo inicia no sandbox. Se outros arquivos que correspondem aos padrões forem criados depois, o processo em execução ainda poderá lê-los caso suas demais permissões permitam o acesso. Consulte Quando os padrões glob de bloqueio de leitura são avaliados para entender como isso afeta processos de longa duração.
unelevated é uma alternativa legada. Essa implementação executa comandos com um token restrito do Windows derivado da sua conta de usuário atual, limita o acesso ao sistema de arquivos com base em listas de controle de acesso (ACLs) e usa controles no nível do ambiente para impedir o acesso à rede, em vez da regra de firewall específica do usuário offline. Oferece isolamento de rede mais fraco que elevated e não permite bloquear a leitura de caminhos específicos, mas ainda é útil quando a política local ou corporativa impede a configuração com aprovação do administrador.
Use o MXC quando o dispositivo for compatível e a política permitir. Caso contrário, dê preferência a elevated, com unelevated como segunda alternativa.
Os administradores corporativos podem restringir as implementações legadas de sandbox que o Codex pode usar por meio do arquivo requirements.toml:
[windows]
allowed_sandbox_implementations = ["elevated"]Esse exemplo permite elevated e impede que o Codex recorra a unelevated. Ele não restringe mxc quando o MXC está disponível. Os demais requisitos gerenciados de permissões e rede continuam em vigor. Para permitir qualquer uma das implementações legadas, inclua os dois valores. O Codex dá preferência a elevated quando nenhum modo é selecionado.
Consulte a referência de requirements.toml para ver os valores aceitos. Para bloquear também o MXC, use o requisito específico windows.allow_mxc.
Por padrão, os dois modos legados de sandbox também usam uma área de trabalho privada para reforçar o isolamento da interface.
Provisionamento do sandbox legado com privilégios elevados pela equipe de TI
Para funcionários sem direitos de administrador local, a equipe de TI pode instalar a CLI e provisionar o sandbox com privilégios elevados antes que o funcionário inicie o Codex. Em um processo de implantação com privilégios elevados, execute:
codex sandbox setup --elevated --user 'DOMAIN\alice' --codex-home 'C:\Users\alice\.codex'Substitua a identidade e o caminho do exemplo pela identidade do funcionário no Windows e pelo caminho do CODEX_HOME dele, respectivamente. O comando lê a configuração desse usuário, provisiona o sandbox e salva windows.sandbox = "elevated". Em seguida, o funcionário executa o Codex em um terminal sem privilégios elevados.
Permissões do sandbox
No modo de acesso completo, o Codex pode atuar fora do diretório do projeto e executar ações destrutivas por engano, o que pode causar perda de dados. Para automatizar tarefas com mais segurança, mantenha os limites do sandbox e use regras para exceções específicas. Outra opção é definir a política de aprovação como nunca para que o Codex tente resolver os problemas sem solicitar permissões elevadas, de acordo com a sua configuração de aprovação e segurança.
Matriz de versões do Windows
| Versão do Windows | Nível de suporte | Observações |
|---|---|---|
| Windows 11 | Recomendado | É a versão mais indicada para usar o Codex no Windows. Use essa versão ao padronizar uma implantação corporativa. |
| Windows 10 recente com todas as atualizações | Suporte conforme possível | Pode funcionar, mas é menos confiável que o Windows 11. No Windows 10, o Codex depende de recursos modernos de console, incluindo o ConPTY. Na prática, é necessária a versão 1809 ou posterior do Windows 10. |
| Builds antigas do Windows 10 | Não recomendado | Há maior probabilidade de faltarem componentes de console necessários, como o ConPTY, e de ocorrerem falhas em ambientes corporativos. |
Considere também as seguintes condições do ambiente:
wingetdeve estar disponível. Se estiver ausente, atualize o Windows ou instale o Gerenciador de Pacotes do Windows antes de configurar o Codex.- A configuração do sandbox legado
elevatedexige aprovação do administrador. - Alguns dispositivos gerenciados pela empresa bloqueiam as etapas de configuração necessárias mesmo quando a versão do sistema operacional é compatível.
- O MXC também exige os recursos nativos descritos em Compatibilidade com o MXC. A matriz, por si só, não indica se o MXC está disponível em um dispositivo específico.
Verificar o acesso de leitura no sandbox
Quando um comando não conseguir ler um diretório, verifique o perfil de permissões ativo, os requisitos gerenciados e as permissões de arquivo do Windows. Na CLI, use /status e /debug-config para inspecionar a sessão e a configuração ativas. Se houver uma restrição gerenciada, peça ao administrador que a revise em vez de desativar o sandbox.
Use o sandbox nativo do Windows por padrão. Opte pelo WSL quando precisar de ferramentas nativas do Linux, quando seu fluxo de trabalho já estiver no WSL2 ou quando as implementações nativas disponíveis no Windows não atenderem às suas necessidades.
Solução de problemas e perguntas frequentes
Se estiver diagnosticando um problema em um computador Windows gerenciado, comece verificando o modo de sandbox nativo, a versão do Windows e os erros de política que o Codex exibir. Para o MXC, verifique a compatibilidade e a política de rede em vigor. Problemas com sandboxes legados podem estar relacionados à configuração, aos direitos de logon ou às permissões do sistema de arquivos.