Konfigurasi 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 Enterprise dapat mengontrol perilaku klien lokal yang didukung dengan:

• Persyaratan: batasan yang diberlakukan admin dan tidak dapat dikesampingkan pengguna.
• Pengaturan default konfigurasi: pengaturan config.toml yang dikelola sistem atau cloud dan dapat diganti pengguna.
• Pengaturan default terkelola lama: nilai awal managed_config.toml yang diterapkan saat klien yang didukung diluncurkan. Pengguna tetap dapat mengubah pengaturan selama klien berjalan; klien menerapkan kembali pengaturan default ini saat dimulai lagi.

Konfigurasi marketplace plugin dan pengaturan default

Tentukan marketplace lokal atau Git dan pengaturan default plugin dalam config.toml sistem atau bagian config.toml pada Konfigurasi terkelola. Pengaturan ini merupakan default, bukan kebijakan yang diberlakukan secara wajib.

Lihat Referensi konfigurasi untuk kunci konfigurasi, Prioritas konfigurasi untuk penggantian pengaturan, dan pengaturan plugin repositori untuk konfigurasi tingkat proyek. Impor dan sinkronisasi GitHub ruang kerja dikelola secara terpisah.

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, dan sumber marketplace plugin yang dapat mereka gunakan). Saat menentukan konfigurasi yang berlaku (misalnya dari config.toml, file profil, atau penggantian konfigurasi CLI), jika suatu nilai bertentangan dengan aturan yang diberlakukan, klien lokal beralih ke nilai yang kompatibel dan memberi tahu pengguna. Jika Anda mengonfigurasi daftar izin mcp_servers, klien hanya mengaktifkan server MCP jika nama dan identitasnya 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.

Migrasikan kebijakan persetujuan untrusted yang sudah dihentikan

Codex dan ChatGPT Work tidak lagi mendukung approval_policy = "untrusted". Hapus pengaturan tersebut dari default terkelola, managed_config.toml lama, dan semua konfigurasi pengguna, proyek, profil, atau startup yang menetapkannya.

Untuk penggunaan interaktif yang hanya membaca, pilih approval_policy = "on-request" dengan sandbox hanya baca atau profil izin yang diperbolehkan oleh persyaratan terkelola Anda. Perintah yang diizinkan oleh sandbox tersebut dapat berjalan tanpa persetujuan.

Untuk mempertahankan persetujuan perintah yang lebih ketat, jangan tetapkan approval_policy secara eksplisit, tetapkan trust_level = "untrusted" pada entri proyek dalam file tingkat pengguna ~/.codex/config.toml, dan pertahankan untrusted dalam allowed_approval_policies. Ini juga menonaktifkan konfigurasi lokal proyek. Menetapkan on-request secara eksplisit menggantikan kebijakan tersebut. Lihat Migrasi dari kebijakan persetujuan untrusted yang sudah dihentikan untuk contoh dan kompromi keamanan.

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 diberlakukan admin untuk ruang kerja tersebut. Ini merupakan saluran distribusi kebijakan yang kompatibel dengan requirements.toml. Saluran ini tidak memberikan akses ruang kerja atau menggantikan RBAC ruang kerja. Persyaratan autentikasi harus dikelola secara lokal.

Buka Konfigurasi terkelola untuk membuat dan menetapkan persyaratan yang dikelola melalui cloud. Misalnya, kebijakan ini membatasi pilihan persetujuan dan sandbox serta meminta konfirmasi sebelum titik masuk shell yang didukung dijalankan:

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.

Konfirmasikan pengalaman admin dan karyawan

Tetapkan seseorang sebagai penanggung jawab setiap kebijakan terkelola, catat pengguna atau grup yang harus menerimanya, dan dokumentasikan alasan bisnis untuk setiap pembatasan sistem berkas, jaringan, persetujuan, atau profil izin.

Sebelum memperluas peluncuran, uji alur kerja yang disetujui dan alur kerja yang sengaja dilarang bersama pengguna perwakilan. Verifikasi pengaturan yang berlaku di klien yang didukung, alih-alih berasumsi bahwa peran atau grup ruang kerja saja menerapkan pembatasan lokal tersebut.

Kelola autentikasi secara lokal

Tetapkan allowed_login_methods, allowed_chatgpt_workspaces, cli_auth_credentials_store, dan chatgpt_base_url dalam file sistem lokal requirements.toml atau persyaratan MDM macOS. Codex mengabaikan keempat pengaturan ini dalam persyaratan yang dikelola melalui cloud. Persyaratan autentikasi lokal berlaku sebelum kredensial dimuat dan sebelum Codex mengambil kebijakan cloud.

