Configuração gerida

A configuração gerida permite aos administradores empresariais definir requisitos e predefinições suportados para o ChatGPT Work e o Codex. Os requisitos limitam o que os utilizadores e as tarefas podem fazer. As predefinições fornecem valores iniciais. O suporte depende do produto, da versão do cliente e do ambiente de execução.

Comece em Segurança de agentes na Consola de administração para aceder às definições suportadas geridas na nuvem. Utilize os controlos de definições para tarefas comuns ou selecione Editar como TOML para inspecionar, copiar ou editar o texto da configuração. Ambas as vistas editam a mesma política; o TOML também disponibiliza campos suportados sem um controlo dedicado. Não é necessário distribuir um ficheiro local para utilizar definições geridas na nuvem. As restrições de autenticação e as implementações geridas por dispositivos têm uma configuração local separada.

Os administradores Enterprise podem controlar o comportamento suportado dos clientes locais com:

• Requisitos: restrições impostas pelos administradores que os utilizadores não podem substituir.

• Predefinições de configuração: definições de config.toml geridas pelo sistema ou na nuvem que os utilizadores podem substituir.

• Predefinições geridas legadas: valores iniciais de managed_config.toml aplicados quando um cliente suportado é iniciado. Os utilizadores continuam a poder alterar as definições durante uma execução. O cliente volta a aplicar estas predefinições da próxima vez que for iniciado.

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

Configurar uma política em Segurança de agentes

Quando a Segurança de agentes está ativada, os proprietários e administradores do espaço de trabalho e os membros com permissões de administração do Codex podem gerir políticas. O acesso ao editor de políticas não concede aos membros acesso às funcionalidades que uma política controla.

Utilize Predefinição do espaço de trabalho como base do espaço de trabalho. Utilize Substituições quando utilizadores, grupos ou funções específicos precisarem de definições diferentes. Uma substituição por público-alvo determina quem recebe uma política; uma definição de ambiente determina onde se aplicam os controlos de execução suportados.

1. Abra Consola de administração > Segurança de agentes e selecione Predefinição do espaço de trabalho ou a política que pretende editar em Substituições.
2. Abra Requisitos para definir limites obrigatórios ou Predefinições para definir valores iniciais que os membros podem alterar dentro desses limites.
3. Mantenha as definições de aprovação, pesquisa na Web e outras definições gerais do agente em Global. Quando disponível, utilize Adicionar definições de ambiente no cartão relevante para adicionar Ambientes locais ou Ambientes Codex Cloud para as definições de execução suportadas. Um documento de ambiente vazio herda as definições de Global; não copia nem fixa a base atual.
4. Utilize os controlos descritos neste guia. Para campos avançados, selecione Editar como TOML e edite o ficheiro requirements.toml ou config.toml do âmbito adequado. Selecione Utilizar controlos de definições para regressar ao editor visual.
5. Reveja as mensagens de validação e selecione Guardar alterações. Aplicar uma regra num editor de regras atualiza o rascunho; esta ação, por si só, não guarda a política.
6. Verifique a seleção da política e o comportamento dos clientes suportados conforme descrito em Confirmar a experiência dos administradores e dos colaboradores.

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

Copiar ou reutilizar 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 definições noutra política. Selecione Utilizar controlos de definições para regressar ao editor visual.

1. Abra a política de origem e selecione Editar como TOML.
2. Escolha o âmbito que pretende copiar: Global ou um separador de ambiente disponível. Copie o texto de Requisitos (requirements.toml), Predefinições (config.toml) ou de ambos, consoante o que pretende reutilizar.
3. Abra a política de destino, selecione Editar como TOML e escolha o âmbito correspondente. Cole os requisitos em requirements.toml e as predefinições em config.toml. Reveja as definições existentes no destino antes de substituir o texto; mantenha as definições não relacionadas que devam continuar a aplicar-se.
4. Reveja as mensagens de validação e os destinatários e a prioridade da política de destino, e selecione Guardar alterações. Confirme o comportamento resultante do cliente antes de confiar na política copiada.

O texto copiado contém as definições criadas para essa política e esse âmbito. Não inclui atribuições, a ordem das políticas, outros documentos de ambiente nem a configuração efetiva combinada a partir de outras políticas e definições de dispositivos. Copie as definições de ambiente separadamente quando necessário. Alternar entre vistas ou copiar texto não guarda uma alteração à política.

Experimente o exemplo abaixo: altere uma definição e selecione Editar como TOML para ver a respetiva configuração. Regresse com Utilizar controlos de definições para continuar a experimentar.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Escolher o controlo adequado

Controlar o navegador e o Computer Use

Utilize Segurança de agentes na Consola de administração para gerir o acesso ao navegador e a aplicações nativas nos clientes de ambiente de trabalho suportados. Comece pelos controlos da interface. Os exemplos de TOML abaixo fornecem uma referência de configuração para a distribuição de políticas através de ficheiros e para definições que exigem o editor TOML.

O Browser Use controla a atividade realizada pelo agente num navegador. O Computer Use controla a atividade realizada pelo agente em aplicações nativas de ambiente de trabalho. As definições do painel do navegador integrado são independentes do Browser Use. Consulte sessões do navegador e sessões iniciadas existentes para conhecer as diferenças entre os percursos de utilização do navegador.

Antes de começar

Utilize uma conta com permissão para gerir políticas de Segurança de agentes. Confirme que pessoas recebem a política e que versões de cliente e sistemas operativos precisa de suportar. Consulte Segurança de agentes para obter informações sobre atribuições de políticas, definições de Global e substituições de ambiente suportadas.

Utilize Requisitos para definir limites que os utilizadores não podem substituir. As Predefinições estabelecem valores iniciais dentro desses limites. Permitir um site ou uma aplicação não instala um plugin, não concede permissões do sistema operativo, não inicia a sessão de um utilizador nem aprova uma ação que ainda exija revisão.

Em Disponibilidade de funcionalidades de ambiente de trabalho, reveja Utilização do navegador, Utilização de navegador externo e Utilização do computador. Forçar desativação desativa a funcionalidade correspondente; uma regra de permissão para um site ou aplicação não se sobrepõe a esta definição. Reveja Acesso CDP completo separadamente; Bloquear ativação pelo utilizador impede os utilizadores de o ativarem.

Estes controlos de ambiente de trabalho não configuram o navegador alojado do Work Cloud. Gira Utilização do navegador na nuvem e Acesso à rede na nuvem separadamente em Consola de administração > Permissões e funções > Capacidades do espaço de trabalho > Capacidades do computador na nuvem. Consulte como o Agent Security se aplica ao Work Cloud.

Configurar o acesso ao navegador

1. Abra Consola de administração > Agent Security. Utilize Predefinição do espaço de trabalho como configuração de base do espaço de trabalho ou abra a política relevante em Substituições. Em Requisitos, aceda a Controlos do navegador de ambiente de trabalho.
2. Em Regras de sites, abra as ações da linha Predefinição e escolha Editar predefinição. Para limitar o acesso aos sites aprovados, defina Acesso ao site como Bloquear e, em seguida, escolha Aplicar regra. A linha Predefinição fornece os valores que uma regra de site correspondente deixa em Utilizar regra predefinida.
3. Escolha Adicionar regra de site. Em Site ou padrão, introduza uma origem: um esquema, nome de anfitrião e porta opcional. Por exemplo, https://example.com é válido; https://example.com/files não é. Não inclua um caminho, uma consulta ou um fragmento. HTTP e HTTPS são origens diferentes. Especifique a porta quando esta diferir da porta predefinida do esquema.
4. Defina Acesso ao site e reveja Transferências, Carregamentos e Depuração/CDP. Escolha Permitir ou Bloquear, conforme adequado, ou deixe uma definição em Utilizar regra predefinida. 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íticas e aprovação.
5. Reveja Revisão automática, Permitir sempre e Duração da aprovação para o site. Duração da aprovação disponibiliza Este turno e Esta conversa. Reveja também Histórico do navegador, Guardar aprovações de sites e Aprovar pedidos automaticamente em Controlos do navegador de ambiente de trabalho.
6. Escolha Adicionar regra, reveja as mensagens de validação e selecione Guardar alterações. Teste um site permitido e um site bloqueado num cliente compatível que receba a política. Teste os carregamentos, as transferências e outras ações restritas separadamente.

Adicionar uma regra de site

A linha Predefinição aplica-se quando uma regra de site deixa uma permissão em Predefinição. Se as regras se sobrepuserem, Bloquear prevalece para cada permissão.

Site ou padrão 

Acesso ao siteUtilizar regra predefinida

