Dokumentasi ChatGPT
Bahasa Indonesia
Hubungi kami goolvyouyou@gmail.com

Konfigurasi terkelola

Terapkan persyaratan runtime pada seluruh klien lokal yang didukung dan distribusikan nilai default terkelola

Konfigurasi terkelola mengontrol perilaku runtime lokal yang didukung untuk kapabilitas yang tercakup dalam aplikasi desktop ChatGPT, Codex CLI, dan ekstensi IDE. Persyaratan yang didukung dapat berbeda menurut klien dan versi. Konfigurasi terkelola tidak memberikan akses ke ruang kerja ChatGPT, menetapkan lisensi pengguna, atau menggantikan kontrol akses berbasis peran (RBAC) ruang kerja. Gunakan Peran dan izin ruang kerja untuk akses fitur ruang kerja dan halaman ini untuk kebijakan runtime lokal.

Admin perusahaan dapat mengontrol perilaku klien lokal yang didukung dengan dua cara:

  • Persyaratan: batasan yang diterapkan admin dan tidak dapat ditimpa pengguna.
  • Nilai default terkelola: nilai awal yang diterapkan saat klien yang didukung diluncurkan. Pengguna tetap dapat mengubah pengaturan selama suatu proses berjalan; klien menerapkan kembali nilai default terkelola saat dimulai berikutnya.

Persyaratan yang diterapkan admin (requirements.toml)

Persyaratan membatasi pengaturan yang sensitif terhadap keamanan (kebijakan persetujuan, peninjau persetujuan, kebijakan peninjauan otomatis, mode sandbox, profil izin, mode pencarian web, hook terkelola, server MCP yang dapat diaktifkan pengguna, serta sumber marketplace plugin yang dikonfigurasi pengguna yang dapat mereka tambahkan, gunakan untuk menginstal, atau segarkan). Saat menyelesaikan konfigurasi (misalnya dari config.toml, file profil, atau penimpaan konfigurasi CLI), jika suatu nilai bertentangan dengan aturan yang diterapkan, klien lokal kembali ke nilai yang kompatibel dan memberi tahu pengguna. Jika Anda mengonfigurasi daftar yang diizinkan mcp_servers, klien hanya mengaktifkan server MCP apabila nama dan identitasnya sama-sama cocok dengan entri yang disetujui; jika tidak, klien menonaktifkannya.

Persyaratan juga dapat membatasi flag fitur melalui tabel [features] dalam requirements.toml. Perhatikan bahwa fitur tidak selalu sensitif terhadap keamanan, tetapi perusahaan dapat menetapkan nilainya jika diinginkan. Kunci yang tidak dicantumkan tetap tidak dibatasi.

Untuk Codex 0.138.0 atau yang lebih baru, utamakan profil izin dengan allowed_permission_profiles dan default_permissions terkelola. Gunakan allowed_sandbox_modes hanya untuk deployment lama yang masih mengonfigurasi sandbox_mode.

Untuk daftar kunci yang tepat, lihat bagian requirements.toml dalam Referensi Konfigurasi.

Lokasi dan urutan prioritas

Setiap klien lokal yang didukung menyusun persyaratan dari prioritas terendah hingga tertinggi:

  1. requirements.toml sistem (/etc/codex/requirements.toml pada sistem Unix, termasuk Linux dan macOS, atau %ProgramData%\OpenAI\Codex\requirements.toml pada Windows).
  2. Persyaratan yang dikelola perusahaan dan dikirimkan dalam bundel konfigurasi cloud.
  3. Kolom lama managed_config.toml yang ditafsirkan ulang oleh klien lokal sebagai persyaratan.
  4. Preferensi terkelola macOS (MDM) yang dikirimkan melalui com.openai.codex:requirements_toml_base64.

