Configuração gerenciada

Com a configuração gerenciada, administradores de empresas podem definir os requisitos e padrões compatíveis com o ChatGPT Work e o Codex. Os requisitos limitam o que usuários e tarefas podem fazer. Os padrões definem os valores iniciais. A compatibilidade depende do produto, da versão do cliente e do ambiente de execução.

Para gerenciar na nuvem as configurações compatíveis, comece em Segurança do agente no Console de administração. Use os controles de configuração para tarefas comuns ou selecione Editar como TOML para consultar, copiar ou editar o texto da configuração. As duas visualizações editam a mesma política. O TOML também dá acesso aos campos compatíveis que não têm controle próprio. Você não precisa distribuir um arquivo local para usar configurações gerenciadas na nuvem. As restrições de autenticação e as implantações gerenciadas por dispositivo têm uma configuração local separada.

Os administradores podem controlar o comportamento dos clientes locais compatíveis usando:

• Requisitos: restrições impostas pelo administrador que os usuários não podem substituir.

• Padrões de configuração: configurações de config.toml gerenciadas pelo sistema ou na nuvem que os usuários podem substituir.

• Padrões gerenciados legados: valores iniciais de managed_config.toml aplicados quando um cliente compatível é iniciado. Os usuários ainda podem alterar as configurações durante a execução. O cliente reaplica esses padrões na próxima inicialização.

Consulte Segurança do agente para conhecer a configuração de base Global, as substituições por ambiente e as listas de campos do orquestrador e do executor.

Se os usuários não entrarem no Codex com o ChatGPT, você poderá distribuir padrões e requisitos para a CLI do Codex e o aplicativo para desktop por um endpoint HTTPS que você administra. Consulte Hospede a configuração do Codex para sua equipe.

Configure uma política em Segurança do agente

Nos espaços de trabalho em que Segurança do agente está habilitada, os proprietários e administradores do espaço de trabalho, assim como os membros com permissões de administrador do Codex, podem gerenciar políticas. O acesso ao editor de políticas não concede aos membros acesso aos recursos controlados pela política.

Use Padrão do espaço de trabalho para definir a configuração de base do espaço de trabalho. Use Substituições quando usuários, grupos ou funções específicos precisarem de configurações diferentes. Uma substituição por público define quem recebe a política. Uma configuração de ambiente define onde os controles de execução compatíveis se aplicam.

1. Abra Console de administração > Segurança do agente e selecione Padrão do espaço de trabalho ou a política que deseja editar em Substituições.
2. Abra Requisitos para impor limites ou Padrões para definir valores iniciais que os membros podem alterar dentro desses limites.
3. Mantenha a aprovação, a pesquisa na Web e outras configurações que valem para todo o agente em Global. Quando disponível, use Adicionar configurações de ambiente no cartão correspondente para adicionar Ambientes locais ou Ambientes do Codex Cloud e definir as configurações de execução compatíveis. Um documento de ambiente vazio herda as configurações de Global, sem copiar nem fixar a configuração de base atual.
4. Use os controles descritos neste guia. Para campos avançados, selecione Editar como TOML e edite o requirements.toml ou o config.toml do escopo apropriado. Selecione Usar controles de configuração para voltar ao editor visual.
5. Confira as mensagens de validação e selecione Salvar alterações. Aplicar uma regra no editor de regras atualiza apenas o rascunho. Para salvar a política, é preciso salvar as alterações.
6. Verifique a seleção da política e o comportamento do cliente compatível conforme descrito em Confirme a experiência de administradores e funcionários.

Os editores de ambiente e os campos compatíveis dependem do espaço de trabalho e da política. Consulte Onde as configurações se aplicam antes de mover uma configuração de Global para um ambiente. Uma configuração em Global não se aplica necessariamente a todos os produtos ou formas de execução.

Copie ou reutilize uma configuração

O editor visual não substitui o TOML. Selecione Editar como TOML para copiar uma configuração, manter uma cópia de referência ou reutilizar configurações em outra política. Selecione Usar controles de configuração para voltar ao editor visual.

1. Abra a política de origem e selecione Editar como TOML.
2. Escolha o escopo que deseja copiar: Global ou uma das abas de ambiente disponíveis. Copie o texto de Requisitos (requirements.toml), de Padrões (config.toml) ou de ambos, conforme o que deseja reutilizar.
3. Abra a política de destino, selecione Editar como TOML e escolha o escopo correspondente. Cole os requisitos em requirements.toml e os padrões em config.toml. Confira as configurações existentes no destino antes de substituir o texto e mantenha as demais configurações que ainda devem valer.
4. Confira as mensagens de validação, o público-alvo e a prioridade da política de destino. Em seguida, selecione Salvar alterações. Confirme o comportamento resultante no cliente antes de usar a política copiada.

O texto copiado contém as configurações definidas naquela política e naquele escopo. Ele não inclui atribuições, ordem das políticas, documentos de outros ambientes nem a configuração efetiva que resulta da combinação com outras políticas e configurações do dispositivo. Copie separadamente as configurações de ambiente quando necessário. Alternar entre visualizações ou copiar texto não salva alterações na política.

Experimente o exemplo abaixo: altere uma configuração e selecione Editar como TOML para vê-la em TOML. Volte com Usar controles de configuração para continuar testando.

Escolha o controle adequado

Controle o Navegador e o Uso do computador

Use Segurança do agente no Console de administração para gerenciar o acesso ao navegador e a aplicativos nativos nos clientes de desktop compatíveis. Comece pelos controles da interface. Os exemplos em TOML abaixo servem de referência para distribuir políticas por arquivo e definir configurações que exigem o editor de TOML.

O recurso Navegador controla as atividades que o agente realiza em um navegador. O Uso do computador controla as atividades que o agente realiza em aplicativos nativos de desktop. As configurações do painel do navegador integrado são independentes do recurso Navegador. Consulte Sessões do navegador e logins existentes para entender as diferenças entre as formas de acesso ao navegador.

Antes de começar

Use uma conta com permissão para gerenciar políticas de Segurança do agente. Confirme quem recebe a política e quais versões de cliente e sistemas operacionais você precisa atender. Consulte Segurança do agente para saber mais sobre atribuições de políticas, configurações de Global e substituições por ambiente compatíveis.

Use Requisitos para definir limites que os usuários não podem substituir. Os Padrões definem os valores iniciais dentro desses limites. Permitir um site ou aplicativo não instala um plugin, não concede permissões do sistema operacional, não faz login pelo usuário nem aprova uma ação que ainda exige revisão.

Em Disponibilidade de recursos para desktop, confira Navegador, Uso de navegador externo e Uso do computador. Forçar desativação desativa o recurso correspondente. Uma regra que permite um site ou aplicativo não substitui essa configuração. Confira Acesso completo ao CDP separadamente. Bloquear ativação pelo usuário impede que os usuários o habilitem.

Esses controles de desktop não configuram o navegador hospedado do Work Cloud. Gerencie Uso do navegador na nuvem e Acesso à rede na nuvem separadamente em Console de administração > Permissões e funções > Recursos do espaço de trabalho > Recursos do computador na nuvem. Consulte Como a Segurança do agente se aplica ao Work Cloud.

Configure o acesso ao navegador

1. Abra Console de administração > Segurança do agente. Use Padrão do espaço de trabalho para definir a configuração de base ou abra a política correspondente em Substituições. Em Requisitos, acesse Controles do navegador para desktop.
2. Em Regras de sites, abra as ações da linha Padrão e escolha Editar padrão. Para limitar o acesso a sites aprovados, defina Acesso ao site como Bloquear e escolha Aplicar regra. A linha Padrão fornece os valores que uma regra correspondente ao site deixa como Usar regra padrão.
3. Escolha Adicionar regra de site. Em Site ou padrão, insira uma origem composta de esquema, nome do host e porta opcional. Por exemplo, https://example.com é válido, mas https://example.com/files não é. Não inclua caminho, consulta ou fragmento. HTTP e HTTPS são origens diferentes. Especifique a porta quando ela for diferente da porta padrão do esquema.
4. Defina Acesso ao site e confira Downloads, Uploads e Depuração/CDP. Escolha Permitir ou Bloquear, conforme o caso, ou mantenha a configuração em Usar regra padrão. Depuração/CDP controla o acesso completo ao Chrome DevTools Protocol para depuração do navegador. Permitir mantém as verificações normais de política e aprovação.
5. Confira Revisão automática, Sempre permitir e Duração da aprovação para o site. Duração da aprovação oferece as opções Neste turno e Nesta conversa. Confira também Histórico do navegador, Salvar aprovações de sites e Aprovar solicitações automaticamente em Controles do navegador para desktop.
6. Escolha Adicionar regra, confira as mensagens de validação e selecione Salvar alterações. Teste um site permitido e um bloqueado em um cliente compatível que receba a política. Teste separadamente uploads, downloads e outras ações restritas.

Adicionar regra de site

A linha Padrão fornece o valor de cada permissão definida como Usar regra padrão. Se houver sobreposição de regras, Bloquear prevalece para cada permissão.

Site ou padrão 

Acesso ao siteUsar regra padrão

DownloadsUsar regra padrão

UploadsUsar regra padrão

Depuração/CDPUsar regra padrão

Revisão automáticaUsar regra padrão

Sempre permitirUsar regra padrão

Duração da aprovaçãoUsar regra padrão