TransferênciasUtilizar regra predefinida

CarregamentosUtilizar regra predefinida

Depuração/CDPUtilizar regra predefinida

Revisão automáticaUtilizar regra predefinida

Permitir sempreUtilizar regra predefinida

Duração da aprovaçãoUtilizar regra predefinida

Desativar a revisão automática das ações do navegador envia essas ações ao utilizador para aprovação. Não desativa a monitorização de segurança do modelo.

Quando vários padrões de origem correspondem, o valor mais restritivo prevalece para cada definição. A configuração local não pode atenuar uma proibição gerida. As proibições de rede geridas e as listas exclusivas de permissões também se aplicam às ferramentas do navegador. Consulte os campos da política do navegador para obter informações sobre padrões de origem e o comportamento de aprovação.

O Computer Use também pode operar um navegador como aplicação nativa. As regras de sites e capacidades do Browser Use não se aplicam a essa via. Reveja o acesso a aplicações nativas separadamente; consulte os limites de segurança do navegador.

Configurar o acesso a aplicações nativas

1. Em Requisitos, aceda a Controlos de aplicações de ambiente de trabalho > Regras de aplicações.
2. Utilize as ações da linha Predefinição para configurar o acesso de aplicações sem uma regra correspondente. Para limitar o Computer Use a aplicações aprovadas, bloqueie o acesso por predefinição e adicione regras de permissão para essas aplicações.
3. Escolha Adicionar regra de aplicação. Na caixa de diálogo Editar regra, selecione ID de pacote macOS, AUMID do Windows ou Executável do Windows em Aplicação. Introduza o Identificador da aplicação exato para um ID de pacote ou Application User Model ID (AUMID). Para Executável do Windows, introduza Nome do editor e Nome do produto; Nome do binário é opcional. Utilize informações verificadas sobre a identidade da aplicação, em vez de um nome a apresentar ou caminho de ficheiro.
4. Defina Acesso à aplicação para a regra e, em seguida, escolha Adicionar regra. Reveja Guardar aprovações de aplicações em Controlos de aplicações de ambiente de trabalho, reveja as mensagens de validação e selecione Guardar alterações. Desativar as aprovações guardadas continua a permitir aprovações para a sessão atual; permitir aprovações guardadas não aprova uma aplicação.
5. Teste uma aplicação permitida e uma aplicação bloqueada em cada sistema operativo suportado na sua implementação. Confirme que as permissões do sistema operativo continuam a aplicar-se e que os utilizadores continuam a ter de fornecer as aprovações necessárias.

Editar regra

Defina o acesso predefinido às aplicações e substitua-o para as aplicações correspondentes.

AplicaçãoID de pacote macOS

Identificador da aplicação 

Acesso à aplicaçãoEscolher acesso

Consulte os campos da política do Computer Use para conhecer os requisitos de identidade do Windows e as restrições de utilização com o computador bloqueado para Macs geridos.

Verificar a política efetiva

Se um site ou aplicação permitido continuar bloqueado, verifique outras regras correspondentes, as atribuições e a prioridade das políticas, os requisitos do dispositivo e a configuração do utilizador. Uma regra de permissão numa fonte não contorna outra proibição aplicável. Consulte as localizações e a precedência dos requisitos.

Se uma definição não tiver efeito, verifique se o cliente, o sistema operativo e a via de distribuição da política a suportam. Preste especial atenção ao Work Cloud com acesso ao computador local: alguns campos têm suporte parcial ou requerem validação. Consulte Compatibilidade do Work na Referência de configuração.

Verifique as permissões do espaço de trabalho e os controlos de plugins separadamente quando um utilizador não conseguir aceder à funcionalidade ou ao plugin necessário.

Referência de configuração TOML

Os exemplos seguintes descrevem a mesma intenção de política para requirements.toml. Utilize-os ao gerir políticas através de ficheiros ou do editor TOML. Não é necessário editar um ficheiro local para utilizar os controlos disponíveis em Agent Security.

Este exemplo de navegador nega o acesso por predefinição, permite https://example.com, bloqueia os carregamentos e o acesso CDP completo 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 ou defina auto_review = "deny" numa política de origem para a restringir nessa origem.

Para ativar as Ferramentas de sites numa área de trabalho Enterprise elegível, defina browser_use.allow_webmcp = true. Esta ativação gerida aplica-se ao navegador integrado da aplicação de computador. Definir o valor como false ou omiti-lo mantém as verificações normais de disponibilidade da funcionalidade; false não impõe um bloqueio. As preferências do utilizador e as permissões dos sites continuam a aplicar-se.

Este exemplo de aplicação nativa permite Calculator no macOS, nega outras aplicações por predefinição e impede que as aprovações de aplicações 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 aplicações empacotadas com computer_use.windows.aumids ou executáveis com computer_use.windows.exes. As regras de executáveis exigem publisher_name, product_name e access; binary_name é opcional.

Para consultar todos os campos e valores suportados, utilize a referência de requirements.toml. Para desativar uma capacidade em vez de restringir sites ou aplicações individuais, consulte Fixar sinalizadores de funcionalidades.

Outros controlos da aplicação de computador

Os controlos da aplicação de computador seguintes abrangem a disponibilidade de funcionalidades, Locked Use, Appshots e o controlo remoto de dispositivos. Utilize as definições dedicadas à disponibilidade de funcionalidades e a Locked Use; configure Appshots e o controlo remoto de dispositivos com Editar como TOML. Para restrições de destino no tráfego da aplicação de computador, consulte Controlar os destinos de rede da aplicação de computador.

Fixar sinalizadores de funcionalidades

Para as funcionalidades da aplicação de computador disponíveis em Agent security, abra Global > Requisitos > Disponibilidade de funcionalidades da aplicação de computador. Defina Navegador na aplicação, Utilização do navegador, Utilização de navegador externo ou Utilização do computador como Forçar desativação para desativar essa capacidade e, em seguida, selecione Guardar alterações. Para Acesso CDP completo, escolha Bloquear ativação pelo utilizador para impedir que os utilizadores o ativem. Permitir uma funcionalidade não se sobrepõe à sua disponibilidade no produto, na plataforma ou na implementação gradual.

Para outros sinalizadores de funcionalidades suportados, utilize Editar como TOML e o documento requirements.toml de Global ou uma fonte local de requisitos suportada. Os exemplos seguintes incluem a fixação de funcionalidades do ambiente de execução e de funcionalidades específicas da aplicação de computador:

[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

Utilize as chaves canónicas de funcionalidades da tabela [features] de config.toml para as funcionalidades do ambiente de execução. O ambiente de execução local normaliza as funcionalidades reconhecidas para respeitar estes valores fixados e rejeita escritas em conflito em config.toml ou nas definições de funcionalidades dos ficheiros de perfil.

Uma definição gerida de unified_exec = false mantém a execução de comandos disponível, mas desativa os processos retomáveis e a ferramenta write_stdin. A configuração do utilizador não pode desativar esta funcionalidade.

• in_app_browser = false desativa o painel do navegador integrado.
• in_app_updates = false desativa o atualizador próprio da aplicação de computador ChatGPT ao reiniciar, quando suportado. Não afeta a implementação de pacotes externos nem prolonga o suporte de versões anteriores da aplicação. Para orientações de configuração e implementação gradual, consulte Gerir atualizações da aplicação.
• browser_use = false desativa as capacidades suportadas de Browser Use. A utilização externa de Browser Use e a utilização de aplicações nativas com Computer Use têm controlos separados.
• browser_use_full_cdp_access = false desativa o acesso CDP completo no ambiente de execução local, incluindo o modo de programador do navegador, e impede que a aplicação de computador ChatGPT ative a definição correspondente.
• browser_use_external = false desativa a utilização de Browser Use pelo agente através de extensões de navegador suportadas.
• computer_use = false desativa a utilização de aplicações nativas com Computer Use, incluindo a operação de um navegador como aplicação nativa, bem como Record & Replay e os fluxos de instalação ou configuração relacionados.

Desativar apenas Browser Use não bloqueia todas as vias de acesso ao navegador. A utilização de aplicações nativas com Computer Use continua a permitir operar um navegador quando essa capacidade e o acesso à aplicação são permitidos; as regras de sites e capacidades de Browser Use não se aplicam a essa via. Para a bloquear, defina Utilização do computador como Forçar desativação (computer_use = false) ou negue a aplicação de navegador nas Regras de aplicações se outras aplicações nativas devam continuar disponíveis. Reveja Utilização de navegador externo e Navegador na aplicação separadamente. Consulte sessões do navegador e sessões iniciadas existentes para conhecer os controlos que se aplicam a cada via.

Se omitir estas chaves, a política permite as funcionalidades, sujeitas à disponibilidade normal no cliente, na plataforma e na implementação gradual.

Restringir a utilização do computador bloqueado

Para impedir que os utilizadores ativem Locked Use num Mac gerido, abra Global > Requisitos > Controlos da aplicação de computador, defina Permitir utilização enquanto bloqueado como Desativado e selecione Guardar alterações. Esta definição não desativa Locked Use num Mac onde já esteja ativado.

O requisito equivalente para o editor TOML ou para a distribuição gerida por dispositivos é:

[computer_use]
allow_locked_computer_use = false

Este requisito remove os controlos que permitem ativar Locked Use. Não desativa Locked Use se já estiver ativado. Se o omitir, a disponibilidade normal do produto e a definição local do utilizador continuam a aplicar-se.

Desativar Appshots

Appshots permitem que os clientes suportados incluam capturas do estado das aplicações. Para os desativar para utilizadores geridos pela nuvem, abra Editar como TOML em Agent security e defina o campo de nível superior allow_appshots em requirements.toml de Global. Para implementações geridas por dispositivos, utilize a fonte local de requisitos aplicável:

allow_appshots = false

Onde Appshots estiverem disponíveis, allow_appshots = false desativa-os. Se omitir a chave, os requisitos não restringem Appshots e aplicam-se as verificações normais de disponibilidade do produto. Os clientes de app-server que leem os requisitos efetivos através de configRequirements/read recebem a mesma restrição como allowAppshots; um valor de allowAppshots omitido ou null não desativa Appshots.

Desativar o controlo remoto de dispositivos

Para desativar o controlo remoto de dispositivos para utilizadores geridos pela nuvem, utilize Editar como TOML em Agent security e defina o campo de nível superior allow_remote_control em requirements.toml de Global. Pode também definir allow_remote_control numa fonte local de requisitos suportada:

allow_remote_control = false

Onde o controlo remoto de dispositivos for suportado, allow_remote_control = false desativa-o. Se omitir a chave, os requisitos não restringem o controlo remoto de dispositivos e aplicam-se as verificações normais de disponibilidade do produto. Este requisito não desativa as ligações remotas SSH.

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

Utilize esta secção para definir o comportamento de aprovação, os limites das permissões e os valores predefinidos iniciais. Comece por Limites da política e Predefinições. As tarefas posteriores explicam os requisitos TOML para a imposição de revisores, perfis de permissões personalizados, restrições do sistema de ficheiros, substituições de anfitrião e regras de comandos.

Requisitos impostos pelo administrador (requirements.toml)

Os requisitos restringem definições sensíveis em termos de segurança (política de aprovação, revisor de aprovações, política de revisão automática, modo de sandbox, perfis de permissões, modo de pesquisa na Web, hooks geridos, os MCP servers que os utilizadores podem ativar e as fontes de marketplaces de plugins que podem utilizar). Ao resolver a configuração (por exemplo, a partir de config.toml, ficheiros de perfil ou substituições de configuração da CLI), se um valor entrar em conflito com uma regra imposta, o cliente local recorre a um valor compatível e notifica o utilizador. Se configurar uma lista de permissões mcp_servers, o cliente só ativa um MCP server quando tanto o nome como a identidade correspondem a uma entrada aprovada; caso contrário, o cliente desativa-o.

Os requisitos também podem restringir sinalizadores de funcionalidades através da tabela [features] em requirements.toml. Tenha em atenção que as funcionalidades nem sempre são sensíveis à segurança, mas as empresas podem fixar valores se assim o pretenderem. As chaves omitidas permanecem sem restrições.

Para o Codex 0.138.0 ou posterior, dê preferência aos perfis de permissões com allowed_permission_profiles e default_permissions gerido. Utilize allowed_sandbox_modes apenas para implementações legadas que ainda configurem sandbox_mode.

Para obter a lista exata de chaves, consulte a secção requirements.toml na Referência de configuração.

Definir limites de aprovação, sandbox e pesquisa na Web

Utilize Requisitos > Limites da política para limitar as opções suportadas do cliente. Estes controlos restringem a configuração; não selecionam o valor inicial. Defina o valor inicial separadamente em Predefinições.

1. Em Global, abra Políticas de aprovação e selecione os tipos de aprovação permitidos. Por exemplo, Perguntar quando necessário permite ao agente pedir aprovação para ações como a elevação de permissões da sandbox. Nunca perguntar impede pedidos de aprovação; não concede execução sem restrições.
2. Abra Modos de sandbox para limitar as opções de sandbox legadas. Só de leitura restringe a escrita, Escrita na área de trabalho permite escrever na área de trabalho e nas raízes configuradas como graváveis, e Acesso total remove o isolamento do sistema de ficheiros. Utilize os requisitos de perfis de permissões para implementações que utilizam perfis de permissões 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 Desativada para desativar a pesquisa na Web. As restrições de pesquisa na Web são independentes das regras de rede dos comandos.
4. Reveja as opções permitidas e os valores predefinidos correspondentes e, em seguida, selecione Guardar alterações.

Deixar um requisito por definir não impõe qualquer limite ao abrigo dessa política. As outras políticas aplicáveis continuam em vigor. A opção Perguntar para comandos não fidedignos corresponde a untrusted na lista de permissões dos requisitos; não repõe a definição explícita approval_policy = "untrusted" descontinuada. Siga as orientações de migração abaixo para esse caso.

Para restringir a pesquisa na Web, utilize Global > Requisitos > Salvaguardas de políticas > 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.

Definir valores predefinidos de configuração

Os valores predefinidos dão aos membros uma configuração inicial. Não impõem uma restrição nem concedem acesso a uma capacidade da área de trabalho.

1. Abra o cartão Valores predefinidos da política. Mantenha os valores predefinidos de todo o agente em Global; utilize um separador de ambiente disponível para os valores predefinidos de execução suportados.
2. Em Execução de comandos, escolha a Política de aprovação e o Revisor de aprovações iniciais, bem como o Modo de sandbox ou as Permissões predefinidas aplicáveis. O revisor determina quem revê os pedidos de aprovação por predefinição; a política de aprovação determina quando podem ocorrer pedidos.
3. Em Pesquisa na Web, escolha o modo inicial de Pesquisa na Web e o Contexto de pesquisa na Web. Em Aplicações e ferramentas, reveja Aplicações/conectores, Ferramentas de mundo aberto e Ferramentas destrutivas para as ferramentas de aplicações suportadas.
4. Confirme que os valores predefinidos cumprem os seus Requisitos e selecione Guardar alterações.

Utilize Editar como TOML para valores predefinidos suportados sem controlos visuais, como a configuração do marketplace de plugins. Estes valores predefinidos na nuvem utilizam a precedência normal da configuração. Diferem da precedência legada de managed_config.toml, que coloca os valores predefinidos geridos acima da configuração local no arranque.

Exemplo de requirements.toml

Este exemplo bloqueia --ask-for-approval never e --sandbox danger-full-access (incluindo --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"; não torna approval_policy = "untrusted" uma definição explícita suportada.

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

O Codex e o ChatGPT Work já não suportam approval_policy = "untrusted". Remova esta definição dos valores predefinidos geridos, do ficheiro legado managed_config.toml e de qualquer configuração de utilizador, projeto, perfil ou arranque que a defina.

Para utilização interativa só de leitura, selecione approval_policy = "on-request" com uma sandbox ou um perfil de permissões só de leitura permitido pelos seus requisitos geridos. Os comandos permitidos por essa sandbox podem ser executados sem aprovação.

Para manter aprovações de comandos mais rigorosas, omita uma definição explícita de approval_policy, defina trust_level = "untrusted" na entrada do projeto no ficheiro ao nível do utilizador ~/.codex/config.toml e mantenha untrusted em allowed_approval_policies. Isto também desativa a configuração local do projeto. Definir on-request explicitamente sobrepõe-se a essa política. Consulte Migrar da política de aprovação untrusted descontinuada para ver exemplos e os compromissos em matéria de segurança.

Configurar a política de revisão automática

Para tornar a revisão automática a predefinição, utilize Global > Valores predefinidos > Execução de comandos > Revisor de aprovações. Um valor predefinido permite aos utilizadores escolher outro revisor permitido. Para exigir revisão automática ou fornecer as instruções de revisão da sua organização, utilize Editar como TOML e edite o ficheiro Global requirements.toml. Estes requisitos são independentes dos controlos de revisão automática do navegador.

Utilize allowed_approvals_reviewers para exigir ou permitir a revisão automática. Defina-o como ["auto_review"] para exigir revisão automática, ou inclua "user" quando os utilizadores puderem escolher a aprovação manual.

Defina guardian_policy_config para substituir a secção específica do inquilino da política de revisão automática. O ambiente de execução local continua a utilizar o modelo de revisor integrado e o contrato de saída. A definição gerida guardian_policy_config tem precedência sobre a definição local [auto_review].policy.

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

guardian_policy_config = """
## Environment Profile
- Trusted internal destinations include github.com/my-org, artifacts.example.com,
  and internal CI systems.

## Tenant Risk Taxonomy and Allow/Deny Rules
- Treat uploads to unapproved third-party file-sharing services as high risk.
- Deny actions that expose credentials or private source code to untrusted
  destinations.
"""

Controlar os perfis de permissões disponíveis

Utilize Valores predefinidos > Execução de comandos > Permissões predefinidas para escolher o perfil integrado com que os utilizadores começam. Para impor quais os perfis que os utilizadores podem selecionar ou para definir perfis personalizados, utilize Editar como TOML e configure requirements.toml para o âmbito Global aplicável ou o âmbito de um ambiente de execução suportado. Escolher apenas um valor predefinido não restringe os perfis disponíveis.

Utilize allowed_permission_profiles para controlar os perfis de permissões incorporados e personalizados que os utilizadores podem selecionar. Este é o equivalente de perfis de permissões de allowed_sandbox_modes; utilize a lista de permissões que corresponda à forma como os seus utilizadores selecionam permissões.

As listas de permissões de perfis de permissões requerem o Codex 0.138.0 ou posterior. O Codex 0.137.0 e versões anteriores ignoram allowed_permission_profiles e default_permissions gerido.

Utilize os exemplos de perfis de permissões abaixo apenas depois de todos os clientes geridos executarem uma versão compatível. Não implemente perfis personalizados geridos antes de concluir a atualização da frota.

Quando presente, a tabela corresponde à lista completa de perfis permitidos. Permite perfis definidos como true e recusa perfis omitidos ou definidos como false, incluindo perfis incorporados adicionados em futuras versões do Codex.

Permitir os perfis padrão

Esta política permite acesso só de leitura e ao espaço de trabalho, mas não acesso total:

default_permissions = ":workspace"

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

Adicionar uma predefinição gerida com o mínimo de privilégios

Os administradores podem definir um perfil personalizado na mesma origem de requisitos. Utilize nomes de perfil específicos da organização que não entrem em conflito com nomes existentes na configuração carregada dos utilizadores. Os nomes personalizados não podem começar por : nem utilizar o nome reservado filesystem.

Não implemente perfis personalizados geridos em clientes que executem o Codex 0.137.0 ou versões anteriores. Esses clientes reconhecem a tabela de perfis, mas não a predefinição gerida que a seleciona.

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"

Permitir apenas perfis definidos pela empresa

Omita todos os perfis incorporados quando os utilizadores só devam selecionar perfis definidos pelos administradores:

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 expandir :workspace, embora os utilizadores não possam selecionar diretamente o perfil incorporado :workspace.

Desativar um perfil permitido por outra origem

As listas de permissões são combinadas por nome de perfil. Uma vez que os requisitos da cloud têm precedência superior aos requisitos do sistema, os requisitos da cloud podem utilizar false para desativar um perfil permitido pelo ficheiro do sistema.

Requisitos da cloud:

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 explicitamente default_permissions como um perfil permitido. Se for omitido, o ambiente de execução local utiliza :workspace como predefinição apenas quando :workspace e :read-only estiverem explicitamente permitidos. Quando allowed_permission_profiles está ausente, os requisitos geridos não restringem os nomes de perfil que os utilizadores podem selecionar. Cada entrada deve indicar um perfil incorporado ou um perfil personalizado definido numa origem de configuração ou requisitos carregada. Defina perfis personalizados nos requisitos geridos para controlar centralmente o respetivo comportamento.

Impor requisitos de negação de leitura

Utilize Editar como TOML para adicionar restrições do sistema de ficheiros ao ficheiro requirements.toml do âmbito Global aplicável ou de um ambiente de execução suportado. Estas restrições bloqueiam leituras de caminhos sensíveis; uma predefinição só de leitura, por si só, não oculta ficheiros.

Os administradores podem negar leituras de caminhos exatos ou padrões glob com [permissions.filesystem]. Os utilizadores não podem enfraquecer estes requisitos através 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 existem requisitos de negação de leitura, o ambiente de execução local rejeita permissões de acesso total e mantém a execução local numa sandbox só de leitura ou da área de trabalho para os poder impor. No Windows nativo, a definição gerida deny_read aplica-se às ferramentas de acesso direto a ficheiros; as leituras de subprocessos da shell não utilizam esta regra de sandbox.

Substituir requisitos de sandbox por anfitrião

Utilize Editar como TOML em Segurança do agente para criar requisitos específicos do anfitrião. Os controlos de ambiente selecionam um ambiente de execução; os padrões de anfitrião selecionam as máquinas correspondentes no ambiente de execução suportado.

Utilize [[remote_sandbox_config]] quando uma política gerida deva aplicar diferentes requisitos de sandbox em diferentes anfitriões. Por exemplo, pode manter uma predefinição mais restrita para portáteis e permitir escritas no espaço de trabalho em máquinas de desenvolvimento ou executores de CI correspondentes. Atualmente, as entradas específicas de anfitrião 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 hostname_patterns com o nome do anfitrião resolvido da melhor forma possível. Dá preferência ao nome de domínio completamente qualificado quando este está disponível e, como alternativa, utiliza o nome do anfitrião local. A correspondência não distingue maiúsculas de minúsculas; * corresponde a qualquer sequência de caracteres e ? corresponde a um caráter.

A primeira entrada [[remote_sandbox_config]] correspondente prevalece na mesma origem de requisitos. Se nenhuma entrada corresponder, o ambiente de execução local mantém o allowed_sandbox_modes de nível superior. A correspondência do nome do anfitrião serve apenas para selecionar políticas; não a trate como prova autenticada do dispositivo.

Impor regras de comandos através de requisitos

Utilize Editar como TOML em Segurança do agente para adicionar regras de comandos e restrições de MCP servers ao ficheiro Global requirements.toml. As regras de comandos especificam decisões de aprovação ou negação para os comandos correspondentes; as restrições MCP limitam as identidades de servidores que o cliente pode ativar. O controlo Políticas de aprovação não cria nenhum destes conjuntos de regras.

Os administradores também podem impor regras de comandos restritivas a partir de requirements.toml utilizando uma tabela [rules]. Estas regras são combinadas com os ficheiros .rules normais, e a decisão mais restritiva continua a prevalecer.

Ao contrário de .rules, as regras dos requisitos têm de especificar decision, e essa decisão tem de 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 MCP servers que um cliente local pode ativar, adicione uma lista de aprovação mcp_servers. Para servidores stdio, estabeleça a correspondência com command; para servidores HTTP com transmissão em fluxo, estabeleça a correspondência com url:

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

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

A forma de cadeia de caracteres de identity.command corresponde apenas ao command configurado. Não inspeciona args, cwd, env ou env_vars.

Para restringir uma invocação stdio completa, estabeleça a correspondência com o executável e 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, o número de argumentos e a ordem dos argumentos têm de corresponder. As regras de argumentos e URL suportam correspondência exact, prefix e regex do valor completo. As regras estruturadas de comandos continuam a não inspecionar cwd, env ou env_vars. Os MCP servers incluídos em plugins utilizam as mesmas estruturas de identidade em plugins.<plugin>.mcp_servers.<server>.

Se mcp_servers estiver presente mas vazio, o cliente local desativa todos os MCP servers.

Configurar o acesso à rede

O acesso à rede dos comandos e o das aplicações de ambiente de trabalho utilizam controlos diferentes. Comece pelos Controlos de utilização da rede para o tráfego de comandos suportado, reveja os limites do ambiente e do ambiente de execução e, em seguida, utilize os requisitos separados das aplicações de ambiente de trabalho, se necessário. As regras de sites do navegador continuam em Controlar o navegador e o Computer Use.

Configurar requisitos de acesso à rede

Utilize Requisitos > Controlos de utilização da rede para gerir o acesso à rede dos comandos suportados em Segurança do agente. Configure uma base comum em Global, ou num separador disponível de Ambientes locais ou Ambientes Codex Cloud para definições de execução específicas do ambiente.

1. Defina Rede gerida como Ativada para aplicar regras de domínio ao tráfego de comandos gerido. Adicionar apenas regras de domínio não ativa o proxy gerido.
2. Em Regras de rede, selecione Adicionar regra de rede. Introduza um Domínio, como api.openai.com ou **.example.com, sem esquema de URL nem caminho. Escolha Permitir ou Negar em Acesso e selecione Guardar regra para atualizar o rascunho. Repita para outros destinos.
3. Defina Permitir apenas domínios adicionados por administradores como Ativada se as definições do utilizador e as aprovações por domínio não puderem alargar a lista de permissões gerida. Inclua as entradas Permitir necessárias; uma lista apenas com negações não permite outros destinos.
4. Reveja Permitir acesso à rede local para fluxos de trabalho que precisem de serviços à escuta locais ou de destinos privados. As ligações locais diretas podem contornar as regras de domínio do proxy. Reveja os limites de conectividade do Codex Cloud abaixo antes de alterar esta definição.
5. Reveja as regras herdadas e as mensagens de validação e selecione Guardar alterações. Teste um pedido que deva ter êxito e outro que deva ser bloqueado em cada ambiente de execução afetado.

Definir Rede gerida como Desativada limpa as regras de rede criadas nesse âmbito e guarda um valor explícito de desativação; não desativa o acesso à Internet. Não definida remove as definições de rede criadas nesse âmbito para que a política aplicável ou os valores predefinidos do ambiente de execução possam ser aplicados. Remover definições de ambiente pode revelar regras Globais herdadas. Utilize Editar como TOML para campos de rede avançados ou listas de domínios legadas existentes que o editor visual não consegue representar.

Utilize [experimental_network] em requirements.toml quando os administradores tiverem de definir centralmente os requisitos de acesso à rede. Estes requisitos são independentes da opção features.network_proxy do utilizador: podem configurar a ligação à rede do ambiente isolado sem esse sinalizador de funcionalidade, mas não concedem acesso à rede aos comandos quando o ambiente isolado ativo mantém a ligação à rede desativada. Defina experimental_network.enabled = true para ativar o proxy gerido; as regras de domínio, por si só, não ativam o proxy.

[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"

Utilize experimental_network.managed_allowed_domains_only = true apenas quando também definir entradas "allow" geridas pelo administrador em [experimental_network.domains] e pretender que essas regras sejam exclusivas. Se o valor for true sem regras de permissão geridas, as regras de permissão de domínios adicionadas pelo utilizador deixam de ser aplicadas. Não combine o mapa canónico domains com as listas legadas allowed_domains ou denied_domains.

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

A sintaxe dos domínios, as regras de destinos locais/privados, o comportamento de recusa sobre permissão e as limitações de reassociação de DNS são iguais ao comportamento de rede da sandbox descrito em Aprovações e segurança do agente.

O proxy encaminha os comandos locais executados dentro da sandbox. As ferramentas de navegador também verificam os bloqueios de rede geridos e as listas exclusivas de permissões antes de acederem a uma origem. Trata-se de uma verificação de política separada, que não encaminha o tráfego do navegador através do proxy de comandos. Não filtra a pesquisa na Web, aplicações e conectores, MCP servers, tráfego de aplicações nativas, pedidos ao serviço Codex ou outro tráfego específico de cada capacidade. Utilize os controlos de cada interface:

• Utilize allowed_web_search_modes para restringir a pesquisa na Web.
• Utilize features.apps = false para desativar as integrações de aplicações e conectores, e features.plugins = false para desativar os plugins onde esta opção for suportada.
• Utilize a lista gerida de mcp_servers aprovados para restringir os MCP servers.
• Utilize requisitos de funcionalidades como browser_use, in_app_browser e computer_use para restringir as capacidades de utilização do navegador e do computador.
• Para os comandos geridos suportados do Codex Cloud, configure separadamente os requisitos de Agent Security e as definições de Internet do ambiente Cloud.

Uma lista de domínios permitidos para comandos não substitui estes controlos específicos de cada capacidade.

Nos percursos de execução geridos suportados do Codex Cloud, os requisitos de Agent Security restringem o acesso à rede dos comandos. As definições de Internet do ambiente Codex Cloud aplicam-se separadamente. Um domínio permitido em Agent Security não se sobrepõe a uma restrição nas definições de Internet do ambiente Cloud. Estes controlos de rede dos comandos não desativam, por si só, a pesquisa na Web alojada, as aplicações ou o MCP. O ChatGPT Work Cloud tem permissões de capacidades separadas e não herda estes requisitos de Agent Security.

Uma lista gerida de permissões para comandos aplica-se aos comandos que utilizam o proxy gerido. Quando a política permite a elevação completa para além dos limites da sandbox e esta é aprovada, essa execução pode contornar o proxy de comandos. Uma concessão limitada de acesso à rede é diferente de uma elevação completa para além dos limites da sandbox. Configure requisitos obrigatórios de aprovação e de sandbox para o limite pretendido e teste tanto os comandos comuns como os comandos com elevação de privilégios.

Sem destinos permitidos efetivos: Quando Rede gerida e Permitir apenas domínios adicionados por administradores estão ativadas, os comandos geridos normais precisam de destinos permitidos efetivos. Se não houver entradas Permitir configuradas ou herdadas, esses comandos não têm destinos permitidos. Uma política apenas com negações não permite implicitamente o resto da Internet. Adicione as entradas Permitir necessárias e verifique as regras herdadas antes de guardar. Esta restrição aplica-se ao proxy de comandos geridos, não a todas as ferramentas nem à elevação completa aprovada das permissões da sandbox.

Conectividade local/privada do Codex Cloud: Um valor explícito Off para a conectividade local/privada pode impedir o Codex Cloud de aceder ao respetivo proxy a montante, mesmo quando o domínio de destino é permitido. Verifique o valor final de allow_local_binding e identifique a política ou definição que o fornece. No percurso suportado através do proxy Cloud, este valor assume true por predefinição apenas quando nenhum requisito aplicável, perfil de rede selecionado ou definição da funcionalidade de proxy fornece um valor. Um valor false herdado continua a contar como uma definição explícita. Quando suportado, configure uma substituição Cloud de prioridade superior para alterar este valor para o Codex Cloud sem alterar o valor Global utilizado por Local. Isto não adiciona entradas Allow para domínios. Verifique se o executor suporta a substituição antes de depender dela. Não aplique esta predefinição Cloud a Local.

Quando os requisitos do ambiente estão vazios, aplicam-se os requisitos Globais. Definir Rede gerida como Desativada é independente da definição de acesso à Internet do ambiente Cloud. Consulte Controlos de execução da segurança do agente para obter detalhes sobre o âmbito de execução.

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

Numa determinada política, a ordem da prioridade mais alta para a mais baixa é: substituição de ambiente específica do sistema operativo → substituição de ambiente para todos os sistemas operativos → Global. Uma política de prioridade mais alta continua a prevalecer sobre uma política de prioridade mais baixa, mesmo quando esta última é mais específica. Alguns requisitos têm regras de combinação específicas de cada campo. O ambiente de execução aplica então os requisitos resultantes. Considere os casos de rede específicos de cada campo abaixo separadamente da prioridade das políticas.

Estes exemplos comparam definições de ambiente e Globais dentro da mesma política, com a rede gerida já configurada e sem nenhuma política de prioridade mais alta a alterar os valores. Descrevem a combinação específica de cada campo e o comportamento do ambiente de execução.

Definir acessos a domínios diferentes por ambiente

Para a mesma regra de domínio numa política, uma substituição de ambiente definida por um 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 Global é herdada. Outras regras Negar efetivas ou controlos de acesso podem ainda bloquear um pedido.

Como se combinam as regras de domínio

Estes resultados comparam a mesma chave de domínio dentro de uma política, sem nenhuma política de prioridade mais alta a alterar o resultado. Um valor de prioridade mais alta substitui a mesma chave. As outras chaves herdadas mantêm-se. Uma regra Permitir não contorna outra regra Negar que também corresponda, como um caráter universal herdado. Um mapa de ambiente vazio não limpa as regras herdadas.

Exemplo: Negue packages.example.com em Global e permita-o em Desenvolvimento. Desenvolvimento pode permiti-lo nas condições acima. Produção herda a regra Negar Global, salvo se houver uma substituição.

Confirme que o executor implementado suporta estas regras de combinação. A cobertura dos executores geridos normais ainda precisa de validação.

Limites do Orchestrator. As portas de escuta HTTP/SOCKS geridas e os serviços de escuta do proxy fora da interface de loopback não são suportados pelo ambiente de execução na nuvem; o suporte de regras de sockets depende do percurso de execução. Uma definição de execução local na tabela abaixo não constitui uma configuração suportada do Orchestrator.

Outros limites de rede do ambiente de execução

Todos os nomes de campos abaixo estão em experimental_network em requirements.toml. As setas mostram um valor Global seguido de um valor de ambiente dentro da mesma política. Estes casos de execução local não demonstram que o Orchestrator suporta as mesmas definições.

A ativação do proxy, a exclusividade, o comportamento do proxy a montante e as regras de sockets Unix têm comportamentos específicos de cada executor. Não generalize a combinação de chaves de domínio a estas definições. Verifique os valores efetivos e teste o ambiente de execução implementado. Para a conectividade local/privada do Codex Cloud, consulte Configurar requisitos de acesso à rede.

Verificar o comportamento antes da disponibilização

Teste os destinos reais, os serviços à escuta locais, o comportamento do proxy e os caminhos de sockets utilizados pelos seus fluxos de trabalho. Verifique uma ação que deva ter êxito e outra que deva ser bloqueada em cada ambiente afetado. Verifique se a versão do ambiente de execução implementado suporta cada definição utilizada.

Controlar os destinos de rede da aplicação de ambiente de trabalho

Utilize Editar como TOML na segurança do agente para configurar estes requisitos específicos da aplicação de computador em Global. A interface de Controlos de utilização da rede gere a rede de comandos, que constitui uma política separada.

Utilize [application.network] em requirements.toml para restringir os destinos de rede da aplicação de ambiente de trabalho. Com enabled = true, os pedidos externos têm de utilizar HTTPS ou WSS e corresponder a um domínio exato com um valor "allow" em [application.network.domains]. Os subdomínios não são permitidos implicitamente. Um mapa de domínios vazio não permite destinos externos. Consulte a Referência de configuração para conhecer as chaves suportadas.

Esta política é independente das regras de rede dos comandos e das regras de origem do navegador. Não impõe restrições de destino a módulos nativos nem a processos iniciados, e não rege a execução do Work Cloud.

Configurar plugins e hooks geridos

Para estas tarefas, utilize Editar como TOML na segurança do agente ou uma origem de configuração local suportada. Os valores predefinidos dos marketplaces, as restrições obrigatórias de plugins e os hooks geridos têm finalidades diferentes; escolha a tarefa que corresponde à política de que precisa.

Configurar marketplaces de plugins e valores predefinidos

Utilize Segurança do agente > Editar como TOML para definir marketplaces locais ou Git e valores predefinidos de plugins no documento Global config.toml. Também pode distribuir estas definições no config.toml do sistema. Fornecem uma configuração inicial de marketplaces e plugins, não uma política obrigatória. Para limitar as origens que os membros podem utilizar, configure os requisitos de origens de marketplaces.

Consulte a Referência de configuração para as chaves de configuração, Precedência da configuração para as substituições e definições de plugins do repositório para a configuração ao nível do projeto. A importação e sincronização do GitHub na área de trabalho é independente.

Controlar a disponibilidade de plugins

Utilize Editar como TOML na segurança do agente para definir obrigatoriamente as funcionalidades de plugins no requirements.toml Global ou distribua essas definições através de requisitos locais para clientes geridos ao nível do dispositivo. Predefinições > Aplicações e ferramentas > Aplicações/conectores define os valores predefinidos das ferramentas de aplicações; não é o comutador obrigatório features.plugins. Para as permissões de plugins da área de trabalho, consulte Aplicações e conectores.

Para desativar plugins nos clientes locais suportados, defina features.plugins como false em requirements.toml:

features.plugins = false

Esta definição também se aplica quando os utilizadores iniciam sessão no Codex com uma API key. Consulte a referência de features.plugins para obter a configuração suportada.

Restringir origens de marketplaces de plugins

Utilize Editar como TOML para configurar os requisitos de origem do marketplace no ficheiro Global requirements.toml, ou distribua-os através de requisitos locais. Estas regras limitam as origens locais ou Git que os utilizadores podem adicionar e utilizar. São independentes das predefinições do marketplace.

Para restringir as fontes de marketplaces de plugins, defina restrict_to_allowed_sources = true e estabeleça 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 Git fazem corresponder o URL normalizado do repositório e, quando presente, um ref exato. Os padrões de anfitrião são expressões regulares comparadas com o anfitrião Git em minúsculas; utilize ^ e $ para uma correspondência do anfitrião completo. As regras locais requerem um caminho absoluto e normalizado. Consulte a referência de requirements.toml para obter o esquema completo e o comportamento de intercalação.

Estes 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 os respetivos plugins durante a execução.

Os marketplaces Git com curadoria da OpenAI, incluindo o catálogo de chaves de API, também têm de corresponder à lista de fontes permitidas. Para os permitir, inclua a seguinte fonte Git sem uma restrição 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 certifique-se de que nenhuma regra mais abrangente para o anfitrião a permite. Os plugins incluídos e os plugins da área de trabalho instalados remotamente são independentes desta política de fontes Git com curadoria.

Estas restrições de origem aplicam-se apenas quando um cliente local suporta operações do marketplace de plugins: ChatGPT e Codex na aplicação para computador e Codex CLI. Não controlam a utilização de plugins no ChatGPT na Web ou em dispositivos móveis e não adicionam plugins à extensão IDE.

Impor hooks geridos através de requisitos

Os hooks geridos executam ações definidas pelo administrador em eventos de tarefas ou ferramentas suportados. Utilize Editar como TOML em Agent security para os configurar no ficheiro Global requirements.toml; os controlos das definições não incluem um editor dedicado a hooks. Os percursos de execução abaixo determinam os tipos de hooks que podem ser executados.

Quando a política gerida e os hooks remotos estão ativados, o Work Cloud com acesso local e os dots utilizam hooks MCP remotos geridos pelo administrador no orquestrador na nuvem. Configure os processadores mcp_tool no ficheiro Global requirements.toml. O Work Cloud sem acesso local e as contas pessoais não utilizam estes hooks empresariais. Os processadores de comandos/shell, de prompts e de agentes; os hooks de configurações locais, plugins ou diretórios locais; os hooks com âmbito de ambiente; e os hooks MCP SessionEnd não são suportados com orquestração na nuvem, mesmo quando as ferramentas são executadas localmente. Quando tanto a orquestração como a execução são locais, os hooks suportados existentes continuam a funcionar em conversas do Work e do Codex exclusivamente locais. Os administradores continuam a poder configurar hooks geridos suportados em Agent Security para esses fluxos de trabalho.

Antes de depender destes hooks, teste a conectividade dos callbacks, os eventos necessários e o comportamento em caso de falha. Uma recusa explícita suportada pode bloquear uma ação, mas um erro de callback PreToolUse, um tempo limite excedido ou uma resposta malformada pode fazer com que o hook falhe sem bloquear a ferramenta. Os hooks MCP não fornecem um registo de auditoria completo da Compliance API. Os exemplos de scripts e diretórios que se seguem mantêm o seu âmbito do Codex.

Os administradores também podem definir hooks geridos de ciclo de vida diretamente em requirements.toml. Utilize [hooks] para a configuração do hook propriamente dita e aponte managed_dir para o diretório onde o seu MDM ou as ferramentas de gestão de endpoints instalam os scripts referenciados.

Para impor hooks geridos mesmo aos utilizadores que desativaram os hooks localmente, fixe [features].hooks = true juntamente com [hooks]. Para ignorar os hooks de utilizador, projeto, sessão e plugins, continuando a permitir os hooks geridos, defina allow_managed_hooks_only = true.

allow_managed_hooks_only = true

[features]
hooks = true

[hooks]
managed_dir = "/enterprise/hooks"
windows_managed_dir = 'C:\enterprise\hooks'

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 /enterprise/hooks/pre_tool_use_policy.py"
command_windows = 'py -3 C:\enterprise\hooks\pre_tool_use_policy.py'
timeout = 30
statusMessage = "Checking managed Bash command"

Notas:

• O ambiente de execução local impõe a configuração de hooks de requirements.toml, mas não distribui os scripts de managed_dir.
• Distribua esses scripts com o seu MDM ou a sua solução de gestão de dispositivos.
• Os comandos dos hooks geridos devem referenciar caminhos absolutos para scripts no diretório gerido configurado.
• allow_managed_hooks_only = true ignora os hooks provenientes de utilizadores, projetos, sessões e plugins, mas continua a carregar os hooks de requirements.toml e de outras camadas de configuração gerida.

Compreender o âmbito e a precedência das políticas

Utilize esta secção para verificar onde se aplica uma política, como se combinam os requisitos, como os clientes recebem definições geridas na nuvem e como verificar o resultado.

Para o Work com acesso local e os dots, a política Global suportada rege o orquestrador partilhado na nuvem quando a política gerida está ativada; os requisitos de execução local aplicáveis regem o computador ligado. Os contentores do Work na nuvem mantêm as políticas existentes do Work Cloud, e os controlos de dispositivo suportados continuam a aplicar-se à execução local. O Codex mantém o seu comportamento de configuração existente. A configuração gerida não concede uma licença no espaço de trabalho nem acesso a funcionalidades. Utilize Funções e permissões do espaço de trabalho para esses controlos.

Agent Security e acesso ao computador local com o Work Cloud

Utilize Agent Security na Consola de administração para gerir políticas e configurações. Substitui Policies & Configuration. Agent Security está disponível na Consola de administração, independentemente do acesso ao computador local com o Work Cloud. As políticas, atribuições e ordenação existentes são preservadas. Reveja as suas políticas existentes em Agent Security. O acesso ao computador local com o Work Cloud requer uma adesão separada. Consulte Agent Security para obter orientações sobre a migração.

Antes de transferir a automatização de políticas para Agent Security:

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

2. Utilize a API de políticas para gerir as definições Global. Para gerir as definições Local ou Codex Cloud, utilize a interface de Agent Security. Os fluxos de trabalho existentes da API Global continuam disponíveis após a migração. Teste os seus scripts e integrações do Terraform e confirme que as atribuições e a ordenação das políticas se mantêm inalteradas.

3. Efetue as alterações necessárias e teste a automatização. Verifique se uma atualização pretendida chega à política correta de Agent Security e se os controlos resultantes são impostos.

A migração de políticas não concede acesso ao computador local para o Work ou os dots. Recomenda-se rever ou criar políticas antes da implementação, mas o fluxo de confirmação não exige a criação de políticas para ativar o acesso. Antes de ativar Permitir acesso ao computador local, reveja a configuração de base migrada ou crie uma configuração de base na nuvem se as suas políticas forem atualmente distribuídas apenas através de MDM. Se enforce_residency estiver ativado em qualquer política na nuvem, Permitir acesso ao computador local fica desativado tanto para o Work como para os dots. Esta salvaguarda não configura a residência dos dados do espaço de trabalho nem, por si só, desativa o Work Cloud ou os dots.

As substituições por ambiente permitem variar as definições suportadas numa política. Numa determinada política, a ordem da prioridade mais alta para a mais baixa é: substituição por ambiente específica do sistema operativo → substituição por ambiente para todos os sistemas operativos → Global. Uma política de prioridade superior continua a prevalecer sobre uma política de prioridade inferior, mesmo quando a política de prioridade inferior é mais específica. Alguns requisitos têm regras de combinação específicas de cada campo. Confirme os editores de substituições e os campos disponíveis para o seu espaço de trabalho.

Quando a política gerida e os hooks remotos estão ativados, o Work Cloud com acesso local e os dots utilizam hooks MCP remotos geridos pelo administrador no orquestrador na nuvem. Configure os processadores mcp_tool no ficheiro Global requirements.toml. O Work Cloud sem acesso local e as contas pessoais não utilizam estes hooks empresariais. Os processadores de comandos/shell, de prompts e de agentes; os hooks de configurações locais, plugins ou diretórios locais; os hooks com âmbito de ambiente; e os hooks MCP SessionEnd não são suportados com orquestração na nuvem, mesmo quando as ferramentas são executadas localmente. Quando tanto a orquestração como a execução são locais, os hooks suportados existentes continuam a funcionar em conversas do Work e do Codex exclusivamente locais. Os administradores continuam a poder configurar hooks geridos suportados em Agent Security para esses fluxos de trabalho. Antes de depender destes hooks, teste a conectividade dos callbacks, os eventos necessários e o comportamento em caso de falha. Uma recusa explícita suportada pode bloquear uma ação, mas um erro de callback PreToolUse, um tempo limite excedido ou uma resposta malformada pode fazer com que o hook falhe sem bloquear a ferramenta. Os hooks MCP não fornecem um registo de auditoria completo da Compliance API. Consulte a Referência de configuração.

Localizações e precedência

Na execução local, os requisitos são aplicados da prioridade mais baixa para a mais alta, conforme indicado a seguir. Esta ordenação também se aplica aos passos locais no acesso ao computador local com o Work Cloud:

1. requirements.toml do sistema (/etc/codex/requirements.toml em sistemas Unix, incluindo Linux e macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml no Windows).
2. Requisitos de Agent Security distribuídos no pacote de configuração na nuvem.
3. Campos legados de managed_config.toml que o cliente local reinterpreta como requisitos.
4. Preferências geridas do macOS (MDM) distribuídas através de com.openai.codex:requirements_toml_base64.

As camadas de precedência superior substituem os valores escalares e de lista comuns das camadas inferiores. As tabelas são combinadas por chave, enquanto requisitos como regras, hooks e restrições do sistema de ficheiros têm um comportamento de composição específico de cada campo. Consulte a referência de requirements.toml para obter o esquema atual, em vez de presumir que todos os campos são combinados da mesma forma.

Para manter a retrocompatibilidade, os clientes locais suportados reinterpretam os campos legados approval_policy, approvals_reviewer e sandbox_mode como requisitos. Esta conversão acrescenta opções de compatibilidade quando necessário; utilize requirements.toml para listas explícitas de permissões.

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

Para o Work com acesso local e os dots, distinga a política Global do orquestrador da política de execução. Os requisitos locais aplicáveis regem o computador ligado. Os contentores do Work na nuvem e os computadores dos dots na nuvem utilizam a sua própria configuração de execução e os seus próprios requisitos, em vez do pacote de ambiente gerido utilizado por outros executores.

Para a execução local, os requisitos MDM e os requisitos legados de dispositivos geridos têm prioridade sobre Agent Security. O ficheiro de requisitos do sistema do dispositivo tem prioridade inferior a Agent Security. Em cada política, resolva primeiro as substituições de ambiente específicas do sistema operativo, depois as substituições de ambiente para todos os sistemas operativos e, por fim, Global. Entre políticas, a prioridade da política prevalece sobre a especificidade.

Os requisitos impõem restrições, enquanto as predefinições de configuração fornecem valores iniciais. Para Work com acesso local e dots, a política Global suportada aplica-se através do orquestrador partilhado na nuvem quando a política gerida está ativada. Os requisitos locais aplicáveis de requirements.toml regem a execução num computador ligado. Os contentores na nuvem do Work e os computadores na nuvem do dots utilizam a sua própria configuração de execução e os seus próprios requisitos, em vez do pacote de ambiente gerido utilizado por outros tipos de executores. As restrições de execução local não se aplicam automaticamente a estes computadores na nuvem. Reveja as permissões das capacidades na nuvem e teste separadamente a execução local e na nuvem.

Mantenha os controlos do orquestrador, incluindo aprovações e pesquisa na Web, em Global. Utilize os controlos dedicados Políticas de aprovação permitidas e Modos de pesquisa na Web permitidos, quando disponíveis, e TOML para os outros campos suportados. Consulte a Referência de configuração para obter a lista de campos e o âmbito de execução.

Requisitos geridos na nuvem

Quando um utilizador inicia sessão com ChatGPT num plano suportado, os clientes locais suportados podem receber requisitos impostos pelo administrador e associados ao espaço de trabalho. Este é um canal de distribuição de políticas compatíveis com requirements.toml. Não concede acesso ao espaço de trabalho nem substitui o RBAC do espaço de trabalho. Os requisitos de autenticação têm de ser geridos localmente.

Configure os requisitos comuns com os controlos de segurança do agente. Para uma política que permita apenas aprovações on-request e sandboxes read-only ou workspace-write, utilize Políticas de aprovação e Modos de sandbox em Salvaguardas da política. Para também pedir confirmação antes de um ponto de entrada de shell suportado ser executado, utilize Editar como TOML para adicionar a tabela [rules] a requirements.toml em Global.

O equivalente completo em TOML é:

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" },
]

Verifique se todas as versões dos clientes geridos suportam as chaves que selecionar. Atribua a política aos utilizadores ou grupos pretendidos e verifique se entra em vigor nos respetivos clientes suportados. Utilize a referência de configuração para consultar o esquema atual e a interface de administração para consultar o comportamento atual de atribuição.

O serviço seleciona as camadas de requisitos geridos pela empresa que se aplicam à identidade com sessão iniciada. O cliente local avalia essas camadas em conjunto com as outras fontes de requisitos descritas em Localizações e precedência. Utilize a interface de administração atual para a criação e atribuição 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 consultar as chaves suportadas e exemplos, consulte Exemplo de requirements.toml e a referência de requirements.toml.

Como os clientes locais aplicam os requisitos geridos na nuvem

O comportamento de carregamento local e de cache descrito abaixo refere-se aos clientes locais suportados. Não determina quando uma política na nuvem alterada entra em vigor numa tarefa já em execução que utilize o acesso ao computador local com Work Cloud. Verifique a política efetiva antes de depender de uma restrição alterada.

Quando um utilizador inicia um cliente local suportado e inicia sessão com ChatGPT num plano suportado, o cliente verifica primeiro se existe uma entrada de cache válida e correspondente à identidade. Se não existir uma entrada válida, o cliente obtém o pacote aplicável com novas tentativas e grava uma entrada de cache assinada se a operação for bem-sucedida. Se o pedido falhar ou exceder o tempo limite e não existir uma cache válida, o carregamento do pacote de configuração na nuvem devolve um erro, em vez de iniciar silenciosamente sem a camada de requisitos geridos na nuvem.

Após a resolução da 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 disponibiliza-o para carregamentos de configuração posteriores. Isto não garante que uma tarefa já em execução utilize imediatamente uma política alterada. Algumas definições da aplicação de computador exigem que esta seja reiniciada; siga qualquer pedido de reinício e verifique as definições efetivas antes de depender da alteração.

Confirme a experiência do administrador e do colaborador

Designe uma pessoa responsável por cada política gerida, registe os utilizadores ou grupos que a devem receber e documente a justificação empresarial de qualquer restrição do sistema de ficheiros, da rede, de aprovação ou do perfil de permissões.

Teste um fluxo de trabalho permitido e um fluxo de trabalho bloqueado com um utilizador que tenha as permissões pretendidas. Verifique as definições efetivas no cliente suportado. Uma função ou um grupo do espaço de trabalho, por si só, não impõe uma restrição ao ambiente de execução local.

Utilize Testar políticas em Agent security para verificar que políticas correspondem a uma seleção de membro, grupo ou função. Numa sessão editável, esta ação verifica o rascunho atual sem o guardar. O resultado mostra a seleção de políticas, não a configuração final combinada nem se um cliente impõe uma restrição. Depois de guardar, teste os fluxos de trabalho permitidos e bloqueados em cada cliente e via de execução relevantes.

Implemente a configuração gerida pelo dispositivo

Utilize os requisitos do sistema local ou MDM para restrições de autenticação e políticas geridas pelo dispositivo. O mecanismo legado managed_config.toml tem uma precedência no arranque diferente da de Predefinições em Agent security. O fluxo de trabalho MDM abrange tanto os requisitos como as predefinições legadas.

Faça a gestão da autenticação localmente

Defina allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store e chatgpt_base_url no ficheiro do sistema local requirements.toml ou nos requisitos MDM do macOS. O Codex ignora estes quatro campos nos requisitos geridos na nuvem. Os requisitos de autenticação locais aplicam-se antes de as credenciais serem carregadas e antes de o Codex obter a política da nuvem.

Para exigir o início de sessão com ChatGPT num espaço de trabalho aprovado e guardar as credenciais no armazenamento de credenciais do sistema operativo, utilize:

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 for omitida, esta definição não restringe os métodos de início de sessão. Se for definida, a lista tem de conter pelo menos um método. api permite a autenticação por API, incluindo Amazon Bedrock. A restrição do 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 utilizador têm de cumprir os requisitos. Quando um utilizador seleciona um espaço de trabalho, este também tem de constar na lista gerida de espaços de trabalho permitidos. Se nenhum espaço de trabalho corresponder, o início de sessão com ChatGPT fica indisponível. A autenticação por API continua disponível quando permitida. Se nenhum método de início de sessão estiver disponível, o Codex recusa iniciar.

Consulte a referência de requisitos para obter informações sobre os modos de armazenamento de credenciais e a configuração do URL do serviço.

Predefinições geridas (managed_config.toml)

Utilize Predefinições de Agent security para os valores iniciais suportados geridos na nuvem. Esta secção abrange o mecanismo legado gerido pelo dispositivo managed_config.toml e a sua precedência diferente no arranque. A edição de Predefinições em Agent security não implementa um ficheiro managed_config.toml nos dispositivos dos membros.

As predefinições geridas determinam a configuração com que um cliente local suportado inicia. No arranque, substituem o config.toml local do utilizador e quaisquer substituições --config da CLI. Os utilizadores continuam a poder alterar essas definições durante a execução atual e as predefinições voltam a ser aplicadas da próxima vez que o cliente iniciar.

O GPT-5.5 é descontinuado no Codex com início de sessão no ChatGPT em 14 de outubro de 2026, ao meio-dia PDT (19:00 UTC). Se uma predefinição gerida, um perfil MDM do macOS ou uma configuração guardada fixar gpt-5.5 para esses utilizadores, substitua-o por um modelo disponível. Escolha gpt-6.1-sol depois de um administrador o ter ativado para os utilizadores afetados. A OpenAI API e as sessões do Codex autenticadas com uma API key não são afetadas. Consulte a disponibilidade de modelos no espaço de trabalho.

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

Certifique-se de que as predefinições geridas cumprem os seus requisitos; o ambiente de execução local rejeita valores não permitidos.

Precedência e camadas

O ambiente de execução local reúne a configuração efetiva pela seguinte ordem (os elementos superiores substituem os inferiores):

• Preferências geridas (MDM do macOS; precedência mais alta)
• managed_config.toml (ficheiro de sistema/gerido)
• config.toml (configuração de base do utilizador)

As substituições --config key=value do CLI aplicam-se à base, mas as camadas geridas substituem-nas. Isto significa que cada execução começa com as predefinições geridas, mesmo que forneça sinalizadores locais.

O config.toml da nuvem utiliza a precedência de configuração normal, não a ordem antiga acima. O requirements.toml da nuvem utiliza a precedência de requisitos.

Localizações

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

Se o ficheiro não existir, o ambiente de execução local ignora a camada gerida.

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"            # point at your collector
log_user_prompt = false            # keep prompts redacted
# exporter details live under exporter tables; see Monitoring and telemetry above

Salvaguardas recomendadas

• Prefira workspace-write com aprovações para a maioria dos utilizadores; reserve o acesso total para contentores controlados.
• Mantenha network_access = false, salvo se a sua avaliação de segurança permitir um coletor ou domínios necessários aos seus fluxos de trabalho.
• Utilize a configuração gerida para fixar as definições de OTel (exportador, ambiente), mas mantenha log_user_prompt = false, salvo se a sua política permitir explicitamente o armazenamento do conteúdo dos prompts.
• Audite periodicamente as diferenças entre o config.toml local e a política gerida para detetar desvios; as camadas geridas devem prevalecer sobre as opções e os ficheiros locais.

Preferências geridas do macOS (MDM)

No macOS, os administradores podem enviar um perfil de dispositivo que fornece conteúdos TOML codificados em base64 em:

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

O ambiente de execução local interpreta estes payloads de "preferências geridas" como TOML. Para os valores predefinidos geridos (config_toml_base64), as preferências geridas têm a maior precedência. Para os requisitos (requirements_toml_base64), a precedência segue a ordem dos requisitos. A mesma tabela [features] dos requisitos funciona em requirements_toml_base64; utilize também aí as chaves canónicas das funcionalidades.

Fluxo de trabalho de configuração de MDM

O ambiente de execução local respeita os conteúdos MDM padrão do macOS, pelo que pode distribuir definições com ferramentas como Jamf Pro, Fleet ou Kandji. Uma implementação simples tem o seguinte aspeto:

1. Crie o conteúdo TOML gerido e codifique-o com base64 (sem quebra de linha).
2. Coloque a cadeia no seu perfil MDM, no domínio com.openai.codex, em config_toml_base64 (predefinições geridas) ou requirements_toml_base64 (requisitos).
3. Envie o perfil e, em seguida, peça aos utilizadores que reiniciem o cliente local suportado e confirmem que o resumo da configuração de arranque reflete os valores geridos.
4. Ao revogar ou alterar a política, atualize o conteúdo gerido; o cliente lê a preferência atualizada da próxima vez que for iniciado.

Evite incorporar segredos ou valores dinâmicos que mudem frequentemente no conteúdo. Submeta o TOML gerido ao mesmo controlo de alterações que qualquer outra definição MDM.