Sandbox

O sandbox delimita onde o agente pode atuar de forma autônoma sem ter acesso irrestrito ao seu computador. Quando um chat local executa comandos no aplicativo ChatGPT para desktop, na CLI do Codex ou na extensão para IDE, esses comandos são executados, por padrão, em um ambiente com acesso limitado.

Esse ambiente define o que o agente pode fazer por conta própria, incluindo quais arquivos pode modificar e se os comandos podem usar a rede. Enquanto a tarefa permanece dentro desses limites, o agente pode prosseguir sem parar para pedir confirmação. Quando precisa ultrapassá-los, entra em ação o fluxo de aprovação.

O que o sandbox faz

O sandbox se aplica tanto às operações de arquivo integradas quanto aos comandos que o agente inicia. Quando o agente executa ferramentas como git, gerenciadores de pacotes ou executores de testes, esses comandos herdam os mesmos limites do sandbox.

O Codex usa mecanismos nativos de cada sistema operacional para impor esses limites. A implementação varia entre macOS, Linux, WSL2 e Windows nativo, mas o princípio é o mesmo em todas as interfaces: oferecer ao agente um ambiente delimitado onde ele possa executar tarefas rotineiras de forma autônoma.

Por que usar o sandbox

O sandbox reduz o desgaste de aprovar comandos repetidamente. Dentro dos limites que você já aprovou, o agente pode ler arquivos, fazer alterações e executar comandos rotineiros do projeto sem pedir sua confirmação para cada comando de baixo risco.

O sandbox também torna mais claro o modelo de confiança para o trabalho com agentes de IA. Além de confiar nas intenções do agente, você pode contar com os limites que o sistema impõe à sua atuação. Assim, fica mais fácil deixar o agente trabalhar de forma independente e saber quando ele vai parar para pedir ajuda.

Primeiros passos

O modo de permissões padrão usa automaticamente um ambiente isolado.

Pré-requisitos

No macOS, o ambiente isolado funciona sem configuração adicional graças ao framework Seatbelt, integrado ao sistema.

No Windows, o Codex usa o sandbox nativo do Windows quando você executa o Codex no PowerShell. No WSL2, ele usa a implementação do sandbox do Linux.

No Linux e no WSL2, primeiro instale o bubblewrap com o gerenciador de pacotes da sua distribuição:

sudo apt install bubblewrap

sudo dnf install bubblewrap

O Codex usa o primeiro executável bwrap que encontra no PATH. Se não encontrar nenhum executável bwrap, o Codex recorre a um utilitário que vem com ele. Esse utilitário exige que o sistema permita criar namespaces de usuário sem privilégios. Para que essa configuração funcione de forma confiável, instale o pacote da distribuição que fornece o bwrap.

O Codex exibe um aviso na inicialização se o bwrap estiver ausente ou se o utilitário não conseguir criar o namespace de usuário necessário. Nas distribuições em que o AppArmor restringe essa operação, prefira carregar o perfil do AppArmor para bwrap. Assim, o bwrap pode continuar funcionando sem que você precise desativar a restrição em todo o sistema.

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

sudo systemctl reload apparmor.service

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

Acesso ao computador local com o Work na nuvem

Nas tarefas que usam o acesso ao computador local com o Work na nuvem, a nuvem da OpenAI coordena a conversa. As restrições do sandbox dependem de onde cada etapa é executada:

• Execução na nuvem: os contêineres do Work na nuvem usam as políticas existentes do Work na nuvem. As regras de sites do navegador de desktop não se aplicam automaticamente aos navegadores na nuvem.
• Execução local: as etapas executadas em um computador conectado seguem os requisitos de execução local compatíveis.

Para o Work com acesso local e para os dots, a política Global compatível se aplica ao orquestrador compartilhado na nuvem quando a política gerenciada está ativada. Os contêineres do Work na nuvem e os computadores dos dots na nuvem usam suas próprias configurações e requisitos de execução. Teste a execução local e a execução na nuvem separadamente para confirmar quais controles se aplicam a cada ambiente. Uma política de um ambiente não concede acesso a outro.

Dentro de uma política, a ordem de prioridade, da maior para a menor, é: substituição no ambiente para um sistema operacional específico → substituição no ambiente para todos os sistemas operacionais → Global. A política de maior prioridade prevalece mesmo que a de menor prioridade seja mais específica. Na execução local, os requisitos de MDM e os requisitos legados de dispositivos gerenciados têm precedência sobre os de Segurança de agentes, que, por sua vez, têm precedência sobre os do arquivo de requisitos de sistema do dispositivo.

Consulte Configuração gerenciada para conhecer as regras de mesclagem de cada campo e os limites em tempo de execução. Confira as restrições de acesso a arquivos e à rede que estão em vigor em Segurança do Work na execução local e Segurança do Work na nuvem.

Use o controle de permissões da sua interface para alterar como o Codex lida com ações locais.

As aprovações determinam quando o Codex deve pausar antes de uma ação. O sandbox determina quais arquivos e recursos de rede os comandos podem acessar. Quando houver diferentes escopos de aprovação, como aprovar uma única vez ou por toda a sessão, escolha o menor escopo que permita continuar a tarefa. Por padrão, mantenha o acesso restrito ao projeto. Use projetos ou árvores de trabalho separados para evitar ampliar o acesso a repositórios sem relação entre si.

O ChatGPT Work executa código e comandos de shell em um ambiente isolado e gerenciado. A política do espaço de trabalho e os controles de cada ferramenta determinam quais recursos estão disponíveis. Quando a opção estiver disponível, use Configurações > Controles de dados > Acesso à rede do Work para gerenciar o acesso à rede para código e comandos de shell. Ative Permitir acesso à internet pública para que esses comandos possam acessar a internet pública. Quando a opção está desativada, os comandos só podem acessar os nomes de host necessários que constam de uma lista gerenciada de permissões.