Se você desativar a Revisão automática para ações do navegador, o usuário passará a receber essas ações para aprovação. O monitoramento de segurança do modelo continua ativo.

Quando vários padrões de origem correspondem, prevalece o valor mais restritivo de cada configuração. A configuração local não pode flexibilizar um bloqueio gerenciado. Os bloqueios de rede gerenciados e as listas exclusivas de permissões também se aplicam às ferramentas do navegador. Consulte os campos da política do navegador para saber mais sobre padrões de origem e comportamento das aprovações.

O Uso do computador também pode operar um navegador como aplicativo nativo. As regras de sites e recursos do Navegador não se aplicam a essa forma de acesso. Confira separadamente o acesso a aplicativos nativos e consulte os limites de segurança do navegador.

Configure o acesso a aplicativos nativos

1. Em Requisitos, acesse Controles de aplicativos para desktop > Regras de aplicativos.
2. Use as ações da linha Padrão para configurar o acesso a aplicativos sem regra correspondente. Para limitar o Uso do computador a aplicativos aprovados, bloqueie o acesso por padrão e adicione regras que permitam esses aplicativos.
3. Escolha Adicionar regra de aplicativo. Na caixa de diálogo Editar regra, selecione ID do pacote do macOS, AUMID do Windows ou Executável do Windows em App. Em Identificador do aplicativo, insira o ID exato do pacote ou o Application User Model ID (AUMID). Para Executável do Windows, insira o Nome do fornecedor e o Nome do produto. O Nome do binário é opcional. Use dados verificados de identidade do aplicativo. O nome de exibição e o caminho do arquivo não servem como identificadores.
4. Defina Acesso ao aplicativo para a regra e escolha Adicionar regra. Confira Salvar aprovações de aplicativos em Controles de aplicativos para desktop, leia as mensagens de validação e selecione Salvar alterações. Desativar o salvamento de aprovações ainda permite aprovações para a sessão atual. Permitir o salvamento não aprova um aplicativo.
5. Teste um aplicativo permitido e um bloqueado em cada sistema operacional compatível da sua implantação. Confirme que as permissões do sistema operacional continuam valendo e que os usuários ainda precisam conceder as aprovações exigidas.

Editar regra

Defina o acesso padrão aos aplicativos e substitua-o para os aplicativos que correspondem à regra.

AppID do pacote do macOS

Identificador do aplicativo 

Acesso ao aplicativoEscolher acesso

Consulte os campos da política de Uso do computador para conhecer os requisitos de identidade no Windows e as restrições de uso com o computador bloqueado para Macs gerenciados.

Verifique a política efetiva

Se um site ou aplicativo permitido continuar bloqueado, confira as demais regras correspondentes, as atribuições e a prioridade das políticas, os requisitos do dispositivo e a configuração do usuário. Uma regra de permissão em uma fonte não contorna um bloqueio aplicável de outra fonte. Consulte Locais e precedência dos requisitos.

Se uma configuração não tiver efeito, verifique se o cliente, o sistema operacional e o mecanismo de distribuição da política são compatíveis com ela. Preste atenção especial ao Work Cloud com acesso ao computador local: alguns campos têm compatibilidade parcial ou exigem validação. Consulte Compatibilidade com o modo Work na referência de configuração.

Verifique as permissões do espaço de trabalho e os controles de plugins separadamente quando um usuário não conseguir acessar o recurso ou o plugin necessário.

Referência de configuração em TOML

Os exemplos a seguir mostram como expressar as mesmas políticas em requirements.toml. Use-os ao gerenciar políticas por arquivos ou pelo editor de TOML. Você não precisa editar um arquivo local para usar os controles disponíveis em Segurança do agente.

Este exemplo de navegador nega o acesso por padrão, permite https://example.com, bloqueia uploads e acesso completo ao CDP nesse site e limita a aprovação de acesso ao site ao turno atual:

[browser_use]
allow_history_access = false
allow_global_persistent_approval = false

[browser_use.default_origin_policy]
access = "deny"

[browser_use.origins."https://example.com"]
access = "allow"
uploads = "deny"
downloads = "allow"
full_cdp_access = "deny"
persistent_approval = false
access_approval_lifetime = "turn"

Para desativar a Revisão automática das ações do navegador, defina browser_use.disable_auto_review = true. Para desativá-la apenas em uma origem específica, defina auto_review = "deny" na política dessa origem.

Nos planos gerenciados elegíveis, deixe browser_use.allow_webmcp sem definir ou defina o campo como true para que a política do espaço de trabalho permita o uso das ferramentas de sites no navegador integrado do aplicativo para desktop. Defina o campo como false para desativar o acesso concedido por essa política. Os usuários cujas contas já receberam acesso durante a liberação gradual do recurso podem continuar usando as ferramentas de sites. O uso também depende da compatibilidade do modelo, das configurações do navegador e das permissões do site.

Este exemplo de aplicativo nativo permite a Calculadora no macOS, nega o acesso a outros aplicativos por padrão e impede que as aprovações de aplicativos persistam entre sessões:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

As políticas do Windows podem identificar aplicativos empacotados com computer_use.windows.aumids ou executáveis com computer_use.windows.exes. As regras para executáveis exigem publisher_name, product_name e access. O campo binary_name é opcional.

Para consultar todos os campos e valores compatíveis, use a referência de requirements.toml. Para desativar um recurso inteiro em vez de restringir sites ou aplicativos específicos, consulte Fixe os valores das flags de recursos.

Outros controles de desktop

Os controles de desktop a seguir abrangem a disponibilidade de recursos, o uso com o computador bloqueado, as capturas de aplicativos e o controle remoto do dispositivo. Use as configurações específicas para disponibilidade de recursos e uso com o computador bloqueado. Configure as capturas de aplicativos e o controle remoto do dispositivo com Editar como TOML. Para restringir os destinos do tráfego do aplicativo para desktop, consulte Controle os destinos de rede do aplicativo para desktop.

Fixe os valores das flags de recursos

Para os recursos de desktop disponíveis em Segurança do agente, abra Global > Requisitos > Disponibilidade de recursos para desktop. Defina Navegador integrado, Navegador, Uso de navegador externo ou Uso do computador como Forçar desativação para desativar o recurso correspondente e selecione Salvar alterações. Para Acesso completo ao CDP, escolha Bloquear ativação pelo usuário para impedir que os usuários habilitem o recurso. Permitir um recurso não altera sua disponibilidade por produto, plataforma ou etapa de lançamento.

Para outras flags de recursos compatíveis, use Editar como TOML e o documento requirements.toml de Global ou uma fonte local de requisitos compatível. Os exemplos a seguir fixam valores de recursos do ambiente de execução e de recursos específicos de desktop:

[features]
hooks = true
unified_exec = false

# Disable surface-specific features when needed.
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
in_app_updates = false
computer_use = false

Para os recursos do ambiente de execução, use as chaves canônicas de config.toml listadas na tabela [features]. O ambiente de execução local ajusta os recursos reconhecidos aos valores fixados e rejeita gravações conflitantes em config.toml ou nas configurações de recursos dos arquivos de perfil.

A configuração gerenciada unified_exec = false mantém a execução de comandos disponível, mas desativa os processos que podem ser retomados e a ferramenta write_stdin. A configuração do usuário não pode desativar esse recurso.

• in_app_browser = false desativa o painel do navegador integrado.
• in_app_updates = false desativa, na reinicialização, o atualizador do próprio aplicativo ChatGPT para desktop, quando há suporte. Isso não afeta a implantação externa de pacotes nem estende o suporte a versões anteriores do aplicativo. Para orientações sobre configuração e implantação, consulte Gerencie as atualizações do aplicativo.
• browser_use = false desativa os recursos compatíveis do Navegador. O uso de navegador externo e o Uso do computador em aplicativos nativos têm controles separados.
• browser_use_full_cdp_access = false desativa o acesso completo ao CDP no ambiente de execução local, inclusive no modo de desenvolvedor do navegador, e impede que o aplicativo ChatGPT para desktop habilite a configuração correspondente.
• browser_use_external = false desativa o uso do Navegador pelo agente por meio das extensões de navegador compatíveis.
• computer_use = false desativa o Uso do computador em aplicativos nativos, inclusive a operação de um navegador como aplicativo nativo, além do recurso de gravação e reprodução e dos fluxos de instalação ou configuração relacionados.

Desativar apenas o recurso Navegador não bloqueia todas as formas de acesso a navegadores. O Uso do computador em aplicativos nativos ainda pode operar um navegador quando tanto esse recurso quanto o acesso ao aplicativo são permitidos. As regras de sites e recursos do Navegador não se aplicam a essa forma de acesso. Para bloqueá-la, defina Uso do computador como Forçar desativação (computer_use = false) ou bloqueie o aplicativo do navegador em Regras de aplicativos caso outros aplicativos nativos devam continuar disponíveis. Confira Uso de navegador externo e Navegador integrado separadamente. Consulte Sessões do navegador e logins existentes para conhecer os controles aplicáveis a cada forma de acesso.

Se você omitir essas chaves, a política permitirá os recursos, sujeitos à disponibilidade normal por cliente, plataforma e etapa de lançamento.

Restrinja o uso com o computador bloqueado

Para impedir que os usuários habilitem o uso com o computador bloqueado em um Mac gerenciado, abra Global > Requisitos > Controles de aplicativos para desktop, defina Permitir uso com o computador bloqueado como Desativado e selecione Salvar alterações. Essa configuração não desativa o recurso em um Mac onde ele já está habilitado.

