Configuração gerida

A configuração gerida controla o comportamento suportado do ambiente de execução local para capacidades abrangidas na aplicação ChatGPT para computador, no Codex CLI e na extensão do IDE. Os requisitos suportados podem variar consoante o cliente e a versão. A configuração gerida não concede acesso ao espaço de trabalho do ChatGPT, não atribui licenças nem substitui o controlo de acesso baseado em funções (RBAC) do espaço de trabalho. Utilize Funções e permissões do espaço de trabalho para o acesso às funcionalidades do espaço de trabalho e esta página para a política do ambiente de execução local.

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.
Valores predefinidos de configuração: definições de config.toml geridas pelo sistema ou pela nuvem que os utilizadores podem substituir.
Valores predefinidos geridos legados: valores iniciais de managed_config.toml aplicados quando um cliente suportado é iniciado. Os utilizadores podem continuar a alterar definições durante uma execução; o cliente volta a aplicar estes valores predefinidos no arranque seguinte.

Configurar marketplaces de plugins e predefinições

Defina marketplaces locais ou Git e predefinições de plugins no config.toml do sistema ou na secção config.toml de Configuração gerida. Estas definições são predefinições, não uma política imposta.

Consulte a Referência de configuração para conhecer as chaves de configuração, a Precedência de configuração para saber mais sobre substituições e as definições de plugins do repositório para configurar ao nível do projeto. A importação e sincronização do GitHub na área de trabalho são independentes.

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 servidores MCP 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 servidor MCP 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.

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 das predefinições geridas, do antigo managed_config.toml e de qualquer configuração de utilizador, projeto, perfil ou arranque que a defina.

Para utilização interativa apenas de leitura, selecione approval_policy = "on-request" com uma sandbox ou um perfil de permissões apenas de leitura permitido pelos 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 substitui essa política. Consulte Migrar da política de aprovação untrusted descontinuada para ver exemplos e ponderar as implicações de segurança.

Localizações e precedência

Cada cliente local suportado compõe os requisitos da precedência mais baixa para a mais alta:

requirements.toml do sistema (/etc/codex/requirements.toml em sistemas Unix, incluindo Linux e macOS, ou %ProgramData%\OpenAI\Codex\requirements.toml no Windows).
Requisitos geridos pela empresa fornecidos no pacote de configuração na cloud.
Campos legados managed_config.toml que o cliente local reinterpreta como requisitos.
Preferências geridas do macOS (MDM) fornecidas através de com.openai.codex:requirements_toml_base64.

As camadas com precedência superior substituem os valores escalares e de listas comuns das camadas com precedência inferior. As tabelas são intercaladas por chave, enquanto requisitos como regras, hooks e restrições do sistema de ficheiros têm comportamentos de composição específicos dos campos. Utilize a referência requirements.toml para consultar o esquema atual, em vez de presumir que todos os campos são intercalados 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 adiciona opções de compatibilidade quando necessário; utilize requirements.toml para listas de permissões explícitas.

Requisitos geridos na cloud

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

Abra Managed configuration para criar e atribuir requisitos geridos na cloud. Por exemplo, esta política limita as opções de aprovação e de sandbox e solicita confirmação antes da execução de um ponto de entrada de shell suportado:

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

Confirme que cada versão de cliente gerida suporta as chaves que selecionar e teste a política com um pequeno grupo antes de a atribuir a toda a organização. Utilize a referência de configuração para consultar o esquema atual e a superfície de administração para consultar o comportamento atual das atribuições.

O serviço seleciona as camadas de requisitos geridas pela empresa aplicáveis à identidade com sessão iniciada. O cliente local avalia essas camadas em conjunto com as outras origens de requisitos descritas em Localizações e precedência. Utilize a superfície de administração atual para criar e atribuir elementos do lado do espaço de trabalho. Não dependa de um algoritmo de correspondência de grupos copiado; o serviço de administração é responsável por esse comportamento e pode alterá-lo independentemente do formato de requisitos local.

Para consultar as chaves suportadas e exemplos, consulte Exemplo de requirements.toml e a referência requirements.toml.

Como os clientes locais aplicam requisitos geridos na cloud

Quando um utilizador inicia um cliente local suportado e inicia sessão com o ChatGPT num plano suportado, o cliente começa por procurar uma entrada de cache válida e correspondente à identidade. Se não estiver disponível uma entrada válida, o cliente obtém o pacote aplicável com novas tentativas e, em caso de êxito, grava uma entrada de cache assinada. Se o pedido falhar ou exceder o tempo limite e não estiver disponível uma cache válida, o carregamento do pacote de configuração na cloud devolve um erro, em vez de iniciar silenciosamente sem a camada de requisitos geridos na cloud.