Lapisan dengan prioritas lebih tinggi menimpa nilai skalar dan daftar biasa dari lapisan berprioritas lebih rendah. Tabel digabungkan berdasarkan kunci, sedangkan persyaratan seperti aturan, hook, dan pembatasan sistem file memiliki perilaku penyusunan khusus untuk setiap kolom. Gunakan referensi requirements.toml untuk skema saat ini, alih-alih menganggap bahwa setiap kolom digabungkan dengan cara yang sama.

Untuk kompatibilitas mundur, klien lokal yang didukung menafsirkan ulang kolom lama approval_policy, approvals_reviewer, dan sandbox_mode sebagai persyaratan. Konversi ini menambahkan pilihan kompatibilitas bila diperlukan; gunakan requirements.toml untuk daftar yang diizinkan secara eksplisit.

Persyaratan yang dikelola melalui cloud

Saat pengguna masuk dengan ChatGPT pada paket yang didukung, klien lokal yang didukung dapat menerima persyaratan yang diterapkan admin dan terkait dengan ruang kerja. Ini adalah saluran pengiriman untuk kebijakan yang kompatibel dengan requirements.toml. Hal ini tidak memberikan akses ruang kerja atau menggantikan RBAC ruang kerja.

Buka Konfigurasi terkelola untuk membuat dan menetapkan persyaratan yang dikelola melalui cloud. Sebagai contoh, kebijakan ini mewajibkan klien yang didukung menggunakan residensi data Amerika Serikat, membatasi pilihan persetujuan dan sandbox, serta menampilkan permintaan konfirmasi sebelum titik masuk shell yang didukung dijalankan:

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

Pastikan setiap versi klien terkelola mendukung kunci yang Anda pilih, dan uji kebijakan tersebut dengan kelompok kecil sebelum menetapkannya ke seluruh organisasi. Gunakan referensi konfigurasi untuk skema saat ini dan antarmuka administrasi untuk perilaku penetapan saat ini.

Layanan memilih lapisan persyaratan yang dikelola perusahaan yang berlaku bagi identitas yang telah masuk. Klien lokal mengevaluasi lapisan tersebut bersama sumber persyaratan lain yang dijelaskan dalam Lokasi dan urutan prioritas. Gunakan antarmuka administrasi saat ini untuk pembuatan dan penetapan di sisi ruang kerja. Jangan mengandalkan algoritma pencocokan grup yang disalin; layanan administrasi mengendalikan perilaku tersebut dan dapat mengubahnya secara independen dari format persyaratan lokal.

Untuk kunci dan contoh yang didukung, lihat Contoh requirements.toml dan referensi requirements.toml.

Cara klien lokal menerapkan persyaratan yang dikelola melalui cloud

Saat pengguna memulai klien lokal yang didukung dan masuk dengan ChatGPT pada paket yang didukung, klien terlebih dahulu memeriksa entri cache yang valid dan cocok dengan identitas. Jika tidak tersedia entri yang valid, klien mengambil bundel yang berlaku dengan percobaan ulang dan menulis entri cache bertanda tangan jika berhasil. Jika permintaan gagal atau kehabisan waktu dan tidak tersedia cache yang valid, pemuatan bundel konfigurasi cloud akan menghasilkan kesalahan, bukan dimulai secara diam-diam tanpa lapisan persyaratan yang dikelola melalui cloud.

Setelah cache diselesaikan, klien menyusun persyaratan cloud bersama lapisan persyaratan lain yang dijelaskan di atas. Penyegaran di latar belakang dapat memperbarui cache untuk proses mulai berikutnya; penyegaran tersebut tidak menggantikan persyaratan yang sudah dimuat ke dalam proses saat ini.

Contoh requirements.toml

Contoh ini memblokir --ask-for-approval never dan --sandbox danger-full-access (termasuk --yolo):

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

Menonaktifkan Appshots

Untuk menonaktifkan Appshots bagi pengguna terkelola, tetapkan persyaratan tingkat teratas allow_appshots:

allow_appshots = false