O requisito equivalente para o editor de TOML ou para distribuição por gerenciamento de dispositivos é:

[computer_use]
allow_locked_computer_use = false

Esse requisito remove os controles que permitem habilitar o uso com o computador bloqueado. Se o recurso já estiver habilitado, continuará ativo. Se você omitir o requisito, continuarão valendo a disponibilidade normal do produto e a configuração local do usuário.

Desative as capturas de aplicativos

O recurso de capturas de aplicativos permite que clientes compatíveis incluam instantâneos de aplicativos. Para desativá-lo para usuários gerenciados na nuvem, abra Editar como TOML em Segurança do agente e defina o campo de nível superior allow_appshots no requirements.toml de Global. Para implantações gerenciadas por dispositivo, use a fonte local de requisitos aplicável:

allow_appshots = false

Onde as capturas de aplicativos estiverem disponíveis, allow_appshots = false as desativa. Se você omitir a chave, os requisitos não restringirão as capturas e as verificações normais de disponibilidade do produto continuarão valendo. Os clientes do App Server que leem os requisitos efetivos por configRequirements/read recebem a mesma restrição no campo allowAppshots. Um valor omitido ou null para allowAppshots não desativa as capturas de aplicativos.

Desative o controle remoto do dispositivo

Para desativar o controle remoto do dispositivo para usuários gerenciados na nuvem, use Editar como TOML em Segurança do agente e defina o campo de nível superior allow_remote_control no requirements.toml de Global. Você também pode definir allow_remote_control em uma fonte local de requisitos compatível:

allow_remote_control = false

Onde houver suporte ao controle remoto do dispositivo, allow_remote_control = false o desativa. Se você omitir a chave, os requisitos não restringirão o controle remoto e as verificações normais de disponibilidade do produto continuarão valendo. Esse requisito não desativa conexões remotas SSH.

Defina aprovações e permissões de execução

Use esta seção para definir o comportamento das aprovações, os limites das permissões e os valores iniciais. Comece por Limites da política e Padrões. As tarefas seguintes explicam os requisitos em TOML para exigir um revisor específico, personalizar perfis de permissão, restringir o sistema de arquivos, substituir configurações por host e definir regras de comandos.

Requisitos impostos pelo administrador (requirements.toml)

Os requisitos restringem configurações que afetam a segurança, como a política de aprovação, o revisor de aprovações, a política de Revisão automática, o modo de sandbox, os perfis de permissão, o modo de pesquisa na Web, os hooks gerenciados, os servidores MCP que os usuários podem habilitar e as fontes de marketplaces de plugins que podem usar. Ao determinar a configuração efetiva, por exemplo, a partir de config.toml, arquivos de perfil ou substituições de configuração da CLI, o cliente local adota um valor compatível e avisa o usuário se algum valor entrar em conflito com uma regra obrigatória. Se você configurar uma lista de permissões em mcp_servers, o cliente habilitará um servidor MCP somente se o nome e a identidade corresponderem a uma entrada aprovada. Caso contrário, o cliente desativará o servidor.

Os requisitos também podem restringir flags de recursos pela tabela [features] de requirements.toml. Nem todos os recursos afetam a segurança, mas as empresas podem fixar seus valores se desejarem. As chaves omitidas permanecem sem restrição.

No Codex 0.138.0 ou posterior, prefira perfis de permissão com allowed_permission_profiles e um valor gerenciado de default_permissions. Use allowed_sandbox_modes apenas em implantações legadas que ainda configuram sandbox_mode.

Para ver a lista exata de chaves, consulte a seção sobre requirements.toml na referência de configuração.

Defina limites para aprovações, sandbox e pesquisa na Web

Use Requisitos > Limites da política para limitar as opções dos clientes compatíveis. Esses controles restringem a configuração sem selecionar o valor inicial. Defina esse valor separadamente em Padrões.

1. Em Global, abra Políticas de aprovação e selecione as modalidades permitidas. Por exemplo, Perguntar quando necessário permite que o agente solicite aprovação para ações como executar comandos fora da sandbox. Nunca perguntar impede solicitações de aprovação, sem conceder execução irrestrita.
2. Abra Modos de sandbox para limitar as opções legadas de sandbox. Somente leitura restringe gravações, Gravação no espaço de trabalho permite gravar no espaço de trabalho e nos diretórios raiz configurados para gravação, e Acesso completo remove o isolamento do sistema de arquivos. Use requisitos de perfis de permissão em implantações que usam perfis de permissão em vez de sandbox_mode.
3. Em Global, abra Modos de pesquisa na Web para limitar a pesquisa na Web. Escolha Em cache para permitir pesquisas em cache sem pesquisa em tempo real ou Desativado para desativar a pesquisa na Web. As restrições de pesquisa na Web são independentes das regras de rede dos comandos.
4. Confira as opções permitidas e os padrões correspondentes. Em seguida, selecione Salvar alterações.

Se um requisito ficar sem valor, aquela política não imporá um limite para ele. As demais políticas aplicáveis continuam valendo. A opção Perguntar para comandos não confiáveis corresponde a untrusted na lista de permissões dos requisitos. Ela não restabelece a configuração explícita descontinuada approval_policy = "untrusted". Nesse caso, siga as orientações de migração abaixo.

Para restringir a pesquisa na Web, use Global > Requisitos > Limites da política > Modos de pesquisa na Web. O TOML equivalente é:

allowed_web_search_modes = ["cached"] # "disabled" remains implicitly allowed

allowed_web_search_modes = [] permite apenas "disabled". Por exemplo, allowed_web_search_modes = ["cached"] impede a pesquisa na Web em tempo real mesmo em sessões danger-full-access.

Defina os padrões de configuração

Os padrões fornecem uma configuração inicial aos membros. Eles não impõem restrições nem concedem acesso a recursos do espaço de trabalho.

1. Abra o cartão Padrões da política. Mantenha os padrões que valem para todo o agente em Global. Use uma aba de ambiente disponível para os padrões de execução compatíveis.
2. Em Execução de comandos, escolha a Política de aprovação e o Revisor de aprovações iniciais, além do Modo de sandbox ou das Permissões padrão aplicáveis. O revisor determina quem analisa as solicitações de aprovação por padrão. A política de aprovação determina quando essas solicitações podem ocorrer.
3. Em Pesquisa na Web, escolha o modo inicial de Pesquisa na Web e o Contexto da pesquisa na Web. Em Apps e ferramentas, confira Apps/conectores, Ferramentas de mundo aberto e Ferramentas destrutivas para as ferramentas de aplicativos compatíveis.
4. Confirme que os padrões atendem aos Requisitos e selecione Salvar alterações.

Use Editar como TOML para definir padrões compatíveis sem controles visuais, como a configuração do marketplace de plugins. Esses padrões da nuvem seguem a precedência normal de configuração. Eles diferem da precedência legada de managed_config.toml, que dá prioridade aos padrões gerenciados sobre a configuração local na inicialização.

Exemplo de requirements.toml

Este exemplo bloqueia --ask-for-approval never e --sandbox danger-full-access (inclusive --yolo):

allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

Aqui, untrusted preserva o comportamento de aprovação mais rigoroso derivado de trust_level = "untrusted". Isso não torna approval_policy = "untrusted" uma configuração explícita compatível.

Migre a política de aprovação descontinuada untrusted

O Codex e o ChatGPT Work não aceitam mais approval_policy = "untrusted". Remova essa configuração dos padrões gerenciados, do arquivo legado managed_config.toml e de todas as configurações de usuário, projeto, perfil ou inicialização que a definam.

Para uso interativo somente leitura, selecione approval_policy = "on-request" com uma sandbox ou um perfil de permissão somente leitura permitido pelos requisitos gerenciados. Os comandos permitidos por essa sandbox podem ser executados sem aprovação.

Para manter aprovações de comandos mais rigorosas, omita a configuração explícita de approval_policy, defina trust_level = "untrusted" na entrada do projeto no arquivo ~/.codex/config.toml do usuário e mantenha untrusted em allowed_approval_policies. Isso também desativa a configuração local do projeto. Definir on-request explicitamente substitui essa política. Consulte Migre da política de aprovação descontinuada untrusted para ver exemplos e avaliar as implicações de segurança.

Configure a política de Revisão automática

Para definir a Revisão automática como padrão, selecione Global > Padrões > Execução de comandos > Revisor de aprovações. Os usuários ainda podem escolher outro revisor permitido. Para exigir a Revisão automática ou substituir a política que o revisor usa para avaliar solicitações, selecione Editar como TOML e edite o requirements.toml do escopo Global. As ações do navegador têm controles próprios de Revisão automática.

O exemplo a seguir exige a Revisão automática para as solicitações de aprovação elegíveis. Para permitir também a aprovação manual, inclua "user" em allowed_approvals_reviewers.

allowed_approval_policies = ["on-request"]
allowed_approvals_reviewers = ["auto_review"]

Para substituir a política inteira, use guardian_policy_config. Consulte Configuração da Revisão automática para conhecer a política padrão e saber como preparar uma política substituta.

Controle os perfis de permissão disponíveis

