Membangun sandbox yang aman dan efektif untuk mengaktifkan Codex di Windows

Saat saya bergabung dengan tim rekayasa Codex pada September 2025, Codex untuk Windows belum memiliki implementasi sandbox, yang berarti pengguna Windows dipaksa memilih di antara dua opsi yang kurang memadai saat menggunakan agen pengodean OpenAI:

1. Menyetujui hampir setiap perintah (bahkan baca) yang ingin dijalankan agen pengodean, yang tidak efisien dan merepotkan. Manfaat utama menggunakan Codex adalah Anda tidak perlu melakukan sendiri semua pekerjaan yang membosankan.
2. Mengaktifkan mode Akses Penuh: membiarkan Codex menjalankan semua perintah tanpa persetujuan atau pembatasan, yang menghilangkan friksi dengan mengorbankan pengawasan.

Codex⁠, agen pengodean kami, berjalan di laptop pengembang—baik melalui CLI, ekstensi IDE, maupun aplikasi desktop. Codex mengelola percakapan antara manusia di depan keyboard dan model yang berjalan di cloud untuk menangani inferensi.

Codex secara default berjalan dengan izin pengguna nyata, yang berarti Codex dapat melakukan semua hal yang bisa dilakukan pengguna. Ini kuat sekaligus berpotensi berbahaya. Model pengodean itu dapat menyuruh harness menjalankan perintah secara lokal, mulai dari menjalankan pengujian hingga membaca atau mengedit file sampai membuat branch Git, sehingga mode default Codex berusaha menemukan keseimbangan yang tepat antara efektivitas dan keamanan. Mode default ini memungkinkan Codex membaca file hampir di mana saja dan menulis file di dalam workspace Anda (yaitu direktori tempat Anda menjalankan Codex), tanpa akses internet kecuali Anda menentukannya. Untuk mewujudkan pembatasan otomatis atas penulisan file dan akses jaringan dalam batas aman ini, Codex memerlukan lingkungan sandbox yang benar-benar menegakkan pembatasan tersebut.

Sandbox adalah lingkungan eksekusi yang dibatasi. Ketika pengembang menggunakan Codex, sistem operasi komputernya meluncurkan sebuah perintah dengan izin yang dikurangi, dan pembatasan itu diteruskan ke seluruh pohon proses. Setiap perintah Codex dijalankan dalam sandbox sejak awal, dan setiap proses turunannya tetap berada di dalam batas yang sama.

Codex memerlukan fitur isolasi yang didukung oleh sistem operasi komputer untuk menerapkan sandbox yang efektif. Beberapa sistem operasi menyediakan utilitas yang melakukan ini dengan baik (misalnya Seatbelt di MacOs, seccomp atau bubblewrap di Linux); namun, Windows saat ini tidak menyediakan kemampuan jenis ini secara bawaan.

Untuk membuat Codex sama aman dan menyenangkannya digunakan di Windows seperti di tempat lain, kami perlu menerapkan sandbox kami sendiri.

Windows menawarkan beberapa alat dan primitif untuk isolasi. Walaupun tidak ada yang benar-benar memenuhi kebutuhan kami, kami meninjau sejumlah solusi potensial—yakni AppContainer, Windows Sandbox, dan pelabelan Mandatory Integrity Control.

AppContainer

• Apa: AppContainer adalah sandbox native Windows, model isolasi berbasis kapabilitas yang dibuat untuk aplikasi yang sejak awal tahu persis apa yang perlu diaksesnya.
• Mengapa: Menarik karena menawarkan batas OS yang nyata, bukan sekadar pembatasan best-effort.
• Mengapa tidak: Codex bukan sebuah aplikasi dengan cakupan yang sempit. Codex menjalankan alur kerja pengembang yang terbuka: shell, Git, Python, manajer paket, alat build, dan biner lain apa pun yang diputuskan agen sebagai kebutuhannya. Dalam praktiknya, hal itu membuat AppContainer tidak cocok untuk masalah tersebut. Itu merupakan isolasi yang kuat, tetapi untuk kelas beban kerja yang jauh lebih sempit daripada “membiarkan agen beroperasi seperti pengembang.”

Windows Sandbox

