Configuração gerenciada

A configuração gerenciada controla o comportamento do ambiente de execução local para as capacidades abrangidas no aplicativo do ChatGPT para desktop, na Codex CLI e na extensão para IDE. Os requisitos compatíveis podem variar conforme o cliente e a versão. A configuração gerenciada não concede acesso ao workspace do ChatGPT, não atribui licenças nem substitui o controle de acesso baseado em funções (RBAC) do workspace. Consulte Funções e permissões do workspace para controlar o acesso aos recursos do workspace e esta página para definir a política do ambiente de execução local.

Os administradores empresariais podem controlar o comportamento dos clientes locais compatíveis de duas maneiras:

• Requisitos: restrições impostas pelos administradores que os usuários não podem substituir.
• Valores padrão gerenciados: valores iniciais aplicados quando um cliente compatível é iniciado. Os usuários ainda podem alterar as configurações durante uma execução; o cliente reaplica os valores padrão gerenciados na próxima inicialização.

Requisitos impostos pelos administradores (requirements.toml)

Os requisitos restringem configurações sensíveis à segurança (política de aprovação, revisor de aprovações, política de revisão automática, modo de sandbox, perfis de permissão, modo de Pesquisa na Web, hooks gerenciados, quais servidores MCP os usuários podem habilitar e quais fontes do Marketplace de plug-ins configuradas pelos usuários eles podem adicionar, usar para instalação ou atualizar). Ao resolver uma configuração (por exemplo, com base em config.toml, arquivos de perfil ou substituições de configuração da CLI), se um valor entrar em conflito com uma regra imposta, o cliente local usará um valor compatível e notificará o usuário. Se você configurar uma lista de permissões em mcp_servers, o cliente só habilitará um servidor MCP quando seu nome e sua identidade corresponderem a uma entrada aprovada; caso contrário, o cliente o desabilitará.

Os requisitos também podem restringir sinalizadores de recursos por meio da tabela [features] em requirements.toml. Os recursos nem sempre são sensíveis à segurança, mas as empresas podem fixar valores, se desejarem. As chaves omitidas não ficam sujeitas a restrições.

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

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

Locais e precedência

Cada cliente local compatível combina os requisitos da menor para a maior precedência:

1. O 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 gerenciados pela empresa fornecidos no pacote de configuração da nuvem.
3. Campos legados de managed_config.toml que o cliente local reinterpreta como requisitos.
4. Preferências gerenciadas do macOS (MDM) fornecidas por meio de com.openai.codex:requirements_toml_base64.

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

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

Requisitos gerenciados na nuvem

Quando um usuário faz login com o ChatGPT em um plano compatível, os clientes locais compatíveis podem receber requisitos impostos pelos administradores e associados ao workspace. Esse é um canal para distribuir políticas compatíveis com requirements.toml. Ele não concede acesso ao workspace nem substitui o RBAC do workspace.

Abra Configuração gerenciada para criar e atribuir requisitos gerenciados na nuvem. Por exemplo, esta política limita as opções de aprovação e de sandbox e solicita confirmação antes que um ponto de entrada compatível do shell seja executado:

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 se todas as versões dos clientes gerenciados são compatíveis com as chaves selecionadas e teste a política com um grupo pequeno antes de atribuí-la à organização inteira. Use a referência de configuração para consultar o esquema atual e a interface de administração para verificar o comportamento atual das atribuições.

O serviço seleciona as camadas de requisitos gerenciados pela empresa aplicáveis à identidade autenticada. O cliente local avalia essas camadas juntamente com as demais fontes de requisitos descritas em Locais e precedência. Use a interface de administração atual para criar e atribuir requisitos no workspace. Não se baseie em um algoritmo copiado de correspondência de grupos; o serviço de administração controla esse comportamento e pode alterá-lo independentemente do formato dos requisitos locais.

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

Como os clientes locais aplicam requisitos gerenciados na nuvem