Use Padrões > Execução de comandos > Permissões padrão para escolher o perfil integrado inicial dos usuários. Para restringir os perfis que eles podem selecionar ou definir perfis personalizados, use Editar como TOML e configure requirements.toml no escopo Global ou no ambiente de execução compatível correspondente. Escolher apenas um padrão não restringe os perfis disponíveis.

Use allowed_permission_profiles para controlar quais perfis de permissão integrados e personalizados os usuários podem selecionar. Para perfis de permissão, essa configuração equivale a allowed_sandbox_modes. Use a lista de permissões que corresponde à forma como os usuários selecionam permissões.

As listas de perfis de permissão permitidos exigem o Codex 0.138.0 ou posterior. O Codex 0.137.0 e versões anteriores ignoram allowed_permission_profiles e o valor gerenciado de default_permissions.

Use os exemplos de perfis de permissão abaixo somente depois que todos os clientes gerenciados estiverem em uma versão compatível. Aguarde a conclusão da atualização de todos os clientes antes de implantar perfis personalizados gerenciados.

Quando presente, a tabela contém a lista completa de perfis permitidos. Ela permite os perfis definidos como true e nega os omitidos ou definidos como false, inclusive perfis integrados que venham a ser adicionados em versões futuras do Codex.

Permita os perfis padrão

Esta política permite acesso somente leitura e acesso ao espaço de trabalho, mas bloqueia o acesso completo:

default_permissions = ":workspace"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
# ":danger-full-access" is omitted, so it is denied.

Adicione um padrão gerenciado com privilégio mínimo

Os administradores podem definir um perfil personalizado na mesma fonte de requisitos. Use nomes de perfil específicos da organização que não entrem em conflito com nomes nas configurações carregadas dos usuários. Os nomes personalizados não podem começar com : nem usar o nome reservado filesystem.

Não implante perfis personalizados gerenciados em clientes com o Codex 0.137.0 ou anterior. Esses clientes reconhecem a tabela de perfis, mas não o padrão gerenciado que seleciona o perfil.

Por exemplo:

default_permissions = "acme_review_only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = true
acme_review_only = true
# ":danger-full-access" is intentionally omitted, so it is denied.

[permissions.acme_review_only]
description = "Review code without modifying the workspace."
extends = ":read-only"

Permita apenas perfis definidos pela empresa

Omita todos os perfis integrados quando os usuários só puderem selecionar perfis definidos pelo administrador:

default_permissions = "acme_workspace"

[allowed_permission_profiles]
acme_workspace = true

[permissions.acme_workspace]
description = "Workspace access with sensitive files denied."
extends = ":workspace"

[permissions.acme_workspace.filesystem]
glob_scan_max_depth = 3

[permissions.acme_workspace.filesystem.":workspace_roots"]
"**/*.env" = "deny"

O perfil personalizado pode estender :workspace mesmo que os usuários não possam selecionar diretamente o perfil integrado :workspace.

Desative um perfil permitido por outra fonte

As listas de permissões são combinadas pelo nome do perfil. Como os requisitos da nuvem têm precedência sobre os requisitos do sistema, os requisitos da nuvem podem usar false para desativar um perfil permitido pelo arquivo do sistema.

Requisitos da nuvem:

default_permissions = ":read-only"

[allowed_permission_profiles]
":read-only" = true
":workspace" = false

Requisitos do sistema:

[allowed_permission_profiles]
":read-only" = true
":workspace" = true  # Not honored because cloud requirements set this to false.

Defina default_permissions explicitamente como um perfil permitido. Se o campo for omitido, o ambiente de execução local adotará :workspace como padrão somente quando tanto :workspace quanto :read-only forem permitidos explicitamente. Na ausência de allowed_permission_profiles, os requisitos gerenciados não restringem os nomes de perfil que os usuários podem selecionar. Cada entrada deve nomear um perfil integrado ou um perfil personalizado definido em uma fonte de configuração ou requisitos carregada. Defina os perfis personalizados nos requisitos gerenciados para controlar seu comportamento de forma centralizada.

Imponha requisitos de bloqueio de leitura

Use Editar como TOML para adicionar restrições ao sistema de arquivos no requirements.toml de Global ou do ambiente de execução compatível correspondente. Essas restrições bloqueiam a leitura de caminhos sensíveis. Um padrão somente leitura, por si só, não oculta arquivos.

Os administradores podem bloquear a leitura de caminhos exatos ou padrões glob com [permissions.filesystem]. Os usuários não podem flexibilizar esses requisitos por meio da configuração local.

[permissions.filesystem]
deny_read = [
  # values can be absolute paths...
  "/**/*.env",
  # ...or relative to $HOME/%USERPROFILE% using `~`.
  "~/.ssh",
  # But relative paths starting with `./` are not allowed.
]

Quando há requisitos de bloqueio de leitura, o ambiente de execução local rejeita permissões de acesso completo e mantém a execução local em uma sandbox somente leitura ou do espaço de trabalho para poder impor esses requisitos. No Windows nativo, o deny_read gerenciado se aplica às ferramentas de acesso direto a arquivos. Leituras feitas por subprocessos do shell não usam essa regra da sandbox.

Substitua requisitos de sandbox por host

Use Editar como TOML em Segurança do agente para definir requisitos específicos por host. Os controles de ambiente selecionam um ambiente de execução. Os padrões de host selecionam as máquinas correspondentes no ambiente de execução compatível.

Use [[remote_sandbox_config]] quando uma mesma política gerenciada precisar aplicar requisitos de sandbox diferentes em hosts diferentes. Por exemplo, você pode manter um padrão mais rigoroso para notebooks e permitir gravações no espaço de trabalho em máquinas de desenvolvimento ou executores de CI que correspondam aos padrões. No momento, as entradas específicas de host substituem apenas allowed_sandbox_modes:

allowed_sandbox_modes = ["read-only"]