Após a resolução da cache, o cliente compõe os requisitos da cloud com as outras camadas de requisitos descritas acima. Uma atualização em segundo plano pode atualizar a cache para um arranque posterior; não substitui os requisitos já carregados no processo atual.

Confirmar a experiência do administrador e do colaborador

Atribua a uma pessoa a responsabilidade 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.

Antes de alargar a implementação, teste um fluxo de trabalho aprovado e outro intencionalmente não permitido com um utilizador representativo. Verifique as definições efetivas no cliente suportado, em vez de presumir que uma função ou um grupo do espaço de trabalho, por si só, aplica a restrição local.

Gerir a 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 de MDM do macOS. O Codex ignora estes quatro campos nos requisitos geridos na nuvem. Os requisitos de autenticação locais aplicam-se antes do carregamento das credenciais e antes de o Codex obter a política da nuvem.

Para exigir o início de sessão com o ChatGPT numa área de trabalho aprovada 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 o Amazon Bedrock. A restrição da área de trabalho também se aplica aos tokens de acesso do Codex.

As definições forced_login_method e forced_chatgpt_workspace_id configuradas pelo utilizador têm de cumprir os requisitos. Quando um utilizador seleciona uma área de trabalho, esta também tem de constar na lista gerida de áreas de trabalho permitidas. Se nenhuma área de trabalho corresponder, o início de sessão com o ChatGPT fica indisponível. A autenticação por API permanece disponível quando permitida. Se nenhum método de início de sessão estiver disponível, o Codex recusa-se a iniciar.

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

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.

Desativar Appshots

Para desativar Appshots para utilizadores geridos, defina o requisito de nível superior allow_appshots:

allow_appshots = false

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

Desativar o controlo remoto de dispositivos

Para desativar o controlo remoto de dispositivos para utilizadores geridos, defina o requisito de nível superior allow_remote_control:

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 ligações SSH remotas.

Controlar os perfis de permissões 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.

Substituir requisitos de sandbox por anfitrião

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.

Também pode restringir o modo de pesquisa na Web:

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 em direto na Web, mesmo em sessões danger-full-access.

Configurar requisitos de acesso à rede

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 reencaminhamento de DNS são iguais ao comportamento de rede da sandbox descrito em Aprovações e segurança do agente.

O proxy encaminha comandos locais executados dentro do ambiente isolado. 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, não do encaminhamento do tráfego do navegador através do proxy de comandos. Não filtra pesquisas na Web, aplicações e conectores, servidores MCP, tráfego de aplicações nativas, pedidos ao serviço Codex nem tráfego do Codex cloud. Utilize os controlos de cada interface:

Utilize allowed_web_search_modes para restringir a pesquisa na Web.
Utilize features.apps = false para desativar integrações de aplicações e conectores e features.plugins = false para desativar plugins quando suportado.
Utilize a lista gerida de servidores aprovados mcp_servers para restringir os servidores MCP.
Utilize requisitos de funcionalidades como browser_use, in_app_browser e computer_use para restringir as capacidades do browser e de utilização do computador.
Configure o acesso à rede do Codex cloud nas respetivas definições do ambiente de cloud.

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

Controlar o navegador e o Computer Use

Utilize as tabelas [browser_use] e [computer_use] em requirements.toml para restringir os clientes de computador suportados. Valide a política nas versões dos clientes e nos sistemas operativos da sua implementação. Uma regra de permissão configurada não instala um plugin, não concede uma permissão do sistema operativo nem aprova uma ação que continue a exigir revisão.

Para o acesso pelo navegador, configure uma política de origens. Uma origem inclui o esquema, o anfitrião e uma porta opcional, como https://example.com ou https://*.example.com:8443. Não inclua um caminho, uma consulta nem um fragmento. Ao contrário das regras de domínio da rede de comandos, as regras de origem do navegador distinguem HTTP de HTTPS e fazem a correspondência da porta.

Este exemplo restringe o acesso pelo navegador a um site aprovado e impede carregamentos e o acesso completo ao Chrome DevTools Protocol (CDP) nesse site:

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

As regras de origem correspondentes são resolvidas por campo. Um bloqueio correspondente prevalece; caso contrário, a política de origem predefinida fornece os campos que as regras correspondentes não especificam. A configuração local pode adicionar restrições, mas não pode flexibilizar um bloqueio gerido. Os bloqueios de rede e as listas exclusivas de permissões de rede geridas continuam a ser aplicados.