• Apa: Windows Sandbox adalah VM ringan sekali pakai milik Microsoft. Anda mendapatkan desktop Windows baru dengan batas isolasi yang kuat, dan apa pun yang Anda lakukan di dalamnya akan hilang saat sesi berakhir.
• Mengapa: Menarik karena alasan yang jelas—jauh lebih kompatibel dengan perangkat lunak arbitrer dibandingkan AppContainer, dan dari perspektif keamanan ini merupakan kotak yang jauh lebih kuat.
• Mengapa tidak: Codex perlu bertindak langsung pada checkout, alat, dan lingkungan nyata milik pengguna, bukan di dalam desktop sementara terpisah yang memerlukan penyiapan serta penghubung host/guest. Ini juga memiliki masalah produk yang mendasar: Windows Sandbox bahkan tidak tersedia pada SKU Windows Home.

Pelabelan integritas Mandatory Integrity Control (MIC)

• Apa: Windows memiliki konsep yang disebut “tingkat integritas,” seperti rendah, sedang, dan tinggi, yang menentukan sejauh mana sistem memercayai objek dan proses. Aturan dasarnya adalah bahwa proses dengan integritas lebih rendah tidak dapat menulis ke objek dengan tingkat integritas yang lebih tinggi, meskipun ACL normal sebenarnya mengizinkannya. Misalnya, proses berintegritas rendah diperlakukan sebagai kurang tepercaya, sehingga Windows memblokirnya agar tidak menulis ke objek normal berintegritas sedang, kecuali objek tersebut dilabeli ulang secara eksplisit untuk mengizinkannya.
• Mengapa: MIC terlihat elegan di atas kertas—jalankan Codex pada integritas rendah, label ulang root yang dapat ditulis sebagai integritas rendah, lalu biarkan Windows menegakkan larangan menulis di tempat lain. Itu akan memberi kita jalur non-admin dengan mekanisme OS nyata yang mendasarinya.
• Mengapa tidak: Seperti ACL, label integritas memodifikasi filesystem host yang sebenarnya, dan dalam kasus ini perubahan semantiknya sangat luas. Menandai workspace sebagai integritas rendah tidak hanya berarti “Codex dapat menulis di sini.” Ini sebenarnya berarti proses dengan integritas rendah secara umum dapat menulis di sana. Pada mesin pengembang sungguhan, hal itu mengubah checkout aktual milik pengguna menjadi penampung berintegritas rendah bagi host, yang jauh lebih berisiko daripada memberikan ACL yang ditargetkan dengan cermat ke satu desain sandbox. Meskipun alat pengembang dengan integritas menengah tetap berfungsi, model kepercayaan yang mendasari workspace telah berubah dengan cara yang sulit dibatasi dan lebih sulit lagi untuk dibenarkan.

Setelah mengevaluasi semua opsi itu sebagai jalan buntu, kami mulai merancang solusi kami sendiri untuk menghadirkan pengalaman Codex yang baik bagi pengguna Windows.

Prototipe fungsional pertama kami menggunakan kombinasi konsep dan alat Windows untuk menerapkan isolasi yang kami butuhkan. Sejak awal, salah satu tujuannya adalah membuat ini berfungsi tanpa memerlukan elevasi, yang berarti Codex tidak perlu meminta hak akses administrator kepada pengguna hanya untuk menyiapkan atau menjalankan sandbox. Itu berarti mencari tahu cara menetapkan batasan yang wajar pada dua hal: operasi tulis file dan akses jaringan.

Jika kami sama sekali tidak membatasi penulisan file, kami akan menghadapi masalah keamanan. Jika kami membatasi penulisan file terlalu ketat, sandbox justru akan merugikan produktivitas pengguna karena perlu meminta persetujuan terus-menerus. Untuk memecahkan masalah ini, kami mengandalkan dua elemen dasar penting dari Windows: SID dan token write-restricted.

SID, atau pengidentifikasi keamanan, adalah identitas yang dikaitkan Windows dengan izin. Setiap pengguna memiliki SID, grup memiliki SID, dan bahkan satu sesi masuk mendapatkan SID-nya sendiri. Misalnya, sesi masuk yang sedang aktif mungkin memiliki SID seperti S-1-5-5-X-Y. SID yang ditetapkan untuk grup administrator lokal mungkin adalah S-1-5-32-544.

Windows juga memungkinkan Anda membuat SID sintetis yang tidak sesuai dengan pengguna nyata tetapi tetap dapat muncul dalam ACL (access control list), yang menentukan siapa yang dapat membaca/menulis/mengeksekusi file atau direktori tertentu. Itu menjadikan SID primitif yang berguna untuk sandbox kami: kami dapat membuat SID khusus untuk digunakan sandbox Codex, tanpa mengganggu hal lain di mesin.