[[remote_sandbox_config]]
hostname_patterns = ["*.devbox.example.com", "runner-??.ci.example.com"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

O ambiente de execução local compara cada entrada de hostname_patterns com o nome de host que consegue resolver. Ele dá preferência ao nome de domínio totalmente qualificado, quando disponível, e usa o nome de host local como alternativa. A correspondência não diferencia maiúsculas de minúsculas. * corresponde a qualquer sequência de caracteres e ? corresponde a um caractere.

Dentro da mesma fonte de requisitos, prevalece a primeira entrada [[remote_sandbox_config]] correspondente. Se nenhuma entrada corresponder, o ambiente de execução local manterá o allowed_sandbox_modes de nível superior. A correspondência do nome de host serve apenas para selecionar a política. Não a trate como prova autenticada da identidade do dispositivo.

Imponha regras de comandos por meio dos requisitos

Use Editar como TOML em Segurança do agente para adicionar regras de comandos e restrições de servidores MCP ao requirements.toml de Global. As regras de comandos determinam se comandos correspondentes exigem aprovação ou devem ser negados. As restrições de MCP limitam as identidades de servidor que o cliente pode habilitar. O controle Políticas de aprovação não permite definir nenhum desses conjuntos de regras.

Os administradores também podem impor regras restritivas de comandos em requirements.toml usando uma tabela [rules]. Essas regras são combinadas com as dos arquivos .rules comuns, e a decisão mais restritiva continua prevalecendo.

Diferentemente dos arquivos .rules, as regras de requisitos precisam especificar decision, cujo valor deve ser "prompt" ou "forbidden" (não "allow").

[rules]
prefix_rules = [
  { pattern = [{ token = "rm" }], decision = "forbidden", justification = "Use git clean -fd instead." },
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

Para restringir os servidores MCP que um cliente local pode habilitar, adicione uma lista de servidores aprovados em mcp_servers. Para servidores stdio, use command na correspondência. Para servidores HTTP com suporte a streaming, use url:

[mcp_servers.docs]
identity = { command = "codex-mcp" }

[mcp_servers.remote]
identity = { url = "https://example.com/mcp" }

Quando identity.command é uma string, a comparação considera apenas o command configurado. Ela não verifica args, cwd, env ou env_vars.

Para restringir uma invocação stdio completa, especifique a correspondência do executável e de cada argumento posicional:

[mcp_servers.internal.identity]
command = { executable = "/usr/local/bin/codex-mcp", args = [
  { match = "exact", value = "serve" },
  { match = "prefix", value = "--workspace=" },
] }

O executável, a quantidade de argumentos e a ordem dos argumentos devem corresponder. As regras para argumentos e URLs aceitam correspondência exact, prefix e regex sobre o valor inteiro. As regras estruturadas de comandos também não verificam cwd, env ou env_vars. Os servidores MCP incluídos em plugins usam os mesmos formatos de identidade em plugins.<plugin>.mcp_servers.<server>.

Se mcp_servers estiver presente, mas vazio, o cliente local desativará todos os servidores MCP.

Configure o acesso à rede

O acesso à rede por comandos e pelo aplicativo para desktop tem controles diferentes. Comece pelos Controles de uso da rede para o tráfego de comandos compatíveis, confira os limites do ambiente e da execução e, se necessário, use os requisitos específicos do aplicativo para desktop. As regras de sites do navegador estão em Controle o Navegador e o Uso do computador.

Use o proxy do sistema para solicitações do cliente nativo

A configuração experimental features.respect_system_proxy permite que o ambiente de execução nativo do Codex, usado pelo ChatGPT para desktop e pelo Codex, utilize as configurações de proxy do sistema operacional nas próprias solicitações de rede. Habilite-a em dispositivos que precisam de um proxy do sistema ou de configuração automática de proxy (PAC). O valor padrão é false.

Adicione o seguinte a uma fonte compatível de padrões de config.toml ou a managed_config.toml:

[features]
respect_system_proxy = true

A configuração local do projeto não pode habilitar essa opção. Para MDM do macOS, inclua o mesmo TOML em config_toml_base64. Reinicie o cliente depois de alterar a configuração local. Para desativar a opção, defina-a como false na fonte de configuração que a habilitou.

Login e padrões da nuvem

O recurso independente system_proxy_fallback vem habilitado por padrão. Após uma falha de conexão, ele pode repetir pelo proxy do sistema as solicitações compatíveis de login e configuração da nuvem, mesmo quando respect_system_proxy é false. Essa alternativa pode permitir que clientes compatíveis façam login e busquem padrões da nuvem sem ativação local. Desativar apenas respect_system_proxy não desativa essa alternativa.

Se o acesso direto não funcionar e a alternativa estiver indisponível, desativada ou falhar, implante respect_system_proxy localmente antes do login.

Escopo e limitações

Valide o login e uma solicitação autenticada com as versões de cliente e nas redes que pretende usar. Considere os seguintes limites:

• Escopo das solicitações: a configuração se aplica aos clientes de rede do ambiente de execução do Codex. Ela não configura todas as solicitações do ChatGPT para desktop ou do navegador, nem todos os processos de plugins ou comandos do shell. Ela não impõe uma lista de destinos permitidos nem garante o bloqueio de conexões diretas. Para saber qual tráfego é compatível, consulte os requisitos de rede dos comandos e os requisitos de rede do aplicativo para desktop.
• Suporte por plataforma: o macOS e o Windows oferecem descoberta nativa do proxy do sistema. Quando o sistema não consegue resolver o proxy, o ambiente de execução usa as configurações explícitas de proxy do ambiente, se disponíveis. Caso contrário, conecta-se diretamente. Outras plataformas usam essa mesma alternativa de configuração do ambiente ou conexão direta em vez da descoberta nativa.
• Roteamento por PAC: o ambiente de execução seleciona uma rota no resultado do PAC. Se a conexão falhar, ele não tenta as entradas de proxy ou DIRECT seguintes no resultado.
• Autenticação no Windows: versões compatíveis podem responder a um desafio HTTP 407 do proxy durante o estabelecimento do túnel usando as credenciais do usuário conectado ao Windows com Negotiate ou NTLM. Não há suporte a proxies HTTPS que exigem tokens de autenticação vinculados à conexão TLS do proxy.

Configure os requisitos de acesso à rede

Use Requisitos > Controles de uso da rede para gerenciar o acesso à rede dos comandos compatíveis em Segurança do agente. Configure uma base compartilhada em Global ou use uma aba disponível de Ambientes locais ou Ambientes do Codex Cloud para as configurações de execução específicas do ambiente.

1. Defina Rede gerenciada como Ativada para aplicar regras de domínio ao tráfego gerenciado de comandos. Apenas adicionar regras de domínio não ativa o proxy gerenciado.
2. Em Regras de rede, selecione Adicionar regra de rede. Insira um Domínio, como api.openai.com ou **.example.com, sem esquema de URL ou caminho. Escolha Permitir ou Negar em Acesso e selecione Salvar regra para atualizar o rascunho. Repita para outros destinos.
3. Defina Permitir apenas domínios adicionados por administradores como Ativado se as configurações dos usuários e as aprovações por domínio não puderem ampliar a lista gerenciada de permissões. Inclua as entradas de permissão necessárias. Uma lista que contém apenas bloqueios não permite outros destinos.
4. Confira Permitir acesso à rede local para fluxos de trabalho que precisam de serviços em escuta local ou destinos privados. Conexões locais diretas podem contornar as regras de domínio do proxy. Antes de alterar essa configuração, confira abaixo os limites de conectividade do Codex Cloud.
5. Confira as regras herdadas e as mensagens de validação. Em seguida, selecione Salvar alterações. Em cada ambiente de execução afetado, teste uma solicitação que deve funcionar e outra que deve ser bloqueada.

Definir Rede gerenciada como Desativada remove as regras de rede definidas naquele escopo e armazena um valor explícito de desativação. Isso não desativa o acesso à internet. Não definido remove as configurações de rede definidas no escopo para que possam valer a política aplicável ou os padrões do ambiente de execução. Ao remover configurações de ambiente, as regras herdadas de Global podem voltar a valer. Use Editar como TOML para campos de rede avançados ou listas legadas de domínios existentes que o editor visual não consegue representar.

No Codex 0.166.0, [network_proxy] é a tabela canônica de requirements.toml para gerenciar o acesso dos comandos à rede. O Codex também aceita o nome anterior, [experimental_network]. Use um único nome de tabela por camada. Se as camadas usarem nomes diferentes, o Codex aplicará a precedência normal dos requisitos.

Defina enabled = true na tabela gerenciada para iniciar o proxy independentemente da configuração features.network_proxy do usuário. A sandbox ativa também precisa permitir que os comandos acessem a rede. O exemplo usa o nome reconhecido pelos clientes e pelas camadas de validação de políticas de versões anteriores.

[experimental_network]
enabled = true
managed_allowed_domains_only = true

[experimental_network.domains]
"api.openai.com" = "allow"
"**.example.com" = "allow"
"blocked.example.com" = "deny"
"**.exfil.example.com" = "deny"

Use experimental_network.managed_allowed_domains_only = true somente quando também definir entradas "allow" administradas em [experimental_network.domains] e quiser que essas regras sejam exclusivas. Se o valor for true e não houver regras gerenciadas de permissão, as regras de permissão de domínio adicionadas pelos usuários deixarão de valer. Não combine o mapa canônico domains com as listas legadas allowed_domains ou denied_domains.

*.example.com corresponde apenas aos subdomínios. **.example.com corresponde ao domínio raiz e a seus subdomínios. Uma regra de bloqueio correspondente prevalece sobre uma regra de permissão.

A sintaxe dos domínios, as regras para destinos locais ou privados, a precedência dos bloqueios sobre as permissões e as limitações relativas a DNS rebinding seguem o comportamento da rede da sandbox descrito em Aprovações e segurança do agente.

O proxy roteia o tráfego dos comandos locais executados dentro da sandbox. Antes de acessar uma origem, as ferramentas do navegador também verificam os bloqueios de rede gerenciados e as listas exclusivas de permissões. Essa verificação de política é separada e não encaminha o tráfego do navegador pelo proxy dos comandos. O proxy não filtra a pesquisa na Web, os aplicativos e conectores, os servidores MCP, o tráfego de aplicativos nativos, as solicitações de serviço do Codex nem o tráfego específico de outros recursos. Use os controles correspondentes a cada recurso:

• Use allowed_web_search_modes para restringir a pesquisa na Web.
• Use features.apps = false para desativar integrações de aplicativos e conectores e features.plugins = false para desativar plugins onde houver suporte.
• Use a lista gerenciada de servidores aprovados em mcp_servers para restringir os servidores MCP.
• Use requisitos de recursos como browser_use, in_app_browser e computer_use para restringir os recursos de navegador e uso do computador.
• Para comandos gerenciados compatíveis do Codex Cloud, confira as configurações de internet do ambiente e as de Segurança do agente. O ambiente ainda pode bloquear um domínio permitido em Segurança do agente.

Teste separadamente os comandos comuns e, se a política permitir, a execução totalmente fora da sandbox. Quando aprovada, a execução totalmente fora da sandbox pode contornar o proxy gerenciado de comandos. Consulte Isolamento de rede.

Nenhum destino permitido na configuração efetiva: quando Rede gerenciada e Permitir apenas domínios adicionados por administradores estão ativados, os comandos gerenciados comuns precisam de uma regra de permissão explícita ou herdada. Antes de salvar, confira os destinos permitidos na configuração efetiva.

Conectividade local ou privada do Codex Cloud: se um comando na nuvem não conseguir acessar um domínio permitido, verifique o valor efetivo de allow_local_binding. Se o valor herdado for Desativado, ele poderá bloquear o acesso ao proxy upstream. Consulte Conectividade local ou privada do Codex Cloud para conhecer o valor padrão e as substituições específicas da nuvem.

Quando os requisitos do ambiente estão vazios, valem os requisitos de Global. Definir Rede gerenciada como Desativada é independente da configuração de acesso à internet do ambiente de nuvem. Consulte Controles de execução de Segurança do agente para saber mais sobre o escopo de execução.

Precedência das políticas de rede e limites de execução

Dentro de uma política, a ordem de prioridade, da maior para a menor, é: substituição de ambiente específica do sistema operacional → substituição de ambiente para todos os sistemas operacionais → Global. Uma política de maior prioridade prevalece sobre outra de menor prioridade, mesmo que a segunda seja mais específica. Alguns requisitos têm regras de combinação próprias de cada campo. O ambiente de execução impõe os requisitos resultantes. Considere os casos de rede específicos por campo a seguir separadamente da prioridade das políticas.

Os exemplos comparam configurações de ambiente e de Global dentro da mesma política, com a rede gerenciada já configurada e sem que uma política de maior prioridade altere os valores. Eles descrevem como cada campo é combinado e aplicado durante a execução.

Defina acessos diferentes a domínios por ambiente

Para a mesma regra de domínio dentro de uma política, uma substituição de ambiente definida pelo administrador pode permitir um domínio negado em Global ou negar um domínio permitido em Global. Sem uma substituição de ambiente, a regra de Global é herdada. Outras regras de bloqueio efetivas ou controles de acesso ainda podem bloquear uma solicitação.

Como as regras de domínio são combinadas

Esses resultados comparam a mesma chave de domínio em uma única política, sem que uma política de maior prioridade altere o resultado. O valor de maior prioridade substitui o valor da mesma chave. As outras chaves herdadas permanecem. Uma permissão não contorna outro bloqueio correspondente, como uma regra herdada com curinga. Um mapa de ambiente vazio não remove as regras herdadas.

Exemplo: negue packages.example.com em Global e permita-o em Desenvolvimento. Desenvolvimento poderá permitir o acesso nas condições acima. Produção herdará o bloqueio de Global, a menos que haja uma substituição.

Confirme que o executor implantado oferece suporte a essas regras de combinação. O suporte nos executores gerenciados comuns ainda precisa ser validado.

Limites do orquestrador. O ambiente de execução na nuvem não aceita portas gerenciadas de escuta HTTP/SOCKS nem proxies que escutem fora do loopback. O suporte a regras de socket depende da forma de execução. As configurações de execução local da tabela abaixo não são configurações compatíveis do orquestrador.

Outros limites de rede durante a execução

Todos os campos abaixo pertencem à tabela gerenciada network_proxy (também aceita com o nome experimental_network) em requirements.toml. As setas indicam um valor de Global seguido de um valor do ambiente na mesma política. Esses casos de execução local não comprovam que o orquestrador aceita as mesmas configurações.

A ativação e a exclusividade do proxy, o comportamento do proxy upstream e as regras de sockets Unix dependem do executor. Não generalize a combinação das chaves de domínio para essas configurações. Verifique os valores efetivos e teste o ambiente de execução implantado. Para conectividade local ou privada no Codex Cloud, consulte Configure os requisitos de acesso à rede.

Verifique o comportamento antes da implantação

Teste os destinos, serviços em escuta local, comportamento do proxy e caminhos de sockets usados nos seus fluxos de trabalho. Em cada ambiente afetado, verifique uma ação que deve funcionar e outra que deve ser bloqueada. Confira se a versão implantada do ambiente de execução aceita cada configuração usada.

Controle os destinos de rede do aplicativo para desktop

Use Editar como TOML em Segurança do agente para configurar em Global esses requisitos específicos de desktop. A interface de Controles de uso da rede gerencia a rede dos comandos, que tem uma política separada.

Use [application.network] em requirements.toml para restringir os destinos de rede do aplicativo para desktop. Com enabled = true, as solicitações externas devem usar HTTPS ou WSS e corresponder a um domínio exato com valor "allow" em [application.network.domains]. Os subdomínios não são permitidos implicitamente. Um mapa de domínios vazio não permite nenhum destino externo. Consulte a referência de configuração para ver as chaves compatíveis.

Essa política é independente da rede dos comandos e das regras de origem do navegador. Ela não restringe os destinos de módulos nativos ou processos iniciados pelo aplicativo nem rege a execução no Work Cloud.

Configure plugins e hooks gerenciados

Para essas tarefas, use Editar como TOML em Segurança do agente ou uma fonte de configuração local compatível. Os padrões de marketplace, as restrições obrigatórias de plugins e os hooks gerenciados têm finalidades diferentes. Escolha a tarefa correspondente à política de que precisa.

Configure marketplaces e padrões de plugins

Use Segurança do agente > Editar como TOML para definir marketplaces locais ou Git e padrões de plugins no documento config.toml de Global. Você também pode distribuir essas configurações no config.toml do sistema. Elas fornecem a configuração inicial dos marketplaces e plugins, sem impor uma política. Para limitar as fontes que os membros podem usar, configure os requisitos de fontes de marketplace.

Consulte a referência de configuração para ver as chaves, a precedência de configuração para entender as substituições e as configurações de plugins do repositório para configurar no nível do projeto. A importação e sincronização com o GitHub no espaço de trabalho são independentes.

Controle a disponibilidade de plugins

Use Editar como TOML em Segurança do agente para impor configurações de recursos de plugins no requirements.toml de Global ou distribua essas configurações por meio de requisitos locais nos clientes gerenciados por dispositivo. Padrões > Apps e ferramentas > Apps/conectores define padrões para ferramentas de aplicativos. A configuração obrigatória features.plugins é separada. Para permissões de plugins no espaço de trabalho, consulte Apps e conectores.

Para desativar os plugins em clientes locais compatíveis, defina features.plugins como false em requirements.toml:

features.plugins = false

Essa configuração também se aplica quando os usuários entram no Codex com uma chave de API. Consulte a referência de features.plugins para ver a configuração compatível.

Restrinja as fontes de marketplaces de plugins

Use Editar como TOML para configurar os requisitos de fontes de marketplace no requirements.toml de Global ou distribua-os por meio dos requisitos locais. Essas regras limitam quais fontes locais ou Git os usuários podem adicionar e usar. Elas são independentes dos padrões de marketplace.

Para restringir as fontes de marketplaces de plugins, defina restrict_to_allowed_sources = true e especifique uma ou mais regras de origem:

[marketplaces]
restrict_to_allowed_sources = true

[marketplaces.allowed_sources.company_plugins]
source = "git"
url = "https://github.com/example/company-plugins.git"
ref = "main"

[marketplaces.allowed_sources.internal_git]
source = "host_pattern"
host_pattern = '^git\.example\.com$'

[marketplaces.allowed_sources.local_plugins]
source = "local"
path = "/opt/company/codex-plugins"

As regras de Git verificam a URL normalizada do repositório e, quando presente, exigem correspondência exata de ref. Os padrões de host são expressões regulares comparadas ao host Git em minúsculas. Use ^ e $ para corresponder ao nome de host inteiro. As regras locais exigem um caminho absoluto e normalizado. Consulte a referência de requirements.toml para ver o schema completo e entender como as regras são combinadas.

Esses requisitos rejeitam operações de adição de marketplaces, instalação de plugins e atualização de marketplaces Git configurados que não correspondam às regras. Também filtram os marketplaces configurados e seus plugins durante a execução.

Os marketplaces Git com curadoria da OpenAI, inclusive o catálogo para chaves de API, também precisam corresponder à lista de fontes permitidas. Para permiti-los, inclua a seguinte fonte Git sem restrição de ref:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Para excluir os catálogos com curadoria, omita essa fonte e confirme que nenhuma regra de host mais abrangente a permite. Os plugins incluídos no produto e os plugins do espaço de trabalho instalados remotamente são independentes dessa política de fontes Git com curadoria.

Essas restrições de fontes só se aplicam onde o cliente local oferece suporte a operações de marketplace de plugins: no ChatGPT e no Codex no aplicativo para desktop e na CLI do Codex. Elas não controlam o uso de plugins no ChatGPT na Web ou em dispositivos móveis nem adicionam plugins à extensão de IDE.

Imponha hooks gerenciados por meio dos requisitos

Em Segurança do agente, abra Global > Requisitos > Editar como TOML. Para o modo Work com acesso ao computador local e para os dots, configure os manipuladores mcp_tool compatíveis no requirements.toml de Global. Antes da implantação, teste a conexão do callback e verifique o que acontece quando ele excede o tempo limite. Consulte Hooks com orquestração na nuvem para conhecer os eventos compatíveis e o comportamento em caso de falha.

Para o Codex local, distribua os scripts dos hooks pela ferramenta de gerenciamento de dispositivos. Para exigir a execução desses hooks mesmo que um usuário desative os hooks, fixe [features].hooks = true em requirements.toml. Consulte o exemplo de configuração de hooks gerenciados para ver os caminhos dos scripts e saber como permitir apenas hooks gerenciados.

Entenda o escopo e a precedência das políticas

Use esta seção para verificar onde uma política se aplica, como os requisitos são combinados, como os clientes recebem configurações gerenciadas na nuvem e como verificar o resultado.

Para o modo Work com acesso local e os dots, a política compatível de Global rege o orquestrador compartilhado da nuvem quando a política gerenciada está habilitada. Os requisitos de execução local aplicáveis regem o computador conectado. Os contêineres do modo Work na nuvem mantêm as políticas existentes do Work Cloud, e os controles de dispositivo compatíveis continuam se aplicando à execução local. O Codex mantém seu comportamento de configuração atual. A configuração gerenciada não concede uma licença de membro no espaço de trabalho nem acesso a recursos. Use Funções e permissões do espaço de trabalho para esses controles.

Segurança do agente e acesso ao computador local com o Work Cloud

Use Segurança do agente no Console de administração para gerenciar políticas e configurações. Essa área substitui Políticas e configuração. Segurança do agente está disponível no Console de administração independentemente do acesso ao computador local com o Work Cloud. As políticas existentes, suas atribuições e sua ordem são preservadas. Confira suas políticas existentes em Segurança do agente. O acesso ao computador local com o Work Cloud exige ativação separada. Consulte Segurança do agente para orientações sobre migração.

Antes de migrar a automação de políticas para Segurança do agente:

1. Identifique as integrações afetadas. Faça um inventário das configurações do Terraform e dos scripts que atualizam políticas e registre quais políticas eles gerenciam.

2. Use a API de políticas para gerenciar as configurações de Global. Para gerenciar as configurações de Local ou do Codex Cloud, use a interface de Segurança do agente. Os fluxos de trabalho existentes da API para Global continuam disponíveis após a migração. Teste os scripts e as integrações com o Terraform e confirme que as atribuições e a ordem das políticas foram preservadas.

3. Faça os ajustes necessários e teste a automação. Verifique se uma atualização chega à política correta de Segurança do agente e se os controles resultantes são aplicados.

A migração de políticas não concede ao modo Work nem aos dots acesso ao computador local. Recomenda-se conferir ou criar políticas antes da implantação, mas o fluxo de confirmação não exige a criação de uma política para habilitar o acesso. Antes de habilitar Permitir acesso ao computador local, confira a configuração de base migrada ou crie uma base na nuvem se hoje você distribui as políticas somente por MDM. Se enforce_residency estiver habilitado em qualquer política da nuvem, Permitir acesso ao computador local ficará desativado tanto para o modo Work quanto para os dots. Essa proteção não configura a residência de dados do espaço de trabalho nem desativa, por si só, o Work Cloud ou os dots.

As substituições de ambiente permitem variar as configurações compatíveis dentro de uma política. Em cada política, a ordem de prioridade, da maior para a menor, é: substituição de ambiente específica do sistema operacional → substituição de ambiente para todos os sistemas operacionais → Global. Uma política de maior prioridade prevalece sobre outra de menor prioridade, mesmo que a segunda seja mais específica. Alguns requisitos têm regras de combinação próprias de cada campo. Confirme quais editores e campos de substituição estão disponíveis no seu espaço de trabalho.

Antes de habilitar o acesso local para um fluxo de trabalho que usa hooks, verifique quais hooks são executados com orquestração na nuvem.

Locais e precedência

Na execução local, os requisitos são aplicados na seguinte ordem, da menor para a maior prioridade. Essa ordem também se aplica às etapas locais do acesso ao computador local com o Work Cloud:

1. requirements.toml do sistema (/etc/codex/requirements.toml em sistemas Unix, inclusive Linux e macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml no Windows).
2. Requisitos de Segurança do agente distribuídos no pacote de configuração da nuvem.
3. Campos legados de managed_config.toml que o cliente local reinterpreta como requisitos.
4. Preferências gerenciadas do macOS (MDM) distribuídas por com.openai.codex:requirements_toml_base64.

As camadas de maior precedência substituem valores escalares e listas comuns das camadas inferiores. As tabelas são combinadas por chave, enquanto requisitos como regras, hooks e restrições do sistema de arquivos seguem regras de combinação específicas por campo. Consulte a referência de requirements.toml para ver o schema atual. Não presuma que todos os campos são combinados da mesma forma.

Para manter a compatibilidade com versões anteriores, os clientes locais compatíveis reinterpretam os campos legados approval_policy, approvals_reviewer e sandbox_mode como requisitos. Essa conversão adiciona opções de compatibilidade quando necessário. Use requirements.toml para definir listas de permissões explícitas.

Precedência no acesso ao computador local com o Work Cloud

Para o modo Work com acesso local e os dots, diferencie a política do orquestrador em Global da política de execução. Os requisitos locais aplicáveis regem o computador conectado. Os contêineres do modo Work na nuvem e os computadores dos dots na nuvem usam suas próprias configurações e requisitos de execução, em vez do pacote de ambiente gerenciado usado por outros executores.

Na execução local, os requisitos de MDM e os requisitos legados de dispositivos gerenciados têm precedência sobre Segurança do agente. O arquivo de requisitos do sistema do dispositivo tem prioridade inferior à de Segurança do agente. Dentro de cada política, resolva primeiro as substituições de ambiente específicas do sistema operacional, depois as substituições para todos os sistemas operacionais e, por fim, Global. Entre políticas, a prioridade prevalece sobre a especificidade.

Os requisitos impõem restrições, enquanto os padrões de configuração fornecem valores iniciais. Para o modo Work com acesso local e os dots, a política compatível de Global se aplica por meio do orquestrador compartilhado da nuvem quando a política gerenciada está habilitada. Os requisitos locais aplicáveis de requirements.toml regem a execução em um computador conectado. Os contêineres do modo Work na nuvem e os computadores dos dots na nuvem usam suas próprias configurações e requisitos de execução, em vez do pacote de ambiente gerenciado usado por outros tipos de executor. As restrições de execução local não se aplicam automaticamente a esses computadores na nuvem. Confira as permissões dos recursos da nuvem e teste separadamente a execução local e na nuvem.

Mantenha em Global os controles do orquestrador, inclusive aprovações e pesquisa na Web. Use os controles específicos Políticas de aprovação permitidas e Modos de pesquisa na Web permitidos, quando disponíveis, e TOML para os outros campos compatíveis. Consulte a referência de configuração para ver a lista de campos e o escopo de execução.

Requisitos gerenciados na nuvem

Quando um usuário entra com o ChatGPT em um plano compatível, os clientes locais compatíveis podem receber requisitos impostos pelo administrador e associados ao espaço de trabalho. Esse é um canal de distribuição de políticas compatíveis com requirements.toml. Ele não concede acesso ao espaço de trabalho nem substitui o controle de acesso baseado em funções (RBAC) do espaço de trabalho. Os requisitos de autenticação precisam ser gerenciados localmente.

Configure os requisitos comuns com os controles de Segurança do agente. Para uma política que permita apenas aprovações mediante solicitação e sandboxes somente leitura ou com gravação no espaço de trabalho, use Políticas de aprovação e Modos de sandbox em Limites da política. Para também solicitar aprovação antes da execução de um ponto de entrada de shell compatível, use Editar como TOML e adicione a tabela [rules] ao requirements.toml de Global.

O TOML equivalente completo é:

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["bash", "sh", "zsh"] }], decision = "prompt", justification = "Require explicit approval for shell entry points" },
]

