Membina persekitaran sandbox yang selamat dan berkesan untuk mendayakan Codex pada Windows

Apabila saya menyertai pasukan kejuruteraan Codex pada September 2025, Codex untuk Windows belum mempunyai pelaksanaan sandbox, yang bermaksud bahawa pengguna Windows terpaksa memilih antara dua pilihan yang kurang memuaskan apabila menggunakan ejen pengekodan OpenAI:

1. Meluluskan hampir setiap perintah (malah operasi baca) yang mahu dijalankan oleh agen pengekodan, yang tidak cekap dan menjengkelkan. Salah satu manfaat utama menggunakan Codex ialah anda tidak perlu melakukan semua kerja yang membosankan itu sendiri.
2. Mengaktifkan mod Akses Penuh: membenarkan Codex menjalankan semua perintah tanpa kelulusan atau sekatan, yang mengurangkan halangan tetapi mengorbankan pengawasan.

Codex⁠, ejen pengekodan kami, dijalankan pada komputer riba pembangun—sama ada melalui CLI, sambungan IDE atau apl desktop. Ia mengurus perbualan antara manusia yang menggunakan papan kekunci dengan model yang beroperasi dalam awan untuk mengendalikan inferens.

Secara lalai, Codex berjalan dengan kebenaran pengguna sebenar, yang bermaksud ia boleh melakukan semua perkara yang boleh dilakukan oleh pengguna tersebut. Ini sangat berkuasa dan berpotensi berbahaya. Model pengekodan mungkin mengarahkan abah-abah untuk menjalankan perintah secara setempat, daripada menjalankan ujian hingga membaca atau mengedit fail hingga mencipta cabang Git, jadi mod lalai Codex cuba mencari keseimbangan yang tepat antara keberkesanan dengan keselamatan. Mod lalai ini membolehkan Codex membaca fail hampir di mana-mana sahaja dan menulis fail dalam ruang kerja anda (iaitu, direktori tempat anda menjalankan Codex), tanpa akses internet melainkan anda menyatakan bahawa anda menginginkannya. Untuk mencapai kekangan automatik ini bagi menulis fail dan mengakses rangkaian dalam had yang selamat, Codex memerlukan persekitaran sandbox yang benar-benar menguatkuasakan kekangan ini.

Sebuah sandbox ialah persekitaran pelaksanaan yang terhad. Apabila seorang pembangun menggunakan Codex, sistem pengendalian komputer mereka melancarkan perintah dengan kebenaran yang dikurangkan, dan kekangan tersebut merambat turun sepanjang pepohon proses. Setiap arahan Codex dijalankan dalam persekitaran sandbox dari awal, dan setiap proses turunan kekal berada dalam sempadan yang sama.

Codex memerlukan ciri pengasingan yang dikuatkuasakan oleh sistem pengendalian komputer untuk melaksanakan kotak pasir yang berkesan. Sesetengah sistem pengendalian menyediakan utiliti yang melaksanakan perkara ini dengan baik (cth., Seatbelt pada MacOs, seccomp atau bubblewrap pada Linux); walau bagaimanapun, Windows pada masa ini tidak menyediakan keupayaan jenis ini secara terbina dalam.

Untuk memastikan Codex sama selamat dan menyenangkan untuk digunakan pada Windows seperti di platform lain, kami perlu melaksanakan sandbox kami sendiri.

Windows menawarkan beberapa alat dan primitif untuk pengasingan. Walaupun tiada satu pun daripada mereka yang memenuhi keperluan kami, kami melihat beberapa penyelesaian yang berpotensi—iaitu, AppContainer, Windows Sandbox dan pelabelan Kawalan Integriti Mandatori.

AppContainer

