Konfigurasi terkelola

Konfigurasi terkelola memungkinkan admin perusahaan menetapkan persyaratan dan pengaturan default yang didukung untuk ChatGPT Work dan Codex. Persyaratan membatasi tindakan yang dapat dilakukan pengguna dan tugas. Pengaturan default menyediakan nilai awal. Dukungan bergantung pada produk, versi klien, dan lingkungan eksekusi.

Mulai di Keamanan agen pada Konsol Admin untuk pengaturan yang didukung dan dikelola melalui cloud. Gunakan kontrol pengaturan untuk tugas umum, atau pilih Edit sebagai TOML untuk memeriksa, menyalin, atau mengedit teks konfigurasi. Kedua tampilan mengedit kebijakan yang sama; TOML juga menampilkan bidang yang didukung tanpa kontrol khusus. Anda tidak perlu mendistribusikan file lokal untuk menggunakan pengaturan yang dikelola melalui cloud. Pembatasan autentikasi dan penerapan yang dikelola perangkat memiliki penyiapan lokal tersendiri.

Admin Enterprise dapat mengontrol perilaku klien lokal yang didukung dengan:

• Persyaratan: batasan yang diberlakukan admin dan tidak dapat ditimpa oleh pengguna.

• Pengaturan default konfigurasi: pengaturan config.toml sistem atau yang dikelola melalui cloud yang dapat ditimpa oleh pengguna.

• Pengaturan default terkelola lama: nilai awal managed_config.toml yang diterapkan saat klien yang didukung dijalankan. Pengguna tetap dapat mengubah pengaturan selama klien berjalan. Klien menerapkan kembali pengaturan default ini saat dijalankan berikutnya.

Lihat Agent Security untuk konfigurasi dasar Global, pengaturan pengganti lingkungan, serta daftar kolom orkestrator dan eksekutor.

Mengonfigurasi kebijakan di Keamanan agen

Jika Keamanan agen diaktifkan, pemilik ruang kerja, admin ruang kerja, dan anggota dengan izin admin Codex dapat mengelola kebijakan. Akses ke editor kebijakan tidak memberikan anggota akses ke fitur yang dikendalikan kebijakan tersebut.

Gunakan Default ruang kerja sebagai pengaturan dasar ruang kerja. Gunakan Penggantian jika pengguna, grup, atau peran tertentu memerlukan pengaturan berbeda. Penggantian berdasarkan audiens menentukan siapa yang menerima kebijakan; pengaturan lingkungan menentukan tempat kontrol eksekusi yang didukung berlaku.

1. Buka Konsol Admin > Keamanan agen, lalu pilih Default ruang kerja atau kebijakan yang ingin Anda edit di bagian Penggantian.
2. Buka Persyaratan untuk menetapkan batasan yang diberlakukan, atau Default untuk menetapkan nilai awal yang dapat diubah anggota dalam batasan tersebut.
3. Simpan pengaturan persetujuan, pencarian web, dan pengaturan lain yang berlaku untuk seluruh agen di Global. Jika tersedia, gunakan Tambahkan pengaturan lingkungan pada kartu yang sesuai untuk menambahkan Lingkungan Lokal atau Lingkungan Codex Cloud bagi pengaturan eksekusi yang didukung. Dokumen lingkungan yang kosong mewarisi pengaturan dari Global; dokumen tersebut tidak menyalin atau mengunci pengaturan dasar saat ini.
4. Gunakan kontrol yang dijelaskan dalam panduan ini. Untuk bidang lanjutan, pilih Edit sebagai TOML, lalu edit requirements.toml atau config.toml pada cakupan yang sesuai. Pilih Gunakan kontrol pengaturan untuk kembali ke editor visual.
5. Tinjau pesan validasi, lalu pilih Simpan perubahan. Menerapkan aturan di editor aturan akan memperbarui draf; tindakan tersebut tidak langsung menyimpan kebijakan.
6. Periksa pemilihan kebijakan dan perilaku klien yang didukung seperti yang dijelaskan dalam Memastikan pengalaman admin dan karyawan.

Editor lingkungan dan bidang yang didukung bergantung pada ruang kerja dan kebijakan. Lihat Tempat pengaturan berlaku sebelum memindahkan pengaturan Global ke suatu lingkungan. Pengaturan di Global tidak selalu berlaku untuk setiap produk atau jalur eksekusi.

Menyalin atau menggunakan kembali konfigurasi

Editor visual tidak menggantikan TOML. Pilih Edit sebagai TOML untuk menyalin konfigurasi, menyimpan salinan referensi, atau menggunakan kembali pengaturan dalam kebijakan lain. Pilih Gunakan kontrol pengaturan untuk kembali ke editor visual.

1. Buka kebijakan sumber, lalu pilih Edit sebagai TOML.
2. Pilih cakupan yang ingin Anda salin: Global atau tab lingkungan yang tersedia. Salin teks dari Persyaratan (requirements.toml), Default (config.toml), atau keduanya, sesuai dengan pengaturan yang ingin Anda gunakan kembali.
3. Buka kebijakan tujuan, pilih Edit sebagai TOML, lalu pilih cakupan yang sesuai. Tempel persyaratan ke requirements.toml dan nilai default ke config.toml. Tinjau pengaturan yang sudah ada di tujuan sebelum mengganti teks; pertahankan pengaturan lain yang masih harus berlaku.
4. Tinjau pesan validasi serta sasaran dan prioritas kebijakan tujuan, lalu pilih Simpan perubahan. Pastikan perilaku klien yang dihasilkan sesuai sebelum mengandalkan kebijakan yang disalin.

Teks yang disalin berisi pengaturan yang ditulis untuk kebijakan dan cakupan tersebut. Teks ini tidak menyertakan penetapan, urutan kebijakan, dokumen lingkungan lain, atau konfigurasi efektif yang digabungkan dari kebijakan lain dan pengaturan perangkat. Salin pengaturan lingkungan secara terpisah bila diperlukan. Beralih tampilan atau menyalin teks tidak menyimpan perubahan kebijakan.

Coba contoh di bawah ini: ubah suatu pengaturan, lalu pilih Edit sebagai TOML untuk melihat konfigurasinya. Beralih kembali dengan Gunakan kontrol pengaturan untuk melanjutkan percobaan.

allowed_approval_policies = ["on-request"]
allowed_sandbox_modes = ["read-only"]
allowed_web_search_modes = ["disabled"]

Memilih kontrol yang tepat

Mengontrol browser dan Computer Use

Gunakan Keamanan agen di Konsol Admin untuk mengelola akses browser dan aplikasi native bagi klien desktop yang didukung. Mulai dengan kontrol UI. Contoh TOML di bawah ini menyediakan referensi konfigurasi untuk distribusi kebijakan berbasis file dan pengaturan yang memerlukan editor TOML.

Browser Use mengontrol aktivitas yang dijalankan agen di browser. Computer Use mengontrol aktivitas yang dijalankan agen di aplikasi desktop native. Pengaturan panel browser bawaan terpisah dari Browser Use. Lihat sesi browser dan sesi login yang sudah ada untuk mengetahui perbedaan antarjalur browser.

Sebelum memulai

Gunakan akun dengan izin untuk mengelola kebijakan Keamanan Agen. Pastikan siapa saja yang menerima kebijakan serta versi klien dan sistem operasi yang perlu Anda dukung. Tinjau Keamanan Agen untuk mengetahui penetapan kebijakan, pengaturan Global, dan penggantian lingkungan yang didukung.

Gunakan Persyaratan untuk batasan yang tidak dapat dikesampingkan pengguna. Default menetapkan nilai awal dalam batasan tersebut. Mengizinkan situs atau aplikasi tidak akan menginstal plugin, memberikan izin sistem operasi, membuat pengguna masuk, atau menyetujui tindakan yang masih memerlukan peninjauan.