Di tempat Appshots tersedia, allow_appshots = false akan menonaktifkannya. Jika Anda tidak mencantumkan kunci tersebut, persyaratan tidak membatasi Appshots dan pemeriksaan ketersediaan produk normal akan berlaku. Klien app-server yang membaca persyaratan efektif melalui configRequirements/read menerima pembatasan yang sama dengan allowAppshots; nilai allowAppshots yang tidak dicantumkan atau bernilai null tidak menonaktifkan Appshots.

Menonaktifkan kendali jarak jauh perangkat

Untuk menonaktifkan kendali jarak jauh perangkat bagi pengguna terkelola, tetapkan persyaratan tingkat teratas allow_remote_control:

allow_remote_control = false

Di tempat kendali jarak jauh perangkat didukung, allow_remote_control = false akan menonaktifkannya. Jika Anda tidak mencantumkan kunci tersebut, persyaratan tidak membatasi kendali jarak jauh perangkat dan pemeriksaan ketersediaan produk normal akan berlaku. Persyaratan ini tidak menonaktifkan koneksi jarak jauh SSH.

Mengontrol profil izin yang tersedia

Gunakan allowed_permission_profiles untuk mengontrol profil izin bawaan dan kustom yang dapat dipilih pengguna. Ini adalah padanan profil izin untuk allowed_sandbox_modes; gunakan daftar yang diizinkan yang sesuai dengan cara pengguna Anda memilih izin.

Daftar profil izin yang diizinkan memerlukan Codex 0.138.0 atau yang lebih baru. Codex 0.137.0 dan versi sebelumnya mengabaikan allowed_permission_profiles dan default_permissions terkelola.

Gunakan contoh profil izin di bawah hanya setelah setiap klien terkelola menjalankan rilis yang mendukungnya. Jangan melakukan deployment profil kustom terkelola hingga peningkatan seluruh armada selesai.

Jika ada, tabel tersebut merupakan daftar lengkap profil yang diizinkan. Tabel ini mengizinkan profil yang ditetapkan ke true dan menolak profil yang tidak dicantumkan atau ditetapkan ke false, termasuk profil bawaan yang ditambahkan dalam versi Codex mendatang.

Mengizinkan profil standar

Kebijakan ini mengizinkan akses hanya baca dan akses ruang kerja, tetapi bukan akses penuh:

default_permissions = ":workspace"

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

Menambahkan nilai default hak akses minimum yang terkelola

Admin dapat menentukan profil kustom dalam sumber persyaratan yang sama. Gunakan nama profil khusus organisasi yang tidak akan bertabrakan dengan nama dalam konfigurasi yang dimuat pengguna. Nama kustom tidak boleh diawali dengan : atau menggunakan nama khusus filesystem.

Jangan melakukan deployment profil kustom terkelola ke klien yang menjalankan Codex 0.137.0 atau versi sebelumnya. Klien tersebut mengenali tabel profil, tetapi tidak mengenali nilai default terkelola yang memilihnya.

Sebagai contoh:

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"

Hanya mengizinkan profil yang ditentukan perusahaan

Jangan cantumkan profil bawaan apa pun jika pengguna hanya boleh memilih profil yang ditentukan admin:

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"

Profil kustom dapat memperluas :workspace meskipun pengguna tidak dapat memilih profil bawaan :workspace secara langsung.

Menonaktifkan profil yang diizinkan oleh sumber lain

Daftar izin digabungkan berdasarkan nama profil. Karena persyaratan cloud memiliki prioritas lebih tinggi daripada persyaratan sistem, persyaratan cloud dapat menggunakan false untuk menonaktifkan profil yang diizinkan oleh file sistem.

Persyaratan cloud:

default_permissions = ":read-only"

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

Persyaratan sistem:

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

