Turvalise ja tõhusa liivakasti loomine Codexi jaoks Windowsis

Kui liitusin 2025. aasta septembris Codexi insenerimeeskonnaga, puudus Windowsi Codexil liivakasti teostus, mis tähendas, et Windowsi kasutajad pidid OpenAI kodeerimisagentide kasutamisel valima kahe kehva variandi vahel:

1. peaaegu iga käsu (isegi lugemised) kinnitamine, mida kodeerimisagent käivitada soovis, mis on ebatõhus ja tüütu. Codexi kasutamise suur eelis on see, et sa ei pea kogu tüütut tööd ise tegema;
2. täisjuurdepääsu režiimi lubamine: lasta Codexil käivitada kõik käsud ilma kinnituse või piiranguteta, mis vähendab hõõrdumist järelevalve arvelt.

Meie kodeerimisagent Codex⁠ töötab arendajate sülearvutites — olgu selleks CLI, IDE laienduse või töölauarakenduse kaudu. See haldab vestlust klaviatuuri taga oleva inimese ja pilves töötava mudeli vahel, mis tegeleb järeldamisega.

Codex töötab vaikimisi päris kasutaja õigustega, mis tähendab, et see saab teha kõike, mida kasutaja saab teha. See on võimas ja potentsiaalselt ohtlik. Kodeerimismudel võib käskida juhtprogrammil kohalikke käske käivitada, alates testide käivitamisest kuni faili lugemise või muutmiseni või Git-haru loomiseni, seega püüab Codexi vaikerežiim leida õige tasakaalu tõhususe ja turvalisuse vahel. See vaikerežiim lubab Codexil lugeda faile peaaegu kõikjal ja kirjutada faile sinu tööjaamas (st kataloogis, kus sa Codexit käitad), ilma internetiühenduseta, välja arvatud juhul, kui sa ütled, et seda soovid. Et saavutada see failidesse kirjutamise ja võrgule juurdepääsu automaatne piiramine ohututes piirides, vajab Codex liivakastikeskkonda, mis neid piiranguid päriselt jõustab.

Liivakast on piiratud käituskeskkond. Kui arendaja kasutab Codexit, käivitab tema arvuti operatsioonisüsteem käsu vähendatud õigustega ja need piirangud kanduvad edasi protsessipuud pidi allapoole. Iga Codexi käsk pannakse algusest peale liivakasti ja iga alamprotsess jääb sama piiri sisse.

Tõhusa liivakasti rakendamiseks vajab Codex eraldusfunktsioone, mida jõustab arvuti operatsioonisüsteem. Mõned operatsioonisüsteemid pakuvad selleks häid utiliite (nt Seatbelt MacOs-is, seccomp või bubblewrap Linuxis); Windows aga ei paku praegu seda tüüpi kasutusvalmis võimekust.

Et muuta Codex Windowsis sama turvaliseks ja meeldivaks kasutada nagu mujalgi, pidime rakendama omaenda liivakasti.

Windows pakub mõningaid tööriistu ja alusmehhanisme isoleerimiseks. Kuigi ükski neist ei vastanud päriselt meie nõuetele, vaatasime läbi mitu võimalikku lahendust — nimelt AppContaineri, Windows Sandboxi ja kohustusliku tervikluse kontrolli märgistuse.

AppContainer

• Mis see on: AppContainer on Windowsi natiivne liivakast, võimekuspõhine mudel, mis on loodud rakendustele, mis teavad juba ette täpselt, millele neil on vaja ligi pääseda.
• Miks: ahvatlev, sest pakub päris OS-i piiri, mitte parima pingutuse piiranguid.
• Miks mitte: Codex ei ole üks kitsalt piiritletud rakendus. See juhib avatud lõpuga arendajatöövooge: shellid, Git, Python, paketihaldurid, ehitustööriistad ja kõik muud binaarid, mida agent otsustab vajada. Praktikas tähendas see, et AppContainer oli selle probleemi jaoks vale kujuga. See oli tugev isolatsioon, kuid palju kitsama töökoormuste klassi jaoks kui „lase agendil tegutseda nagu arendaja“.

Windows Sandbox