Di bagian Ketersediaan fitur desktop, tinjau Penggunaan browser, Penggunaan browser eksternal, dan Penggunaan komputer. Nonaktifkan paksa menonaktifkan fitur terkait; aturan izin untuk situs atau aplikasi tidak dapat mengesampingkannya. Tinjau Akses CDP penuh secara terpisah; Blokir pengaktifan oleh pengguna mencegah pengguna mengaktifkannya.

Kontrol desktop ini tidak mengonfigurasi browser Work Cloud yang dihosting. Kelola Penggunaan browser cloud dan Akses jaringan cloud secara terpisah di Konsol Admin > Izin & peran > Kemampuan ruang kerja > Kemampuan komputer cloud. Lihat cara Agent Security berlaku untuk Work Cloud.

Mengonfigurasi akses browser

1. Buka Konsol Admin > Agent Security. Gunakan Default ruang kerja sebagai pengaturan dasar ruang kerja, atau buka kebijakan terkait di bagian Penggantian. Di Persyaratan, buka Kontrol browser desktop.
2. Di Aturan situs, buka menu tindakan pada baris Default, lalu pilih Edit Default. Untuk membatasi akses hanya ke situs yang disetujui, atur Akses situs ke Blokir, lalu pilih Terapkan aturan. Baris Default menyediakan nilai untuk pengaturan yang dibiarkan oleh aturan situs yang cocok pada Gunakan aturan default.
3. Pilih Tambahkan aturan situs. Di Situs atau pola, masukkan origin: skema, nama host, dan port opsional. Misalnya, https://example.com valid; https://example.com/files tidak valid. Jangan sertakan jalur, kueri, atau fragmen. HTTP dan HTTPS merupakan origin yang berbeda. Tentukan port jika berbeda dari port default skema.
4. Atur Akses situs dan tinjau Unduhan, Unggahan, serta Debug/CDP. Pilih Izinkan atau Blokir sesuai kebutuhan, atau biarkan pengaturan pada Gunakan aturan default. Debug/CDP mengontrol akses penuh ke Chrome DevTools Protocol untuk penelusuran kesalahan browser. Izinkan memungkinkan pemeriksaan kebijakan dan persetujuan normal berlanjut.
5. Tinjau Peninjauan otomatis, Selalu izinkan, dan Durasi persetujuan untuk situs tersebut. Durasi persetujuan menawarkan Giliran ini dan Utas ini. Tinjau juga Riwayat browser, Simpan persetujuan situs, dan Setujui permintaan secara otomatis di Kontrol browser desktop.
6. Pilih Tambahkan aturan, tinjau pesan validasi, lalu pilih Simpan perubahan. Uji situs yang diizinkan dan situs yang diblokir pada klien yang didukung dan menerima kebijakan tersebut. Uji unggahan, unduhan, dan tindakan lain yang dibatasi secara terpisah.

Tambahkan aturan situs

Baris Default berlaku saat aturan situs membiarkan suatu izin pada Default. Jika aturan tumpang tindih, Blokir diutamakan untuk setiap izin.

Situs atau pola 

Akses situsGunakan aturan default

UnduhanGunakan aturan default

UnggahanGunakan aturan default

Debug/CDPGunakan aturan default

Peninjauan otomatisGunakan aturan default

Selalu izinkanGunakan aturan default

Durasi persetujuanGunakan aturan default

Menonaktifkan peninjauan otomatis untuk tindakan browser akan mengirim tindakan tersebut kepada pengguna untuk meminta persetujuan. Hal ini tidak menonaktifkan pemantauan keamanan model.

Jika beberapa pola origin cocok, nilai yang paling ketat diutamakan untuk setiap pengaturan. Konfigurasi lokal tidak dapat melonggarkan penolakan terkelola. Penolakan jaringan terkelola dan daftar izin eksklusif juga berlaku untuk alat browser. Lihat kolom kebijakan browser untuk pola origin dan perilaku persetujuan.

Computer Use juga dapat mengoperasikan browser sebagai aplikasi native. Aturan situs dan kemampuan Browser Use tidak berlaku untuk jalur tersebut. Tinjau akses aplikasi native secara terpisah; lihat batas keamanan browser.

Mengonfigurasi akses aplikasi native

1. Di Persyaratan, buka Kontrol aplikasi desktop > Aturan aplikasi.
2. Gunakan menu tindakan pada baris Default untuk mengonfigurasi akses bagi aplikasi tanpa aturan yang cocok. Untuk membatasi Computer Use hanya ke aplikasi yang disetujui, blokir akses secara default dan tambahkan aturan izin untuk aplikasi tersebut.
3. Pilih Tambahkan aturan aplikasi. Dalam dialog Edit aturan, pilih macOS bundle ID, Windows AUMID, atau Windows executable dari Aplikasi. Masukkan Pengenal aplikasi yang tepat untuk bundle ID atau Application User Model ID (AUMID). Untuk Windows executable, masukkan Nama penerbit dan Nama produk; Nama biner bersifat opsional. Gunakan informasi identitas aplikasi yang terverifikasi, bukan nama tampilan atau jalur file.
4. Atur Akses aplikasi untuk aturan tersebut, lalu pilih Tambahkan aturan. Tinjau Simpan persetujuan aplikasi di bagian Kontrol aplikasi desktop, tinjau pesan validasi, lalu pilih Simpan perubahan. Menonaktifkan persetujuan tersimpan tetap memungkinkan persetujuan untuk sesi saat ini; mengizinkan penyimpanan persetujuan tidak memberikan persetujuan untuk suatu aplikasi.
5. Uji aplikasi yang diizinkan dan aplikasi yang diblokir pada setiap sistem operasi yang didukung dalam penerapan Anda. Pastikan izin sistem operasi tetap berlaku dan pengguna tetap harus memberikan persetujuan yang diperlukan.

Edit aturan

Atur akses aplikasi default dan ganti pengaturan tersebut untuk aplikasi yang cocok.

AplikasimacOS bundle ID

Pengenal aplikasi 

Akses aplikasiPilih akses

Lihat kolom kebijakan Computer Use untuk persyaratan identitas Windows dan pembatasan penggunaan saat terkunci untuk Mac terkelola.

Memeriksa kebijakan yang berlaku

Jika situs atau aplikasi yang diizinkan masih diblokir, periksa aturan lain yang cocok, penetapan dan prioritas kebijakan, persyaratan perangkat, serta konfigurasi pengguna. Aturan izin dari satu sumber tidak mengesampingkan penolakan lain yang berlaku. Lihat lokasi dan urutan prioritas persyaratan.

Jika suatu pengaturan tidak berpengaruh, pastikan klien, sistem operasi, dan jalur penyampaian kebijakan mendukungnya. Perhatikan secara khusus Work Cloud dengan akses komputer lokal: beberapa kolom hanya didukung sebagian atau memerlukan validasi. Lihat kompatibilitas Work dalam Referensi Konfigurasi.

Periksa izin ruang kerja dan kontrol plugin secara terpisah jika pengguna tidak dapat mengakses fitur atau plugin yang diperlukan.

Referensi konfigurasi TOML

Contoh berikut menjelaskan maksud kebijakan yang sama untuk requirements.toml. Gunakan contoh ini saat mengelola kebijakan melalui file atau editor TOML. Anda tidak perlu mengedit file lokal untuk menggunakan kontrol yang tersedia di Agent Security.

Contoh browser ini menolak akses secara default, mengizinkan https://example.com, memblokir unggahan dan akses CDP penuh di situs tersebut, serta membatasi persetujuan akses situs hingga giliran saat ini:

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