• Apa: AppContainer ialah kotak pasir Windows asli, model pengasingan berasaskan keupayaan yang dibina untuk aplikasi yang mengetahui dari awal dengan tepat perkara yang perlu mereka akses.
• Mengapa: Menarik kerana ia menawarkan sempadan OS sebenar dan bukannya sekatan berdasarkan usaha terbaik.
• Mengapa tidak: Codex bukan aplikasi tunggal dengan skop yang terhad. Ia memacu aliran kerja pembangun yang bersifat terbuka: shell, Git, Python, pengurus pakej, alat binaan, dan apa-apa binari lain yang diputuskan oleh ejen sebagai diperlukan. Secara praktiknya, hal itu menjadikan AppContainer tidak sesuai untuk menangani masalah tersebut. Itu merupakan pengasingan yang kukuh, tetapi untuk kelas beban kerja yang jauh lebih sempit berbanding “membenarkan agen beroperasi seperti pembangun.”

Windows Sandbox

• Apa: Windows Sandbox ialah VM ringan pakai buang daripada Microsoft. Anda mendapat desktop Windows yang baharu dengan sempadan pengasingan yang kukuh, dan apa sahaja yang anda lakukan di dalamnya akan hilang apabila sesi tamat.
• Mengapa: Menarik atas sebab-sebab yang jelas—jauh lebih serasi dengan sebarang perisian berbanding AppContainer, dan dari perspektif keselamatan, ia merupakan persekitaran pengasingan yang jauh lebih kukuh.
• Mengapa tidak: Codex perlu bertindak secara langsung pada semak keluar, alat dan persekitaran sebenar pengguna, bukan di dalam desktop pakai buang yang berasingan yang memerlukan persediaan dan jambatan hos/tetamu. Ia juga mempunyai masalah produk yang asas: Windows Sandbox pun tidak tersedia pada SKU Windows Home.

Pelabelan integriti Kawalan Integriti Mandatori (MIC)

• Apa: Windows mempunyai konsep yang dipanggil “tahap integriti,” seperti rendah, sederhana dan tinggi, yang menentukan sejauh mana sistem mempercayai objek dan proses. Peraturan asasnya ialah proses dengan integriti lebih rendah tidak boleh menulis pada objek dengan tahap integriti lebih tinggi, walaupun ACL biasa sebaliknya membenarkannya. Sebagai contoh, proses berintegriti rendah dianggap kurang dipercayai, jadi Windows menyekatnya daripada menulis pada objek biasa berintegriti sederhana, melainkan objek tersebut dilabel semula secara eksplisit untuk membenarkannya.
• Mengapa: MIC nampak kemas secara teori—jalankan Codex pada integriti rendah, label semula akar yang boleh ditulis sebagai integriti rendah, dan biarkan Windows menguatkuasakan larangan menulis di tempat lain. Itu akan memberi kita laluan bukan pentadbir yang disokong oleh mekanisme OS sebenar.
• Mengapa tidak: Seperti ACL, label integriti mengubah suai sistem fail hos sebenar, dan dalam kes ini perubahan semantiknya sangat luas. Menandakan ruang kerja sebagai integriti rendah bukan sekadar bermaksud “Codex boleh menulis di sini.” Ini bermaksud proses berintegriti rendah secara umum boleh menulis ke lokasi tersebut. Pada mesin pembangun sebenar, perkara itu menjadikan checkout sebenar pengguna sebagai sink berintegriti rendah untuk hos, yang jauh lebih berisiko berbanding memberikan ACL yang disasarkan dengan teliti kepada satu reka bentuk sandbox. Walaupun alat pembangun berintegriti sederhana terus berfungsi, model kepercayaan asas ruang kerja telah berubah dengan cara yang sukar dibendung dan lebih sukar untuk diwajarkan.

Setelah menilai semua pilihan tersebut dan mendapati semuanya tidak sesuai untuk diteruskan, kami mula mereka bentuk penyelesaian kami sendiri untuk memberikan pengalaman Codex yang baik kepada pengguna Windows.

Prototaip berfungsi kami yang pertama menggunakan gabungan konsep dan alat Windows untuk melaksanakan pengasingan yang kami perlukan. Dari awal lagi, salah satu matlamatnya adalah untuk memastikan ini berfungsi tanpa memerlukan peningkatan keistimewaan, bermaksud Codex tidak perlu memaparkan prom kepada pengguna untuk mendapatkan keistimewaan pentadbir semata-mata bagi menyediakan atau menjalankan sandbox. Ini bermakna mencari cara untuk menetapkan had yang munasabah pada dua perkara: operasi tulis fail dan akses rangkaian.