Quando um usuário inicia um cliente local compatível e faz login com o ChatGPT em um plano compatível, o cliente primeiro verifica se há uma entrada de cache válida associada à identidade. Se nenhuma entrada válida estiver disponível, o cliente busca o pacote aplicável, faz novas tentativas quando necessário e grava uma entrada de cache assinada se a busca for bem-sucedida. Se a solicitação falhar ou atingir o tempo limite e não houver cache válido disponível, o carregamento do pacote de configuração da nuvem retorna um erro, em vez de iniciar silenciosamente sem a camada de requisitos gerenciados na nuvem.

Após a resolução do cache, o cliente combina os requisitos da nuvem com as outras camadas de requisitos descritas acima. Uma atualização em segundo plano pode atualizar o cache para uma inicialização posterior; ela não substitui os requisitos já carregados no processo atual.

Confirmar a experiência dos administradores e funcionários

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

Antes de ampliar a implantação, teste um fluxo de trabalho aprovado e um fluxo de trabalho intencionalmente não permitido com um usuário representativo. Verifique as configurações efetivas no cliente compatível, em vez de presumir que uma função ou um grupo no workspace, por si só, garante a aplicação da restrição local.

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

Desativar as Capturas do app

Para desativar as Capturas do app para usuários gerenciados, defina o requisito de nível superior allow_appshots:

allow_appshots = false

Quando as Capturas do app estão disponíveis, allow_appshots = false as desativa. Se você omitir a chave, os requisitos não restringirão as Capturas do app, e as verificações normais de disponibilidade do produto serão aplicadas. Os clientes do App Server que leem os requisitos efetivos por meio de configRequirements/read recebem a mesma restrição no campo allowAppshots; um valor ausente ou null em allowAppshots não desativa as Capturas do app.

Desativar o controle remoto do dispositivo

Para desativar o controle remoto do dispositivo para usuários gerenciados, defina o requisito de nível superior allow_remote_control:

allow_remote_control = false

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

Controlar os perfis de permissão disponíveis

Use allowed_permission_profiles para controlar quais perfis de permissão integrados e personalizados os usuários podem selecionar. Esta é a opção para perfis de permissão correspondente a allowed_sandbox_modes; use a lista de permissões que corresponda à forma como os usuários selecionam permissões.

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

Use os exemplos de perfis de permissão abaixo somente depois que todos os clientes gerenciados executarem uma versão compatível. Não implante perfis personalizados gerenciados até que a atualização da frota esteja concluída.

Quando está presente, a tabela é a lista completa de perfis permitidos. Ela autoriza perfis definidos como true e bloqueia perfis omitidos ou definidos como false, inclusive perfis integrados adicionados em versões futuras do Codex.

Permitir os perfis padrão

Esta política permite acesso somente leitura e acesso ao workspace, mas não acesso completo:

default_permissions = ":workspace"

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

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

Os administradores podem definir um perfil personalizado na mesma fonte de requisitos. Use nomes de perfil específicos da organização que não entrem em conflito com nomes presentes na configuração carregada dos usuários. Os nomes personalizados não podem começar com : nem usar filesystem como nome, pois ele é reservado.

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

Por exemplo:

default_permissions = "acme_review_only"

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

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

Permitir somente perfis definidos pela empresa

Omita todos os perfis integrados quando os usuários só puderem 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 estender :workspace, mesmo que os usuários não possam selecionar diretamente o perfil integrado :workspace.

Desativar um perfil permitido por outra fonte

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

Requisitos da nuvem:

default_permissions = ":read-only"

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

Requisitos do sistema:

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

Defina default_permissions explicitamente como um perfil permitido. Se ele for omitido, o ambiente de execução local usará :workspace como padrão somente quando :workspace e :read-only estiverem explicitamente permitidos. Quando allowed_permission_profiles estiver ausente, os requisitos gerenciados não restringirão os nomes de perfil que os usuários podem selecionar. Cada entrada deve indicar um perfil integrado ou personalizado definido em uma configuração ou fonte de requisitos carregada. Defina perfis personalizados nos requisitos gerenciados para controlar o comportamento deles de forma centralizada.

Substituir os requisitos de sandbox por host