Untuk menonaktifkan peninjauan otomatis atas tindakan browser, tetapkan browser_use.disable_auto_review = true, atau tetapkan auto_review = "deny" pada kebijakan origin untuk membatasinya pada origin tersebut.

Untuk mengaktifkan Alat situs bagi ruang kerja Enterprise yang memenuhi syarat, tetapkan browser_use.allow_webmcp = true. Pengaktifan terkelola ini berlaku untuk browser bawaan aplikasi desktop. Menetapkannya ke false atau mengabaikannya tetap mempertahankan pemeriksaan ketersediaan fitur yang normal; false tidak memberlakukan pemblokiran. Preferensi pengguna dan izin situs tetap berlaku.

Contoh aplikasi native ini mengizinkan Calculator di macOS, menolak aplikasi lain secara default, dan mencegah persetujuan aplikasi tetap berlaku antarsesi:

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

Untuk semua field dan nilai yang didukung, gunakan referensi requirements.toml. Untuk menonaktifkan suatu kemampuan alih-alih membatasi situs atau aplikasi satu per satu, lihat Tetapkan flag fitur.

Kontrol desktop lainnya

Kontrol desktop berikut mencakup ketersediaan fitur, Locked Use, Appshots, dan kendali jarak jauh perangkat. Gunakan pengaturan khusus untuk ketersediaan fitur dan Locked Use; konfigurasikan Appshots dan kendali jarak jauh perangkat dengan Edit sebagai TOML. Untuk pembatasan tujuan lalu lintas aplikasi desktop, lihat Kontrol tujuan jaringan aplikasi desktop.

Tetapkan flag fitur

Untuk fitur desktop yang tersedia di Agent security, buka Global > Persyaratan > Ketersediaan fitur desktop. Tetapkan Browser dalam aplikasi, Penggunaan browser, Penggunaan browser eksternal, atau Penggunaan komputer ke Paksa nonaktif untuk menonaktifkan kemampuan tersebut, lalu pilih Simpan perubahan. Untuk Akses CDP penuh, pilih Blokir pengaktifan oleh pengguna agar pengguna tidak dapat mengaktifkannya. Mengizinkan suatu fitur tidak mengesampingkan ketersediaannya berdasarkan produk, platform, atau peluncuran.

Untuk flag fitur lain yang didukung, gunakan Edit sebagai TOML dan dokumen requirements.toml Global, atau sumber persyaratan lokal yang didukung. Contoh berikut mencakup penetapan fitur runtime dan fitur khusus desktop:

[features]
hooks = 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] di 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.

Pengaturan terkelola unified_exec = false tetap menyediakan eksekusi perintah, tetapi menonaktifkan proses yang dapat dilanjutkan dan alat write_stdin. Konfigurasi pengguna tidak dapat menonaktifkan fitur ini.

• in_app_browser = false menonaktifkan panel browser bawaan.
• in_app_updates = false menonaktifkan pembaru bawaan aplikasi desktop ChatGPT saat dimulai ulang, jika didukung. Pengaturan ini tidak memengaruhi penerapan paket eksternal atau memperpanjang dukungan untuk versi aplikasi yang lebih lama. Untuk panduan penyiapan dan peluncuran, lihat Kelola pembaruan aplikasi.
• browser_use = false menonaktifkan kemampuan Browser Use yang didukung. Browser Use eksternal dan Computer Use untuk aplikasi native memiliki kontrol terpisah.
• browser_use_full_cdp_access = false menonaktifkan akses CDP penuh di runtime lokal, termasuk mode Browser Developer, dan mencegah aplikasi desktop ChatGPT mengaktifkan pengaturan terkait.
• browser_use_external = false menonaktifkan Browser Use yang dijalankan agen melalui ekstensi browser yang didukung.
• computer_use = false menonaktifkan Computer Use untuk aplikasi native, termasuk pengoperasian browser sebagai aplikasi native, beserta Record & Replay dan alur penginstalan atau penyiapan terkait.

Menonaktifkan Browser Use saja tidak memblokir semua jalur akses browser. Computer Use untuk aplikasi native masih dapat mengoperasikan browser jika kemampuan tersebut dan akses aplikasi diizinkan; aturan situs dan kemampuan Browser Use tidak berlaku untuk jalur tersebut. Untuk memblokirnya, tetapkan Penggunaan komputer ke Paksa nonaktif (computer_use = false), atau tolak aplikasi browser di Aturan aplikasi jika aplikasi native lain harus tetap tersedia. Tinjau Penggunaan browser eksternal dan Browser dalam aplikasi secara terpisah. Lihat sesi browser dan sesi masuk yang sudah ada untuk mengetahui kontrol yang berlaku bagi setiap jalur.

Jika Anda mengabaikan kunci ini, kebijakan mengizinkan fitur tersebut, sesuai ketersediaan normal pada klien, platform, dan peluncuran.

Batasi penggunaan komputer saat terkunci

Untuk mencegah pengguna mengaktifkan Locked Use di Mac terkelola, buka Global > Persyaratan > Kontrol aplikasi desktop, tetapkan Izinkan penggunaan saat terkunci ke Dinonaktifkan, lalu pilih Simpan perubahan. Pengaturan ini tidak menonaktifkan Locked Use di Mac yang sudah mengaktifkannya.

Persyaratan yang setara untuk editor TOML atau distribusi melalui pengelolaan perangkat adalah:

[computer_use]
allow_locked_computer_use = false

Persyaratan ini menghapus kontrol untuk mengaktifkan Locked Use. Persyaratan ini tidak menonaktifkan Locked Use jika sudah diaktifkan. Jika Anda mengabaikannya, ketersediaan produk normal dan pengaturan lokal pengguna tetap berlaku.

Nonaktifkan Appshots

Appshots memungkinkan klien yang didukung menyertakan snapshot aplikasi. Untuk menonaktifkannya bagi pengguna yang dikelola melalui cloud, buka Edit sebagai TOML di Agent security dan tetapkan field tingkat teratas allow_appshots di requirements.toml Global. Untuk penerapan yang dikelola melalui perangkat, gunakan sumber persyaratan lokal yang sesuai:

allow_appshots = false

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

Nonaktifkan kendali jarak jauh perangkat

Untuk menonaktifkan kendali jarak jauh perangkat bagi pengguna yang dikelola melalui cloud, gunakan Edit sebagai TOML di Agent security dan tetapkan field tingkat teratas allow_remote_control di requirements.toml Global. Anda dapat juga menetapkan allow_remote_control di sumber persyaratan lokal yang didukung:

allow_remote_control = false

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

Atur persetujuan dan izin eksekusi

Gunakan bagian ini untuk mengatur perilaku persetujuan, batas izin, dan nilai default awal. Mulailah dengan Batasan kebijakan dan Default. Tugas berikutnya menjelaskan persyaratan TOML untuk pemberlakuan peninjau, profil izin kustom, pembatasan sistem file, penggantian pengaturan host, dan aturan perintah.

Persyaratan yang diberlakukan 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, MCP server 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 MCP server 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.

Tetapkan batasan persetujuan, sandbox, dan pencarian web

Gunakan Persyaratan > Batasan kebijakan untuk membatasi pilihan klien yang didukung. Kontrol ini membatasi konfigurasi; kontrol ini tidak menentukan nilai awal. Tetapkan nilai awal secara terpisah di Default.