Tetapkan default_permissions secara eksplisit ke profil yang diizinkan. Jika tidak dicantumkan, runtime lokal menggunakan :workspace sebagai nilai default hanya jika :workspace dan :read-only sama-sama diizinkan secara eksplisit. Jika allowed_permission_profiles tidak ada, persyaratan terkelola tidak membatasi nama profil yang dapat dipilih pengguna. Setiap entri harus menyebutkan profil bawaan atau profil kustom yang ditentukan dalam konfigurasi atau sumber persyaratan yang dimuat. Tentukan profil kustom dalam persyaratan terkelola agar perilakunya dapat dikontrol secara terpusat.

Menimpa persyaratan sandbox berdasarkan host

Gunakan [[remote_sandbox_config]] jika satu kebijakan terkelola harus menerapkan persyaratan sandbox yang berbeda pada host yang berbeda. Sebagai contoh, Anda dapat mempertahankan nilai default yang lebih ketat untuk laptop sekaligus mengizinkan penulisan ruang kerja pada dev box atau runner CI yang cocok. Entri khusus host saat ini hanya menimpa 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"]

Runtime lokal membandingkan setiap entri hostname_patterns dengan nama host yang diselesaikan dengan upaya terbaik. Runtime mengutamakan nama domain yang sepenuhnya memenuhi syarat jika tersedia dan kembali ke nama host lokal jika tidak. Pencocokan tidak membedakan huruf besar-kecil; * cocok dengan urutan karakter apa pun, dan ? cocok dengan satu karakter.

Entri [[remote_sandbox_config]] pertama yang cocok akan digunakan dalam sumber persyaratan yang sama. Jika tidak ada entri yang cocok, runtime lokal mempertahankan allowed_sandbox_modes tingkat teratas. Pencocokan nama host hanya ditujukan untuk pemilihan kebijakan; jangan menganggapnya sebagai bukti perangkat yang diautentikasi.

Anda juga dapat membatasi mode pencarian web:

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

allowed_web_search_modes = [] hanya mengizinkan "disabled". Sebagai contoh, allowed_web_search_modes = ["cached"] mencegah pencarian web langsung bahkan dalam sesi danger-full-access.

Mengonfigurasi persyaratan akses jaringan

Gunakan [experimental_network] dalam requirements.toml jika administrator perlu menentukan persyaratan akses jaringan secara terpusat. Persyaratan ini terpisah dari pengalih features.network_proxy milik pengguna: persyaratan ini dapat mengonfigurasi jaringan sandbox tanpa flag fitur tersebut, tetapi tidak memberikan akses jaringan kepada perintah jika sandbox aktif tetap menonaktifkan jaringan.

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

Gunakan experimental_network.managed_allowed_domains_only = true hanya jika Anda juga menentukan allowed_domains milik administrator dan ingin daftar yang diizinkan tersebut bersifat eksklusif. Jika nilainya true tanpa aturan izin terkelola, aturan izin domain yang ditambahkan pengguna tidak akan tetap berlaku.

Sintaks domain, aturan tujuan lokal/pribadi, perilaku penolakan yang mengungguli izin, dan keterbatasan DNS rebinding sama dengan perilaku jaringan sandbox yang dijelaskan dalam Persetujuan agen & keamanan.

Menetapkan flag fitur

Anda juga dapat menetapkan flag fitur bagi pengguna yang menerima requirements.toml terkelola:

[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

Gunakan kunci fitur kanonis dari tabel [features] milik config.toml untuk fitur runtime. Runtime lokal menormalkan fitur yang dikenali agar memenuhi penetapan ini dan menolak penulisan yang bertentangan ke config.toml atau pengaturan fitur dalam file profil.

  • in_app_browser = false menonaktifkan panel browser bawaan.
  • in_app_updates = false menonaktifkan pembaru milik aplikasi desktop ChatGPT saat dimulai ulang, jika didukung. Hal ini tidak memengaruhi deployment paket eksternal atau memperpanjang dukungan untuk versi aplikasi lama. Untuk panduan penyiapan dan peluncuran, lihat Mengelola pembaruan aplikasi.
  • browser_use = false menonaktifkan Computer Use di browser dan ketersediaan Browser Agent.
  • browser_use_full_cdp_access = false menonaktifkan akses CDP penuh dalam runtime lokal, termasuk mode Browser Developer, serta mencegah aplikasi desktop ChatGPT mengaktifkan pengaturan terkait.
  • browser_use_external = false menonaktifkan Browser Use eksternal.
  • computer_use = false menonaktifkan Computer Use, Record & Replay, serta alur penginstalan atau penyiapan terkait.

Jika Anda tidak mencantumkan kunci ini, kebijakan mengizinkan fitur tersebut, dengan tetap tunduk pada ketersediaan klien, platform, dan peluncuran normal.

Membatasi penggunaan komputer saat terkunci

Untuk mencegah Computer Use beroperasi setelah Mac terkelola terkunci, tambahkan persyaratan ini:

[computer_use]
allow_locked_computer_use = false

Persyaratan ini tidak mengaktifkan Computer Use. Persyaratan ini hanya mencegah penggunaan saat terkunci di macOS. Jika Anda tidak mencantumkannya, persyaratan tidak membatasi penggunaan saat terkunci; ketersediaan produk normal dan pengaturan lokal pengguna tetap berlaku.

Mengonfigurasi kebijakan peninjauan otomatis

Gunakan allowed_approvals_reviewers untuk mewajibkan atau mengizinkan peninjauan otomatis. Tetapkan ke ["auto_review"] untuk mewajibkan peninjauan otomatis, atau sertakan "user" jika pengguna dapat memilih persetujuan manual.

Tetapkan guardian_policy_config untuk mengganti bagian khusus tenant dalam kebijakan peninjauan otomatis. Runtime lokal tetap menggunakan templat peninjau bawaan dan kontrak output. guardian_policy_config terkelola memiliki prioritas lebih tinggi daripada [auto_review].policy lokal.

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

Menerapkan persyaratan penolakan baca

Admin dapat menolak pembacaan jalur yang tepat atau pola glob dengan [permissions.filesystem]. Pengguna tidak dapat memperlemah persyaratan ini melalui konfigurasi lokal.

[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.
]

Jika persyaratan penolakan baca tersedia, runtime lokal menolak izin akses penuh dan mempertahankan eksekusi lokal dalam sandbox hanya baca atau ruang kerja agar dapat menerapkannya. Pada Windows native, deny_read terkelola berlaku untuk alat file langsung; pembacaan oleh subproses shell tidak menggunakan aturan sandbox ini.

Menerapkan hook terkelola dari persyaratan

Admin juga dapat menentukan hook siklus hidup terkelola secara langsung dalam requirements.toml. Gunakan [hooks] untuk konfigurasi hook itu sendiri, dan arahkan managed_dir ke direktori tempat alat MDM atau pengelolaan endpoint Anda menginstal skrip yang dirujuk.

Untuk menerapkan hook terkelola bahkan bagi pengguna yang menonaktifkan hook secara lokal, tetapkan [features].hooks = true bersama [hooks]. Untuk melewati hook pengguna, proyek, sesi, dan plugin sekaligus tetap mengizinkan hook terkelola, tetapkan 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"

Catatan:

  • Runtime lokal menerapkan konfigurasi hook dari requirements.toml, tetapi tidak mendistribusikan skrip dalam managed_dir.
  • Kirimkan skrip tersebut dengan solusi MDM atau pengelolaan perangkat Anda.
  • Perintah hook terkelola harus merujuk ke jalur skrip absolut di bawah direktori terkelola yang dikonfigurasi.
  • allow_managed_hooks_only = true melewati hook dari sumber pengguna, proyek, sesi, dan plugin, tetapi tetap memuat hook dari requirements.toml dan lapisan konfigurasi terkelola lainnya.

Menerapkan aturan perintah dari persyaratan

Admin juga dapat menerapkan aturan perintah yang membatasi dari requirements.toml dengan menggunakan tabel [rules]. Aturan ini digabungkan dengan file .rules biasa, dan keputusan yang paling membatasi tetap berlaku.

Tidak seperti .rules, aturan persyaratan harus menentukan decision, dan keputusan tersebut harus berupa "prompt" atau "forbidden" (bukan "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." },
]