Confira se todas as versões de clientes gerenciados aceitam as chaves selecionadas. Atribua a política aos usuários ou grupos pretendidos e verifique se ela entra em vigor nos clientes compatíveis dessas pessoas. Consulte a referência de configuração para ver o schema atual e a interface de administração para conferir como as atribuições funcionam atualmente.

O serviço seleciona as camadas de requisitos gerenciados pela empresa que se aplicam à identidade autenticada. O cliente local avalia essas camadas em conjunto com as outras fontes de requisitos descritas em Locais e precedência. Use a interface de administração atual para criar e atribuir políticas no espaço de trabalho. Não dependa de uma cópia do algoritmo de correspondência de grupos. O serviço de administração controla esse comportamento e pode alterá-lo independentemente do formato dos requisitos locais.

Para ver chaves compatíveis e exemplos, consulte o exemplo de requirements.toml e a referência de requirements.toml.

Como os clientes locais aplicam os requisitos gerenciados na nuvem

O comportamento de carregamento local e cache descrito abaixo vale para os clientes locais compatíveis. Ele não determina quando uma alteração de política na nuvem entra em vigor em uma tarefa já em execução que usa acesso ao computador local com o Work Cloud. Verifique a política efetiva antes de contar com uma restrição alterada.

Quando um usuário inicia um cliente local compatível e entra com o ChatGPT em um plano compatível, o cliente primeiro verifica se há uma entrada de cache válida que corresponda à identidade autenticada. Se não houver, o cliente busca o pacote aplicável, repete a tentativa se necessário e, em caso de sucesso, grava uma entrada de cache assinada. Se a solicitação falhar ou exceder o tempo limite e não houver cache válido, o carregamento do pacote de configuração da nuvem retornará um erro em vez de permitir que o cliente inicie silenciosamente sem a camada de requisitos gerenciados na nuvem.