1. Di Global, buka Kebijakan persetujuan dan pilih jenis persetujuan yang diizinkan. Misalnya, Tanyakan bila diperlukan memungkinkan agen meminta persetujuan untuk tindakan seperti eskalasi sandbox. Jangan pernah bertanya mencegah permintaan persetujuan; opsi ini tidak memberikan izin eksekusi tanpa batas.
2. Buka Mode sandbox untuk membatasi pilihan sandbox lama. Hanya baca membatasi penulisan, Penulisan ruang kerja mengizinkan penulisan di dalam ruang kerja dan direktori akar yang dikonfigurasi sebagai dapat ditulisi, dan Akses penuh menghapus isolasi sistem berkas. Gunakan persyaratan profil izin untuk penerapan yang menggunakan profil izin sebagai pengganti sandbox_mode.
3. Di Global, buka Mode pencarian web untuk membatasi pencarian web. Pilih Cache untuk mengizinkan pencarian dari cache tanpa pencarian langsung, atau Dinonaktifkan untuk menonaktifkan pencarian web. Pembatasan pencarian web terpisah dari aturan jaringan perintah.
4. Tinjau pilihan yang diizinkan beserta nilai default yang sesuai, lalu pilih Simpan perubahan.

Membiarkan suatu persyaratan tidak ditetapkan berarti kebijakan tersebut tidak memberlakukan batasan. Kebijakan lain yang berlaku tetap diterapkan. Opsi Tanyakan untuk perintah yang tidak tepercaya berpadanan dengan untrusted dalam daftar izin persyaratan; opsi ini tidak memulihkan pengaturan eksplisit approval_policy = "untrusted" yang telah dihentikan. Ikuti panduan migrasi di bawah untuk kasus tersebut.

Untuk membatasi pencarian web, gunakan Global > Persyaratan > Batasan kebijakan > Mode pencarian web. TOML yang setara adalah:

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

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

Tetapkan nilai default konfigurasi

Nilai default memberikan konfigurasi awal kepada anggota. Nilai ini tidak memberlakukan pembatasan atau memberikan akses ke kemampuan ruang kerja.

1. Buka kartu Default pada kebijakan. Simpan nilai default yang berlaku untuk seluruh agen di Global; gunakan tab lingkungan yang tersedia untuk nilai default eksekusi yang didukung.
2. Di bagian Eksekusi perintah, pilih Kebijakan persetujuan dan Peninjau persetujuan awal, serta Mode sandbox atau Izin default yang berlaku. Peninjau menentukan siapa yang meninjau permintaan persetujuan secara default; kebijakan persetujuan menentukan kapan permintaan dapat diajukan.
3. Di bagian Pencarian web, pilih mode Pencarian web dan Konteks pencarian web awal. Di bagian Aplikasi dan alat, tinjau Aplikasi/konektor, Alat dunia terbuka, dan Alat destruktif untuk alat aplikasi yang didukung.
4. Pastikan nilai default memenuhi Persyaratan Anda, lalu pilih Simpan perubahan.

Gunakan Edit sebagai TOML untuk nilai default yang didukung tanpa kontrol visual, seperti konfigurasi marketplace plugin. Nilai default cloud ini menggunakan urutan prioritas konfigurasi normal. Nilai ini berbeda dari urutan prioritas managed_config.toml lama, yang menempatkan nilai default terkelola di atas konfigurasi lokal saat startup.

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.

Migrasikan kebijakan persetujuan untrusted yang telah dihentikan

Codex dan ChatGPT Work tidak lagi mendukung approval_policy = "untrusted". Hapus pengaturan tersebut dari nilai default terkelola, managed_config.toml lama, dan setiap 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 diizinkan oleh persyaratan terkelola Anda. Perintah yang diizinkan oleh sandbox tersebut dapat dijalankan tanpa persetujuan.

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

Konfigurasikan kebijakan peninjauan otomatis

Untuk menjadikan peninjauan otomatis sebagai default, gunakan Global > Default > Eksekusi perintah > Peninjau persetujuan. Nilai default memungkinkan pengguna memilih peninjau lain yang diizinkan. Untuk mewajibkan peninjauan otomatis atau menyediakan instruksi peninjauan organisasi Anda, gunakan Edit sebagai TOML dan edit requirements.toml Global. Persyaratan ini terpisah dari kontrol peninjauan otomatis browser.

