Mbangun lingkungan sandbox sing aman lan efektif kanggo ngaktifake Codex ing Windows

Nalika aku gabung karo tim engineering Codex ing September 2025, Codex kanggo Windows durung nduwé implementasi sandbox, sing tegesé pangguna Windows kepeksa milih salah siji saka rong pilihan sing kurang becik nalika nggunakake agen ngoding OpenAI:

1. Nyetujoni meh saben perintah (malah sing mung maca) sing arep dijalanké agen ngoding, sing ora efisien lan ngrepoti. Salah siji paedah utama nggunakake Codex yaiku njenengan ora kudu nindakake kabeh gaweyan sing mboseni dhewe.
2. Ngaktifake mode Full Access: ngidini Codex mbukak kabeh perintah tanpa persetujuan utawa watesan, sing ngilangake hambatan nanging kanthi ngorbanake pengawasan.

Codex⁠, agen ngoding kita, mlaku ing laptop pangembang—apa liwat CLI, ekstensi IDE, utawa aplikasi desktop. Iki ngatur obrolan antarane manungsa ing ngarep keyboard lan model sing mlaku ing cloud kanggo nangani inferensi.

Codex mlaku nganggo idin saka pangguna nyata kanthi gawan, tegesé bisa nindakake kabeh sing bisa ditindakake pangguna. Iki nduwèni kekuwatan lan duwé potensi mbebayani. Model ngoding bisa uga ngandhani harness supaya nglakokaké perintah sacara lokal, wiwit saka nglakokaké tes nganti maca utawa nyunting file nganti nggawe cabang Git, mula mode gawan Codex nyoba nemokaké imbangan sing trep antarane efektivitas lan keamanan. Mode gawan iki ngidini Codex maca file meh ing ngendi wae lan nulis file ing sajroning workspace njenengan (yaiku, direktori panggonan njenengan nglakokaké Codex), tanpa akses internet kajaba njenengan nemtokake yen njenengan pengin. Kanggo nggayuh watesan otomatis iki kanggo nulis file lan ngakses jaringan ing wates sing aman, Codex mbutuhake lingkungan sandbox sing pancen ngetrapaké watesan-watesan iki.

Sandbox yaiku lingkungan eksekusi sing diwatesi. Nalika pangembang nggunakake Codex, sistem operasi komputeré ngluncurake command nganggo idin sing diwatesi, lan watesan kasebut diterusake mudhun ing wit proses. Saben perintah Codex diisolasi ing sandbox saka wiwitan, lan saben proses turunane tetep ana ing wates sing padha.

Codex mbutuhake fitur isolasi sing diterapake dening sistem operasi komputer kanggo ngetrapake sandbox sing efektif. Sawetara sistem operasi nyedhiyakake utilitas sing bisa nindakake iki kanthi becik (kayata Seatbelt ing macOS, seccomp utawa bubblewrap ing Linux); nanging, Windows saiki durung nyedhiyakake jinis kapabilitas iki minangka fitur bawaan.

Kanggo nggawe Codex padha aman lan nyenengake kanggo digunakaké ing Windows kaya sing wis ana ing papan liya, kita kudu ngimplementasikaké sandbox dhewe.

Windows nyedhiyakake sawetara alat lan primitif kanggo isolasi. Sanajan ora ana siji wae sing bener-bener nyukupi syarat kita, kita wis nliti sawetara solusi potensial—yaiku, AppContainer, Windows Sandbox, lan pelabelan Mandatory Integrity Control.

AppContainer

• Apa: AppContainer yaiku sandbox asli Windows, model isolasi adhedhasar kapabilitas sing dirancang kanggo aplikasi sing saka wiwitan ngerti kanthi persis apa sing kudu diakses.
• Apa sebabé: Narik kawigaten amarga nawakaké wates OS sing nyata tinimbang watesan sing mung adhedhasar upaya paling apik.
• Napa ora: Codex dudu aplikasi sing cakupane winates banget. Iki nggerakake alur kerja pangembang sing mbukak: shell, Git, Python, pangatur paket, piranti build, lan binari liyane sing dianggep dibutuhake dening agen. Ing praktiké, kuwi ndadèkaké AppContainer ora cocog kanggo masalah kasebut. Iki minangka isolasi sing kuwat, nanging kanggo kelas beban kerja sing luwih sempit tinimbang “ngidini agen beroperasi kaya pangembang.”