Untuk mewajibkan proses masuk ChatGPT ke ruang kerja yang disetujui dan menyimpan kredensial di penyimpanan kredensial OS, gunakan:

allowed_login_methods = ["chatgpt"]
allowed_chatgpt_workspaces = ["00000000-0000-0000-0000-000000000000"]
cli_auth_credentials_store = "keyring"

allowed_login_methods menerima chatgpt, api, atau keduanya. Jika tidak dicantumkan, pengaturan ini tidak membatasi metode masuk. Jika ditetapkan, daftar harus berisi setidaknya satu metode. api mengizinkan autentikasi API, termasuk Amazon Bedrock. Pembatasan ruang kerja juga berlaku untuk token akses Codex.

forced_login_method dan forced_chatgpt_workspace_id yang dikonfigurasi pengguna harus mematuhi persyaratan. Saat pengguna memilih ruang kerja, ruang kerja tersebut juga harus tercantum dalam daftar izin ruang kerja terkelola. Jika tidak ada ruang kerja yang cocok, proses masuk ChatGPT tidak tersedia. Autentikasi API tetap tersedia jika diizinkan. Jika tidak ada metode masuk yang tersedia, Codex menolak untuk memulai.

Lihat referensi persyaratan untuk mode penyimpanan kredensial dan konfigurasi URL layanan.

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

Di sini, untrusted mempertahankan perilaku persetujuan yang lebih ketat yang berasal dari trust_level = "untrusted"; ini tidak menjadikan approval_policy = "untrusted" sebagai pengaturan eksplisit yang didukung.

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] di requirements.toml ketika administrator perlu menetapkan persyaratan akses jaringan secara terpusat. Persyaratan ini terpisah dari tombol features.network_proxy milik pengguna: persyaratan tersebut dapat mengonfigurasi jaringan sandbox tanpa flag fitur itu, tetapi tidak memberikan akses jaringan perintah ketika sandbox aktif tetap menonaktifkan jaringan. Atur experimental_network.enabled = true untuk mengaktifkan proksi terkelola; aturan domain saja tidak akan mengaktifkan proksi.

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

Gunakan experimental_network.managed_allowed_domains_only = true hanya jika Anda juga menetapkan entri "allow" milik administrator di [experimental_network.domains] dan ingin menjadikan aturan tersebut eksklusif. Jika nilainya true tanpa aturan izin terkelola, aturan izin domain yang ditambahkan pengguna tidak lagi berlaku. Jangan gabungkan pemetaan kanonis domains dengan daftar lama allowed_domains atau denied_domains.

*.example.com hanya cocok dengan subdomain. **.example.com cocok dengan domain apeks dan subdomainnya. Aturan penolakan yang cocok mengalahkan aturan izin.

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.

Proksi merutekan perintah lokal yang berjalan di dalam sandbox. Alat browser juga memeriksa penolakan jaringan terkelola dan daftar izin eksklusif sebelum mengakses suatu origin; ini merupakan pemeriksaan kebijakan terpisah, bukan perutean lalu lintas browser melalui proksi perintah. Proksi ini tidak memfilter pencarian web, aplikasi dan konektor, server MCP, lalu lintas aplikasi native, permintaan layanan Codex, atau lalu lintas cloud Codex. Gunakan kontrol untuk setiap antarmuka:

• Gunakan allowed_web_search_modes untuk membatasi pencarian web.
• Gunakan features.apps = false untuk menonaktifkan integrasi aplikasi dan konektor, serta features.plugins = false untuk menonaktifkan plugin jika didukung.
• Gunakan daftar server MCP yang disetujui dan dikelola dalam mcp_servers untuk membatasi server MCP.
• Gunakan persyaratan fitur seperti browser_use, in_app_browser, dan computer_use untuk membatasi kemampuan browser dan Computer Use.
• Konfigurasikan akses jaringan cloud Codex dalam pengaturan lingkungan cloud-nya.

Daftar domain perintah yang diizinkan tidak menggantikan kontrol khusus kemampuan ini.

Mengontrol browser dan Computer Use

Gunakan tabel [browser_use] dan [computer_use] di requirements.toml untuk membatasi klien desktop yang didukung. Validasi kebijakan pada versi klien dan sistem operasi dalam deployment Anda. Aturan izin yang dikonfigurasi tidak menginstal plugin, memberikan izin sistem operasi, atau menyetujui tindakan yang masih memerlukan peninjauan.

Untuk akses browser, konfigurasikan kebijakan origin. Origin mencakup skema, host, dan port opsional, seperti https://example.com atau https://*.example.com:8443. Jangan sertakan path, kueri, atau fragmen. Berbeda dengan aturan domain jaringan perintah, aturan origin browser membedakan HTTP dari HTTPS dan mencocokkan port.