Token proses adalah objek keamanan di Windows yang menentukan identitas dan hak akses untuk proses yang sedang berjalan. Hal-hal tersebut menentukan tindakan apa saja yang dapat dilakukan oleh suatu proses. Token well-restricted adalah jenis token proses tertentu yang membuat Windows melakukan pemeriksaan akses tambahan pada operasi tulis.

Agar suatu penulisan berhasil, dua pemeriksaan harus lolos:

1. Identitas pengguna normal (“pemilik” token) harus diizinkan melakukannya
2. Setidaknya satu SID dalam daftar SID terbatas token juga harus diberi akses

Dalam praktiknya, pemeriksaan ini memungkinkan kami menggunakan ACL untuk menentukan secara tepat di mana sandbox dapat memodifikasi filesystem, yang memberi granularitas yang kami butuhkan untuk operasi penulisan.

Dengan SID dan token write-restricted, sandbox non-elevated kami bekerja seperti ini:

1. Penyiapan sandbox membuat SID sintetis bernama sandbox-write.
2. SID sandbox-write diberi akses tulis, eksekusi, dan hapus terhadap
   1. Direktori kerja saat ini
   2. Setiap writable_roots tambahan yang dikonfigurasi di config.toml.
3. Penyiapan sandbox secara eksplisit menolak SID yang sama itu untuk akses tulis ke lokasi “hanya-baca di dalam area yang dapat ditulis” seperti:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex meluncurkan perintah di bawah token write-restricted yang daftar SID terbatasnya mencakup Everyone, SID sesi login saat ini, dan SID sintetis sandbox-write.

Alur ini secara efektif menyelesaikan pembatasan penulisan file dan tampak menjanjikan. Kini kami memerlukan solusi untuk membatasi akses jaringan sandbox.

Membatasi akses jaringan adalah bagian penting dari sandbox; tanpanya, kode berbahaya dapat mengekfiltrasi data dari mesin ke internet. Karena kami ingin menghindari kebutuhan elevasi, opsi kami untuk memblokir lalu lintas jaringan secara kuat terbatas. Alat yang ingin kami gunakan, seperti Windows Firewall, umumnya tidak dapat dipasang tanpa izin admin.

Tanpa Windows Firewall sebagai opsi, kami membatasi hal-hal yang dapat kami kendalikan. Kami mencoba membuat lingkungan anak bersifat fail-closed untuk berbagai alat berjaringan yang benar-benar digunakan pengembang, sehingga perintah Git, penginstal paket, dll. akan gagal di sandbox dan pengguna harus menyetujui setiap operasi yang terhubung ke internet. Idenya adalah merusak jalur keluar yang jelas: mengirim lalu lintas yang mengenali proxy ke endpoint mati, membuat transport HTTP(S) Git melakukan hal yang sama, dan membuat Git melalui SSH langsung gagal. Selain itu, kami menambahkan direktori kecil denybin di awal PATH dan mengurutkan ulang PATHEXT agar skrip stub SSH dan SCP ditemukan sebelum biner asli.

Misalnya, berikut beberapa override lingkungan spesifik yang kami gunakan untuk membatasi akses jaringan:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Itu menangkap banyak trafik normal yang digerakkan alat, tetapi tetap saja hanya bersifat anjuran. Suatu proses dapat mengabaikan lingkungan, melewati PATH, atau langsung membuka socket—terlalu berisiko.

Seperti halnya implementasi perangkat lunak yang menarik, prototipe pertama memiliki beberapa kelebihan dan kekurangan. Meskipun prototipe ini menyelesaikan pekerjaan hanya dengan beberapa kapabilitas Windows standar, memungkinkan penulisan filesystem yang sangat eksplisit dan granular, serta berjalan tanpa elevasi—sehingga mengurangi kebutuhan pengguna untuk menerima prompt elevasi berlebihan atau menjadi admin di mesin lokal mereka—prototipe ini memiliki beberapa kekurangan nyata, beberapa di antaranya membuatnya tidak memenuhi syarat untuk menjadi desain akhir kami:

• Kecepatan penyiapan: Menerapkan ACL workspace bisa mahal tergantung pada topologi direktori workspace.
• Jejak: Kami menerapkan ACL nyata pada sistem pengembang, meskipun jejaknya tidak terlalu invasif karena semua ACL yang diterapkan berkaitan dengan SID sintetis yang dibuat secara khusus dan hanya digunakan oleh sandbox.
• Semantik yang sulit diubah: Ketergantungan pada ACL untuk pembatasan berbasis file berarti bahwa mengubah semantik sandbox menjadi mahal dan kompleks. Sedangkan di macOS, kami dapat mengubah secara dinamis cara kami menghasilkan file .sbpl yang digunakan untuk mengonfigurasi Seatbelt, sandbox Windows mungkin memerlukan operasi yang lambat dan intensif untuk menyesuaikan ACL.
• Perlindungan jaringan lemah. Seperti disebutkan sebelumnya, sifatnya “anjuran”, pasti bisa dilewati oleh beberapa program yang menerapkan stack jaringan mereka sendiri, dan tidak dirancang untuk bertahan terhadap kode yang bersifat adversarial.

Tiga masalah pertama melekat pada implementasi sandbox kustom yang cukup fleksibel untuk alur agentik. Namun, cerita penekanan jaringan berbeda.

Selain agen berbahaya yang dapat dengan mudah mengakali penekanan jaringan berbasis lingkungan, banyak kode/biner berniat baik juga akan mengakalinya jika mereka tidak mematuhi variabel proxy lingkungan, atau jika mereka menerapkan kode jaringan berbasis socket sendiri. Kami merasa aspek ini cukup penting untuk mempertimbangkan investasi pada mode sandbox yang lebih baik.

Untuk memperoleh penekanan jaringan yang lebih baik, kami ingin menggunakan Windows Firewall, yang memungkinkan kami memblokir lalu lintas jaringan keluar untuk pengguna atau program. Sayangnya, kami tidak dapat secara efektif membuat aturan firewall yang fungsional yang hanya berlaku untuk perintah yang dijalankan oleh harness Codex karena beberapa alasan:

• Windows tidak mengizinkan aturan firewall dicocokkan dengan identitas non-principal dari token terbatas. Artinya, kami tidak dapat menerapkan aturan firewall ke “token apa pun yang menyertakan SID sintetis kami dalam daftar SID terbatasnya.”
• Meskipun kami dapat membuat aturan firewall yang cocok dengan biner tertentu, itu hanya memungkinkan kami membatasi jaringan untuk codex.exe itu sendiri. Hal itu tidak akan berlaku untuk proses yang dijalankan oleh agen atas nama pengguna, seperti proses Git atau Python.
• Dimensi pencocokan firewall lainnya juga memiliki bentuk yang salah. Aturan bercakupan pengguna tetap cocok dengan pengguna Windows yang sebenarnya dalam desain non-elevated, bukan hanya dengan proses turunan yang dibatasi. Aturan jalur program terlalu umum: aturan tersebut dapat memblokir codex.exe atau python.exe secara umum, tetapi tidak pada satu pemanggilan python.exe ini yang dijalankan dalam sandbox. Aturan berbasis port atau alamat juga merupakan kebijakan yang sepenuhnya keliru. Misalnya, kami tidak ingin memblokir port 443; kami ingin memblokir akses keluar arbitrer untuk pohon proses terbatas tertentu ini.

Untuk menerapkan aturan firewall secara khusus pada perintah sandbox kami, kami perlu menjalankannya sebagai principal terpisah, bukan sebagai pengguna “asli”. Pendekatan ini membawa kami ke jalur baru, yakni jalur di mana kami melonggarkan batasan “tanpa elevasi”.

Iterasi berikutnya dari sandbox, yang merupakan implementasi kami saat ini, memerlukan hak akses admin yang lebih tinggi saat penyiapan. Oleh karena itu, saya menyebutnya “sandbox elevated.” Pada batas tempat Codex menjalankan perintah di sistem, sandbox elevated tampak sama seperti sandbox non-elevated. Ini masih menjalankan proses anak di bawah token terbatas—serupa dengan token write_restricted dengan daftar SID terbatas yang sama yaitu [Everyone, Logon, Synthetic]—namun, principal token ini bukan lagi pengguna Windows yang sebenarnya, melainkan salah satu dari dua pengguna lokal yang dibuat oleh Codex sendiri:

• CodexSandboxOffline (yang ditargetkan oleh aturan firewall)
• CodexSandboxOnline (yang tidak ditargetkan oleh aturan firewall)