Defina browser_use.disable_auto_review = true para desativar a revisão automática de aprovações de ações do navegador ou defina auto_review = "deny" numa política de origem para a restringir nessa origem. Isto controla o tratamento das aprovações, mas não desativa a monitorização de segurança do modelo.

Para aplicações nativas, defina uma política de acesso predefinida e identifique as aplicações permitidas. Por exemplo, esta política do macOS permite a Calculadora e impede que as aprovações sejam guardadas:

[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 em pacotes através de computer_use.windows.aumids ou executáveis através de computer_use.windows.exes. As regras de executáveis exigem publisher_name, product_name e access; binary_name é opcional. Utilize a identidade verificada da aplicação, e não apenas o respetivo nome de apresentação.

Consulte a referência de configuração para ver todos os campos e as restrições de utilização bloqueada para dispositivos macOS geridos.

Fixar sinalizadores de funcionalidades

Também pode fixar sinalizadores de funcionalidades para utilizadores que recebam um requirements.toml gerido:

[features]
personality = 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 de funcionalidades canónicas da tabela [features] de config.toml para funcionalidades do ambiente de execução. O ambiente de execução local normaliza as funcionalidades reconhecidas para respeitar estas fixações e rejeita escritas em conflito em config.toml ou nas definições de funcionalidades do ficheiro de perfil.

in_app_browser = false desativa o painel de browser incorporado.
in_app_updates = false desativa o atualizador próprio da aplicação ChatGPT para computador ao reiniciar, quando suportado. Não afeta a implementação de pacotes externos nem prolonga o suporte para versões antigas da aplicação. Para obter orientações de configuração e implementação, consulte Gerir atualizações da aplicação.
browser_use = false desativa o Computer Use nos browsers e a disponibilidade do Browser Agent.
browser_use_full_cdp_access = false desativa o acesso CDP completo no ambiente de execução local, incluindo o modo Browser Developer, e impede que a aplicação ChatGPT para computador ative a definição correspondente.
browser_use_external = false desativa o Browser Use externo.
computer_use = false desativa o Computer Use, Record & Replay e os fluxos de instalação ou configuração relacionados.

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

Restringir a utilização num computador bloqueado

Para impedir que os utilizadores ativem a Utilização bloqueada num Mac gerido, adicione este requisito:

[computer_use]
allow_locked_computer_use = false

Este requisito remove os controlos para ativar a Utilização bloqueada. Não desativa a Utilização bloqueada se esta já estiver ativada. Se o omitir, a disponibilidade normal do produto e a definição local do utilizador continuam a ser aplicadas.

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

Utilize allowed_approvals_reviewers para exigir ou permitir a revisão automática. Defina-o como ["auto_review"] para exigir a 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 incorporado e o contrato de saída. O guardian_policy_config gerido tem precedência sobre o [auto_review].policy local.

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

Impor requisitos de recusa de leitura

Os administradores podem recusar 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 recusa 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 do espaço de trabalho para poder impô-los. No Windows nativo, o deny_read gerido aplica-se a ferramentas diretas de ficheiros; as leituras de subprocessos do shell não utilizam esta regra da sandbox.

Impor hooks geridos a partir dos requisitos

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

Para impor hooks geridos mesmo aos utilizadores que desativaram localmente os hooks, fixe [features].hooks = true em conjunto com [hooks]. Para ignorar hooks de utilizador, projeto, sessão e plugin, permitindo ainda assim 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 em managed_dir.
Forneça esses scripts através da sua solução de MDM ou gestão de dispositivos.
Os comandos de hooks geridos devem referenciar caminhos absolutos de scripts no diretório gerido configurado.
allow_managed_hooks_only = true ignora hooks provenientes de origens de utilizador, projeto, sessão e plugin, mas continua a carregar hooks de requirements.toml e de outras camadas de configuração geridas.

Impor regras de comandos a partir dos requisitos

Os administradores também podem impor regras restritivas de comandos a partir de requirements.toml através de uma tabela [rules]. Estas regras são intercaladas 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 servidores MCP que um cliente local pode ativar, adicione uma lista de aprovados mcp_servers. Para servidores stdio, faça a correspondência com command; para servidores HTTP transmissíveis, faç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 identity.command corresponde apenas ao command configurado. Não inspeciona args, cwd, env nem env_vars.

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

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

Controlar a disponibilidade de plugins

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

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.

Predefinições geridas (`managed_config.toml`)

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.

Se uma predefinição gerida, um perfil MDM do macOS ou uma configuração guardada fixar gpt-5.5 para utilizadores do Codex com sessão iniciada através do ChatGPT, substitua-o por gpt-5.6-sol antes de 14 de outubro de 2026. O GPT-5.5 deixará de estar disponível no ChatGPT, ChatGPT Work e Codex em todos os planos nessa data. A API da OpenAI não é afetada. Consulte a disponibilidade de modelos no espaço de trabalho.

Se uma predefinição gerida, um perfil MDM do macOS ou uma configuração guardada fixar gpt-5.4 ou gpt-5.4-mini para utilizadores com sessão iniciada no ChatGPT, atualize-a antes de 31 de agosto de 2026. Substitua gpt-5.4 por gpt-5.6-terra e gpt-5.4-mini por gpt-5.6-luna. A OpenAI API e o Codex autenticado com a sua própria API key não são afetados. Consulte a disponibilidade de modelos no espaço de trabalho.

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.

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 analisa estes conteúdos de «preferências geridas» como TOML. Para as predefinições geridas (config_toml_base64), as preferências geridas têm a precedência mais alta. Para os requisitos (requirements_toml_base64), a precedência segue a ordem dos requisitos geridos na cloud descrita acima. A mesma tabela [features] do lado dos requisitos funciona em requirements_toml_base64; utilize também aí as chaves de funcionalidades canónicas.

Fluxo de trabalho de configuração do 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:

Crie o conteúdo TOML gerido e codifique-o com base64 (sem quebra de linha).
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).
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.
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.

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