Jika kami tidak mengehadkan penulisan fail langsung, kami akan menghadapi isu keselamatan. Jika kami mengehadkan penulisan fail terlalu ketat, sandbox akan menjejaskan produktiviti pengguna kerana perlu meminta kelulusan berterusan. Untuk menyelesaikan masalah ini, kami bergantung pada dua komponen asas Windows yang penting: SIDs dan token dengan sekatan tulis.

SID, atau pengecam keselamatan, ialah identiti yang Windows kaitkan dengan keizinan. Setiap pengguna mempunyai SID, kumpulan mempunyai SID, malah satu sesi log masuk pun mendapat SID tersendiri. Sebagai contoh, sesi log masuk semasa mungkin mempunyai SID seperti S-1-5-5-X-Y. SID yang diperuntukkan kepada kumpulan pentadbir setempat mungkin ialah S-1-5-32-544.

Windows juga membolehkan anda mencipta SID sintetik yang tidak sepadan dengan pengguna sebenar tetapi masih boleh muncul dalam ACL (senarai kawalan akses), yang menentukan siapa yang boleh membaca/menulis/menjalankan fail atau direktori tertentu. Itu menjadikan SIDs sebagai primitif yang berguna untuk kotak pasir kami: kami boleh mencipta SIDs secara eksklusif untuk digunakan oleh kotak pasir Codex, tanpa mengganggu apa-apa yang lain pada mesin tersebut.

Token proses ialah objek keselamatan dalam Windows yang menentukan identiti dan hak istimewa untuk proses yang sedang berjalan. Perkara-perkara ini menentukan tindakan yang boleh dilakukan oleh sesuatu proses. Token terhad tulis ialah jenis token proses tertentu yang membuatkan Windows melakukan semakan capaian tambahan pada operasi tulis.

Untuk memastikan operasi tulis berjaya, dua semakan mesti lulus:

1. Identiti pengguna biasa (token “pemilik”) mesti dibenarkan untuk melakukannya
2. Sekurang-kurangnya satu SID dalam senarai SID terhad bagi token juga mesti diberikan akses

Dalam praktiknya, semakan ini membolehkan kami menggunakan ACL untuk mentakrifkan dengan tepat lokasi sandbox boleh mengubah suai sistem fail, sekali gus menyediakan tahap perincian yang kami perlukan bagi operasi tulis.

Dengan SID dan token terhad tulis, kotak pasir kami tanpa peningkatan hak berfungsi seperti ini:

1. Persediaan sandbox telah mencipta SID sintetik yang dipanggil sandbox-write.
2. SID sandbox-write telah diberikan akses tulis, laksana dan padam kepada
   1. Direktori kerja semasa
   2. Sebarang writable_roots tambahan yang dikonfigurasikan dalam config.toml.
3. Persediaan sandbox secara eksplisit menafikan akses tulis kepada SID yang sama itu untuk lokasi “baca sahaja dalam boleh tulis” seperti:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex menjalankan perintah di bawah token dengan sekatan tulis yang senarai SID terhadnya merangkumi Everyone, SID sesi yang sedang dilog masuk, dan SID sintetik sandbox-write.

Aliran ini berjaya menyelesaikan isu mengehadkan penulisan fail dengan berkesan dan kelihatan menjanjikan. Kini kami memerlukan penyelesaian untuk mengehadkan akses rangkaian sandbox.

Mengehadkan akses rangkaian merupakan bahagian penting dalam sandbox; tanpanya, kod berniat jahat boleh mengeksfiltrasi data daripada mesin ke internet. Oleh sebab kami ingin mengelakkan keperluan peningkatan hak istimewa, kami mempunyai pilihan yang terhad untuk menyekat trafik rangkaian dengan berkesan. Alat yang ingin kami gunakan, seperti Windows Firewall, secara umumnya tidak dapat dipasang tanpa kebenaran pentadbir.