A pesquisa na Web, os plug-ins e o navegador remoto têm controles separados. As alterações entram em vigor depois que a execução atual do código ou do comando de shell termina e o Work atualiza o ambiente de execução. A versão Web do ChatGPT não disponibiliza o sandbox local do Codex nem o seletor de modo de aprovação.

No aplicativo ChatGPT para desktop, use o controle de permissões abaixo do editor. Dependendo da sua configuração, o menu pode incluir Pedir aprovação, Aprovar por mim para solicitações de aprovação elegíveis, Acesso completo e perfis de permissões nomeados ou personalizados.

Selecione um modo para explorar este exemplo da documentação. Isso não altera suas permissões no ChatGPT ou no Codex.

Do anything

Approve for me

GPT-6 AstraLight

How should ChatGPT actions be approved?Learn more

• Ask for approvalAlways ask to edit external files and use the internet
• Approve for meOnly ask for actions detected as potentially unsafe
• Full accessUnrestricted access to the internet and any file on your computer
• Custom (config.toml)Uses permissions defined in config.toml

Approve for me

Approve for me keeps the same workspace-write sandbox as Ask for approval, but eligible approval requests are routed through automatic review instead of showing a prompt for manual approval. More details about automatic review.

Sandbox

workspace-write

Approvals policy

on-request

Reviewer

auto_review

Na CLI, digite /permissions para abrir o seletor de permissões e alterar o perfil de permissões ativo.

Na extensão para IDE, use o controle de permissões abaixo do editor. Dependendo da sua configuração, o menu pode incluir Pedir aprovação, Aprovar por mim para solicitações de aprovação elegíveis, Acesso completo e perfis de permissões nomeados ou personalizados.

Configurar os padrões

Para que o Codex inicie sempre com o mesmo comportamento, defina os padrões em config.toml. A seção Configuração básica explica como o arquivo funciona, e a Referência de configuração documenta as chaves exatas sandbox_mode, approval_policy, approvals_reviewer e sandbox_workspace_write.writable_roots. Use essas configurações para definir quanta autonomia o agente terá por padrão, em quais diretórios poderá gravar, quando deverá pausar para pedir aprovação e quem analisará as solicitações de aprovação elegíveis.

Os modos de sandbox mais comuns são:

• read-only: o agente pode inspecionar arquivos, mas precisa de aprovação para editá-los ou executar comandos.
• workspace-write: o agente pode ler arquivos, fazer alterações no espaço de trabalho e executar comandos locais rotineiros dentro desse limite. Esse é o modo padrão para trabalhar localmente com poucas interrupções.
• danger-full-access: o agente opera sem as restrições do sandbox. Esse modo remove os limites de acesso ao sistema de arquivos e à rede. Use-o somente quando quiser que o agente atue com acesso completo.

As políticas de aprovação mais comuns são:

• on-request: por padrão, o agente trabalha dentro do sandbox e pede aprovação quando precisa ultrapassar esse limite.
• never: o agente não pausa para pedir aprovação.

O Codex e o ChatGPT Work não oferecem mais untrusted como opção de política de aprovação. Se uma configuração existente usar esse valor, consulte Como migrar da política de aprovação descontinuada untrusted.

Quando as aprovações são interativas, você também pode escolher quem analisa as solicitações com approvals_reviewer:

• user: as solicitações de aprovação são apresentadas ao usuário. Esse é o padrão.
• auto_review: as solicitações de aprovação elegíveis são encaminhadas a um agente revisor (consulte revisão automática).

O acesso completo combina sandbox_mode = "danger-full-access" com approval_policy = "never". Já a configuração predefinida de menor risco para automação local combina sandbox_mode = "workspace-write" com approval_policy = "on-request". Você também pode usar as opções equivalentes da CLI: --sandbox workspace-write --ask-for-approval on-request. Em seguida, mantenha approvals_reviewer = "user" para aprovações manuais ou defina approvals_reviewer = "auto_review" para a revisão automática das solicitações.

Se o agente precisar trabalhar em mais de um diretório, você pode definir diretórios raiz com permissão de gravação para ampliar os locais que ele pode modificar sem remover o sandbox por completo. Se precisar ampliar ou restringir os limites de confiança, ajuste o modo de sandbox e a política de aprovação padrão em vez de recorrer a exceções pontuais.

Quando um fluxo de trabalho exigir uma exceção específica, use regras. Com as regras, você pode permitir a execução de comandos fora do sandbox, exigir aprovação ou proibir a execução com base no prefixo do comando. Em geral, isso é mais adequado do que ampliar o acesso de forma abrangente. Para saber onde ajustar as configurações específicas da IDE, consulte Configurações da extensão do Codex para IDE.

A revisão automática, quando disponível, não altera os limites do sandbox. Ela é uma das opções de approvals_reviewer para solicitações de aprovação relacionadas a esses limites, como pedidos de elevação de permissões do sandbox, tentativas de acesso à rede bloqueadas ou chamadas de ferramentas com efeitos colaterais que ainda exigem aprovação. As ações já permitidas dentro do sandbox são executadas sem revisão adicional. Para saber mais sobre o ciclo de vida do revisor, os tipos de acionamento, o que acontece quando uma solicitação é negada e os detalhes de configuração, consulte revisão automática.

Os detalhes de cada plataforma estão na documentação correspondente. Para saber como configurar e solucionar problemas no Windows nativo e como o sandbox funciona nesse sistema, consulte Windows. Para conhecer os requisitos administrativos e as restrições que a organização pode impor ao ambiente isolado e às aprovações, consulte Aprovações e segurança de agentes.