Gunakan allowed_approvals_reviewers untuk mewajibkan atau mengizinkan peninjauan otomatis. Tetapkan nilainya 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 keluaran. guardian_policy_config terkelola lebih diutamakan 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.
"""

Mengontrol profil izin yang tersedia

Gunakan Default > Eksekusi perintah > Izin default untuk memilih profil bawaan yang digunakan pengguna saat memulai. Untuk memberlakukan profil mana yang dapat dipilih pengguna atau untuk menentukan profil kustom, gunakan Edit sebagai TOML dan konfigurasikan requirements.toml untuk cakupan Global atau lingkungan eksekusi yang didukung dan sesuai. Memilih nilai default saja tidak membatasi profil 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.

Berlakukan persyaratan penolakan baca

Gunakan Edit sebagai TOML untuk menambahkan pembatasan sistem berkas ke requirements.toml Global atau lingkungan eksekusi yang didukung dan sesuai. Pembatasan ini memblokir pembacaan jalur sensitif; nilai default hanya baca saja tidak menyembunyikan berkas.

Admin dapat menolak pembacaan untuk jalur persis atau pola glob dengan [permissions.filesystem]. Pengguna tidak dapat memperlonggar 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 ditetapkan, runtime lokal menolak izin akses penuh dan mempertahankan eksekusi lokal dalam sandbox hanya baca atau ruang kerja agar persyaratan tersebut dapat diberlakukan. Pada Windows native, deny_read terkelola berlaku untuk alat berkas langsung; pembacaan oleh subproses shell tidak menggunakan aturan sandbox ini.

Menimpa persyaratan sandbox berdasarkan host

Gunakan Edit sebagai TOML di Keamanan agen untuk menyusun persyaratan khusus host. Kontrol lingkungan memilih lingkungan eksekusi; pola host memilih mesin yang cocok dalam runtime yang didukung.

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.

Berlakukan aturan perintah dari persyaratan

Gunakan Edit sebagai TOML di Keamanan agen untuk menambahkan aturan perintah dan pembatasan MCP server ke requirements.toml Global. Aturan perintah menentukan keputusan persetujuan atau penolakan untuk perintah yang cocok; pembatasan MCP membatasi identitas server mana yang dapat diaktifkan klien. Kontrol Kebijakan persetujuan tidak menyusun salah satu dari kedua kumpulan aturan ini.

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

Berbeda dengan .rules, aturan persyaratan harus menetapkan 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 MCP server mana yang dapat diaktifkan klien lokal, tambahkan daftar mcp_servers yang disetujui. Untuk server stdio, cocokkan berdasarkan command; untuk server HTTP yang mendukung streaming, 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 ini tidak memeriksa args, cwd, env, atau env_vars.

Untuk membatasi pemanggilan stdio secara lengkap, cocokkan berkas eksekusi dan setiap argumen posisi:

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

Berkas eksekusi, jumlah argumen, dan urutan argumen harus cocok. Aturan argumen dan URL mendukung pencocokan exact, prefix, dan regex untuk seluruh nilai. Aturan perintah terstruktur tetap tidak memeriksa cwd, env, atau env_vars. MCP server yang dibundel dengan plugin menggunakan bentuk identitas yang sama di bawah plugins.<plugin>.mcp_servers.<server>.

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

Konfigurasikan akses jaringan

Jaringan perintah dan jaringan aplikasi desktop menggunakan kontrol yang berbeda. Mulai dengan Kontrol penggunaan jaringan untuk lalu lintas perintah yang didukung, tinjau batasan lingkungan dan runtime, lalu gunakan persyaratan aplikasi desktop yang terpisah jika diperlukan. Aturan situs browser tetap berada di Kontrol browser dan Computer Use.

Mengonfigurasi persyaratan akses jaringan

Gunakan Persyaratan > Kontrol penggunaan jaringan untuk mengelola jaringan perintah yang didukung di Keamanan agen. Konfigurasikan pengaturan dasar bersama di Global, atau tab Lingkungan Lokal atau Lingkungan Codex Cloud yang tersedia untuk pengaturan eksekusi khusus lingkungan.

1. Atur Jaringan terkelola ke Aktif untuk menerapkan aturan domain pada lalu lintas perintah terkelola. Menambahkan aturan domain saja tidak mengaktifkan proksi terkelola.
2. Di bagian Aturan jaringan, pilih Tambahkan aturan jaringan. Masukkan Domain seperti api.openai.com atau **.example.com, tanpa skema URL atau jalur. Pilih Izinkan atau Tolak di bagian Akses, lalu pilih Simpan aturan untuk memperbarui draf. Ulangi untuk tujuan lainnya.
3. Atur Hanya izinkan domain yang ditambahkan admin ke Aktif jika pengaturan pengguna dan persetujuan per domain tidak boleh memperluas daftar izin terkelola. Sertakan entri Izinkan yang diperlukan; daftar yang hanya berisi penolakan tidak mengizinkan tujuan lain.
4. Tinjau Izinkan akses jaringan lokal untuk alur kerja yang memerlukan listener lokal atau tujuan privat. Koneksi lokal langsung dapat melewati aturan domain proksi. Tinjau batas konektivitas Codex Cloud di bawah sebelum mengubah pengaturan ini.
5. Tinjau aturan yang diwarisi dan pesan validasi, lalu pilih Simpan perubahan. Uji satu permintaan yang seharusnya berhasil dan satu yang seharusnya diblokir di setiap lingkungan eksekusi yang terdampak.

Mengatur Jaringan terkelola ke Nonaktif menghapus aturan jaringan yang dibuat untuk cakupan tersebut dan menyimpan nilai nonaktif secara eksplisit; tindakan ini tidak menonaktifkan akses internet. Tidak diatur menghapus pengaturan jaringan yang dibuat untuk cakupan tersebut sehingga kebijakan atau nilai default runtime yang berlaku dapat diterapkan. Menghapus pengaturan lingkungan dapat memunculkan aturan Global yang diwarisi. Gunakan Edit sebagai TOML untuk kolom jaringan lanjutan atau daftar domain lama yang sudah ada yang tidak dapat direpresentasikan oleh editor visual.

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 aturan penolakan jaringan terkelola dan daftar izin eksklusif sebelum mengakses suatu origin. Ini merupakan pemeriksaan kebijakan terpisah, bukan perutean lalu lintas browser melalui proksi perintah. Pemeriksaan ini tidak memfilter pencarian web, aplikasi dan konektor, MCP server, lalu lintas aplikasi native, permintaan layanan Codex, atau lalu lintas khusus kemampuan lainnya. 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 yang disetujui untuk mcp_servers terkelola guna membatasi MCP server.
• Gunakan persyaratan fitur seperti browser_use, in_app_browser, dan computer_use untuk membatasi kemampuan browser dan penggunaan komputer.
• Untuk perintah Codex Cloud terkelola yang didukung, konfigurasikan persyaratan Agent Security dan pengaturan internet lingkungan Cloud secara terpisah.

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

Pada jalur eksekusi Codex Cloud terkelola yang didukung, persyaratan Agent Security membatasi akses jaringan perintah. Pengaturan internet lingkungan Codex Cloud berlaku secara terpisah. Domain yang diizinkan dalam Agent Security tidak mengesampingkan pembatasan dalam pengaturan internet lingkungan Cloud. Kontrol jaringan perintah ini tidak dengan sendirinya menonaktifkan pencarian web yang dihosting, aplikasi, atau MCP. ChatGPT Work Cloud memiliki izin kemampuan terpisah dan tidak mewarisi persyaratan Agent Security ini.

Daftar izin perintah terkelola berlaku untuk perintah yang menggunakan proksi terkelola. Jika kebijakan mengizinkan eskalasi sandbox penuh dan eskalasi tersebut disetujui, eksekusi tersebut dapat melewati proksi perintah. Pemberian akses jaringan terbatas berbeda dari eskalasi sandbox penuh. Konfigurasikan persyaratan persetujuan dan sandbox yang diberlakukan sesuai batas yang dituju, lalu uji perintah biasa maupun perintah dengan eskalasi.

Tidak ada tujuan yang diizinkan secara efektif: Saat Jaringan terkelola dan Hanya izinkan domain yang ditambahkan admin diatur ke Aktif, perintah terkelola biasa memerlukan tujuan yang diizinkan secara efektif. Jika tidak ada entri Izinkan yang dikonfigurasi atau diwarisi, perintah tersebut tidak memiliki tujuan yang diizinkan. Kebijakan yang hanya berisi penolakan tidak secara implisit mengizinkan bagian internet lainnya. Tambahkan entri Izinkan yang diperlukan dan periksa aturan yang diwarisi sebelum menyimpan. Pembatasan ini berlaku untuk proksi perintah terkelola, bukan untuk setiap alat atau eskalasi sandbox penuh yang telah disetujui.

Konektivitas lokal/privat Codex Cloud: Nilai Off yang eksplisit untuk konektivitas lokal/privat dapat mencegah Codex Cloud menjangkau proxy upstream-nya, meskipun domain tujuan diizinkan. Periksa nilai akhir allow_local_binding dan identifikasi kebijakan atau pengaturan yang memberikan nilai tersebut. Pada jalur proxy Cloud yang didukung, nilai ini secara default adalah true hanya jika tidak ada persyaratan yang berlaku, profil jaringan yang dipilih, atau pengaturan fitur proxy yang memberikan nilai. Nilai false yang diwarisi tetap dianggap sebagai pengaturan eksplisit. Jika didukung, tetapkan penggantian Cloud dengan prioritas lebih tinggi untuk mengubah nilai ini bagi Codex Cloud tanpa mengubah nilai Global yang digunakan oleh Local. Tindakan ini tidak menambahkan entri Allow domain. Verifikasi dukungan eksekutor sebelum mengandalkan penggantian tersebut. Jangan terapkan nilai default Cloud ini pada Local.

Jika persyaratan lingkungan kosong, persyaratan Global berlaku. Jaringan terkelola yang diatur ke Nonaktif terpisah dari pengaturan akses Internet lingkungan Cloud. Lihat kontrol eksekusi Agent Security untuk detail tentang cakupan eksekusi.

Urutan prioritas kebijakan jaringan dan batas runtime

Dalam suatu kebijakan, urutan dari tertinggi ke terendah adalah penggantian pengaturan lingkungan khusus OS → penggantian pengaturan lingkungan untuk semua OS → Global. Kebijakan dengan prioritas lebih tinggi tetap mengungguli kebijakan dengan prioritas lebih rendah, meskipun kebijakan berprioritas lebih rendah tersebut lebih spesifik. Beberapa persyaratan memiliki aturan penggabungan khusus per kolom. Runtime kemudian memberlakukan persyaratan yang telah ditentukan. Pertimbangkan kasus jaringan khusus per kolom di bawah secara terpisah dari prioritas kebijakan.

Contoh-contoh ini membandingkan pengaturan lingkungan dan Global dalam kebijakan yang sama, dengan jaringan terkelola yang sudah dikonfigurasi dan tanpa kebijakan berprioritas lebih tinggi yang mengubah nilainya. Contoh-contoh ini menjelaskan perilaku penggabungan khusus per kolom dan perilaku runtime.

Atur akses domain yang berbeda untuk setiap lingkungan

Untuk aturan domain yang sama dalam suatu kebijakan, penggantian pengaturan lingkungan oleh admin dapat mengizinkan domain yang ditolak di Global atau menolak domain yang diizinkan di Global. Tanpa penggantian pengaturan lingkungan, aturan Global diwarisi. Aturan Tolak lain yang berlaku atau kontrol akses lainnya tetap dapat memblokir permintaan.

Cara aturan domain digabungkan

Hasil ini membandingkan kunci domain yang sama dalam satu kebijakan, tanpa kebijakan berprioritas lebih tinggi yang mengubah hasilnya. Nilai berprioritas lebih tinggi menggantikan kunci yang sama. Kunci lain yang diwarisi tetap berlaku. Aturan Izinkan tidak melewati aturan Tolak lain yang cocok, seperti wildcard yang diwarisi. Peta lingkungan yang kosong tidak menghapus aturan yang diwarisi.

Contoh: Tolak packages.example.com di Global dan izinkan di Development. Development dapat mengizinkannya sesuai ketentuan di atas. Production mewarisi aturan Tolak Global kecuali jika diganti.

Pastikan eksekutor yang diterapkan mendukung aturan penggabungan ini. Cakupan dukungan untuk eksekutor terkelola biasa masih perlu divalidasi.

Batas Orchestrator. Port listener HTTP/SOCKS terkelola dan listener proksi non-loopback tidak didukung oleh runtime cloud; dukungan aturan soket bergantung pada jalur eksekusi. Pengaturan eksekusi lokal dalam tabel di bawah bukan merupakan konfigurasi Orchestrator yang didukung.

Batas runtime jaringan lainnya

Semua nama kolom di bawah berada di bawah experimental_network dalam requirements.toml. Tanda panah menunjukkan nilai Global yang diikuti oleh nilai lingkungan dalam kebijakan yang sama. Kasus eksekusi lokal ini tidak membuktikan dukungan Orchestrator untuk pengaturan yang sama.

Aktivasi proksi, eksklusivitas, perilaku proksi upstream, dan aturan soket Unix memiliki perilaku yang bergantung pada eksekutor. Jangan menggeneralisasi penggabungan kunci domain ke pengaturan ini. Verifikasi nilai yang berlaku dan uji runtime yang diterapkan. Untuk konektivitas lokal/privat Codex Cloud, lihat Konfigurasikan persyaratan akses jaringan.

Verifikasi perilaku sebelum peluncuran

Uji tujuan aktual, listener lokal, perilaku proksi, dan jalur soket yang digunakan alur kerja Anda. Periksa satu tindakan yang seharusnya berhasil dan satu yang seharusnya diblokir di setiap lingkungan yang terdampak. Pastikan versi runtime yang diterapkan mendukung setiap pengaturan yang Anda gunakan.

Kontrol tujuan jaringan aplikasi desktop

Gunakan Edit sebagai TOML di Keamanan agen untuk mengonfigurasi persyaratan khusus desktop ini di Global. UI Kontrol penggunaan jaringan mengelola jaringan perintah, yang merupakan kebijakan terpisah.

Gunakan [application.network] di requirements.toml untuk membatasi tujuan jaringan aplikasi desktop. Dengan enabled = true, permintaan eksternal harus menggunakan HTTPS atau WSS dan cocok persis dengan domain yang memiliki nilai "allow" di [application.network.domains]. Subdomain tidak diizinkan secara implisit. Peta domain yang kosong tidak mengizinkan tujuan eksternal apa pun. Lihat Referensi Konfigurasi untuk mengetahui kunci yang didukung.

Kebijakan ini terpisah dari aturan jaringan perintah dan origin browser. Kebijakan ini tidak memberlakukan pembatasan tujuan pada modul native atau proses yang diluncurkan, dan tidak mengatur eksekusi Work Cloud.

Konfigurasikan plugin dan hook terkelola

Untuk tugas-tugas ini, gunakan Edit sebagai TOML di Keamanan agen atau sumber konfigurasi lokal yang didukung. Nilai default marketplace, pembatasan plugin yang diberlakukan, dan hook terkelola memiliki tujuan berbeda; pilih tugas yang sesuai dengan kebijakan yang Anda perlukan.

Konfigurasikan marketplace plugin dan nilai default

Gunakan Keamanan agen > Edit sebagai TOML untuk menentukan marketplace lokal atau Git dan nilai default plugin dalam dokumen config.toml Global. Anda juga dapat mendistribusikan pengaturan ini dalam config.toml sistem. Pengaturan ini menyediakan konfigurasi awal marketplace dan plugin, bukan kebijakan yang diberlakukan. Untuk membatasi sumber yang dapat digunakan anggota, konfigurasikan persyaratan sumber marketplace.

Lihat Referensi Konfigurasi untuk kunci konfigurasi, Urutan prioritas konfigurasi untuk penggantian pengaturan, dan pengaturan plugin repositori untuk konfigurasi tingkat proyek. Impor dan sinkronisasi GitHub ruang kerja merupakan hal terpisah.

Mengontrol ketersediaan plugin

Gunakan Edit sebagai TOML di Keamanan agen untuk pengaturan fitur plugin yang diberlakukan dalam requirements.toml Global, atau distribusikan melalui persyaratan lokal untuk klien yang dikelola perangkat. Default > Aplikasi dan alat > Aplikasi/konektor mengatur nilai default alat aplikasi; pengaturan ini bukan sakelar features.plugins yang diberlakukan. Untuk izin plugin ruang kerja, lihat Aplikasi dan konektor.

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

Gunakan Edit sebagai TOML untuk mengonfigurasi persyaratan sumber marketplace dalam requirements.toml Global, atau distribusikan melalui persyaratan lokal. Aturan ini membatasi sumber lokal atau Git yang dapat ditambahkan dan digunakan pengguna. Aturan ini terpisah dari pengaturan default marketplace.

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.

Terapkan hook terkelola dari persyaratan

Hook terkelola menjalankan tindakan yang ditentukan administrator pada peristiwa tugas atau alat yang didukung. Gunakan Edit sebagai TOML di Agent security untuk mengonfigurasinya dalam requirements.toml Global; kontrol pengaturan tidak menyertakan editor hook khusus. Jalur eksekusi di bawah ini menentukan jenis hook yang dapat dijalankan.

Saat kebijakan terkelola dan hook jarak jauh diaktifkan, Work Cloud dengan akses lokal dan dots menggunakan hook MCP jarak jauh yang dikelola admin pada orkestrator cloud. Konfigurasikan penangan mcp_tool dalam requirements.toml Global. Work Cloud tanpa akses lokal dan akun pribadi tidak menggunakan hook perusahaan ini. Penangan perintah/shell, prompt, dan agen; hook dari konfigurasi lokal, plugin, atau direktori lokal; hook dengan cakupan lingkungan; serta hook MCP SessionEnd tidak didukung dengan orkestrasi cloud, meskipun alat dijalankan secara lokal. Saat orkestrasi dan eksekusi sama-sama berlangsung secara lokal, hook yang sudah didukung tetap berfungsi dalam utas Work dan Codex yang sepenuhnya lokal. Admin tetap dapat mengonfigurasi hook terkelola yang didukung di Agent Security untuk alur kerja tersebut.

Sebelum mengandalkan hook ini, uji konektivitas callback, peristiwa yang diperlukan, dan perilaku saat terjadi kegagalan. Penolakan eksplisit yang didukung dapat memblokir tindakan, tetapi kesalahan callback PreToolUse, batas waktu yang terlampaui, atau respons dengan format yang salah dapat menyebabkan hook gagal tanpa memblokir alat. Hook MCP tidak menyediakan jejak audit Compliance API yang lengkap. Contoh skrip dan direktori berikut tetap memiliki cakupan Codex.

Admin juga dapat menentukan hook siklus hidup terkelola langsung dalam requirements.toml. Gunakan [hooks] untuk konfigurasi hook itu sendiri, dan arahkan managed_dir ke direktori tempat MDM atau alat pengelolaan endpoint Anda memasang 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 sambil 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.
• Distribusikan skrip tersebut dengan MDM atau solusi pengelolaan perangkat Anda.
• Perintah hook terkelola harus merujuk ke jalur skrip absolut di dalam 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.

Pahami cakupan dan urutan prioritas kebijakan

Gunakan bagian ini untuk memeriksa tempat kebijakan berlaku, cara persyaratan digabungkan, cara klien menerima pengaturan yang dikelola melalui cloud, dan cara memverifikasi hasilnya.

Untuk Work dengan akses lokal dan dots, kebijakan Global yang didukung mengatur orkestrator cloud bersama saat kebijakan terkelola diaktifkan; persyaratan eksekusi lokal yang berlaku mengatur komputer yang terhubung. Kontainer cloud Work mempertahankan kebijakan Work Cloud yang ada, dan kontrol perangkat yang didukung tetap berlaku untuk eksekusi lokal. Codex mempertahankan perilaku konfigurasi yang ada. Konfigurasi terkelola tidak memberikan lisensi pengguna ruang kerja atau akses fitur. Gunakan Peran dan izin ruang kerja untuk kontrol tersebut.

Agent Security dan akses komputer lokal dengan Work Cloud

Gunakan Agent Security di Admin Console untuk mengelola kebijakan dan konfigurasi. Fitur ini menggantikan Policies & Configuration. Agent Security tersedia di Admin Console, secara independen dari akses komputer lokal dengan Work Cloud. Kebijakan, penetapan, dan urutan yang ada dipertahankan. Tinjau kebijakan Anda yang ada di Agent Security. Akses komputer lokal dengan Work Cloud memerlukan pengaktifan terpisah. Lihat Agent Security untuk panduan migrasi.

Sebelum memindahkan otomatisasi kebijakan ke Agent Security:

1. Identifikasi integrasi yang terdampak. Inventarisasi konfigurasi Terraform dan skrip yang memperbarui kebijakan, lalu catat kebijakan yang dikelolanya.

2. Gunakan API kebijakan untuk mengelola pengaturan Global. Untuk mengelola pengaturan Local atau Codex Cloud, gunakan UI Agent Security. Alur kerja API Global yang ada tetap tersedia setelah migrasi. Uji skrip dan integrasi Terraform Anda, lalu pastikan penetapan dan urutan kebijakan tidak berubah.

3. Lakukan perubahan yang diperlukan dan uji otomatisasi. Verifikasi bahwa pembaruan yang dimaksud mencapai kebijakan Agent Security yang benar dan bahwa kontrol yang dihasilkan diterapkan.

Migrasi kebijakan tidak memberikan akses komputer lokal untuk Work atau dots. Sebaiknya tinjau atau buat kebijakan sebelum peluncuran, tetapi alur konfirmasi tidak mewajibkan pembuatan kebijakan untuk mengaktifkan akses. Sebelum mengaktifkan Izinkan akses komputer lokal, tinjau konfigurasi dasar yang dimigrasikan atau buat konfigurasi dasar cloud jika kebijakan Anda saat ini hanya didistribusikan melalui MDM. Jika enforce_residency diaktifkan dalam kebijakan cloud mana pun, Izinkan akses komputer lokal dinonaktifkan untuk Work maupun dots. Pengamanan ini tidak mengonfigurasi residensi ruang kerja dan tidak dengan sendirinya menonaktifkan Work Cloud atau dots.

Penggantian pengaturan lingkungan memungkinkan variasi pengaturan yang didukung dalam suatu kebijakan. Dalam suatu kebijakan, urutan dari tertinggi ke terendah adalah penggantian pengaturan lingkungan khusus OS → penggantian pengaturan lingkungan untuk semua OS → Global. Kebijakan berprioritas lebih tinggi tetap mengungguli kebijakan berprioritas lebih rendah, meskipun kebijakan berprioritas lebih rendah lebih spesifik. Beberapa persyaratan memiliki aturan penggabungan khusus per bidang. Pastikan editor penggantian pengaturan dan bidang yang tersedia untuk ruang kerja Anda.

Saat kebijakan terkelola dan hook jarak jauh diaktifkan, Work Cloud dengan akses lokal dan dots menggunakan hook MCP jarak jauh yang dikelola admin pada orkestrator cloud. Konfigurasikan penangan mcp_tool dalam requirements.toml Global. Work Cloud tanpa akses lokal dan akun pribadi tidak menggunakan hook perusahaan ini. Penangan perintah/shell, prompt, dan agen; hook dari konfigurasi lokal, plugin, atau direktori lokal; hook dengan cakupan lingkungan; serta hook MCP SessionEnd tidak didukung dengan orkestrasi cloud, meskipun alat dijalankan secara lokal. Saat orkestrasi dan eksekusi sama-sama berlangsung secara lokal, hook yang sudah didukung tetap berfungsi dalam utas Work dan Codex yang sepenuhnya lokal. Admin tetap dapat mengonfigurasi hook terkelola yang didukung di Agent Security untuk alur kerja tersebut. Sebelum mengandalkan hook ini, uji konektivitas callback, peristiwa yang diperlukan, dan perilaku saat terjadi kegagalan. Penolakan eksplisit yang didukung dapat memblokir tindakan, tetapi kesalahan callback PreToolUse, batas waktu yang terlampaui, atau respons dengan format yang salah dapat menyebabkan hook gagal tanpa memblokir alat. Hook MCP tidak menyediakan jejak audit Compliance API yang lengkap. Lihat Referensi Konfigurasi.

Lokasi dan urutan prioritas

Untuk eksekusi lokal, persyaratan diterapkan dari prioritas lebih rendah ke lebih tinggi sebagai berikut. Urutan ini juga berlaku untuk langkah lokal dalam akses komputer lokal dengan Work Cloud:

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 Agent Security yang didistribusikan dalam bundel konfigurasi cloud.
3. Bidang managed_config.toml lama yang ditafsirkan ulang oleh klien lokal sebagai persyaratan.
4. Preferensi terkelola macOS (MDM) yang didistribusikan melalui com.openai.codex:requirements_toml_base64.

Lapisan berprioritas lebih tinggi menggantikan nilai skalar dan daftar biasa dari lapisan berprioritas lebih rendah. Tabel digabungkan berdasarkan kunci, sedangkan persyaratan seperti aturan, hook, dan pembatasan sistem berkas memiliki perilaku penggabungan khusus per bidang. Gunakan referensi requirements.toml untuk skema terkini, alih-alih menganggap setiap bidang digabungkan dengan cara yang sama.

Untuk kompatibilitas dengan versi sebelumnya, klien lokal yang didukung menafsirkan ulang bidang lama approval_policy, approvals_reviewer, dan sandbox_mode sebagai persyaratan. Konversi ini menambahkan pilihan kompatibilitas jika diperlukan; gunakan requirements.toml untuk daftar izin eksplisit.

Urutan prioritas untuk akses komputer lokal dengan Work Cloud

Untuk Work dengan akses lokal dan dots, bedakan kebijakan orkestrator Global dari kebijakan eksekusi. Persyaratan lokal yang berlaku mengatur komputer yang terhubung. Kontainer cloud Work dan komputer cloud dots menggunakan konfigurasi serta persyaratan eksekusinya sendiri, alih-alih bundel lingkungan terkelola yang digunakan oleh eksekutor lain.

Untuk eksekusi lokal, MDM dan persyaratan perangkat terkelola lama memiliki prioritas lebih tinggi daripada Agent Security. File persyaratan sistem perangkat memiliki prioritas lebih rendah daripada Agent Security. Dalam setiap kebijakan, selesaikan penggantian lingkungan khusus OS sebelum penggantian lingkungan untuk semua OS, lalu Global. Di antara kebijakan, prioritas kebijakan mengungguli tingkat kekhususan.

Persyaratan menetapkan batasan, sedangkan nilai default konfigurasi menyediakan nilai awal. Untuk Work dengan akses lokal dan dots, kebijakan Global yang didukung berlaku melalui orkestrator cloud bersama saat kebijakan terkelola diaktifkan. Persyaratan requirements.toml lokal yang berlaku mengatur eksekusi pada komputer yang terhubung. Kontainer cloud Work dan komputer cloud dots menggunakan konfigurasi eksekusi dan persyaratannya sendiri, bukan paket lingkungan terkelola yang digunakan oleh jenis eksekutor lain. Pembatasan eksekusi lokal tidak otomatis berlaku untuk komputer cloud ini. Tinjau izin kapabilitas cloud dan uji eksekusi lokal serta cloud secara terpisah.

Tempatkan kontrol orkestrator, termasuk persetujuan dan pencarian web, di Global. Gunakan kontrol khusus Kebijakan persetujuan yang diizinkan dan Mode pencarian web yang diizinkan jika tersedia, serta TOML untuk kolom lain yang didukung. Lihat Referensi Konfigurasi untuk daftar kolom dan cakupan eksekusi.

Persyaratan yang dikelola melalui cloud

Saat pengguna masuk dengan ChatGPT pada paket yang didukung, klien lokal yang didukung dapat menerima persyaratan yang diberlakukan admin dan terkait dengan ruang kerja. Ini merupakan saluran distribusi untuk kebijakan yang kompatibel dengan requirements.toml. Saluran ini tidak memberikan akses ruang kerja atau menggantikan RBAC ruang kerja. Persyaratan autentikasi harus dikelola secara lokal.

Konfigurasikan persyaratan umum dengan kontrol keamanan agen. Untuk kebijakan yang hanya mengizinkan persetujuan on-request dan sandbox read-only atau workspace-write, gunakan Kebijakan persetujuan dan Mode sandbox di bagian Batasan kebijakan. Agar permintaan persetujuan juga muncul sebelum titik masuk shell yang didukung dijalankan, gunakan Edit sebagai TOML untuk menambahkan tabel [rules] ke requirements.toml Global.

Padanan TOML lengkapnya adalah:

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. Tetapkan kebijakan kepada pengguna atau grup yang dituju dan verifikasi bahwa kebijakan tersebut berlaku pada klien mereka yang didukung. Gunakan referensi konfigurasi untuk skema terkini dan antarmuka administrasi untuk perilaku penetapan terkini.

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

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

Cara klien lokal menerapkan persyaratan yang dikelola melalui cloud

Perilaku pemuatan dan cache lokal di bawah ini menjelaskan klien lokal yang didukung. Penjelasan ini tidak menetapkan kapan perubahan kebijakan cloud mulai berlaku pada tugas yang sudah berjalan menggunakan akses komputer lokal dengan Work Cloud. Verifikasi kebijakan yang berlaku sebelum mengandalkan pembatasan yang diubah.

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 ada entri yang valid, klien mengambil paket yang berlaku dengan percobaan ulang dan menulis entri cache bertanda tangan setelah berhasil. Jika permintaan gagal atau waktu habis dan tidak ada cache yang valid, pemuatan paket konfigurasi cloud mengembalikan kesalahan alih-alih memulai secara diam-diam tanpa lapisan persyaratan yang dikelola melalui cloud.

Setelah menentukan cache yang akan digunakan, klien menggabungkan persyaratan cloud dengan lapisan persyaratan lain yang dijelaskan di atas. Penyegaran di latar belakang memperbarui paket dalam cache dan menyediakannya untuk pemuatan konfigurasi berikutnya. Hal ini tidak menjamin bahwa tugas yang sudah berjalan langsung menggunakan kebijakan yang diubah. Beberapa pengaturan desktop mengharuskan aplikasi dimulai ulang; ikuti setiap permintaan mulai ulang dan verifikasi pengaturan yang berlaku sebelum mengandalkan perubahan tersebut.

Verifikasi pengalaman admin dan karyawan

Tunjuk seseorang untuk bertanggung jawab atas setiap kebijakan terkelola, catat pengguna atau grup yang harus menerimanya, dan dokumentasikan alasan bisnis untuk setiap pembatasan sistem file, jaringan, persetujuan, atau profil izin.

Uji alur kerja yang diizinkan dan alur kerja yang diblokir dengan pengguna yang memiliki izin yang dituju. Periksa pengaturan yang berlaku pada klien yang didukung. Peran atau grup ruang kerja saja tidak memberlakukan pembatasan runtime lokal.

Gunakan Uji kebijakan di Agent security untuk memeriksa kebijakan yang cocok dengan pilihan anggota, grup, atau peran. Dalam sesi yang dapat diedit, fitur ini memeriksa draf saat ini tanpa menyimpannya. Hasilnya menunjukkan pemilihan kebijakan, bukan konfigurasi akhir yang telah digabungkan atau apakah klien memberlakukan pembatasan. Setelah menyimpan, uji alur kerja yang diizinkan dan diblokir pada setiap klien dan jalur eksekusi yang relevan.

Terapkan konfigurasi yang dikelola perangkat

Gunakan persyaratan sistem lokal atau MDM untuk pembatasan autentikasi dan kebijakan yang dikelola perangkat. Mekanisme lama managed_config.toml memiliki urutan prioritas saat startup yang berbeda dari Default di Agent security. Alur kerja MDM mencakup persyaratan dan nilai default lama.

Kelola autentikasi secara lokal

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

Untuk mewajibkan masuk dengan 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 dihilangkan, 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 ruang kerja yang diizinkan dan dikelola. Jika tidak ada ruang kerja yang cocok, masuk dengan 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.

Nilai default terkelola (managed_config.toml)

Gunakan Default di Agent security untuk nilai awal yang didukung dan dikelola melalui cloud. Bagian ini membahas mekanisme lama yang dikelola perangkat, yaitu managed_config.toml, serta urutan prioritasnya yang berbeda saat startup. Mengedit Default di Agent security tidak menerapkan file managed_config.toml ke perangkat anggota.

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.

GPT-5.5 dihentikan dari Codex dengan login ChatGPT pada 14 Oktober 2026 pukul 12.00 PDT (19.00 UTC). Jika default terkelola, profil MDM macOS, atau konfigurasi tersimpan menyematkan gpt-5.5 bagi pengguna tersebut, gantilah dengan model yang tersedia. Pilih gpt-6.1-sol setelah administrator mengaktifkannya bagi pengguna yang terdampak. OpenAI API dan sesi Codex yang diautentikasi dengan API key tidak terpengaruh. Lihat ketersediaan model ruang kerja.

Untuk konfigurasi yang masih menetapkan gpt-5.4 atau gpt-5.4-mini, ikuti panduan migrasi GPT-5.4.

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

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.

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 untuk sebagian besar pengguna; khususkan akses penuh untuk container yang terkontrol.
• Pertahankan network_access = false kecuali tinjauan keamanan Anda mengizinkan kolektor atau domain yang diperlukan oleh alur kerja Anda.
• Gunakan konfigurasi terkelola untuk menetapkan pengaturan OTel (eksportir, lingkungan), tetapi pertahankan log_user_prompt = false kecuali kebijakan Anda secara eksplisit mengizinkan penyimpanan isi prompt.
• Audit perbedaan antara config.toml lokal dan kebijakan terkelola secara berkala untuk mendeteksi penyimpangan; lapisan terkelola harus diutamakan daripada flag dan file lokal.

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), prioritas mengikuti urutan persyaratan. Tabel [features] yang sama di sisi persyaratan berfungsi dalam requirements_toml_base64; gunakan juga kunci fitur kanonis di sana.

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.