Tanpa Windows Firewall sebagai pilihan, perkara yang dapat kami kawal menjadi terhad. Kami cuba menjadikan persekitaran anak bersifat fail-closed untuk jenis alat berangkaian yang sebenarnya digunakan oleh pembangun, supaya arahan Git, pemasang pakej, dsb., akan gagal dalam sandbox dan pengguna perlu meluluskan sebarang operasi yang berhadapan dengan Internet. Ideanya adalah untuk melumpuhkan laluan keluar yang jelas: hantar trafik yang menyedari proksi ke titik akhir yang tidak berfungsi, jadikan pengangkutan HTTP(S) Git melakukan perkara yang sama, dan pastikan Git melalui SSH gagal serta-merta. Selain itu, kami menambahkan direktori kecil denybin pada bahagian hadapan PATH dan menyusun semula PATHEXT supaya skrip rintisan SSH dan SCP diselesaikan sebelum binari sebenar.

Sebagai contoh, berikut ialah beberapa penggantian persekitaran khusus yang kami gunakan untuk mengehadkan akses rangkaian:

• 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=hos setempat,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Itu mengesan banyak trafik biasa yang dijana oleh alat, tetapi ia masih sekadar bersifat nasihat. Sesuatu proses boleh mengabaikan persekitaran, memintas PATH, atau hanya membuka soket secara terus—terlalu berisiko.

Seperti mana-mana pelaksanaan perisian yang menarik, prototaip pertama mempunyai beberapa kelebihan dan kekurangan. Walaupun ia menyelesaikan tugas dengan hanya beberapa keupayaan Windows standard, membolehkan penulisan sistem fail yang sangat eksplisit dan terperinci, serta berjalan tanpa peningkatan hak—mengurangkan keperluan untuk pengguna menerima prom peningkatan hak yang berlebihan atau menjadi pentadbir pada mesin setempat mereka—ia mempunyai beberapa kelemahan sebenar, sesetengah daripadanya menyebabkan ia tidak layak menjadi reka bentuk akhir kami:

• Kelajuan persediaan: Menerapkan ACL ruang kerja boleh memerlukan banyak sumber bergantung pada topologi direktori ruang kerja.
• Jejak: Kami menggunakan ACL sebenar pada sistem pembangun, walaupun jejak tersebut tidak begitu invasif kerana semua ACL yang digunakan berkaitan dengan SID sintetik yang dicipta khas dan hanya digunakan oleh sandbox.
• Semantik yang sukar diubah: Kebergantungan pada ACL untuk sekatan berasaskan fail bermakna semantik sandbox adalah mahal dan rumit untuk diubah. Manakala pada macOS, kita boleh mengubah secara dinamik cara kita menjana .sbpl fail yang digunakan untuk mengkonfigurasi Seatbelt, sandbox Windows mungkin memerlukan operasi yang perlahan dan intensif untuk melaraskan ACL.
• Perlindungan rangkaian lemah. Seperti yang disebut sebelum ini, ia bersifat “nasihat,” pasti akan dipintas oleh sesetengah program yang melaksanakan tindanan rangkaian mereka sendiri, dan tidak direka bentuk untuk bertahan terhadap kod yang bersifat memusuhi.

Tiga isu pertama memang wujud dalam pelaksanaan sandbox tersuai yang cukup fleksibel untuk aliran agentik. Namun, halnya berbeza bagi penyekatan rangkaian.

Selain agen berniat jahat yang dapat memintas penyekatan rangkaian berasaskan persekitaran dengan mudah, banyak kod/binari yang berniat baik juga akan memintasnya sekiranya kod/binari tersebut tidak mematuhi pemboleh ubah proksi persekitaran, atau jika kod/binari tersebut melaksanakan kod rangkaian berasaskan soket mereka sendiri. Kami berpendapat bahawa aspek ini sudah memadai untuk mempertimbangkan pelaburan dalam mod sandbox yang lebih baik.

Untuk mendapatkan pengekangan rangkaian yang lebih baik, kami ingin menggunakan Windows Firewall, yang membolehkan kami menyekat trafik rangkaian keluar untuk pengguna atau program. Malangnya, kami tidak dapat mencipta peraturan tembok api yang berfungsi dengan berkesan yang hanya terpakai pada perintah yang dilancarkan oleh harness Codex atas beberapa sebab:

• Windows tidak membenarkan pemadanan peraturan tembok api dengan identiti bukan prinsipal bagi token terhad. Ini bermaksud kami tidak dapat menerapkan peraturan firewall pada “sebarang token yang menyertakan SID sintetik kami dalam senarai SID terhadnya."
• Walaupun kita boleh mencipta peraturan tembok api yang sepadan dengan binari tertentu, itu hanya membolehkan kita mengehadkan akses rangkaian untuk codex.exe itu sendiri. Ia tidak akan terpakai pada proses yang dilancarkan oleh ejen bagi pihak pengguna, seperti proses Git atau Python.
• Dimensi padanan firewall yang lain juga mempunyai bentuk yang salah. Peraturan berskop pengguna masih dipadankan dengan pengguna Windows sebenar dalam reka bentuk tanpa peningkatan hak, bukan hanya dengan proses anak terhad. Peraturan laluan program terlalu umum: peraturan tersebut boleh menyekat codex.exe atau python.exe secara umum, tetapi bukan pemanggilan python.exe yang dikotakpasirkan ini. Peraturan berasaskan port atau alamat juga merupakan dasar yang salah sama sekali. Sebagai contoh, kami tidak mahu menyekat port 443; kami mahu menyekat akses keluar sewenang-wenangnya untuk pepohon proses terhad khusus ini.

Untuk menggunakan peraturan tembok api secara khusus pada perintah kami yang disandboxkan, kami perlu menjalankannya sebagai prinsipal berasingan, bukan sebagai pengguna “sebenar”. Pendekatan ini membawa kami ke laluan baharu, yang membolehkan kami melonggarkan kekangan “tiada peningkatan hak istimewa” kami.

Iterasi seterusnya bagi sandbox, iaitu pelaksanaan semasa kami, memerlukan kebenaran pentadbir yang lebih tinggi semasa persediaan. Oleh itu, saya merujuk kepadanya sebagai “sandbox yang ditingkatkan.” Pada sempadan tempat Codex memulakan perintah pada sistem, sandbox dengan keistimewaan dinaikkan kelihatan seperti sandbox tanpa keistimewaan dinaikkan. Ia masih menjalankan proses anak di bawah token terhad—begitu juga token write_restricted dengan senarai SID terhad yang sama iaitu [Everyone, Logon, Synthetic]—namun, prinsipal token ini bukan lagi pengguna Windows sebenar tetapi salah seorang daripada dua pengguna setempat yang dicipta oleh Codex sendiri:

• CodexSandboxOffline (yang disasarkan oleh peraturan tembok api)
• CodexSandboxOnline (yang tidak disasarkan oleh peraturan tembok api)

Butiran yang kelihatan kecil ini sebenarnya mempunyai implikasi besar terhadap persekitaran sandbox, siapa yang boleh menggunakannya, serta kerumitan penyediaan dan pelaksanaan masa jalannya.

Ia secara visual serupa dengan prototaip tanpa peningkatan keistimewaan, dengan pengenalan peraturan tembok api dan pengguna Windows khusus, yang sebenarnya menjalankan perintah tersebut. (Walau bagaimanapun, pengenalan konsep baharu ini bermakna terdapat lebih banyak kerja persediaan yang perlu dilakukan sebelum sandbox boleh mula menjalankan dan melindungi perintah.)

Reka bentuk sandbox tanpa hak istimewa yang dinaikkan mempunyai langkah penyediaan yang mudah, tetapi langkah itu agak kecil:

• Cipta SID sintetik jika diperlukan
• Terapkan ACL untuk SID sintetik sandbox-write

Walau bagaimanapun, kotak pasir yang dinaikkan keistimewaannya mempunyai lebih banyak tugas untuk dilakukan.

• Cipta SID sintetik, jika belum dicipta
• Cipta pengguna sandbox dalam talian dan luar talian, jika belum dicipta
• Simpan kelayakan pengguna yang baru dicipta secara setempat dan enkripsi menggunakan API Perlindungan Data Windows (DPAPI) di lokasi yang pengguna sandbox tidak dapat baca
• Cipta peraturan tembok api yang menyekat semua akses rangkaian keluar untuk pengguna CodexSandboxOffline atau, jika peraturan tersebut sudah wujud, sahkan bahawa peraturan tersebut betul