Windows Sandbox

• Apa: Windows Sandbox yaiku VM entheng saka Microsoft sing bisa dibuwang. Njenengan entuk desktop Windows anyar sing resik kanthi wates isolasi sing kuwat, lan apa wae sing njenengan tindakake ing njero bakal ilang nalika sesi rampung.
• Napa: Menarik amarga alasan sing wis cetha—adoh luwih kompatibel karo piranti lunak apa wae tinimbang AppContainer, lan saka perspektif keamanan, iki wadhah isolasi sing luwih kuwat.
• Napa ora: Codex kudu tumindak langsung ing checkout nyata pangguna, alat, lan lingkungané, dudu ing njero desktop kapisah sing mung sauntara sing bakal mbutuhake persiyapan lan host/guest bridging. Iki uga nduwèni masalah produk sing dhasar: Windows Sandbox malah ora kasedhiya ing SKU Windows Home.

Pelabelan integritas Mandatory Integrity Control (MIC)

• Apa: Windows nduwé konsep sing diarani “tingkat integritas,” kayata rendah, sedang, lan tinggi, sing nemtokake sepira gedhene kapercayan sistem marang objek lan proses. Aturan dhasaré yaiku proses kanthi integritas luwih endhek ora bisa nulis menyang objek kanthi tingkat integritas sing luwih dhuwur, sanajan ACL normal sakjané ngidini. Contone, proses kanthi integritas rendah dianggep kurang dipercaya, mula Windows ngalangi proses kasebut supaya ora nulis menyang objek integritas medium normal, kajaba objek kasebut kanthi eksplisit dilabeli maneh kanggo ngidini proses kasebut.
• Napa: MIC katon elegan ing teorine—mbukak Codex kanthi integritas rendah, menehi label ulang root sing bisa ditulisi dadi integritas rendah, lan supaya Windows ngetrapake ora ana penulisan ing papan liya. Kuwi mesthine bakal menehi kita jalur non-admin sing didhukung dening mekanisme OS sing nyata.
• Napa ora: Kaya ACL, label integritas ngowahi sistem berkas host nyata, lan ing kasus iki owah-owahan semantike amba banget. Nandhani ruang kerja minangka integritas rendah ora mung ateges “Codex bisa nulis ing kene.” Iki tegesé proses kanthi integritas rendah umumé bisa nulis ing kana. Ing mesin pangembang sing nyata, kuwi ngowahi checkout nyata pangguna dadi sink integritas rendah kanggo host, sing luwih beboyo tinimbang menehi ACL sing ditargetake kanthi tliti marang siji rancangan sandbox. Sanajan piranti pangembang kanthi tingkat integritas medium tetep bisa mlaku, model kapercayan dhasar saka workspace wis owah kanthi cara sing angel dikendhalèni lan luwih angel dijustifikasi.

Sawisé ngevaluasi kabèh opsi lan nemtokaké manawa kabèh mau ora layak diterusaké, kita miwiti ngrancang solusi dhéwé kanggo nyedhiyakake pengalaman Codex sing apik kanggo pangguna Windows.

Prototipe fungsional pisanan kita nggunakake kombinasi konsep lan piranti Windows kanggo ngleksanakaké isolasi sing kita butuhake. Wiwit wiwitan, salah siji tujuane yaiku supaya iki bisa mlaku tanpa mbutuhake elevasi, tegese Codex ora perlu njaluk hak istimewa administrator saka pangguna mung kanggo nyiyapake utawa nglakokake sandbox. Kuwi ateges nemtokaké carané netepaké watesan sing wajar kanggo rong perkara: nulis file lan akses jaringan.