Dê preferência a 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 revisão de segurança permitir um coletor ou os domínios exigidos pelos seus fluxos de trabalho.
Utilize a configuração gerida para fixar definições de OTel (exportador, ambiente), mas mantenha log_user_prompt = false, salvo se a sua política permitir explicitamente armazenar o conteúdo dos pedidos.
Audite periodicamente as diferenças entre o config.toml local e a política gerida para detetar desvios; as camadas geridas devem prevalecer sobre sinalizadores e ficheiros locais.

Pesquisas recentes

Pesquisas sugeridas

Navegação da documentação

Configurar marketplaces de plugins e predefinições

Requisitos impostos pelo administrador (requirements.toml)

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

Localizações e precedência

Requisitos geridos na cloud

Como os clientes locais aplicam requisitos geridos na cloud

Confirmar a experiência do administrador e do colaborador

Gerir a autenticação localmente

Exemplo de requirements.toml

Desativar Appshots

Desativar o controlo remoto de dispositivos

Controlar os perfis de permissões disponíveis

Permitir os perfis padrão

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

Permitir apenas perfis definidos pela empresa

Desativar um perfil permitido por outra origem

Substituir requisitos de sandbox por anfitrião

Configurar requisitos de acesso à rede

Controlar o navegador e o Computer Use

Fixar sinalizadores de funcionalidades

Restringir a utilização num computador bloqueado

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

Impor requisitos de recusa de leitura

Impor hooks geridos a partir dos requisitos

Impor regras de comandos a partir dos requisitos

Controlar a disponibilidade de plugins

Restringir origens de marketplaces de plugins

Predefinições geridas (`managed_config.toml`)

Precedência e camadas

Localizações

Preferências geridas do macOS (MDM)

Fluxo de trabalho de configuração do MDM

Exemplo de managed_config.toml

Salvaguardas recomendadas

Configurar marketplaces de plugins e predefinições

Requisitos impostos pelo administrador (requirements.toml)

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

Localizações e precedência

Requisitos geridos na cloud

Como os clientes locais aplicam requisitos geridos na cloud

Confirmar a experiência do administrador e do colaborador

Gerir a autenticação localmente

Exemplo de requirements.toml

Desativar Appshots

Desativar o controlo remoto de dispositivos

Controlar os perfis de permissões disponíveis

Permitir os perfis padrão

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

Permitir apenas perfis definidos pela empresa

Desativar um perfil permitido por outra origem

Substituir requisitos de sandbox por anfitrião

Configurar requisitos de acesso à rede

Controlar o navegador e o Computer Use

Fixar sinalizadores de funcionalidades

Restringir a utilização num computador bloqueado

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

Impor requisitos de recusa de leitura

Impor hooks geridos a partir dos requisitos

Impor regras de comandos a partir dos requisitos

Controlar a disponibilidade de plugins

Restringir origens de marketplaces de plugins

Predefinições geridas (managed_config.toml)

Precedência e camadas

Localizações

Preferências geridas do macOS (MDM)

Fluxo de trabalho de configuração do MDM

Exemplo de managed_config.toml

Salvaguardas recomendadas

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

Predefinições geridas (`managed_config.toml`)