• Mis: Windows Sandbox on Microsofti ühekordseks kasutamiseks mõeldud kerge virtuaalmasin. Sa saad värske Windowsi töölaua tugeva isolatsioonipiiriga ning kõik, mida selle sees teed, kaob seansi lõpus.
• Miks: huvitav ilmselgetel põhjustel — suvalise tarkvaraga palju paremini ühilduv kui AppContainer ja turvalisuse vaates palju tugevam kast.
• Miks mitte: Codex peab tegutsema otse kasutaja tegeliku checkouti, tööriistade ja keskkonna peal, mitte eraldi ühekordses töölauas, mis vajaks seadistust ja hosti/külalise sildamist. Sellel oli ka põhimõtteline tootemure: Windows Sandbox pole Windows Home’i SKU-des üldse saadaval.

Mandatory Integrity Control (MIC) tervikluse märgistus

• Mis: Windowsis on mõiste „terviklustasemed“, näiteks madal, keskmine ja kõrge, mis määravad, kui palju süsteem objekte ja protsesse usaldab. Põhireegel on, et madalama terviklusega protsess ei saa kirjutada kõrgema terviklusetasemega objekti, isegi kui tavaline ACL seda muidu lubaks. Näiteks käsitletakse madala terviklusega protsessi vähem usaldusväärsena, seega blokeerib Windows sellel kirjutamise tavalistele keskmise terviklusega objektidele, kui neid objekte pole selleks sõnaselgelt ümber märgistatud.
• Miks: MIC nägi paberil elegantne välja — käivita Codex madala terviklusega, märgista kirjutatavad juured madala terviklusega ümber ja lase Windowsil mujal kirjutamiskeelu jõustada. See oleks andnud meile mitteadministraatori tee koos päris OS-i mehhanismiga selle taga.
• Miks mitte: nagu ACL-id, muudavad ka tervikluse märgised päris hostfailisüsteemi ja selles juhtumis on semantiline muudatus eriti lai. Tööjaama märkimine madala terviklusega ei tähenda ainult „Codex saab siia kirjutada“. See tähendab, et madala terviklusega protsessid saavad üldiselt sinna kirjutada. Päris arendaja masinas muudab see kasutaja tegeliku checkouti hosti jaoks madala terviklusega neeluks, mis on palju riskantsem kui hoolikalt sihitud ACL-ide andmine ühele liivakasti lahendusele. Isegi kui keskmise terviklusega arendajatööriistad edasi töötavad, on tööjaama aluseks olev usaldusmudel muutunud viisil, mida on raske ohjata ja veel raskem põhjendada.

Olles hinnanud kõik variandid sobimatuks, hakkasime kavandama oma lahendust, et tuua Windowsi kasutajateni hea Codexi kasutuskogemus.

Meie esimene töötav prototüüp kasutas vajaliku isoleerimise rakendamiseks Windowsi kontseptsioonide ja tööriistade kombinatsiooni. Algusest peale oli üks eesmärk teha see nii, et kõrgendatud õigusi poleks vaja, mis tähendas, et Codex ei peaks liivakasti seadistamiseks või käitamiseks küsima kasutajalt administraatoriõigusi. See tähendas välja mõtlemist, kuidas panna mõistlikud piirid kahele asjale: failidesse kirjutamisele ja võrgule juurdepääsule.

Kui me ei piiraks failidesse kirjutamist üldse, tekiks turvarisk. Kui piiraksime seda liiga palju, kahjustaks liivakast kasutaja tootlikkust, sest pidevalt tuleks kinnitust küsida. Selle probleemi lahendamiseks toetusime kahele tähtsale Windowsi ehitusplokile: SID-id ja kirjutamispiiranguga tokenid.

SID ehk turbeidentifikaator on identiteet, mille külge Windows õigused seob. Igal kasutajal on SID, rühmadel on SID-id ja isegi ühel sisselogimisseansil on oma SID. Näiteks võib praegusel sisselogitud seansil olla SID nagu S-1-5-5-X-Y. Kohalike administraatorite rühmale määratud SID võib olla S-1-5-32-544.

Windows võimaldab luua ka sünteetilisi SID-e, mis ei vasta päris kasutajale, kuid võivad siiski ilmuda ACL-ides (juurdepääsukontrolli loendites), mis määravad, kes saab konkreetseid faile või katalooge lugeda/kirjutada/täita. See teeb SID-id meie liivakasti jaoks kasulikuks alusmehhanismiks: saame luua SID-id üksnes Codexi liivakasti jaoks, ilma et segaksime midagi muud masinas.

