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 empresariais podem controlar o comportamento suportado dos clientes locais de duas formas:

• Requisitos: restrições impostas pelo administrador que os utilizadores não podem substituir.
• Predefinições geridas: valores iniciais aplicados quando um cliente suportado é iniciado. Os utilizadores ainda podem alterar as definições durante uma execução; o cliente volta a aplicar as predefinições geridas da próxima vez que for iniciado.

Requisitos impostos pelo administrador (requirements.toml)

Os requisitos restringem definiçõ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ões, modo de pesquisa na Web, hooks geridos, servidores MCP que os utilizadores podem ativar e origens de marketplaces de plugins configuradas pelos utilizadores que estes podem adicionar, utilizar para instalações ou atualizar). Ao resolver a configuração (por exemplo, a partir de config.toml, ficheiros de perfil ou substituições da configuração do CLI), se um valor entrar em conflito com uma regra imposta, o cliente local utiliza 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 o respetivo nome e 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.

Localizações e precedência

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

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 geridos pela empresa fornecidos no pacote de configuração na cloud.
3. Campos legados managed_config.toml que o cliente local reinterpreta como requisitos.
4. 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 ao espaço de trabalho. Este é um canal de fornecimento 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.

Abra Configuração gerida para criar e atribuir requisitos geridos na cloud. Por exemplo, esta política exige que os clientes suportados utilizem a residência de dados nos Estados Unidos, limita as opções de aprovação e sandbox e solicita confirmação antes da execução de um ponto de entrada de shell suportado:

enforce_residency = "us"
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.

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 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 devam definir centralmente os requisitos de acesso à rede. Estes requisitos são independentes do seletor de utilizador features.network_proxy: podem configurar a rede da sandbox sem esse sinalizador de funcionalidade, mas não concedem aos comandos acesso à rede quando a sandbox ativa mantém a rede desativada.

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

Utilize experimental_network.managed_allowed_domains_only = true apenas quando também definir allowed_domains pertencente ao administrador e pretender que essa lista de permissões seja exclusiva. Se for true sem regras de permissão geridas, as regras de permissão de domínios adicionadas pelos utilizadores deixam de ser eficazes.

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.

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 o Computer Use funcione depois de um Mac gerido ser bloqueado, adicione este requisito:

[computer_use]
allow_locked_computer_use = false

Este requisito não ativa o Computer Use. Apenas impede a utilização quando o dispositivo está bloqueado no macOS. Se o omitir, os requisitos não restringem a utilização quando o dispositivo está bloqueado; continuam a aplicar-se a disponibilidade normal do produto e a definição local do utilizador.

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 operações em origens de marketplaces configuradas pelos utilizadores, defina restrict_to_allowed_sources = true e 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 não correspondentes de adição de marketplaces, instalação de plugins e atualização de marketplaces Git configurados para origens configuradas pelos utilizadores. Os marketplaces OpenAI geridos pelo Codex continuam disponíveis quando a respetiva origem e o nome reservado correspondem. Os requisitos não filtram durante o ambiente de execução marketplaces de utilizadores já configurados nem os respetivos plugins.

Estas restrições de origens aplicam-se apenas quando um cliente local suporta operações de marketplaces de plugins: ChatGPT Work e Codex na aplicação para computador e Codex CLI. Não adicionam plugins ao Chat, à extensão do IDE nem a dispositivos móveis.

Predefinições geridas (managed_config.toml)

As predefinições geridas são intercaladas sobre o config.toml local de um utilizador e têm precedência sobre quaisquer substituições --config do CLI, definindo os valores iniciais quando um cliente local suportado é iniciado. Os utilizadores ainda podem alterar essas definições durante uma execução; o cliente volta a aplicar as predefinições geridas da próxima vez que for iniciado.

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.

Os requisitos geridos na cloud afetam a camada de requisitos (não as predefinições geridas). Consulte acima a secção Requisitos impostos pelo administrador para obter informações sobre a precedência.

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:

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.

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.