Persetujuan agen & keamanan

Codex membantu melindungi kode dan data Anda serta mengurangi risiko penyalahgunaan.

Secara default, agen berjalan dengan akses jaringan dinonaktifkan. Secara lokal, Codex menggunakan sandbox yang diterapkan oleh OS untuk membatasi hal yang dapat disentuhnya (biasanya hanya ruang kerja saat ini), beserta kebijakan persetujuan yang mengatur kapan Codex harus berhenti dan meminta persetujuan Anda sebelum bertindak.

Untuk penjelasan umum tentang cara kerja sandbox di aplikasi desktop ChatGPT, Codex CLI, dan ekstensi IDE, lihat sandbox. Untuk ikhtisar keamanan perusahaan yang lebih luas, lihat laporan resmi keamanan Codex.

Migrasi dari kebijakan persetujuan untrusted yang telah dihentikan

Codex dan ChatGPT Work tidak lagi mendukung approval_policy = "untrusted". Pengaturan yang telah dihentikan ini dapat membuat kedua klien gagal dijalankan. Hapus pengaturan tersebut dari konfigurasi pengguna atau proyek, file profil, skrip startup, dan pengaturan default yang dikelola. Untuk penggunaan interaktif dengan akses hanya baca:

sandbox_mode = "read-only"
approval_policy = "on-request"

Atau jalankan codex --sandbox read-only --ask-for-approval on-request.

Dengan on-request, perintah yang diizinkan oleh sandbox dapat dijalankan tanpa persetujuan, membaca file yang dapat diakses, dan menggunakan akses jaringan jika diaktifkan.

Untuk mempertahankan aturan persetujuan perintah yang lebih ketat, jangan tetapkan approval_policy secara eksplisit dan tambahkan entri proyek ke file tingkat pengguna ~/.codex/config.toml Anda:

[projects."/path/to/project"]
trust_level = "untrusted"

Perintah kemudian memerlukan persetujuan kecuali aturan kebijakan eksekusi mengizinkannya. Ini juga menonaktifkan konfigurasi lokal proyek. Menetapkan on-request secara eksplisit mengesampingkan kebijakan yang diturunkan dari proyek; allowed_approval_policies yang dikelola harus mencakup untrusted untuk mengizinkannya.

Sandbox dan persetujuan

Kontrol keamanan Codex berasal dari dua lapisan yang bekerja bersama:

• Mode sandbox: Hal yang secara teknis dapat dilakukan Codex (misalnya, lokasi yang dapat ditulisi dan apakah jaringan dapat diakses) saat menjalankan perintah yang dihasilkan model.
• Kebijakan persetujuan: Kapan Codex harus meminta persetujuan Anda sebelum menjalankan tindakan (misalnya, keluar dari sandbox, menggunakan jaringan, atau menjalankan perintah di luar kumpulan tepercaya).

Codex menggunakan mode sandbox yang berbeda, tergantung tempat Anda menjalankannya:

• Codex cloud: Berjalan dalam kontainer terisolasi yang dikelola OpenAI sehingga tidak dapat mengakses sistem host atau data lain yang tidak terkait. Menggunakan model runtime dua fase: penyiapan berjalan sebelum fase agen dan dapat mengakses jaringan untuk menginstal dependensi yang ditentukan, lalu fase agen berjalan secara offline secara default kecuali Anda mengaktifkan akses internet untuk lingkungan tersebut. Rahasia yang dikonfigurasi bagi lingkungan cloud hanya tersedia selama penyiapan dan dihapus sebelum fase agen dimulai.
• Codex CLI / ekstensi IDE: Mekanisme tingkat OS menerapkan kebijakan sandbox. Pengaturan default mencakup tanpa akses jaringan dan izin tulis yang dibatasi pada ruang kerja aktif. Anda dapat mengonfigurasi sandbox, kebijakan persetujuan, dan pengaturan jaringan berdasarkan toleransi risiko Anda.

Dalam preset Auto (misalnya, --sandbox workspace-write --ask-for-approval on-request), Codex dapat membaca file, melakukan pengeditan, dan menjalankan perintah di direktori kerja secara otomatis.