Protsessitokenid on Windowsi turbeobjektid, mis määravad töötava protsessi identiteedi ja õigused. Need määravad, milliseid toiminguid protsess saab teha. Kirjutuspiiranguga token on eriline protsessitokeni tüüp, mis paneb Windowsi kirjutamistoimingute korral tegema täiendava juurdepääsukontrolli.

Selleks et kirjutamine õnnestuks, tuleb läbida kaks kontrolli:

1. Tavaline kasutajaidentiteet (tokeni „omanik“) peab seda lubama
2. Vähemalt ühele tokeni piiratud SID-ide loendi SID-ile peab samuti juurdepääs olema antud

Praktikas võimaldasid need kontrollid meil kasutada ACL-e selleks, et määrata täpselt, kus liivakast sai failisüsteemi muuta, mis andis meile kirjutamistoimingute ümber vajaliku detailsuse.

SID-ide ja kirjutamispiiranguga tokenitega töötas meie kõrgendamata liivakast nii:

1. Liivakasti seadistus lõi sünteetilise SID-i nimega sandbox-write.
2. sandbox-write SID-ile anti kirjutus-, käivitus- ja kustutusõigus
   1. Praegune töökataloog
   2. Kõik täiendavad writable_roots, mis on seadistatud failis config.toml.
3. Liivakasti seadistus keelas sõnaselgelt sellel samal SID-il kirjutamisõiguse „kirjutatava sees kirjutuskaitstud“ asukohtadesse, näiteks:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex käivitas käsud kirjutamispiiranguga tokeni all, mille piiratud SID-ide loend sisaldab Everyone, praeguse sisselogitud seansi SID-i ja sünteetilist SID-i sandbox-write.

See voog lahendas failidesse kirjutamise piiramise tõhusalt ja tundus paljulubav. Nüüd vajasime lahendust liivakasti võrgule juurdepääsu piiramiseks.

Võrgule juurdepääsu piiramine on liivakasti oluline osa; ilma selleta võiks pahatahtlik kood masinast andmeid internetti välja viia. Kuna tahtsime vältida kõrgendatud õiguste nõuet, olid meil tugevaks võrguliikluse blokeerimiseks piiratud võimalused. Tööriistu, mida oleksime tahtnud kasutada, näiteks Windows Firewalli, ei saanud üldjuhul ilma administraatoriõigusteta paigaldada.

Kuna Windows Firewall ei olnud valik, oli kontrollitav piiratud. Püüdsime panna alamkeskkonna arendajate tegelikult kasutatavate võrgutööriistade jaoks vaikimisi tõrkuma nii, et Giti käsud, paketipaigaldajad jne liivakastis ebaõnnestuksid ja kasutaja peaks iga internetti suunduva toimingu kinnitama. Mõte oli mürgitada ilmsed väljapääsud: saata proksiteadlik liiklus surnud lõpp-punkti, panna sama tegema Giti HTTP(S)-transport ja panna Git üle SSH kohe ebaõnnestuma. Lisaks sellele lisasime PATH-i ette väikese väikese denybin-kataloogi PATH-i ja muutsime PATHEXT -i järjestust, et SSH ja SCP stub-skriptid lahenduksid enne tegelikke binaarfaile.

Näiteks siin on mõned konkreetsed keskkonnaülekirjutused, mida kasutasime võrgule juurdepääsu piiramiseks:

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

See püüdis kinni palju tavalist tööriistapõhist liiklust, kuid oli siiski ainult soovituslik. Protsess võis keskkonda ignoreerida, PATH-ist mööda minna või lihtsalt otse sokleid avada — liiga riskantne.

Nagu iga huvitava tarkvarateostuse puhul, oli ka esimesel prototüübil plusse ja miinuseid. Kuigi see tegi töö ära vaid mõne standardse Windowsi võimekusega, võimaldas väga selgeid ja detailseid failisüsteemi kirjutusi ning töötas kõrgendatud õigusteta — vähendades vajadust, et kasutajad peaksid nõustuma liigsete kõrgendamise hüpetega või olema oma kohalikus masinas administraatorid — oli sellel liiga palju puudusi, et olla meie lõplik lahendus:

• Seadistamise kiirus: tööjaama ACL-ide rakendamine võib sõltuvalt tööjaama kataloogi topoloogiast olla kulukas.
• Jälg: rakendasime päris ACL-id arendaja süsteemile, kuigi jalajälg pole eriti pealetükkiv, sest kõik rakendatud ACL-id puudutavad kohandatud sünteetilist SID-i, mida kasutab ainult liivakast.
• Raskesti muudetav semantika: tuginemine ACL-idele failipõhiste piirangute puhul tähendab, et liivakasti semantika muutmine on kulukas ja keerukas. Kui macOS-is saame dünaamiliselt muuta, kuidas genereerime Seatbelti seadistamiseks kasutatavat .sbpl- faili, siis Windowsi liivakast võib ACL-ide kohandamiseks nõuda aeglast ja rasket operatsiooni.
• Võrgukaitse on nõrk. Nagu varem mainitud, oli see „soovituslik“, mõned programmid, mis rakendasid oma võrgupinu, oleksid sellest kindlasti mööda läinud, ja see polnud mõeldud vastu pidama vastandlikule koodile.

Esimesed kolm probleemi on omased kohandatud liivakastiteostusele, mis on agentsete voogude jaoks piisavalt paindlik. Võrgu mahasurumise lugu oli aga teistsugune.

Lisaks sellele, et pahatahtlik agent saaks keskkonnapõhisest võrgu mahasurumisest kergesti mööda minna, läheksid sellest mööda ka paljud heatahtlikud koodid/binaarid lihtsalt siis, kui nad ei austaks keskkonna proksimuutujaid või rakendaksid omaenda soklipõhist võrgukoodi. Leidsime, et sellest aspektist piisab, et investeerida paremasse liivakastirežiimi.

Parema võrgu mahasurumise saavutamiseks tahtsime kasutada Windows Firewalli, mis võimaldab meil kasutajate või programmide jaoks väljaminevat võrguliiklust blokeerida. Kahjuks ei saanud me mõnel põhjusel tõhusalt luua toimivat tulemüürireeglit, mis kehtiks ainult Codexi juhtprogrammi käivitatud käskudele:

• Windows ei luba tulemüürireeglit sobitada piiratud tokeni mitte-peamise identiteediga. See tähendab, et me ei saanud rakendada tulemüürireeglit „mis tahes tokenile, mille piiratud SID-ide loendis on meie sünteetiline SID“.
• Kuigi saaksime luua kindla binaariga sobituva tulemüürireegli, võimaldaks see piirata võrguühendusi ainult codex.exe-le endale. See ei kehtiks protsessidele, mida agent kasutaja nimel käivitab, näiteks Giti või Pythoni protsessidele.
• Ka teised tulemüüri sobitusmõõtmed olid vale kujuga. Kasutajapõhised reeglid sobitusid kõrgendamata lahenduses endiselt päris Windowsi kasutajaga, mitte ainult piiratud alamprotsessiga. Programmitee reeglid olid liiga jämedakoelised: need võisid blokeerida: codex.exe või python.exe, kuid mitte seda konkreetset python.exe liivakastis käivitust. Ka pordi- või aadressipõhised reeglid olid täiesti vale poliitika. Näiteks ei tahtnud me blokeerida porti 443; tahtsime blokeerida suvalise väljamineva juurdepääsu selle konkreetse piiratud protsessipuu jaoks.

Selleks et rakendada tulemüürireegel just meie liivakastitud käskudele, pidime need käivitama eraldi printsipaali, mitte „päris“ kasutajana. See lähenemine viis meid uuele rajale, kus lõdvendasime oma „ilma kõrgendamiseta“ piirangut.

Liivakasti järgmine iteratsioon, mis on meie praegune teostus, nõuab seadistamise ajal kõrgendatud administraatoriõigusi. Seetõttu nimetan seda „kõrgendatud õigustega liivakastiks“. Piiril, kus Codex käivitab süsteemis käsu, paistab kõrgendatud õigustega liivakast samasugune nagu kõrgendamata õigustega liivakast. See käitab alamprotsesse endiselt piiratud tokeni all — samamoodi write_restricted tokeniga, millel on sama piiratud SID-loend [Everyone, Logon, Synthetic]— kuid selle tokeni turbesubjekt ei ole enam tegelik Windowsi kasutaja, vaid üks kahest kohalikust kasutajast, mille Codex ise loob:

• CodexSandboxOffline (see, millele tulemüürireeglid sihivad)
• CodexSandboxOnline (see, millele tulemüürireeglid ei sihi)