Use [[remote_sandbox_config]] quando uma única política gerenciada precisar aplicar requisitos de sandbox diferentes em hosts diferentes. Por exemplo, você pode manter um padrão mais rígido para laptops e permitir gravações no workspace em máquinas de desenvolvimento ou executores de CI correspondentes. Atualmente, as entradas específicas de host substituem somente 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 host obtido pela melhor resolução possível. Ele prioriza o nome de domínio totalmente qualificado quando disponível e, como alternativa, usa o nome do host local. A correspondência não diferencia maiúsculas de minúsculas; * corresponde a qualquer sequência de caracteres, e ? corresponde a um caractere.

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

Você também pode restringir o modo de Pesquisa na Web:

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

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

Configurar requisitos de acesso à rede

Use [experimental_network] em requirements.toml quando os administradores precisarem definir centralmente os requisitos de acesso à rede. Esses requisitos são independentes da opção features.network_proxy do usuário: eles podem configurar o acesso à rede do sandbox sem esse sinalizador de recurso, mas não concedem acesso à rede aos comandos quando o sandbox ativo mantém a rede desativada. Defina experimental_network.enabled = true para ativar o proxy gerenciado; uma lista de permissões, por si só, não ativa o proxy.

experimental_network.enabled = true
experimental_network.allowed_domains = [
  "api.openai.com",
  "*.example.com",
]
experimental_network.denied_domains = [
  "blocked.example.com",
  "*.exfil.example.com",
]

Use experimental_network.managed_allowed_domains_only = true somente quando você também definir allowed_domains sob controle dos administradores e quiser que essa lista de permissões seja exclusiva. Se o valor for true sem regras de permissão gerenciadas, as regras de permissão de domínios adicionadas pelos usuários deixam de ter efeito.

A sintaxe dos domínios, as regras para destinos locais ou privados, a prioridade da negação sobre a permissão e as limitações de DNS rebinding são as mesmas do comportamento de rede do sandbox descrito em Aprovações do agente e segurança.

Esses requisitos se aplicam apenas aos comandos locais executados dentro do sandbox. Eles não encaminham nem filtram a pesquisa na Web, aplicativos e conectores, servidores MCP, atividades do navegador ou de Uso do computador, solicitações ao serviço Codex nem o tráfego do Codex Cloud. Use os controles específicos de cada recurso:

• Use allowed_web_search_modes para restringir a pesquisa na Web.
• Use features.apps = false para desativar integrações com aplicativos e conectores e features.plugins = false para desativar plug-ins quando houver suporte.
• Use a lista gerenciada de servidores aprovados em mcp_servers para restringir os servidores MCP.
• Use requisitos de recursos como browser_use, in_app_browser e computer_use para restringir as capacidades do navegador e de Uso do computador.
• Configure o acesso à rede do Codex Cloud nas configurações do respectivo ambiente de nuvem.

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

Fixar sinalizadores de recursos

Você também pode fixar sinalizadores de recursos para usuários que recebem um arquivo requirements.toml gerenciado:

[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

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

• in_app_browser = false desativa o painel do navegador integrado.
• in_app_updates = false desativa o atualizador próprio do aplicativo do ChatGPT para desktop na reinicialização, quando houver suporte. Isso não afeta a implantação externa de pacotes nem estende o suporte a versões anteriores do aplicativo. Para orientações sobre configuração e implantação, consulte Gerenciar atualizações do aplicativo.
• browser_use = false desativa o Uso do computador em navegadores e a disponibilidade do Agente do navegador.
• browser_use_full_cdp_access = false desativa o acesso completo ao CDP no ambiente de execução local, inclusive o modo Desenvolvedor do navegador, e impede que o aplicativo do ChatGPT para desktop ative a configuração correspondente.
• browser_use_external = false desativa o Navegador externo.
• computer_use = false desativa o Uso do computador, o recurso Gravar e reproduzir e os fluxos relacionados à instalação ou configuração.

Se você omitir essas chaves, a política permitirá os recursos, sujeitos à disponibilidade normal no cliente, na plataforma e na implementação gradual.

Restringir o Uso do computador com o dispositivo bloqueado

Para impedir que o Uso do computador funcione após o bloqueio de um Mac gerenciado, adicione este requisito:

[computer_use]
allow_locked_computer_use = false

Este requisito não ativa o Uso do computador. Ele apenas impede o uso com o dispositivo bloqueado no macOS. Se você o omitir, os requisitos não restringirão o uso com o dispositivo bloqueado; a disponibilidade normal do produto e a configuração local do usuário continuarão válidas.

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

Use allowed_approvals_reviewers para exigir ou permitir a revisão automática. Defina o valor como ["auto_review"] para exigir a revisão automática ou inclua "user" quando os usuários puderem optar pela aprovação manual.

Defina guardian_policy_config para substituir a seção específica do tenant na política de revisão automática. O ambiente de execução local continua usando o modelo integrado do revisor e o contrato de saída. A configuração gerenciada guardian_policy_config tem precedência sobre a configuraçã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.
"""

Aplicar requisitos de negação de leitura

Os administradores podem negar a leitura de caminhos exatos ou correspondentes a padrões glob com [permissions.filesystem]. Os usuários não podem tornar esses requisitos menos restritivos com a configuração local.

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

Quando há requisitos de negação de leitura, o ambiente de execução local rejeita permissões de acesso completo e mantém a execução local em um sandbox somente leitura ou com acesso ao workspace para poder aplicá-los. No Windows nativo, o deny_read gerenciado se aplica às ferramentas de acesso direto a arquivos; as leituras feitas por subprocessos do shell não usam essa regra do sandbox.

Aplicar hooks gerenciados definidos nos requisitos

Os administradores também podem definir hooks de ciclo de vida gerenciados diretamente em requirements.toml. Use [hooks] para configurar os próprios hooks e configure managed_dir para apontar para o diretório em que sua ferramenta de MDM ou de gerenciamento de endpoints instala os scripts referenciados.

Para aplicar hooks gerenciados até mesmo aos usuários que os desativaram localmente, fixe [features].hooks = true junto com [hooks]. Para ignorar hooks do usuário, do projeto, da sessão e de plug-ins sem deixar de permitir hooks gerenciados, 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"

Observações:

• O ambiente de execução local aplica a configuração de hooks definida em requirements.toml, mas não distribui os scripts em managed_dir.
• Distribua esses scripts com sua solução de MDM ou gerenciamento de dispositivos.
• Os comandos de hooks gerenciados devem fazer referência a caminhos absolutos dos scripts no diretório gerenciado configurado.
• allow_managed_hooks_only = true ignora hooks provenientes de fontes do usuário, do projeto, da sessão e de plug-ins, mas continua carregando hooks de requirements.toml e de outras camadas de configuração gerenciada.

Aplicar regras de comandos definidas nos requisitos

Os administradores também podem aplicar regras restritivas de comandos definidas em requirements.toml usando uma tabela [rules]. Essas regras são mescladas aos arquivos .rules comuns, e a decisão mais restritiva continua prevalecendo.

Ao contrário de .rules, as regras definidas nos requisitos devem especificar decision, e essa decisão deve ser "prompt" ou "forbidden" (não "allow").

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

Para restringir quais servidores MCP um cliente local pode ativar, adicione em mcp_servers uma lista de servidores aprovados. Para servidores stdio, use command como critério de correspondência; para servidores HTTP com streaming, use url:

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

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

A representação em string de identity.command corresponde apenas ao command configurado. Ela 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 deles devem corresponder. As regras de argumentos e URL aceitam correspondência por exact, por prefix e por regex aplicado ao valor completo. As regras estruturadas de comandos continuam sem inspecionar cwd, env ou env_vars. Os servidores MCP incluídos em plug-ins usam os mesmos formatos 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 plug-ins

Para desativar plug-ins nos clientes locais compatíveis, defina features.plugins como false em requirements.toml:

features.plugins = false

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

Restringir as fontes do marketplace de plug-ins

Para restringir operações em fontes do marketplace configuradas pelo usuário, defina restrict_to_allowed_sources = true e crie uma ou mais regras para as fontes:

[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 comparam a URL normalizada do repositório e, quando presente, uma ref exata. Os padrões de host são expressões regulares comparadas ao host Git em minúsculas; use ^ e $ para fazer a correspondência do host inteiro. As regras locais exigem um caminho absoluto e normalizado. Consulte a referência de requirements.toml para conhecer o esquema completo e o comportamento de mesclagem.

Esses requisitos rejeitam operações de adição de marketplaces, instalação de plug-ins e atualização de marketplaces Git configurados que não correspondam às regras para fontes configuradas pelo usuário. Os marketplaces da OpenAI gerenciados pelo Codex continuam disponíveis quando a fonte e o nome reservado correspondem. Os requisitos não filtram marketplaces já configurados pelos usuários nem os respectivos plug-ins durante a execução.

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

Valores padrão gerenciados (managed_config.toml)

Os valores padrão gerenciados definem a configuração com que um cliente local compatível é iniciado. Na inicialização, eles substituem o arquivo config.toml local do usuário e quaisquer substituições fornecidas por --config na CLI. Os usuários ainda podem alterar essas configurações durante a execução atual, e os valores padrão voltam a ser aplicados na próxima inicialização do cliente.

Se um valor padrão gerenciado, um perfil MDM do macOS ou uma configuração salva fixar gpt-5.4 ou gpt-5.4-mini para usuários conectados com o ChatGPT, faça a atualização 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 API da OpenAI e o Codex autenticado com sua própria chave de API não são afetados. Consulte a disponibilidade de modelos no workspace.

Verifique se os valores padrão gerenciados atendem aos seus requisitos; o ambiente de execução local rejeita valores não permitidos.

Precedência e camadas

O ambiente de execução local compõe a configuração efetiva nesta ordem (os itens superiores substituem os inferiores):

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

As substituições --config key=value da CLI se aplicam à configuração base, mas as camadas gerenciadas têm precedência sobre elas. Isso significa que cada execução começa com os valores padrão gerenciados, mesmo quando você informa flags locais.

Os requisitos gerenciados na nuvem afetam a camada de requisitos, e não os valores padrão gerenciados. Para saber a ordem de precedência, consulte a seção anterior sobre requisitos impostos por administradores.

Locais

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

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

Preferências gerenciadas do macOS (MDM)

No macOS, os administradores podem distribuir um perfil de dispositivo que fornece payloads TOML codificados em base64 em:

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

O ambiente de execução local interpreta esses payloads de "preferências gerenciadas" como TOML. Para os valores padrão gerenciados (config_toml_base64), as preferências gerenciadas têm a maior precedência. Para os requisitos (requirements_toml_base64), a precedência segue a ordem dos requisitos gerenciados na nuvem descrita acima. A mesma tabela [features] de requisitos funciona em requirements_toml_base64; use também as chaves canônicas de recursos.

Fluxo de trabalho de configuração do MDM

O ambiente de execução local é compatível com os payloads MDM padrão do macOS, permitindo distribuir configurações com ferramentas como Jamf Pro, Fleet ou Kandji. Uma implantação simples funciona assim:

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

Evite incluir segredos ou valores dinâmicos que mudam com frequência no payload. Trate o TOML gerenciado como qualquer outra configuração de MDM sujeita ao controle de alterações.

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

Medidas de proteção recomendadas

• Prefira workspace-write com aprovações para a maioria dos usuários; reserve o acesso completo para contêineres controlados.
• Mantenha network_access = false, a menos que sua revisão de segurança permita um coletor ou os domínios necessários para seus fluxos de trabalho.
• Use a configuração gerenciada para fixar as configurações do OTel (exportador, ambiente), mas mantenha log_user_prompt = false, a menos que sua política permita explicitamente armazenar o conteúdo dos prompts.
• Audite periodicamente as diferenças entre o config.toml local e a política gerenciada para detectar desvios; as camadas gerenciadas devem ter precedência sobre flags e arquivos locais.