Codex meminta persetujuan untuk mengedit file di luar ruang kerja atau menjalankan perintah yang memerlukan akses jaringan. Jika Anda ingin mengobrol atau menyusun rencana tanpa melakukan perubahan, beralihlah ke mode read-only dengan perintah /permissions.

Codex juga dapat meminta persetujuan untuk panggilan alat aplikasi (konektor) yang menyatakan memiliki efek samping, meskipun tindakannya bukan perintah shell atau perubahan file. Panggilan alat aplikasi/MCP yang destruktif selalu memerlukan persetujuan jika alat tersebut menyatakan anotasi destruktif (kecuali jika alat itu menyatakan anotasi baca, yang memiliki prioritas lebih tinggi).

Pemantauan keamanan dan tugas yang dijeda

GPT-6 Astra menyertakan pemantauan keamanan di Codex dan ChatGPT Work. Pemantauan berjalan secara asinkron dan dapat menjeda tugas jika mendeteksi perilaku model yang berpotensi tidak aman. Penjedaan dapat terjadi setelah aktivitas yang memicunya; pemantauan tidak menggantikan sandboxing, izin, atau peninjauan hasil.

Jika tugas dijeda, baca pemberitahuan dan tinjau temuan jika tersedia. Lanjutkan hanya setelah memastikan bahwa tugas dapat diteruskan dengan aman. Jika pemberitahuan menyatakan bahwa tugas telah berakhir atau tidak menawarkan opsi untuk melanjutkan, Anda tidak dapat melanjutkannya dari antarmuka tersebut.

Pemantauan keamanan mengevaluasi perilaku model selama tugas berlangsung. Peninjauan persetujuan otomatis mengevaluasi setiap tindakan yang sudah memerlukan persetujuan sebelum tindakan tersebut dijalankan. Tindakan yang disetujui melalui peninjauan persetujuan otomatis tetap dapat menjadi bagian dari tugas yang kemudian dijeda oleh pemantauan.

Akses jaringan

Untuk Codex cloud, lihat akses internet agen guna mengaktifkan akses internet penuh atau daftar izin domain.

Untuk aplikasi desktop ChatGPT, Codex CLI, atau ekstensi IDE, mode sandbox default workspace-write mempertahankan akses jaringan dalam keadaan nonaktif kecuali Anda mengaktifkannya dalam konfigurasi:

[sandbox_workspace_write]
network_access = true

Isolasi jaringan

Akses jaringan dikontrol melalui aturan tujuan yang berlaku untuk skrip, program, dan subproses yang dijalankan oleh perintah. Jika akses jaringan perintah sudah diaktifkan, aktifkan fitur network_proxy untuk membatasi lalu lintas tersebut sesuai kebijakan jaringan yang Anda konfigurasikan. Menambahkan aturan domain tidak mengaktifkan proksi dengan sendirinya.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Untuk sesi CLI satu kali, gunakan bentuk singkat boolean jika Anda hanya memerlukan sakelar, dan gunakan bentuk tabel jika Anda juga menetapkan opsi kebijakan:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Fitur ini mengubah cara penerapan akses jaringan yang telah diaktifkan; fitur ini tidak memberikan akses jaringan dengan sendirinya. Gunakan sandbox_workspace_write.network_access dengan konfigurasi workspace-write untuk menentukan apakah perintah memiliki akses jaringan:

• Jaringan nonaktif + network_proxy aktif: jaringan tetap nonaktif dan fitur tidak melakukan apa pun.
• Jaringan aktif + network_proxy nonaktif: jaringan tetap aktif dengan akses keluar langsung tanpa batasan.
• Jaringan aktif + network_proxy aktif: jaringan tetap aktif dan lalu lintas keluar dibatasi oleh kebijakan jaringan yang dikonfigurasi.

Fitur proksi juga berlaku untuk profil izin. network.enabled = true milik profil memberikan akses jaringan perintah, sedangkan features.network_proxy = true mengaktifkan pemberlakuan aturan domain profil tersebut:

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Jika Anda menghilangkan fitur proksi dalam contoh ini, perintah memiliki akses jaringan langsung dan aturan izin api.openai.com tidak membatasi tujuannya.