See pealtnäha väike detail mõjutab tegelikult oluliselt liivakasti, seda, kes seda kasutada saab, ning selle seadistamise ja käitusaja teostuse keerukust.

See on visuaalselt sarnane kõrgendamata prototüübiga, kuid lisanduvad tulemüürireeglid ja spetsiaalne Windowsi kasutaja, kes käske tegelikult käivitab. (Nende uute mõistete lisandumine tähendab aga, et enne kui liivakast saab hakata käske käivitama ja kaitsma, tuleb teha rohkem seadistustööd.)

Kõrgendamata liivakasti lahendusel oli lihtne seadistusetapp, kuid see oli suhteliselt väike:

• Loo vajaduse korral sünteetiline SID
• Rakenda ACL-id sünteetilisele SID-ile sandbox-write

Kõrgendatud liivakastil on aga rohkem teha.

• Loo sünteetiline SID, kui seda pole juba loodud
• Loo võrguühendusega ja võrguühenduseta liivakastikasutajad, kui neid pole juba loodud
• Salvesta äsjaloodud kasutajate mandaadid lokaalselt ja krüpti need Windowsi Data Protection API (DPAPI) abil kohta, mida liivakastikasutajad tegelikult lugeda ei saa
• Loo tulemüürireeglid, mis blokeerivad kasutaja CodexSandboxOffline jaoks kogu väljamineva võrguliikluse, või kui need on juba olemas, valideeri, et need on õiged

Seadistusetapis on veel üks nüanss. Codexi liivakastilt oodatakse lugemisjuurdepääsu, mis vastab tegelikule Windowsi kasutajale. Kõrgendamata liivakastis, kus piiratud tokeni printsipaal-SID oli Windowsi kasutaja, see saavutati. Kuid see ei tule tasuta, kui printsipaalist saab uus CodexSandbox i kasutaja. Paljud asjakohased Windowsi kataloogid annavad lugemis-/täitmisõigused „Authenticated Users“-ile. Üks märkimisväärne näide on kasutaja profiilikataloog. Vaikimisi ei saa Windowsi kasutajad lugeda teiste Windowsi kasutajate profiilikatalooge, nii et isegi lihtsad faililugemised ebaõnnestuksid paljudes olukordades.

elle lahendamiseks lisasime liivakasti seadistusprotsessile veel ühe kihi — sellise, mis annab liivakastikasutajatele lugemis-ACL-id seal, kus selliseid ACL-e veel ei pruugi olla. Näiteks mõnele tavaliselt kasutatavale Windowsi kataloogile:

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

Kuna see kataloogide loend on parima pingutuse põhine ja ACL-ide paigaldamine igale neist võib olla üsna kulukas, käitame seda loogikat asünkroonselt, et liivakasti seadistusetapp, mis kasutajate jaoks blokeeriv on, ei peaks ootama nende valmimist.

Kapseldasime seadistusloogika omaette binaari osaliselt selleks, et ületada UAC-piir ainult siis, kui vaja. Ent sügavam põhjus oli arhitektuuriline: liivakasti seadistusel on codex.exe-ga võrreldes põhimõtteliselt erinev ülesanne. Liivakasti seadistusloogika hoidmine eraldi binaaris võimaldas codex.exe-l jääda tavaliseks, kõrgendamata juhtprogrammiks; hoidis Windowsi-põhise seadistusmasina teistel platvormidel codex.exe-d paisutamast; lahutas pikemalt kestva seadistustöö põhiprotsessi elueast; ja andis meile ühe koha, kus käsitleda erinevaid seadistusteid, mida liivakast vajas.

Kuna Windowsi kasutajate ja tokenite sisselogimispiirid töötavad nii, nagu nad töötavad, ei saanud me enam jätkata piiratud tokeni loomist ja selle all protsessi käivitamist nii, nagu saime kõrgendamata liivakastiga. Et käivitada käske tegelikult teise Windowsi kasutajana, oli meie esimene mõte järgmine voog:

• codex.exe töötab tegeliku Windowsi kasutajana. Seejärel, järjekorras, Codex:
  • kutsub liivakasti kasutaja jaoks välja LogonUserW(...).
  • Kutsub sellel liivakasti kasutaja tokenil välja CreateRestrictedToken(...).
  • Kasutades seda piiratud liivakastikasutaja tokenit, kutsub välja CreateProcessAsUserW(...), et käivitada lõplik alamprotsess.