Detail yang tampak kecil ini sebenarnya memiliki implikasi besar bagi sandbox, siapa yang dapat menggunakannya, serta kompleksitas penyiapan dan eksekusi runtime-nya.

Secara visual ini mirip dengan prototipe non-elevated, dengan penambahan aturan firewall dan pengguna Windows khusus yang benar-benar menjalankan perintah. (Namun, hadirnya konsep-konsep baru ini berarti ada lebih banyak pekerjaan penyiapan yang harus dilakukan sebelum sandbox dapat mulai menjalankan dan melindungi perintah.)

Desain sandbox non-elevated memiliki langkah penyiapan yang sederhana, tetapi relatif kecil:

• Membuat SID sintetis jika diperlukan
• Menerapkan ACL untuk SID sintetis sandbox-write

Namun, sandbox elevated memiliki lebih banyak hal yang harus dilakukan.

• Membuat SID sintetis, jika belum dibuat
• Membuat pengguna sandbox online dan offline, jika belum dibuat
• Menyimpan kredensial pengguna yang baru dibuat secara lokal dan mengenkripsinya menggunakan Windows Data Protection API (DPAPI) di lokasi yang sebenarnya tidak dapat dibaca oleh pengguna sandbox
• Membuat aturan firewall yang memblokir semua akses jaringan keluar untuk pengguna CodexSandboxOffline atau, jika sudah ada, memvalidasi bahwa aturan tersebut benar

Ada kerumitan tambahan pada tahap penyiapan. Sandbox Codex diharapkan memiliki akses baca yang setara dengan pengguna Windows yang sebenarnya. Dalam sandbox non-elevated, ketika SID principal token terbatas adalah pengguna Windows, hal ini tercapai. Namun, hal itu tidak didapat begitu saja ketika principal menjadi pengguna CodexSandbox baru. Banyak direktori yang relevan di Windows akan memberikan izin baca/eksekusi kepada “Pengguna Terautentikasi”. Salah satu contoh penting adalah direktori profil pengguna. Secara default, pengguna Windows tidak dapat membaca direktori profil milik pengguna Windows lain, sehingga pembacaan file sederhana sekalipun akan gagal dalam banyak skenario.

Untuk mengatasi ini, kami menambahkan lapisan lain ke proses penyiapan sandbox—lapisan untuk memberikan ACL baca kepada pengguna sandbox di tempat ACL semacam itu mungkin belum ada. Misalnya, ke beberapa direktori Windows yang umum digunakan:

• C:\Users\<real-user>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Karena daftar direktori ini bersifat best-effort dan pemasangan ACL pada masing-masing direktori bisa cukup mahal, kami menjalankan logika ini secara asinkron agar langkah penyiapan sandbox, yang memblokir pengguna, tidak perlu menunggu semuanya selesai.

Kami mengenkapsulasi logika penyiapan dalam biner tersendiri, sebagian agar dapat melewati batas UAC hanya saat diperlukan. Namun alasan yang lebih mendalam bersifat arsitektural: penyiapan sandbox memiliki tugas yang pada dasarnya berbeda dari codex.exe. Menyimpan logika penyiapan sandbox dalam biner khusus memungkinkan codex.exe tetap menjadi harness normal dan non-elevated; mencegah mesin penyiapan khusus Windows membengkakkan ukuran codex.exe di platform lain; memisahkan pekerjaan penyiapan yang berjalan lebih lama dari masa hidup proses utama; dan memberi kami satu tempat untuk menangani berbagai jalur penyiapan yang dibutuhkan sandbox.

Karena cara kerja batas login pengguna dan token Windows, kami tidak dapat lagi terus membuat token terbatas dan menjalankan proses di bawahnya seperti yang bisa kami lakukan pada sandbox non-elevated. Untuk benar-benar menjalankan perintah sebagai pengguna Windows yang berbeda, ide pertama kami adalah alur berikut:

• codex.exe berjalan sebagai pengguna Windows yang sebenarnya. Kemudian, secara berurutan, Codex:
  • Memanggil LogonUserW(...) untuk pengguna sandbox.
  • Memanggil CreateRestrictedToken(...) pada token sandbox-user tersebut.
  • Dengan menggunakan token pengguna sandbox yang dibatasi tersebut, memanggil CreateProcessAsUserW(...) untuk meluncurkan proses anak terakhir.