Persyaratan experimental_network yang dikelola admin terpisah dari sakelar fitur pengguna. Persyaratan tersebut dapat mengonfigurasi dan memulai jaringan dalam sandbox tanpa features.network_proxy, tetapi tidak mengaktifkan akses jaringan jika sandbox aktif mempertahankannya dalam keadaan nonaktif. Lihat Konfigurasi terkelola untuk struktur requirements.toml di sisi administrator.

Kebijakan jaringan

Aturan domain mengutamakan daftar izin:

• Host persis hanya cocok dengan dirinya sendiri.
• *.example.com cocok dengan subdomain seperti api.example.com, tetapi tidak dengan example.com.
• **.example.com cocok dengan domain apex dan subdomain.
• Aturan izin global * cocok dengan semua host publik yang tidak ditolak. Anggap * sebagai akses jaringan luas dan utamakan aturan terbatas jika memungkinkan.
• deny selalu mengalahkan allow, dan * global hanya valid untuk aturan izin.

Tujuan lokal dan privat

Secara default, allow_local_binding = false memblokir tujuan loopback, link-local, dan privat:

• Pengecualian tertentu: tambahkan literal IP lokal persis atau aturan izin localhost jika perintah memerlukan satu target lokal.
• Akses lebih luas: tetapkan allow_local_binding = true hanya jika Anda memang menginginkan jangkauan lokal/privat yang lebih luas.
• Wildcard: aturan wildcard tidak dianggap sebagai pengecualian lokal eksplisit.
• Alamat hasil resolusi: nama host yang diresolusikan ke IP lokal/privat tetap diblokir meskipun cocok dengan daftar izin.

Perlindungan terhadap DNS rebinding

Sebelum mengizinkan nama host, Codex melakukan pemeriksaan klasifikasi DNS dan IP secara best effort:

• Pencarian yang gagal atau kehabisan waktu akan diblokir.
• Nama host yang diresolusikan ke alamat nonpublik akan diblokir.
• Pemeriksaan ini mengurangi risiko DNS rebinding, tetapi tidak menghilangkannya. Pencegahan rebinding sepenuhnya memerlukan pengikatan IP hasil resolusi melalui lapisan transportasi.

Jika DNS berbahaya termasuk dalam cakupan ancaman, terapkan juga kontrol egress pada lapisan yang lebih rendah.

Pengaturan berbahaya

Dua pengaturan sengaja memperluas batas kepercayaan:

• dangerously_allow_non_loopback_proxy = true dapat mengekspos listener proksi di luar loopback.
• dangerously_allow_all_unix_sockets = true melewati daftar izin soket Unix.

Gunakan hanya dalam lingkungan yang dikontrol ketat. Saat proksi soket Unix diaktifkan, listener tetap terbatas pada loopback meskipun binding non-loopback diminta, sehingga jaringan dalam sandbox tidak menjadi jembatan jarak jauh ke daemon lokal.

network_proxy nonaktif secara default. Saat Anda mengaktifkannya:

Lalu lintas di luar proksi jaringan perintah

Proksi jaringan memfilter skrip, program, dan proses anak yang berjalan di dalam sandbox perintah lokal. Proksi ini tidak memfilter pencarian web, panggilan alat aplikasi atau konektor, koneksi server MCP, aktivitas browser atau Computer Use, tugas Codex cloud, maupun permintaan model dan autentikasi klien. Antarmuka ini menggunakan koneksi layanan, pengaturan fitur, kebijakan ruang kerja, atau kontrol lingkungan yang terpisah.

Alat browser secara terpisah memeriksa penolakan jaringan terkelola dan daftar izin eksklusif sebelum mengakses suatu origin. Kebijakan origin browser dapat semakin membatasi akses situs, unggahan, unduhan, dan alat pengembang. Lihat kontrol browser terkelola.

Untuk pengguna terkelola, gabungkan kebijakan jaringan perintah dengan kontrol seperti allowed_web_search_modes, mcp_servers yang disetujui, dan persyaratan fitur untuk aplikasi, plugin, browser, atau Computer Use. Lihat Konfigurasi terkelola.