Untuk membatasi server MCP yang dapat diaktifkan klien lokal, tambahkan daftar yang disetujui mcp_servers. Untuk server stdio, cocokkan berdasarkan command; untuk server HTTP yang dapat dialirkan, cocokkan berdasarkan url:

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

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

Bentuk string identity.command hanya mencocokkan command yang dikonfigurasi. Bentuk tersebut tidak memeriksa args, cwd, env, atau env_vars.

Untuk membatasi pemanggilan stdio secara lengkap, cocokkan file yang dapat dieksekusi dan setiap argumen posisional:

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

File yang dapat dieksekusi, jumlah argumen, dan urutan argumen harus cocok. Aturan argumen dan URL mendukung pencocokan exact, prefix, dan nilai penuh regex. Aturan perintah terstruktur tetap tidak memeriksa cwd, env, atau env_vars. Server MCP yang disertakan dalam plugin menggunakan bentuk identitas yang sama di bawah plugins.<plugin>.mcp_servers.<server>.

Jika mcp_servers ada tetapi kosong, klien lokal menonaktifkan semua server MCP.

Mengontrol ketersediaan plugin

Untuk menonaktifkan plugin dalam klien lokal yang didukung, tetapkan features.plugins ke false dalam requirements.toml:

features.plugins = false

Pengaturan ini juga berlaku saat pengguna masuk ke Codex dengan API key. Lihat referensi features.plugins untuk konfigurasi yang didukung.

Membatasi sumber marketplace plugin

Untuk membatasi operasi pada sumber marketplace yang dikonfigurasi pengguna, tetapkan restrict_to_allowed_sources = true dan tentukan satu atau beberapa aturan sumber:

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

Aturan Git mencocokkan URL repositori yang telah dinormalisasi dan, jika ada, nilai ref yang tepat. Pola host adalah ekspresi reguler yang dicocokkan dengan host Git dalam huruf kecil; gunakan ^ dan $ untuk pencocokan seluruh host. Aturan lokal memerlukan jalur absolut yang telah dinormalisasi. Lihat referensi requirements.toml untuk skema lengkap dan perilaku penggabungan.

Persyaratan ini menolak operasi penambahan marketplace, penginstalan plugin, dan penyegaran marketplace Git yang dikonfigurasi untuk sumber yang dikonfigurasi pengguna jika tidak cocok. Marketplace OpenAI yang dikelola Codex tetap tersedia jika sumber dan nama khususnya cocok. Persyaratan ini tidak memfilter marketplace pengguna yang sudah dikonfigurasi atau pluginnya saat runtime.

Pembatasan sumber ini hanya berlaku jika klien lokal mendukung operasi marketplace plugin: ChatGPT Work dan Codex dalam aplikasi desktop, serta Codex CLI. Pembatasan ini tidak menambahkan plugin ke Chat, ekstensi IDE, atau perangkat seluler.

Nilai default terkelola (managed_config.toml)

Nilai default terkelola digabungkan di atas config.toml lokal milik pengguna dan memiliki prioritas lebih tinggi daripada penimpaan --config CLI, sehingga menetapkan nilai awal saat klien lokal yang didukung diluncurkan. Pengguna tetap dapat mengubah pengaturan tersebut selama suatu proses berjalan; klien menerapkan kembali nilai default terkelola saat dimulai berikutnya.

Jika nilai default terkelola, profil MDM macOS, atau konfigurasi tersimpan menetapkan gpt-5.4 atau gpt-5.4-mini bagi pengguna yang masuk dengan ChatGPT, perbarui sebelum 31 Agustus 2026. Ganti gpt-5.4 dengan gpt-5.6-terra dan gpt-5.4-mini dengan gpt-5.6-luna. OpenAI API dan Codex yang diautentikasi dengan API key Anda sendiri tidak terpengaruh. Lihat ketersediaan model ruang kerja.