Depois de resolver o cache, o cliente combina os requisitos da nuvem com as outras camadas de requisitos descritas acima. Uma atualização em segundo plano atualiza o pacote em cache e o disponibiliza para os próximos carregamentos de configuração. Isso não garante que uma tarefa já em execução passe a usar imediatamente uma política alterada. Algumas configurações de desktop exigem a reinicialização do aplicativo. Siga as solicitações de reinicialização e verifique as configurações efetivas antes de contar com a alteração.

Confirme a experiência de administradores e funcionários

Designe um responsável por cada política gerenciada, registre quais usuários ou grupos devem recebê-la e documente a justificativa de negócio para cada restrição de sistema de arquivos, rede, aprovação ou perfil de permissão.

Teste um fluxo de trabalho permitido e outro bloqueado com um usuário que tenha as permissões pretendidas. Confira as configurações efetivas no cliente compatível. Por si só, uma função ou um grupo do espaço de trabalho não impõe restrições ao ambiente de execução local.

Use Testar políticas em Segurança do agente para conferir quais políticas correspondem ao membro, grupo ou função selecionado. Em uma sessão de edição, o teste verifica o rascunho atual sem salvá-lo. O resultado mostra quais políticas foram selecionadas. Ele não mostra a configuração final combinada nem se o cliente impõe uma restrição. Depois de salvar, teste os fluxos de trabalho permitidos e bloqueados em cada cliente e forma de execução relevante.

Implante configurações gerenciadas por dispositivo

Use os requisitos locais do sistema ou o MDM para restrições de autenticação e políticas gerenciadas por dispositivo. Na inicialização, o mecanismo legado managed_config.toml segue uma precedência diferente da de Padrões em Segurança do agente. O fluxo de trabalho de MDM abrange tanto requisitos quanto padrões legados.