Anda juga dapat mengontrol alat pencarian web tanpa memberikan akses jaringan penuh kepada perintah yang dibuat. Secara default, Codex menggunakan cache pencarian web untuk mengakses hasil. Cache tersebut merupakan indeks hasil web yang dikelola OpenAI, sehingga mode cache mengembalikan hasil yang telah diindeks, bukan mengambil halaman secara langsung. Hal ini mengurangi paparan terhadap prompt injection dari konten langsung yang arbitrer, tetapi Anda tetap harus menganggap hasil web tidak tepercaya. Jika Anda menggunakan --yolo atau pengaturan sandbox akses penuh lainnya, pencarian web menggunakan hasil langsung secara default. Gunakan --search atau tetapkan web_search = "live" untuk mengizinkan penjelajahan langsung, atau tetapkan ke "disabled" untuk menonaktifkan alat:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Tetapkan web_search = "indexed" jika akses web eksternal harus dibatasi oleh indeks pencarian. Berhati-hatilah saat mengaktifkan akses jaringan atau pencarian web di Codex. Prompt injection dapat menyebabkan agen mengambil dan mengikuti instruksi yang tidak tepercaya.

Default dan rekomendasi

• Saat diluncurkan, Codex mendeteksi apakah folder menggunakan kontrol versi dan merekomendasikan:
  • Folder dengan kontrol versi: Auto (tulis ruang kerja + persetujuan sesuai permintaan)
  • Folder tanpa kontrol versi: read-only
• Bergantung pada penyiapan Anda, Codex juga dapat dimulai dalam read-only sampai Anda secara eksplisit memercayai direktori kerja (misalnya, melalui prompt orientasi awal atau /permissions).
• Ruang kerja mencakup direktori saat ini dan direktori sementara seperti /tmp. Gunakan perintah /status untuk melihat direktori yang termasuk dalam ruang kerja.
• Untuk menerima pengaturan default, jalankan codex.
• Anda dapat menetapkannya secara eksplisit:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Jalur yang dilindungi dalam root yang dapat ditulisi

Dalam kebijakan sandbox default workspace-write, root yang dapat ditulisi tetap mencakup jalur yang dilindungi:

• <writable_root>/.git dilindungi sebagai baca-saja, baik muncul sebagai direktori maupun file.
• Jika <writable_root>/.git merupakan file penunjuk (gitdir: ...), jalur direktori Git hasil resolusi juga dilindungi sebagai baca-saja.
• <writable_root>/.agents dilindungi sebagai baca-saja jika tersedia sebagai direktori.
• <writable_root>/.codex dilindungi sebagai baca-saja jika tersedia sebagai direktori.
• Perlindungan bersifat rekursif sehingga semua yang berada di bawah jalur tersebut bersifat baca-saja.

Menjalankan tanpa prompt persetujuan

Anda dapat menonaktifkan prompt persetujuan dengan --ask-for-approval never atau -a never (bentuk singkat).

Opsi ini berfungsi dengan semua mode --sandbox sehingga Anda tetap mengontrol tingkat otonomi Codex. Codex berupaya sebaik mungkin dalam batasan yang Anda tetapkan.

Jika Anda memerlukan Codex untuk membaca file, melakukan pengeditan, dan menjalankan perintah dengan akses jaringan tanpa prompt persetujuan, gunakan --sandbox danger-full-access (atau flag --dangerously-bypass-approvals-and-sandbox). Berhati-hatilah sebelum melakukannya.

Sebagai jalan tengah, approval_policy = { granular = { ... } } memungkinkan kategori prompt persetujuan tertentu tetap interaktif sambil otomatis menolak yang lain. Kebijakan terperinci mencakup persetujuan sandbox, prompt aturan execpolicy, prompt MCP, prompt request_permissions, dan persetujuan skrip skill.

Peninjauan persetujuan otomatis

Secara default, permintaan persetujuan diarahkan kepada Anda:

approvals_reviewer = "user"

Peninjauan persetujuan otomatis berlaku saat persetujuan bersifat interaktif, seperti approval_policy = "on-request" atau kebijakan persetujuan terperinci. Tetapkan approvals_reviewer = "auto_review" untuk mengarahkan permintaan persetujuan yang memenuhi syarat melalui agen peninjau sebelum Codex menjalankan permintaan:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Untuk seluruh siklus hidup peninjau, kondisi pemicu, prioritas konfigurasi, dan perilaku kegagalan, lihat Peninjauan otomatis.