Pastikan nilai default terkelola Anda memenuhi persyaratan; runtime lokal menolak nilai yang tidak diizinkan.

Urutan prioritas dan pelapisan

Runtime lokal menyusun konfigurasi efektif dalam urutan berikut (bagian atas menimpa bagian bawah):

  • Preferensi terkelola (MDM macOS; prioritas tertinggi)
  • managed_config.toml (file sistem/terkelola)
  • config.toml (konfigurasi dasar pengguna)

Penimpaan --config key=value CLI diterapkan ke konfigurasi dasar, tetapi lapisan terkelola menimpanya. Artinya, setiap proses dimulai dari nilai default terkelola meskipun Anda memberikan flag lokal.

Persyaratan yang dikelola melalui cloud memengaruhi lapisan persyaratan (bukan nilai default terkelola). Lihat bagian Persyaratan yang diterapkan admin di atas untuk urutan prioritas.

Lokasi

  • Linux/macOS (Unix): /etc/codex/managed_config.toml
  • Windows/non-Unix: ~/.codex/managed_config.toml

Jika file tidak ada, runtime lokal melewati lapisan terkelola.

Preferensi terkelola macOS (MDM)

Pada macOS, admin dapat mengirim profil perangkat yang menyediakan payload TOML berkode base64 di:

  • Domain preferensi: com.openai.codex
  • Kunci:
    • config_toml_base64 (nilai default terkelola)
    • requirements_toml_base64 (persyaratan)

Runtime lokal mengurai payload "preferensi terkelola" ini sebagai TOML. Untuk nilai default terkelola (config_toml_base64), preferensi terkelola memiliki prioritas tertinggi. Untuk persyaratan (requirements_toml_base64), urutan prioritas mengikuti urutan persyaratan yang dikelola melalui cloud yang dijelaskan di atas. Tabel [features] di sisi persyaratan yang sama berfungsi dalam requirements_toml_base64; gunakan kunci fitur kanonis di sana juga.

Alur kerja penyiapan MDM

Runtime lokal mematuhi payload MDM macOS standar, sehingga Anda dapat mendistribusikan pengaturan dengan alat seperti Jamf Pro, Fleet, atau Kandji. Deployment ringan terlihat seperti berikut:

  1. Buat TOML payload terkelola dan enkode dengan base64 (tanpa pembungkusan).
  2. Masukkan string ke profil MDM Anda di bawah domain com.openai.codex pada config_toml_base64 (nilai default terkelola) atau requirements_toml_base64 (persyaratan).
  3. Kirim profil, lalu minta pengguna memulai ulang klien lokal yang didukung dan memastikan ringkasan konfigurasi awal mencerminkan nilai terkelola.
  4. Saat mencabut atau mengubah kebijakan, perbarui payload terkelola; klien membaca preferensi yang telah disegarkan saat diluncurkan berikutnya.

Hindari menyematkan rahasia atau nilai dinamis yang sering berubah dalam payload. Perlakukan TOML terkelola seperti pengaturan MDM lain yang berada di bawah kontrol perubahan.

Contoh 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

Batasan pengaman yang direkomendasikan

  • Utamakan workspace-write dengan persetujuan bagi sebagian besar pengguna; sediakan akses penuh hanya untuk container terkontrol.
  • Pertahankan network_access = false kecuali peninjauan keamanan Anda mengizinkan pengumpul atau domain yang diperlukan oleh alur kerja Anda.
  • Gunakan konfigurasi terkelola untuk menetapkan pengaturan OTel (pengekspor, lingkungan), tetapi pertahankan log_user_prompt = false kecuali kebijakan Anda secara eksplisit mengizinkan penyimpanan isi prompt.
  • Audit secara berkala perbedaan antara config.toml lokal dan kebijakan terkelola untuk mendeteksi penyimpangan; lapisan terkelola harus mengungguli flag dan file lokal.