Praktikas see soovitud voog ei toiminud, sest CreateProcessAsUserW(...) juures tekkis õiguste barjäär. See tähendab, et codex.exe sai luua liivakasti kasutaja jaoks piiratud tokeni, kuid ei suutnud selle tokeniga päris kasutaja poolelt usaldusväärselt alamprotsessi käivitada. Vajasime protsessi, mis juba töötaks liivakasti kasutajana — see võimaldaks piirangute sammu ja lõpliku käivitamise teha piiri liivakasti kasutaja poolel, mitte päris kasutaja poolel.

See nõue viis codex-command-runner.exe-ni, uue binaarfailini, mille ainus ülesanne on luua piiratud token ja käivitada soovitud käsk. Selle asemel et paluda codex.exe-l kogu voog ise teha (päris kasutaja → liivakasti kasutaja → piiratud token → alamprotsess), jagasime voo kaheks:

1. osa

• codex.exe kutsub CreateProcessWithLogonW(...), et käivitada codex-command-runner.exe liivakasti kasutajana, ilma et veel piiratud tokenit kasutataks.

2. osa

• Käivitaja sees avab OpenProcessToken(GetCurrentProcess(), ...) käivitaja enda tokeni, mis kuulub juba liivakasti kasutajale.
• Käivitaja kutsub GetTokenInformation(...), et saada liivakasti sisselogimis-SID, ja seejärel CreateRestrictedToken(...), et luua lõplik piiratud token.
• Endiselt käivitaja sees kutsub see CreateProcessAsUserW(...) selle piiratud tokeniga, et käivitada päris alamprotsess.

Albert Einstein ütles: „Kõik tuleks teha nii lihtsaks kui võimalik, aga mitte lihtsamaks.“ Sellest vaimust lähtudes lahendas meie lahendus iga probleemi piisavalt hästi. Lõplikul arhitektuuril on neli kihti, mida oleme varem käsitlenud:

• codex.exe ise
• codex-windows-sandbox-setup.exe, mis tegeleb kogu kõrgendatud õigustega seotud seadistustööga
• codex-command-runner.exe, mis käivitab piiratud token käske
• Alamprotsess

Kui ma sellele projektile esimest korda lähenesin, ei olnud mul selget ettekujutust, kuhu see välja jõuab. Alustasin sellega, et instrumenteerisin liivakastimisvõimekuse Codexi ja operatsioonisüsteemi vahelisse piirile. See lähenemine kattub hästi sellega, kuidas Codexi liivakast on teostatud MacOs-is ja Linuxis.

Mida rohkem sain teada konkreetsetest tööriistadest, mida Windows pakub, ja kümnete turvalisust ning kasutusmugavust tasakaalustavate otsuste kaudu, kasvas süsteem oma praegusele kujule — mitu binaari, kohandatud kasutajad, tulemüürireeglid, kõrgendatud õigustega seadistusetapp, asünkroonsed protsessid ja palju muud.

See ei ole eriti lihtne süsteem, kuid iga keerukuse tükk lisati vajadusest, et ehitada liivakast, mis on ühtaegu turvaline ja võimalikult vähe kasutajal jalus.

Püüdes pakkuda Windowsi Codexi kasutajatele head kasutuskogemust, oli meie eesmärk teha midagi turvalist, mis ei teeks järeleandmisi kasulikkuse arvelt — kogu Codexi kasutamise mõte on lasta agentidel tööd teha ilma sinu pideva tähelepanuta.

Üks selle projekti suurimaid õppetunde oli see, et Windows ei andnud meile ühte alusmehhanismi, mis vastaks puhtalt mõistele „turvaline autonoomne kodeerimisagent“. Koostasime mitu tööriista ja mõistet, et ehitada midagi sidusat. Mõned varased ideed osutusid tupikteeks. Lõplik lahendus oli varasemate prototüüpide hübriid, millest igaüks lahendas osa probleemist.

Teine õppetund oli see, et kodeerimisagendi turvalisus on teistsugune loom kui klassikalisem rakendusturvalisus. Codex peab töötama päris arendajate töövoogude jaoks. Inseneritöö seisnes agentsete töökoormustega ühilduvuse ja päris jõustamise tasakaalustamises. See pinge kujundas lõpliku lahenduse kompromisse.

Kas tahad näha Codexi liivakasti töös? Proovi järele⁠.