Peninjau hanya mengevaluasi tindakan yang memang memerlukan persetujuan, seperti eskalasi sandbox, permintaan jaringan yang diblokir, prompt request_permissions, atau panggilan alat aplikasi dan MCP yang memiliki efek samping. Tindakan yang tetap berada di dalam sandbox berlanjut tanpa langkah peninjauan tambahan.

Kebijakan peninjau memeriksa eksfiltrasi data, pemeriksaan kredensial, pelemahan keamanan permanen, dan tindakan destruktif. Tindakan berisiko rendah dan menengah dapat dilanjutkan jika diizinkan kebijakan. Kebijakan menolak tindakan berisiko kritis. Tindakan berisiko tinggi memerlukan otorisasi pengguna yang memadai dan tidak boleh cocok dengan aturan penolakan. Kegagalan pembuatan prompt, sesi peninjauan, dan penguraian akan ditutup secara aman. Waktu habis ditampilkan secara terpisah, tetapi tindakan tetap tidak dijalankan.

Kebijakan peninjau default tersedia di repositori Codex sumber terbuka. Perusahaan dapat mengganti bagian khusus tenant dengan guardian_policy_config dalam persyaratan terkelola. Teks lokal [auto_review].policy juga didukung, tetapi persyaratan terkelola diprioritaskan. Untuk detail penyiapan, lihat Konfigurasi terkelola.

Dalam aplikasi desktop ChatGPT, peninjauan ini muncul sebagai item peninjauan otomatis dengan status seperti Reviewing, Approved, Denied, Aborted, atau Timed out. Item tersebut juga dapat menyertakan tingkat risiko dan penilaian otorisasi pengguna untuk permintaan yang ditinjau.

Peninjauan otomatis menggunakan panggilan model tambahan sehingga dapat menambah penggunaan Codex. Admin dapat membatasinya dengan allowed_approvals_reviewers.

Kombinasi sandbox dan persetujuan yang umum

Untuk proses noninteraktif, gunakan codex exec --sandbox workspace-write; Codex mempertahankan pemanggilan lama codex exec --full-auto sebagai jalur kompatibilitas yang tidak digunakan lagi dan menampilkan peringatan.

Konfigurasi dalam config.toml

Untuk alur kerja konfigurasi yang lebih luas, lihat Dasar-dasar konfigurasi, Konfigurasi lanjutan, dan Referensi Konfigurasi.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Anda juga dapat menyimpan preset sebagai file profil, lalu memilihnya dengan codex --profile profile-name:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Menguji sandbox secara lokal

Untuk melihat apa yang terjadi saat perintah berjalan di bawah sandbox Codex, gunakan perintah Codex CLI berikut:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

Perintah sandbox juga tersedia sebagai codex debug, dan helper platform memiliki alias (misalnya codex sandbox seatbelt dan codex sandbox landlock).

Sandbox tingkat OS

Codex menerapkan sandbox secara berbeda bergantung pada OS Anda:

• macOS menggunakan kebijakan Seatbelt dan menjalankan perintah menggunakan sandbox-exec dengan profil (-p) yang sesuai dengan mode --sandbox pilihan Anda. Saat akses baca terbatas mengaktifkan default platform, Codex menambahkan kebijakan platform macOS terkurasi (alih-alih mengizinkan /System secara luas) untuk mempertahankan kompatibilitas alat umum.
• Linux menggunakan bwrap beserta seccomp secara default.
• Windows menggunakan implementasi sandbox Linux saat berjalan di Windows Subsystem for Linux 2 (WSL2). WSL1 didukung hingga Codex 0.114; mulai 0.115, sandbox Linux beralih ke bwrap sehingga WSL1 tidak lagi didukung. Saat berjalan secara native di Windows, Codex menggunakan implementasi sandbox Windows.

Jika Anda menggunakan ekstensi Codex IDE di Windows, ekstensi tersebut mendukung WSL2 secara langsung. Tetapkan hal berikut dalam pengaturan VS Code agar agen tetap berada di dalam WSL2 setiap kali tersedia:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Hal ini memastikan ekstensi IDE mewarisi semantik sandbox Linux untuk perintah, persetujuan, dan akses sistem file meskipun OS host adalah Windows. Pelajari lebih lanjut dalam panduan WSL.

Saat berjalan secara native di Windows, konfigurasikan mode sandbox native dalam config.toml:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Lihat panduan penyiapan Windows untuk detailnya.