Gerencie a autenticação localmente

Defina allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store e chatgpt_base_url no requirements.toml local do sistema ou nos requisitos de MDM do macOS. O Codex ignora esses quatro campos nos requisitos gerenciados na nuvem. Os requisitos locais de autenticação são aplicados antes do carregamento das credenciais e antes que o Codex busque a política da nuvem.

Para exigir login com o ChatGPT em um espaço de trabalho aprovado e armazenar credenciais no repositório de credenciais do sistema operacional, use:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods aceita chatgpt, api ou ambos. Se omitida, essa configuração não restringe os métodos de login. Se definida, a lista deve conter pelo menos um método. api permite autenticação por API, inclusive pelo Amazon Bedrock. A restrição de espaço de trabalho também se aplica aos tokens de acesso do Codex.

Os valores de forced_login_method e forced_chatgpt_workspace_id configurados pelo usuário devem atender aos requisitos. Quando o usuário seleciona um espaço de trabalho, esse espaço também precisa constar na lista gerenciada de espaços permitidos. Se nenhum espaço de trabalho corresponder, o login com o ChatGPT ficará indisponível. A autenticação por API continuará disponível quando permitida. Se não houver nenhum método de login disponível, o Codex se recusará a iniciar.

Consulte a referência de requisitos para ver os modos de armazenamento de credenciais e a configuração da URL do serviço.

Imponha as configurações do OpenTelemetry

Na CLI do Codex 0.166.0, use [otel] em requirements.toml para configurar separadamente os exportadores de logs, traces e métricas, identificar o ambiente e controlar o conteúdo que o Codex exporta. Este exemplo envia logs a um coletor OTLP/HTTP e limita a 256 bytes em UTF-8 o texto registrado para cada resultado de ferramenta. Ele omite o texto do prompt, o texto da resposta final e as avaliações de aprovação automática.

A versão 26.1027.30824 do aplicativo para macOS inclui a CLI 0.166.0-alpha.5.1. Essa versão da CLI não aceita [otel] em requirements.toml e, por isso, não consegue impor log_user_prompt = false por meio dessa política.

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false
log_agent_responses = false
log_guardian_assessments = false
tool_result = { max_bytes = 256 }
span_attributes = { team = "platform" }
tracestate = { acme = { region = "eu" } }

Os valores gerenciados prevalecem sobre a configuração local. Para exporter, trace_exporter e metrics_exporter, o requisito de maior prioridade que configura cada exportador fornece toda a sua definição, inclusive os cabeçalhos e as configurações de TLS. Para cada configuração escalar e para a tabela tool_result, também prevalece o valor fornecido pelo requisito de maior prioridade que o define. As configurações omitidas continuam configuráveis, a menos que outra camada de requisitos as defina.

Os atributos de span são combinados pelo nome do atributo. Os campos de tracestate são combinados por membro e nome de campo. Para entradas correspondentes, prevalece o valor de maior prioridade. As demais entradas continuam disponíveis, mesmo que uma camada forneça uma tabela de metadados vazia. Consulte Observabilidade e telemetria para conhecer as opções dos exportadores e o conteúdo dos logs.

Migre bancos de dados SQLite em NFS

No Linux, o Codex cria novos bancos de dados SQLite em NFS com o modo de journal DELETE. Para migrar bancos de dados existentes que usam write-ahead logging (WAL), defina unsafe_enforce_sqlite_journal_mode = true no nível superior de requirements.toml. Essa configuração vem desativada por padrão. Quando ela está habilitada, o Codex migra os bancos de dados antes de abri-los para gravação.

A montagem NFS precisa oferecer suporte a bloqueios POSIX entre hosts. Opções de montagem como nolock e local_lock=all impedem que esses bloqueios funcionem. Em todos os hosts, encerre todos os clientes SQLite que usam esses bancos de dados, inclusive o Codex. Inicie uma única instância do Codex e mantenha todos os outros clientes parados até que a migração seja concluída com sucesso. O usuário que executa essa instância precisa ter permissão de gravação no diretório dos bancos de dados e no arquivo de bloqueio da migração. Os arquivos substitutos preservam os bits de permissão Unix dos originais e passam a pertencer a esse usuário. A migração não copia o proprietário, o grupo nem as listas de controle de acesso estendidas dos arquivos originais. O Codex mantém os originais em um diretório privado de backup.

Padrões gerenciados (managed_config.toml)

Use os padrões de Segurança do agente para os valores iniciais compatíveis gerenciados na nuvem. Esta seção descreve o mecanismo legado managed_config.toml, gerenciado por dispositivo, e sua precedência diferente na inicialização. Editar Padrões em Segurança do agente não implanta um arquivo managed_config.toml nos dispositivos dos membros.

Os padrões gerenciados definem a configuração inicial de um cliente local compatível. Na inicialização, eles substituem o config.toml local do usuário e quaisquer substituições --config da CLI. Os usuários ainda podem alterar essas configurações durante a execução atual, e os padrões voltam a valer na próxima inicialização do cliente.

O GPT-5.5 deixa de estar disponível no Codex com login pelo ChatGPT em 14 de outubro de 2026, ao meio-dia PDT (19h UTC). Se um padrão gerenciado, perfil de MDM do macOS ou configuração salva fixar gpt-5.5 para esses usuários, substitua-o por um modelo disponível. Escolha gpt-6.1-sol assim que um administrador o habilitar para os usuários afetados. A API da OpenAI e as sessões do Codex autenticadas com uma chave de API não são afetadas. Consulte a disponibilidade de modelos no espaço de trabalho.

Para configurações que ainda fixam gpt-5.4 ou gpt-5.4-mini, siga as orientações de migração do GPT-5.4.

Confirme que os padrões gerenciados atendem aos requisitos. O ambiente de execução local rejeita valores não permitidos.

Precedência e camadas

O ambiente de execução local monta a configuração efetiva na seguinte ordem, com as camadas de cima prevalecendo sobre as de baixo:

• Preferências gerenciadas (MDM do macOS, maior precedência)
• managed_config.toml (arquivo do sistema ou gerenciado)
• config.toml (configuração de base do usuário)

As substituições --config key=value da CLI se aplicam à base, mas as camadas gerenciadas prevalecem sobre elas. Assim, cada execução começa com os padrões gerenciados mesmo que você forneça flags locais.

O config.toml da nuvem usa a precedência normal de configuração, diferente da ordem legada acima. O requirements.toml da nuvem usa a precedência dos requisitos.

Locais

• Linux/macOS (Unix): /etc/codex/managed_config.toml
• Windows/sistemas que não são Unix: ~/.codex/managed_config.toml

Se o arquivo não existir, o ambiente de execução local ignorará a camada gerenciada.

Exemplo de managed_config.toml

# Set conservative defaults
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

[sandbox_workspace_write]
network_access = false             # keep network disabled unless explicitly allowed

[otel]
environment = "prod"
exporter = { otlp-http = { endpoint = "https://otel.example.com/v1/logs", protocol = "binary" } }
log_user_prompt = false            # keep prompts redacted

Limites recomendados

• Prefira workspace-write com aprovações para a maioria dos usuários. Reserve o acesso completo para contêineres controlados.
• Mantenha network_access = false, a menos que sua revisão de segurança permita o acesso a um coletor ou a domínios necessários aos fluxos de trabalho.
• Para impor as configurações de telemetria, use os requisitos do OpenTelemetry. Mantenha log_user_prompt = false, a menos que sua política permita armazenar o conteúdo dos prompts.
• Audite periodicamente as diferenças entre o config.toml local e a política gerenciada para detectar divergências. As camadas gerenciadas devem prevalecer sobre as flags e os arquivos locais.

Preferências gerenciadas do macOS (MDM)

No macOS, os administradores podem distribuir um perfil de dispositivo que forneça payloads TOML codificados em base64 usando:

• Domínio de preferências: com.openai.codex
• Chaves:
  • config_toml_base64 (padrões gerenciados)
  • requirements_toml_base64 (requisitos)

O ambiente de execução local interpreta esses payloads de “preferências gerenciadas” como TOML. Para padrões gerenciados (config_toml_base64), as preferências gerenciadas têm a maior precedência. Para requisitos (requirements_toml_base64), a precedência segue a ordem dos requisitos. A mesma tabela [features] dos requisitos funciona em requirements_toml_base64. Use as chaves canônicas de recursos ali também.

Fluxo de configuração do MDM

O ambiente de execução local respeita os payloads padrão de MDM do macOS, então você pode distribuir as configurações com ferramentas como Jamf Pro, Fleet ou Kandji. Para uma implantação simples:

1. Crie o payload TOML gerenciado e codifique-o com base64, sem quebras de linha.
2. Insira a string no perfil de MDM, no domínio com.openai.codex, na chave config_toml_base64 (padrões gerenciados) ou requirements_toml_base64 (requisitos).
3. Distribua o perfil e peça aos usuários que reiniciem o cliente local compatível e confirmem que o resumo da configuração na inicialização mostra os valores gerenciados.
4. Ao revogar ou alterar a política, atualize o payload gerenciado. O cliente lerá a preferência atualizada na próxima inicialização.

Evite incluir segredos ou valores dinâmicos que mudam com frequência no payload. Submeta o TOML gerenciado ao mesmo controle de alterações usado para as demais configurações de MDM.