Terdapat satu kerumitan tambahan pada peringkat persediaan. Sandbox Codex dijangka mempunyai akses baca yang setara dengan pengguna Windows sebenar. Dalam sandbox tanpa peningkatan hak, yang mana SID prinsipal token terhad ialah pengguna Windows, perkara ini berjaya dicapai. Walau bagaimanapun, itu tidak diperoleh secara percuma apabila prinsipal tersebut menjadi pengguna CodexSandbox yang baharu. Banyak direktori yang berkaitan pada Windows akan memberikan kebenaran baca/laksana kepada “Pengguna Disahkan”. Satu contoh yang ketara ialah direktori profil pengguna. Secara lalai, pengguna Windows tidak boleh membaca direktori profil pengguna Windows lain, jadi walaupun operasi membaca fail yang mudah akan gagal dalam banyak senario.

Untuk menangani perkara ini, kami menambahkan satu lagi lapisan pada proses persediaan sandbox—iaitu satu lapisan untuk memberikan ACL read kepada pengguna sandbox di tempat ACL sedemikian mungkin belum wujud. Contohnya, kepada beberapa direktori Windows yang biasa digunakan:

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

Oleh sebab senarai direktori ini disediakan berdasarkan usaha terbaik dan pemasangan ACL pada setiap direktori boleh menjadi agak mahal dari segi sumber, kami menjalankan logik ini secara tak segerak supaya langkah penyediaan sandbox, yang menyekat pengguna, tidak perlu menunggu proses tersebut selesai.

Kami merangkumkan logik persediaan dalam binari tersendiri, sebahagiannya untuk merentasi sempadan UAC hanya apabila diperlukan. Tetapi sebab yang lebih mendalam ialah dari segi seni bina: penyediaan sandbox mempunyai tugas yang secara asasnya berbeza daripada codex.exe. Mengekalkan logik persediaan sandbox dalam binari khusus membolehkan codex.exe kekal sebagai harness biasa yang tidak dinaikkan keistimewaannya; menghalang mekanisme persediaan khusus Windows daripada membesarkan codex.exe pada platform lain; menyahgandingkan kerja persediaan yang berjalan lebih lama daripada jangka hayat proses utama; dan memberi kami satu tempat untuk mengendalikan laluan persediaan berbeza yang diperlukan oleh sandbox.

Disebabkan cara sempadan log masuk pengguna Windows dan token berfungsi, kami tidak dapat terus mencipta token terhad dan memulakan proses di bawahnya seperti yang boleh kami lakukan dengan sandbox tanpa peningkatan hak. Untuk benar-benar menjalankan perintah sebagai pengguna Windows yang berbeza, idea pertama kami ialah aliran proses berikut:

• codex.exe berjalan sebagai pengguna Windows sebenar. Kemudian, secara berturutan, Codex:
  • Memanggil LogonUserW(...) untuk pengguna sandbox.
  • Memanggil CreateRestrictedToken(...) pada token pengguna sandbox tersebut.
  • Menggunakan token pengguna sandbox yang terhad itu, memanggil CreateProcessAsUserW(...) untuk melancarkan proses anak terakhir.

Dalam praktiknya, aliran yang diingini itu tidak berjaya kerana terdapat halangan keistimewaan pada CreateProcessAsUserW(...). Ini bermaksud codex.exe boleh mencipta token terhad untuk pengguna sandbox, tetapi ia tidak dapat melancarkan proses anak dengan token tersebut secara boleh dipercayai dari sisi pengguna sebenar bagi sempadan tersebut. Kami memerlukan proses yang sudah berjalan sebagai pengguna sandbox—ini akan membolehkan langkah sekatan dan spawn akhir berlaku di sisi pengguna sandbox bagi sempadan tersebut, bukannya di sisi pengguna sebenar.