Saat Anda menjalankan Linux dalam lingkungan berkontainer seperti Docker, sandbox mungkin tidak berfungsi jika konfigurasi host atau kontainer memblokir namespace, bwrap setuid, atau operasi seccomp yang diperlukan Codex.

Dalam hal tersebut, konfigurasikan kontainer Docker agar menyediakan isolasi yang Anda perlukan, lalu jalankan codex dengan --sandbox danger-full-access (atau flag --dangerously-bypass-approvals-and-sandbox) di dalam kontainer.

Menjalankan Codex dalam Dev Containers

Jika host Anda tidak dapat menjalankan sandbox Linux secara langsung, atau organisasi Anda telah menstandardisasi pengembangan dalam kontainer, jalankan Codex dengan Dev Containers dan biarkan Docker menyediakan batas isolasi luar. Cara ini berfungsi dengan Visual Studio Code Dev Containers dan alat yang kompatibel.

Gunakan contoh devcontainer aman Codex sebagai implementasi referensi. Contoh tersebut menginstal Codex, alat pengembangan umum, bubblewrap, dan kontrol keluar berbasis firewall.

Implementasi referensi mencakup:

• image dasar Ubuntu 24.04 dengan Codex dan alat pengembangan umum yang telah diinstal;
• profil firewall berbasis daftar izin untuk akses keluar;
• pengaturan dan rekomendasi ekstensi VS Code untuk membuka kembali ruang kerja dalam kontainer;
• mount persisten untuk riwayat perintah dan konfigurasi Codex;
• bubblewrap, sehingga Codex tetap dapat menggunakan sandbox Linux ketika kontainer memberikan kapabilitas yang diperlukan.

Untuk mencobanya:

1. Instal Visual Studio Code dan ekstensi Dev Containers.
2. Salin penyiapan contoh Codex .devcontainer ke dalam repositori Anda, atau mulai langsung dari repositori Codex.
3. Di VS Code, jalankan Dev Containers: Open Folder in Container... dan pilih .devcontainer/devcontainer.secure.json.
4. Setelah kontainer dimulai, buka terminal dan jalankan codex.

Anda juga dapat memulai kontainer dari CLI:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

Contoh tersebut memiliki tiga bagian utama:

• .devcontainer/devcontainer.secure.json mengontrol pengaturan, kapabilitas, mount, variabel lingkungan, dan ekstensi VS Code pada kontainer.
• .devcontainer/Dockerfile.secure mendefinisikan image berbasis Ubuntu dan alat yang diinstal.
• .devcontainer/init-firewall.sh menerapkan kebijakan jaringan keluar.

Firewall referensi sengaja dirancang sebagai titik awal. Jika Anda mengandalkan daftar izin domain untuk isolasi, terapkan perlindungan DNS rebinding dan penyegaran DNS yang sesuai dengan lingkungan Anda, seperti penyegaran yang memperhitungkan TTL atau firewall yang memahami DNS.

Di dalam kontainer, pilih salah satu mode berikut:

• Pertahankan sandbox Linux Codex dalam keadaan aktif jika profil Dev Container memberikan kapabilitas yang diperlukan bwrap untuk membuat sandbox internal.
• Jika kontainer adalah batas keamanan yang Anda inginkan, jalankan Codex dengan --sandbox danger-full-access di dalam kontainer agar Codex tidak mencoba membuat lapisan sandbox kedua.

Kontrol versi

Codex bekerja paling baik dengan alur kerja kontrol versi:

• Bekerjalah pada cabang fitur dan pastikan git status bersih sebelum mendelegasikan. Hal ini membuat patch Codex lebih mudah diisolasi dan dibatalkan.
• Utamakan alur kerja berbasis patch (misalnya, git diff/git apply) daripada mengedit file terlacak secara langsung. Lakukan commit secara berkala agar Anda dapat melakukan rollback dalam inkremen kecil.
• Perlakukan saran Codex seperti PR lainnya: jalankan verifikasi yang ditargetkan, tinjau diff, dan dokumentasikan keputusan dalam pesan commit untuk keperluan audit.

Pemantauan dan telemetri