Dalam praktiknya, alur yang diinginkan itu tidak berjalan karena adanya hambatan hak istimewa pada CreateProcessAsUserW(...). Ini berarti codex.exe dapat membuat token terbatas untuk pengguna sandbox, tetapi tidak dapat secara andal meluncurkan proses turunan dengan token tersebut dari sisi pengguna sebenarnya pada batas tersebut. Kami membutuhkan proses yang sudah berjalan sebagai pengguna sandbox—hal ini memungkinkan langkah pembatasan dan penjalanan akhir terjadi di sisi pengguna sandbox dari batas tersebut, bukan di sisi pengguna sebenarnya.

Persyaratan tersebut menghasilkan codex-command-runner.exe, sebuah biner baru yang tugas satu-satunya adalah membuat token terbatas dan menjalankan perintah yang diminta. Alih-alih meminta codex.exe melakukan seluruh alur sendiri (pengguna nyata → pengguna sandbox → token terbatas → proses anak), kami membagi alur itu menjadi dua:

Bagian 1

• codex.exe memanggil CreateProcessWithLogonW(...) untuk meluncurkan codex-command-runner.exe sebagai pengguna sandbox, tanpa menggunakan token terbatas terlebih dahulu.

Bagian 2

• Di dalam runner, OpenProcessToken(GetCurrentProcess(), ...) membuka token milik runner itu sendiri, yang sudah menjadi milik pengguna sandbox.
• Runner memanggil GetTokenInformation(...) untuk mengekstrak SID logon sandbox, lalu CreateRestrictedToken(...) untuk membangun token terbatas akhir.
• Masih di dalam runner, ini memanggil CreateProcessAsUserW(...) dengan token terbatas itu untuk meluncurkan proses anak yang sebenarnya.

Albert Einstein berkata, “Semuanya harus dibuat sesederhana mungkin, tetapi jangan lebih sederhana dari itu.” Dalam semangat itu, desain kami cukup memecahkan setiap masalah. Arsitektur akhirnya memiliki empat lapisan yang sebelumnya telah kami bahas:

• codex.exe itu sendiri
• codex-windows-sandbox-setup.exe untuk menangani semua pekerjaan penyiapan terkait elevasi
• codex-command-runner.exe untuk menjalankan perintah token terbatas
• Proses anak

Saat pertama kali menangani proyek ini, saya belum memiliki gambaran yang pasti mengenai ke mana arah akhirnya nanti. Pendekatan saya adalah memulai dengan menginstrumentasikan kapabilitas sandboxing pada batas antara Codex dan sistem operasi. Pendekatan ini sangat cocok dengan cara sandbox Codex diterapkan di MacOs dan Linux.

Seiring saya mempelajari lebih jauh alat spesifik yang disediakan Windows, dan melalui puluhan keputusan yang menyeimbangkan keamanan serta kemudahan penggunaan, sistem ini tumbuh menjadi bentuknya saat ini—beberapa biner, pengguna kustom, aturan firewall, langkah penyiapan elevated, proses asinkron, dan banyak lagi.

Ini bukan sistem yang terlalu sederhana, tetapi setiap bagian kompleksitas ditambahkan atas dasar kebutuhan, untuk membangun sandbox yang aman dan, sebisa mungkin, tidak menghalangi pengguna.

Dalam upaya menghadirkan pengalaman pengguna yang baik bagi pengguna Codex di Windows, tujuan kami adalah membuat sesuatu yang aman tanpa mengorbankan kegunaan—inti dari penggunaan Codex adalah agar agen dapat melakukan pekerjaan tanpa perhatian terus-menerus dari Anda.

Salah satu pelajaran terbesar dari proyek ini adalah bahwa Windows tidak memberikan kami satu primitif yang secara bersih memetakan ke “agen pengodean otonom yang aman.” Kami menyusun beberapa alat dan konsep untuk membangun sesuatu yang koheren. Beberapa ide awal berujung buntu. Desain akhirnya merupakan hibrida dari prototipe sebelumnya yang masing-masing menyelesaikan sebagian masalah.

Pelajaran lainnya adalah bahwa keamanan untuk agen pengodean adalah hal yang berbeda dari keamanan aplikasi yang lebih klasik. Codex harus berfungsi untuk alur kerja pengembang yang nyata. Pekerjaan rekayasa ini adalah tentang menyeimbangkan kompatibilitas dengan beban kerja agentik terhadap penerapan kebijakan keamanan yang nyata. Ketegangan itu membentuk kompromi dalam desain akhirnya.

Penasaran ingin melihat sandbox Codex beraksi? Cobalah⁠.