Yen kita ora mbatesi panulisan file babar pisan, bakal ana masalah keamanan. Yen kita mbatesi panulisan file kakehan, sandbox bakal ngganggu produktivitas pangguna amarga kudu terus-terusan njaluk persetujuan. Kanggo ngrampungake masalah iki, kita ngandelake rong komponen dhasar Windows sing penting: SID lan token kanthi watesan nulis.

SID, utawa pengenal keamanan, yaiku identitas sing digandhengake Windows karo idin. Saben pangguna nduwèni SID, grup nduwèni SID, lan malah siji sesi login wae nduwèni SID dhéwé. Contone, sesi sing lagi mlebu saiki bisa duwe SID kaya S-1-5-5-X-Y. SID sing diwenehake menyang grup administrator lokal bisa uga S-1-5-32-544.

Windows uga ngidini njenengan nggawe SID sintetis sing ora cocog karo pangguna nyata nanging isih bisa katon ing ACL (dhaptar kontrol akses), sing nemtokake sapa sing bisa maca/nulis/ngeksekusi file utawa direktori tartamtu. Iku ndadekake SID dadi komponen dhasar sing migunani kanggo sandbox kita: kita bisa nggawe SID khusus kanggo digunakake dening sandbox Codex, tanpa ngganggu apa wae liyane ing mesin kasebut.

Token proses yaiku objek keamanan ing Windows sing nemtokake identitas lan hak istimewa kanggo proses sing lagi mlaku. Iki nemtokaké tumindak apa waé sing bisa ditindakake déning sawijining proses. Sawijining token sing diwatesi kanggo nulis yaiku jinis token proses tartamtu sing nyebabake Windows nindakake pamriksa akses tambahan nalika operasi nulis.

Supaya proses nulis kasil, rong pamriksan kudu lolos:

1. Identitas pangguna normal (token “owner”) kudu diidini kanggo nindakake iki
2. Paling ora siji SID ing dhaptar SID sing diwatesi saka token uga kudu diwenehi akses

Ing praktiké, pemeriksaan iki ngidini kita nggunakake ACL kanggo nemtokaké kanthi persis ing ngendi sandbox bisa ngowahi sistem berkas, sing menehi tingkat kerincian sing kita butuhaké kanggo operasi nulis.

Kanthi SID lan token sing diwatesi hak nulisé, sandbox sing ora ditingkataké makarya kaya mangkene:

1. Persiyapan sandbox nggawe SID sintetis sing diarani sandbox-write.
2. SID sandbox-write diwenehi akses tulis, eksekusi, lan hapus menyang
   1. Direktori kerja saiki
   2. writable_roots tambahan apa wae sing dikonfigurasi ing config.toml.
3. Setelan sandbox kanthi eksplisit ora maringi SID sing padha kuwi akses nulis menyang lokasi “mung-diwaca ing njero sing bisa-ditulisi” kayata:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex nglakokake paréntah nganggo token sing diwatesi kanggo nulis, kanthi dhaptar SID sing diwatesi kalebu Kabeh wong, SID sesi sing saiki mlebu, lan SID sintetis sandbox-write.

Alur iki kanthi efektif ngatasi watesan panulisan file lan katon njanjeni. Saiki kita mbutuhake solusi kanggo matesi akses jaringan sandbox.

Matesi akses jaringan iku bagean penting saka sandbox; tanpa kuwi, kode sing mbebayani bisa ngeksfiltrasi data saka mesin menyang Internet. Amarga kita pengin ngindhari syarat peningkatan hak akses, opsi kita winates kanggo mblokir lalu lintas jaringan kanthi kuat. Alat sing arep digunakake, kaya Windows Firewall, umumé ora bisa diinstal tanpa idin admin.