Keperluan itu membawa kepada codex-command-runner.exe, sebuah binari baharu yang satu-satunya tugasnya ialah menjana token terhad dan melancarkan perintah yang diminta. Daripada meminta codex.exe melakukan keseluruhan aliran itu sendiri (pengguna sebenar → pengguna sandbox → token terhad → proses anak), kami membahagikan aliran tersebut kepada dua:

Bahagian 1

• codex.exe memanggil CreateProcessWithLogonW(...) untuk melancarkan codex-command-runner.exe sebagai pengguna sandbox, tanpa menggunakan token terhad lagi.

Bahagian 2

• Di dalam pelari, OpenProcessToken(GetCurrentProcess(), ...) membuka token pelari itu sendiri, yang sudah dimiliki oleh pengguna kotak pasir.
• Pelaksana memanggil GetTokenInformation(...) untuk mengekstrak SID log masuk sandbox, kemudian CreateRestrictedToken(...) untuk membina token terhad akhir.
• Masih di dalam runner, ia memanggil CreateProcessAsUserW(...) dengan token terhad itu untuk melancarkan proses anak sebenar.

Albert Einstein berkata, “Segala-galanya harus dibuat semudah mungkin, tetapi tidak lebih mudah daripada itu.” Selaras dengan semangat itu, reka bentuk kami telah menyelesaikan setiap masalah dengan secukupnya. Seni bina akhir terdiri daripada empat lapisan yang telah kita bincangkan sebelum ini:

• codex.exe itu sendiri
• codex-windows-sandbox-setup.exe untuk mengendalikan semua kerja berkaitan persediaan yang memerlukan hak pentadbir
• codex-command-runner.exe untuk menjalankan perintah token terhad
• Proses anak

Ketika saya mula-mula menangani projek ini, saya tidak begitu pasti ke mana akhirnya projek ini akan menuju. Pendekatan saya ialah bermula dengan menambahkan instrumentasi pada keupayaan sandbox di sempadan antara Codex dengan sistem pengendalian. Pendekatan ini hampir sama dengan cara sandbox Codex dilaksanakan pada MacOs dan Linux.

Apabila saya mempelajari lebih lanjut tentang alat khusus yang disediakan oleh Windows, dan melalui puluhan keputusan yang mengimbangi keselamatan dan kemudahan penggunaan, sistem ini berkembang kepada bentuk semasanya—berbilang binari, pengguna tersuai, peraturan tembok api, langkah persediaan dengan keistimewaan tinggi, proses tak segerak dan banyak lagi.

Ia bukanlah sistem yang begitu mudah, tetapi setiap elemen kerumitan ditambah atas keperluan, untuk membina persekitaran sandbox yang selamat dan, seboleh mungkin, tidak mengganggu pengguna.

Dalam usaha untuk menyampaikan pengalaman pengguna yang baik kepada pengguna Codex pada Windows, matlamat kami adalah untuk menghasilkan sesuatu yang selamat tanpa menjejaskan kegunaan—tujuan utama menggunakan Codex adalah untuk membolehkan ejen melakukan kerja tanpa memerlukan perhatian berterusan daripada anda.

Salah satu pengajaran terbesar daripada projek ini ialah Windows tidak menyediakan satu mekanisme asas yang boleh dipetakan dengan tepat kepada “ejen pengekodan autonomi yang selamat.” Kami menggabungkan beberapa alat dan konsep untuk membina sesuatu yang padu. Beberapa idea awal menemui jalan buntu. Reka bentuk akhir merupakan hibrid daripada prototaip terdahulu yang masing-masing menyelesaikan sebahagian daripada masalah tersebut.

Pelajaran lain ialah bahawa keselamatan untuk agen pengekodan adalah perkara yang sama sekali berbeza berbanding keselamatan aplikasi yang lebih tradisional. Codex perlu berfungsi untuk aliran kerja pembangun dunia sebenar. Kerja kejuruteraan tersebut adalah tentang mengimbangi keserasian dengan beban kerja agentik dengan penguatkuasaan sebenar. Ketegangan tersebut mempengaruhi kompromi dalam reka bentuk akhir.

Tertarik untuk melihat sandbox Codex beraksi? Cuba⁠.