Codex mendukung pemantauan opsional melalui OpenTelemetry (OTel) untuk membantu tim mengaudit penggunaan, menyelidiki masalah, dan memenuhi persyaratan kepatuhan tanpa melemahkan default keamanan lokal. Telemetri nonaktif secara default; aktifkan secara eksplisit dalam konfigurasi Anda.

Ikhtisar

• Codex menonaktifkan ekspor OTel secara default agar proses lokal tetap mandiri.
• Saat diaktifkan, Codex menghasilkan peristiwa log terstruktur yang mencakup percakapan, permintaan API, aktivitas stream SSE/WebSocket, prompt pengguna (disamarkan secara default), keputusan persetujuan alat, dan hasil alat.
• Codex memberi tag pada peristiwa yang diekspor dengan service.name (asal), versi CLI, dan label lingkungan untuk memisahkan lalu lintas dev/staging/prod.

Mengaktifkan OTel (opsional)

Tambahkan blok [otel] ke konfigurasi Codex Anda (biasanya ~/.codex/config.toml), dengan memilih eksportir dan menentukan apakah teks prompt akan dicatat.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" mempertahankan instrumentasi aktif, tetapi tidak mengirim data ke mana pun.
• Untuk mengirim peristiwa ke kolektor Anda sendiri, pilih salah satu:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex mengelompokkan peristiwa dan melakukan flush saat dimatikan. Codex hanya mengekspor telemetri yang dihasilkan oleh modul OTel miliknya.

Kategori peristiwa

Jenis peristiwa yang mewakili mencakup:

• codex.conversation_starts (model, pengaturan penalaran, kebijakan sandbox/persetujuan)
• codex.api_request (percobaan, status/keberhasilan, durasi, dan detail kesalahan)
• codex.sse_event (jenis peristiwa stream, keberhasilan/kegagalan, durasi, serta jumlah token pada response.completed)
• codex.websocket_request dan codex.websocket_event (durasi permintaan serta jenis/keberhasilan/kesalahan per pesan)
• codex.user_prompt (panjang; konten disamarkan kecuali diaktifkan secara eksplisit)
• codex.tool_decision (disetujui/ditolak, sumber: konfigurasi atau pengguna)
• codex.tool_result (durasi, keberhasilan, cuplikan keluaran)

Metrik OTel terkait (pasangan penghitung dan histogram durasi) mencakup codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event, dan codex.tool.call (dengan instrumen .duration_ms yang sesuai).

Untuk katalog peristiwa lengkap dan referensi konfigurasi, lihat dokumentasi konfigurasi Codex di GitHub.

Panduan keamanan dan privasi

• Pertahankan log_user_prompt = false kecuali kebijakan secara eksplisit mengizinkan penyimpanan isi prompt. Prompt dapat memuat kode sumber dan data sensitif.
• Arahkan telemetri hanya ke kolektor yang Anda kendalikan; terapkan batas retensi dan kontrol akses yang selaras dengan persyaratan kepatuhan Anda.
• Perlakukan argumen dan keluaran alat sebagai data sensitif. Utamakan penyamaran di kolektor atau SIEM jika memungkinkan.
• Tinjau pengaturan retensi data lokal (misalnya, history.persistence / history.max_bytes) jika Anda tidak ingin Codex menyimpan transkrip sesi dalam CODEX_HOME. Lihat Konfigurasi Lanjutan dan Referensi Konfigurasi.
• Jika Anda menjalankan CLI dengan akses jaringan dinonaktifkan, ekspor OTel tidak dapat menjangkau kolektor Anda. Untuk mengekspor, izinkan akses jaringan dalam mode workspace-write bagi endpoint OTel, atau lakukan ekspor dari Codex cloud dengan domain kolektor dalam daftar yang disetujui.
• Tinjau peristiwa secara berkala untuk menemukan perubahan persetujuan/sandbox dan eksekusi alat yang tidak terduga.

OTel bersifat opsional dan dirancang untuk melengkapi, bukan menggantikan, perlindungan sandbox dan persetujuan yang dijelaskan di atas.

Konfigurasi terkelola

Admin perusahaan dapat mengonfigurasi pengaturan keamanan Codex untuk ruang kerja mereka di Konfigurasi terkelola. Lihat halaman tersebut untuk detail penyiapan dan kebijakan.