Tanpa Windows Firewall minangka pilihan, kita mbatesi apa wae sing bisa kita kontrol. Kita nyoba nggawe lingkungan anak dadi gagal-tutup kanggo jinis alat berjaringan sing pancen digunakake para developer, supaya perintah Git, installer paket, lsp., bakal gagal ing sandbox lan pangguna kudu nyetujoni operasi apa wae sing ngakses internet. Gagasané yaiku ngracuni jalur uwal sing ketok jelas: ngirim lalu lintas sing ngerti proxy menyang endpoint sing mati, nggawe transport HTTP(S)-é Git nindakake perkara sing padha, lan nggawe Git liwat SSH langsung gagal. Kajaba kuwi, kita nambahake direktori denybin cilik ing ngarep PATH lan ngatur ulang PATHEXT supaya skrip stub SSH lan SCP ditemokake luwih dhisik tinimbang binari asli.

Contone, iki sawetara pangaturan lingkungan tartamtu sing digunakake kanggo matesi 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

Iku nangkep akèh trafik normal sing didorong déning piranti, nanging sifaté isih mung saran. Sawijining proses bisa nglirwakaké lingkungan, ngliwati PATH, utawa mung mbukak soket langsung—kebacut berisiko.

Kaya dene implementasi piranti lunak sing narik kawigaten, prototipe pisanan nduwèni sawetara kaluwihan lan kekurangan. Sanajan bisa ngrampungaké tugasé kanthi mung sawetara kapabilitas Windows standar, ngidini panulisan filesystem sing eksplisit banget lan granular, lan mlaku tanpa ditingkataké—saéngga nyuda kabutuhan pangguna kanggo nampa parintah elevasi sing kakehan utawa dadi admin ing mesin lokalé—solusi iki nduwèni sawetara kekurangan nyata, sawetara saka kekurangan kasebut ndadèkaké solusi iki ora layak dadi desain final kita:

• Kacepetan persiyapan: Nerapake ACL ruang kerja bisa mbutuhake sumber daya gedhe gumantung marang topologi direktori ruang kerja.
• Jejak: Kita ngetrapake ACL nyata menyang sistem pangembang, sanajan jejaké ora pati invasif amarga kabeh ACL sing ditrapake gegayutan karo SID sintetis sing digawe khusus lan mung digunakake dening sandbox.
• Semantik sing angel diowahi: Gumantung marang ACL kanggo watesan adhedhasar file tegese ngganti semantik sandbox iku larang lan rumit. Dene ing macOS, kita bisa ngowahi kanthi dinamis carane kita ngasilake .sbpl. File sing digunakake kanggo ngonfigurasi Seatbelt, sandbox Windows bisa mbutuhake operasi sing alon lan intensif kanggo nyetel ACLs.
• Perlindungan jaringan lemah. Kaya sing wis disebutake sadurunge, iku “saran saja,” mesthi bakal diakali dening sawetara program sing ngetrapake stack jaringan dhewe, lan ora dirancang supaya tahan ngadhepi kode sing sengaja nyerang.

Telung masalah sing kapisan iku melekat ing implementasi sandbox kustom sing cukup fleksibel kanggo alur agen. Nanging, crita babagan supresi jaringan kuwi béda.

Saliyane agen mbebayani bisa kanthi gampang ngliwati penekanan jaringan adhedhasar lingkungan, akeh kode/binari sing niaté apik uga bakal ngliwati iku mung amarga ora manut marang variabel proksi lingkungan, utawa amarga ngetrapaké kode jaringan adhedhasar socket dhéwé. Kita rumangsa manawa aspek iki wis cukup kanggo nimbang nandur modal ing mode sandbox sing luwih apik.

Kanggo entuk penekanan jaringan sing luwih apik, kita pengin nggunakake Windows Firewall, sing ngidini kita mblokir lalu lintas jaringan metu kanggo pangguna utawa program. Sayangé, kita ora bisa kanthi efektif nggawe aturan firewall fungsional sing mung ditrapake kanggo perintah sing diluncurake dening harness Codex amarga sawetara alasan:

• Windows ora ngidini aturan firewall dicocogake karo identitas non-prinsipal saka token sing diwatesi. Iki tegese kita ora bisa nerapake aturan firewall marang “token apa wae sing ngemot SID sintetis kita ing dhaptar SID sing diwatesi."
• Sanajan kita bisa nggawe aturan firewall sing cocog karo binari tartamtu, aturan kasebut mung ngidini kita mbatesi akses jaringan kanggo codex.exe dhewe. Iki ora bakal ditrapake kanggo proses sing diwiwiti agen atas jeneng pangguna, kayata proses Git utawa Python.
• Dimensi pencocokan firewall liyane uga wujudé salah. Aturan kanthi cakupan pangguna isih cocog karo pangguna Windows sing nyata ing desain sing ora ditingkataké, ora mung karo proses anak sing diwatesi. Aturan jalur program kakehan umum: aturan kasebut bisa mblokir codex.exe utawa python.exe sacara umum, nanging ora bisa mblokir siji pemanggilan python.exe iki sing diisolasi ing sandbox. Aturan adhedhasar port utawa alamat uga pancen kabijakan sing salah. Contoné, kita ora pengin mblokir port 443; kita pengin mblokir akses outbound sembarang kanggo wit proses terbatas tartamtu iki.

Kanggo ngetrapake aturan firewall khusus kanggo perintah kita sing diisolasi, kita perlu mbukak perintah kasebut minangka entitas sing kapisah, dudu minangka pangguna “asli”. Pendekatan iki nggawa kita menyang dalan anyar, yaiku dalan sing nggawe kita ngendhori watesan “tanpa elevasi”.

Iterasi sabanjuré saka sandbox, yaiku implementasi saiki kita, mbutuhake idin admin sing ditingkataké nalika persiyapan. Mula, aku nyebut iki minangka “sandbox sing ditingkataké.” Ing wates nalika Codex miwiti perintah ing sistem, sandbox sing ditingkataké katon kaya sandbox sing ora ditingkataké. Iki isih mbukak proses anak nganggo token sing diwatesi—padha karo token write_restricted kanthi dhaptar SID sing diwatesi padha yaiku [Kabeh wong, Logon, Sintetis]—nanging, prinsipal saka token iki saiki dudu maneh pangguna Windows sing nyata, nanging salah siji saka loro pangguna lokal sing digawe dening Codex dhewe:

• CodexSandboxOffline (sing dituju dening aturan firewall)
• CodexSandboxOnline (sing ora ditargetake dening aturan firewall)

Rincian iki sing katon cilik sejatine nduweni implikasi gedhe kanggo sandbox, sapa wae sing bisa nggunakake, lan kerumitan persiyapan lan eksekusi runtime.

Sacara visual, iki mirip karo prototipe sing ora ditingkataké, kanthi ditambahake aturan firewall lan pangguna Windows khusus sing sejatine nglakokake perintah-perintah kasebut. (Nanging, ditepangaké konsep-konsep anyar iki tegesé ana luwih akeh tugas penyiapan sing kudu ditindakake sadurunge sandbox bisa wiwit mlaku lan nglindhungi perintah.)

Desain sandbox sing ora ditingkataké nduwèni langkah persiyapan sing prasaja, nanging ukurane relatif cilik:

• Gawe SID sintetis yen dibutuhake
• Terapake ACL kanggo SID sintetis sandbox-write

Nanging, sandbox sing ditingkataké nduwèni luwih akèh sing kudu ditindakake.

• Gawe SID sintetis, yen durung digawe
• Gawe pangguna sandbox online lan offline, yen durung digawe
• Simpen kredensial pangguna sing mentas digawe sacara lokal lan enkripsi nganggo Windows Data Protection API (DPAPI) ing panggonan sing ora bisa diwaca dening pangguna sandbox
• Gawe aturan firewall sing mblokir kabeh akses jaringan outbound kanggo pangguna CodexSandboxOffline utawa, yen aturan kasebut wis ana, validasi manawa aturan kasebut wis bener