Contoh ini membatasi akses browser ke situs yang disetujui serta mencegah unggahan dan akses penuh Chrome DevTools Protocol (CDP) di situs tersebut:

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

Aturan origin yang cocok diselesaikan per bidang. Penolakan yang cocok akan berlaku; jika tidak, kebijakan origin default menyediakan bidang yang tidak ditentukan oleh aturan yang cocok. Konfigurasi lokal dapat menambahkan pembatasan, tetapi tidak dapat melonggarkan penolakan terkelola. Penolakan jaringan dan daftar izin jaringan terkelola yang eksklusif tetap berlaku.

Atur browser_use.disable_auto_review = true untuk menonaktifkan peninjauan persetujuan otomatis bagi tindakan browser, atau atur auto_review = "deny" pada kebijakan origin untuk membatasinya pada origin tersebut. Ini mengontrol penanganan persetujuan; pengaturan ini tidak menonaktifkan pemantauan keamanan model.

Untuk aplikasi native, tetapkan kebijakan akses default dan identifikasi aplikasi yang diizinkan. Sebagai contoh, kebijakan macOS ini mengizinkan Calculator dan mencegah penyimpanan persetujuan:

[computer_use]
default_app_access = "deny"
allow_persistent_approval = false

[computer_use.macos.bundle_ids]
"com.apple.calculator" = "allow"

Kebijakan Windows dapat mengidentifikasi aplikasi terpaket dengan computer_use.windows.aumids atau file yang dapat dieksekusi dengan computer_use.windows.exes. Aturan file yang dapat dieksekusi memerlukan publisher_name, product_name, dan access; binary_name bersifat opsional. Gunakan identitas aplikasi yang telah diverifikasi, bukan hanya nama tampilannya.

Lihat referensi konfigurasi untuk bidang lengkap dan pembatasan Locked Use untuk perangkat macOS terkelola.

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 pengguna mengaktifkan Locked Use pada Mac terkelola, tambahkan persyaratan ini:

[computer_use]
allow_locked_computer_use = false

Persyaratan ini menghapus kontrol untuk mengaktifkan Locked Use. Persyaratan ini tidak menonaktifkan Locked Use jika fitur tersebut sudah diaktifkan. Jika Anda menghilangkannya, 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 sumber marketplace plugin, 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 jika sumbernya tidak cocok. Persyaratan ini juga memfilter marketplace yang dikonfigurasi beserta pluginnya saat runtime.

Marketplace Git yang dikurasi OpenAI, termasuk katalog API key, juga harus cocok dengan daftar izin sumber. Untuk mengizinkannya, sertakan sumber Git berikut tanpa batasan ref:

[marketplaces.allowed_sources.openai_curated]
source = "git"
url = "https://github.com/openai/plugins.git"

Untuk mengecualikan katalog yang dikurasi, jangan cantumkan sumber tersebut dan pastikan tidak ada aturan host yang lebih luas yang mengizinkannya. Plugin bawaan dan plugin ruang kerja yang diinstal dari jarak jauh terpisah dari kebijakan sumber Git yang dikurasi ini.

Pembatasan sumber ini hanya berlaku jika klien lokal mendukung operasi marketplace plugin: ChatGPT dan Codex di aplikasi desktop, serta Codex CLI. Pembatasan ini tidak mengontrol penggunaan plugin di ChatGPT pada web atau perangkat seluler, dan tidak menambahkan plugin ke ekstensi IDE.

Nilai default terkelola (managed_config.toml)

Default terkelola menetapkan konfigurasi awal klien lokal yang didukung. Saat startup, default tersebut menggantikan config.toml lokal milik pengguna dan setiap penggantian --config dari CLI. Pengguna masih dapat mengubah pengaturan tersebut selama proses yang sedang berjalan, dan default diterapkan kembali saat klien dimulai berikutnya.

Jika pengaturan default terkelola, profil MDM macOS, atau konfigurasi tersimpan menetapkan gpt-5.5 untuk pengguna Codex yang masuk dengan ChatGPT, ganti dengan gpt-5.6-sol sebelum 14 Oktober 2026. GPT-5.5 akan dihentikan di ChatGPT, ChatGPT Work, dan Codex pada semua paket pada tanggal tersebut. OpenAI API tidak terpengaruh. Lihat ketersediaan model ruang kerja.

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.

config.toml cloud menggunakan prioritas konfigurasi normal, bukan urutan lama di atas. requirements.toml cloud menggunakan prioritas persyaratan.

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.