Ana keruwetan tambahan ing tahap persiapan. Sandbox Codex diarepake nduweni akses maca sing padha karo pangguna Windows sing nyata. Ing sandbox sing ora ditingkataké, ing ngendi SID principal saka token sing diwatesi yaiku pangguna Windows, iki bisa digayuh. Nanging, kuwi ora bisa dipikolehi kanthi gratis nalika prinsipal dadi pangguna CodexSandbox anyar. Akeh direktori relevan ing Windows bakal menehi idin maca/eksekusi marang “Pangguna sing Diotentikasi”. Salah siji conto sing misuwur yaiku direktori profil pangguna. Kanthi gawan, panganggo Windows ora bisa maca direktori profil panganggo Windows liyané, mula sanajan maca file sing prasaja ing akèh skenario bakal gagal.

Kanggo ngatasi iki, kita nambahake lapisan liyane menyang proses persiyapan sandbox—yaiku kanggo menehi ACL waca marang pangguna sandbox ing panggonan sing ACL kaya mangkono bisa uga durung ana. Contone, kanggo sawetara direktori Windows sing umum digunakake:

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

Amarga dhaptar direktori iki sifaté usaha paling apik lan masang ACL ing saben direktori bisa mbutuhake sumber daya gedhé, kita nglakokake logika iki kanthi asinkron supaya langkah persiyapan sandbox, sing ngalangi pangguna, ora kudu ngenteni proses kasebut rampung.

Kita ngenkapsulasi logika setup ing binar dhéwé, sebagian supaya bisa ngliwati wates UAC mung yen perlu. Nanging alesan sing luwih jero iku arsitektural: setelan sandbox nduwé tugas sing dhasaré beda karo codex.exe. Njaga logika persiyapan sandbox ing binari khusus ndadekake codex.exe tetep dadi harness normal sing ora ditingkataké; nyegah mekanisme persiyapan khusus Windows supaya ora nggawe codex.exe kakehan muatan ing platform liya; misahake gaweyan persiyapan sing mlaku luwih suwe saka umur proses utama; lan menehi kita siji papan kanggo nangani macem-macem alur persiyapan sing dibutuhake sandbox.

Amarga cara kerja watesan login pangguna lan token ing Windows, kita ora bisa nerusake nggawe token sing diwatesi lan miwiti proses nganggo token kasebut kaya sing bisa ditindakake karo sandbox sing ora ditingkataké. Kanggo bener-bener nglakokake perintah minangka pangguna Windows sing beda, gagasan kapisan kita yaiku alur kaya ing ngisor iki:

• codex.exe mlaku minangka pangguna Windows sing nyata. Banjur, ing sawijining urutan, Codex:
  • Manggil LogonUserW(...) kanggo pangguna sandbox.
  • Manggil CreateRestrictedToken(...) ing token pangguna sandbox kasebut.
  • Nggunakake token pangguna sandbox sing diwatesi kasebut, nelpon CreateProcessAsUserW(...) kanggo ngluncurake proses anak pungkasan.

Ing praktiké, alur sing dikarepake kuwi ora bisa mlaku amarga ana alangan hak istimewa ing CreateProcessAsUserW(...). Iki tegese codex.exe bisa nggawe token sing diwatesi kanggo pangguna sandbox, nanging ora bisa kanthi andal ngluncurake proses anak nganggo token kasebut saka sisih pangguna nyata ing wates kasebut. Kita mbutuhake proses sing wis mlaku minangka pangguna sandbox—iki bakal ngidini langkah pambatesan lan spawn pungkasan kedadeyan ing sisih pangguna sandbox saka wates kasebut, dudu ing sisih pangguna nyata.

Kebutuhan kuwi nyebabaké anané codex-command-runner.exe, binari anyar sing tugasé mung nggawe token sing diwatesi lan ngluncuraké perintah sing dijaluk. Tinimbang njaluk codex.exe nindakake kabeh alur kasebut dhewe (pangguna nyata → pangguna sandbox → token sing diwatesi → proses anak), kita mbagi alur kasebut dadi loro:

Bagean 1

• codex.exe nelpon CreateProcessWithLogonW(...) kanggo ngluncurake codex-command-runner.exe minangka pangguna sandbox, tanpa nggunakake token sing diwatesi dhisik.

Bagean 2

• Ing njero runner, OpenProcessToken(GetCurrentProcess(), ...) mbukak tokené runner dhéwé, sing wis dadi duwèké pangguna sandbox.
• Runner kasebut nelpon GetTokenInformation(...) kanggo ngekstrak SID logon sandbox, banjur CreateRestrictedToken(...) kanggo mbangun token diwatesi pungkasan.
• Isih ing njero runner, iki nyeluk CreateProcessAsUserW(...) nganggo token sing diwatesi kanggo ngluncurake proses anak sing nyata.

Albert Einstein ngendika, 'Kabeh kudu digawe sesederhana mungkin, nanging ora luwih sederhana saka iku.' Selaras karo semangat kuwi, desain kita wis ngrampungake saben masalah kanthi becik. Arsitektur final iki nduwèni patang lapisan sing wis kita bahas sadurungé:

• codex.exe kuwi dhewe
• codex-windows-sandbox-setup.exe kanggo nangani kabeh pakaryan sing gegandhengan karo persiyapan sing ditingkataké
• codex-command-runner.exe kanggo nglakokaké perintah token sing diwatesi
• Proses turunan

Nalika aku sepisanan miwiti nggarap proyek iki, aku durung nduwèni gambaran sing cetha bakal kaya apa pungkasane. Pendekatanku yaiku miwiti kanthi nambahake instrumentasi marang kemampuan isolasi sandbox ing wates antarane Codex lan sistem operasi. Pendekatan iki meh padha banget karo cara sandbox Codex diimplementasikake ing macOS lan Linux.

Nalika aku sinau luwih akeh babagan alat tartamtu sing disedhiyakake Windows, lan liwat puluhan keputusan kanggo ngimbangi keamanan lan kemudahan panggunaan, sistem kasebut berkembang dadi wujud saiki—pirang-pirang binari, pangguna khusus, aturan firewall, langkah persiyapan sing ditingkataké, proses asinkron, lan liya-liyane.

Sistem iki ora kalebu sistem sing prasaja banget, nanging saben unsur kerumitan ditambahake amarga kabutuhan, kanggo mbangun sandbox sing aman lan, sabisa-bisane, ora ngganggu pangguna.

Sajrone ngupaya nyedhiyakake pengalaman pangguna sing apik kanggo pangguna Codex ing Windows, tujuan kita yaiku nggawe solusi sing aman tanpa ngorbanake kagunaane—amarga inti saka nggunakake Codex yaiku supaya agen bisa nindakake pakaryan tanpa perlu terus-terusan njenengan gatekake.

Salah siji piwulang paling gedhé saka proyek iki yaiku Windows ora nyedhiyakake siji primitif sing kanthi mulus cocog karo “agen ngoding otonom sing aman.” Kita nyusun sawetara piranti lan konsep kanggo mbangun sawijining perkara sing koheren. Sawetara gagasan awal mau jebul buntu. Desain pungkasan kuwi gabungan saka prototipe-prototipe sadurungé sing saben-saben ngrampungaké sapérangan saka masalah kasebut.

Piwulang liyane yaiku manawa keamanan kanggo agen coding kuwi tantangan sing beda tinimbang keamanan aplikasi sing luwih klasik. Codex kudu bisa digunakake kanggo alur kerja nyata para pangembang. Karya rekayasa kasebut yaiku babagan ngimbangi antarane kompatibilitas karo beban kerja agentic lan panegakan nyata. Ketegangan kuwi mbentuk kompromi ing desain pungkasan.

Penasaran pengin ndeleng cara kerjane sandbox Codex? Coba saiki⁠.