Mpe Coding Agent VM ya Kutupwa

Kwa nini VM ya kutupwa ni bora kuliko laptop yako

Mpe coding agent VM ya kutupwa, na jambo baya zaidi analoweza kufanya ni kuharibu mashine unayoweza kuijenga upya ndani ya dakika kumi. Agent bado anapata root, bado anasakinisha packages, na bado anaendesha test suite bila kuomba ruhusa kwa kila hatua. Tofauti iko kwenye mahali ambapo uharibifu unatokea. Kwenye laptop, agent anashiriki home directory na SSH keys zako, browser profile yako, files zako za .env na kila repository nyingine ambayo umewahi ku-clone. Kwenye server ya kutupwa, ana shell, checkout, na hakuna kitu kingine chenye thamani ya kuchukuliwa.

Huo ndio msingi wote wa hoja, na hoja hii inahusu kutokulingana kwa madhara, si uwezekano wa kutokea. Agent makini kwenye laptop iliyolindwa kwa uangalifu huwa salama karibu kila mara. Mara moja inaposhindikana, gharama si commit mbaya. Ni kurejesha mfumo kutoka backup, ikiwa unayo.

Bainisha upeo wa uharibifu (blast radius) kabla ya kuujadili

Upeo wa uharibifu unamaanisha seti ya vitu ambavyo mchakato (process) unaweza kuvifikia. Kwa wakala (agent) anayeendesha kama mtumiaji wa kawaida kwenye mashine yako ya kawaida, seti hiyo ni kubwa kuliko vile watu wengi wanavyodhani.

Inajumuisha ~/.ssh/id_ed25519, ambayo kwa kawaida huwa haijasimbwa (unencrypted), kwa sababu ulichoka kuandika passphrase. Inajumuisha ~/.aws/credentials na ~/.config/gh/hosts.yml, ambazo zimeundwa zikiwa katika maandishi ya kawaida (plain text). Inajumuisha kila hazina (repository) iliyo chini ya ~/code, ikiwemo zile zenye connection strings za uzalishaji (production) kwenye faili la env la ndani. Inajumuisha historia ya shell yako, ambayo ina token ulizowahi kubandika (paste) mara moja. Pia inajumuisha mtandao ambao laptop yako imeunganishwa nao, ambao mara nyingi ni mtandao wa nyumbani au ofisini wenye huduma zisizohitaji uthibitisho (unauthenticated).

Hakuna hata moja kati ya hayo inayohitaji wakala mwenye nia mbaya. Inahitaji amri moja tu iliyoandikwa kwa ujasiri lakini ikiwa na makosa. rm -rf "$BUILD_DIR"/* ikiwa na BUILD_DIR haijawekwa, ambayo hupanuka na kuwa /* na kupita kizuizi cha kawaida cha GNU rm cha kutofuta / yenyewe, git clean -xfd katika saraka (directory) isiyo sahihi, docker system prune -af --volumes inayofuta database yako ya ndani, au chmod -R 777 yenye nia njema kwenye saraka ya nyumbani (home directory). Mawakala wamefunzwa kwenye mtandao uleule uliowafundisha watu wengine amri hizo.

Utaratibu unaokuokoa si busara ya wakala. Ni ukweli kwamba mashine inayoweza kupata uharibifu huo ni ile ambayo ulikuwa tayari kuipoteza.

Hesabu ya gharama inachosha, na hilo ndilo jambo muhimu

VPS ndogo hugharimu dola chache kwa mwezi. Kurejesha laptop ya developer huchukua siku moja, na hiyo ndiyo hali nzuri, ambapo unatambua tatizo mara moja na ulikuwa na backup.

Fanya hesabu kwa kutumia nambari zako mwenyewe. Chukua kiwango chako cha malipo kwa saa, kisha zidisha kwa idadi ya saa ambazo zingehitajika kusakinisha upya operating system, kurejesha home directory, kubadilisha SSH key, kubadilisha personal access token na ku-clone tena repositories ishirini. Linganisha gharama hiyo na miezi kumi na miwili ya server ndogo zaidi anayoitoa provider wako. Gharama ya server inakuwa nafuu kabla ya tukio moja kutokea ndani ya miaka kadhaa, na tukio hilo si lazima liwe kubwa sana ili kufikia kiwango hicho. Kupoteza alasiri moja kwa sababu ya local environment iliyoharibika tayari kunatosha kulipia mwaka mzima.

Nusu ya pili ya hesabu inahusu snapshots. Snapshot kabla ya kuendesha kazi yenye hatari hubadilisha hali mbaya kutoka "rejesha kila kitu" kuwa "rudi kwenye hali ya awali na ujaribu prompt tofauti". Chaguo hilo halipo kwenye laptop unayoandikia sasa, kwa sababu huwezi kuunda snapshot ya mashine unayoitumia kama dawati lako.

Mazingira kufikia Oktoba 2026

Kuna majibu matatu ya kweli kwa swali "wakala anapaswa kuendeshwa wapi", na yanahusisha uwiano kati ya mambo mawili: nguvu ya mpaka wa usalama, na kiasi cha usanidi unaokubali.

Micro VM ya ndani. Zana katika kategoria hii huwasha mashine pepe (virtual machine) halisi kwenye maunzi yako, huweka (mount) hazina yako (repository) ndani yake, na kumpa wakala ruhusa ya root ndani. clawk ndiyo mfano wa sasa, na hoja yake kuu ni kama thesis ya chapisho hili: wape mawakala wa uandishi wa msimbo (coding agents) VM ya Linux inayoweza kutupwa, si kompyuta yako ya mkononi. Kufikia Oktoba 2026, inalenga macOS 14 na matoleo mapya zaidi kwenye Apple silicon, ikiwa na usaidizi wa majaribio wa Linux kupitia Firecracker, na inasakinishwa kwa brew install clawkwork/tap/clawk. Unaendesha clawk ndani ya hazina ili kuwasha sandbox na kuunganisha wakala, clawk down ili kuizima, na clawk destroy ili kuiondoa. Mpaka wa usalama ni hypervisor, ambao ni imara. Kikwazo ni kwamba VM huishi kwenye mashine unayobeba, kwa hivyo inashindania kumbukumbu yako na huacha kufanya kazi unapofunga kifuniko cha kompyuta.

Container. Docker ndilo jibu ambalo watu wengi tayari wameshasakinisha, na ni muhimu kweli.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm hutupa container baada ya kutoka na --network none huiondolea mtandao kabisa, jambo ambalo ni chaguo-msingi zuri kwa ajili ya ujenzi (build) au majaribio. Elewa wazi kile ambacho hii haifanyi: container hushiriki kernel ya mwenyeji (host), kwa hivyo hitilafu ya kernel ni njia ya kutoka, na mpaka wa usalama hupotea pindi tu unapoongeza --privileged au kuweka /var/run/docker.sock ili wakala aweze "kutumia Docker". Kuweka Docker socket ndani ya container ni sawa na kuipa container hiyo ruhusa ya root kwenye mwenyeji.

VPS ya kawaida unayoweza kuijenga upya. Hakuna zana mpya, mpaka wa kernel halisi, snapshots za mtoa huduma, na inaendelea kufanya kazi unapozima kompyuta yako. Huu ndio muundo ambao mwongozo huu wote unaelezea, na ndio unaostahimili kazi ndefu za mawakala, kwa sababu kazi inayochukua saa nne haijali kama umekwenda nyumbani.

Muundo wa VPS: mpe wakala mtumiaji wake mwenyewe

Anza na seva iliyoimarishwa. Dakika kumi za kwanza kwenye VPS mpya hushughulikia sehemu zisizohusu wakala pekee: masasisho, login isiyo ya root, SSH ya kutumia funguo pekee, na firewall.

Kisha tengeneza akaunti inayokuwepo kwa ajili ya wakala pekee, ili kosa ndani yake lisiweze kuathiri kitu kingine chochote kwenye seva.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password inamaanisha hakuna nenosiri la kubahatisha, na unafikia akaunti hiyo kwa sudo -u agent au ufunguo wa SSH. Kumbuka kuwa agent kwa makusudi haipo kwenye kundi la sudo. Wakala mwenye sudo ana root, na root anaweza kusoma faili za kila mtumiaji mwingine, kwa hivyo utengano ulioujenga hivi punde ni wa mapambo tu. Ikiwa wakala anahitaji kweli kusakinisha vifurushi, hiyo ni hoja ya kuwa na seva nzima anayomiliki, si kumpa sudo kwenye seva inayoshirikiwa. Kanuni za jumla ziko kwenye upendeleo mdogo kwa watumiaji wa Linux kwenye VPS.

Kagua mpaka kabla ya kuamini. Kama mtumiaji wa agent, jaribu kuorodhesha saraka ya nyumbani ya akaunti yako mwenyewe:

sudo -u agent ls /home/you

Unapaswa kuona ls: cannot open directory '/home/you': Permission denied. Ikiwa unaona orodha ya faili badala yake, saraka yako ya nyumbani inaweza kusomwa na watumiaji wengine, na wakala anaweza kusoma chochote ndani yake ambacho hakijafungwa kando, kama vile faili ya .env inayoweza kusomwa na kila mtu. Rekebisha kwa sudo chmod 700 /home/you. Ufunguo wako wa siri wa SSH si kitu ambacho jaribio hili hulinda: ssh hupuuza faili ya ufunguo wa siri ambayo watumiaji wengine wanaweza kuifikia, kwa hivyo ufunguo wowote unaokufanyia kazi tayari hauwezi kusomwa na agent, bila kujali hali ya saraka yako ya nyumbani.

Weka credentials nje kabisa ya mashine

Lengo la mashine ya muda linapotea ukiinakili secrets za production. Kanuni ni rahisi: hakuna kitu kwenye mashine hiyo kinachopaswa kuwa credential ambayo usingesita kuibadilisha leo alasiri.

Kwa git, forward SSH agent yako badala ya kunakili key. Private key hubaki kwenye laptop yako, na maombi ya sahihi pekee ndiyo hupitia connection.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Command ya pili inapaswa kujibu Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Hilo linathibitisha kwamba git push itafanya kazi bila kuwepo kwa key file kwenye server. Endesha ls -la ~/.ssh kwenye mashine hiyo baadaye, kisha uthibitishe kwamba hakuna private key ndani yake.

Agent forwarding ina tahadhari moja muhimu, kwa hiyo itaje wazi: wakati umeunganishwa, mtu yeyote mwenye root kwenye server hiyo anaweza kutumia socket iliyoforwardiwa kujithibitisha kama wewe. Kwenye server ambayo mtumiaji mwingine pekee ni wewe, huo ni mabadilishano yanayokubalika. Kwenye mashine inayotumiwa na watu wengi, si salama, na deploy key yenye ruhusa kwa repository moja ndiyo chaguo bora. Chaguo hizi zimeelezwa katika Misingi ya usimamizi wa SSH keys.

Kwa API keys, mpe agent key yake yenye spending limit yake, na ihifadhi kwenye file inayomilikiwa na mtumiaji agent yenye mode 600. Mashine ikiharibiwa, revoke key hiyo badala ya kubaki ukijiuliza ikiwa ilivuja. Kuweka model spend ionekane kwa kila key pia ndiyo njia inayofanya namba zilizo katika Udhibiti wa gharama za AI agent kwenye VPS zibaki zikitabirika.

Punguza uwezo wa wakala kufikia mtandao

Kutenga mfumo wa faili ni nusu ya ulinzi. Nusu nyingine ni egress: kile ambacho mchakato unaruhusiwa kuwasiliana nacho. Linux inaweza kuchuja trafiki inayotoka kwa kutumia mtumiaji aliyeianzisha, jambo ambalo linaendana kikamilifu na muundo huu.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Sheria husomwa kwa mpangilio, kwa hivyo REJECT ya mwisho inakamata kila kitu ambacho mistari ya awali haikuruhusu. Ijaribu kama wakala:

sudo -u agent curl -sS -m 5 http://example.com

Hiyo inapaswa kufeli mara moja kwa hitilafu ya curl: (7) Failed to connect to example.com, ikifuatiwa na maneno yanayotofautiana kulingana na toleo lako la curl, kwa sababu sheria ya kukataa (reject) hujibu mara moja badala ya kuacha muunganisho ukining'inia. Ombi la HTTPS kwa mwenyeji (host) yuleyule linapaswa bado kufanikiwa.

Kuna mipaka miwili ya kweli. Kwanza, sheria hizi hupotea wakati wa reboot inayofuata isipokuwa ukiizihifadhi, kwa kutumia sudo apt install -y iptables-persistent na kisha sudo netfilter-persistent save. Pili, hii huchuja port na anwani, si majina. Sheria inayoruhusu port 443 inaruhusu kila mwenyeji wa HTTPS kwenye Internet, ambayo inatosha kufikia API ya modeli na pia inatosha kufikia pastebin. Orodha halisi ya kuruhusu vikoa (domain allow-list) inahitaji trafiki kupitia proksi inayosoma hostname iliyoombwa, ambayo ni mashine nyingi zaidi kuliko vile usanidi wa msanidi mmoja unavyohitaji. Dai tu kile ulichonacho: udhibiti wa egress katika kiwango cha port, kwenye mashine ambayo ulikuwa tayari kuipoteza.

Weka hali safi kati ya kazi

Hali safi kwa kila kazi ni faida ambayo mara nyingi haithaminiwi. Agent aliyefanya kazi kwa saa tatu kwenye tiketi iliyopita anaweza kuwa ameacha packages zilizowekwa, migrations zilizotekelezwa kwa sehemu, node_modules iliyopitwa na wakati, na git working tree yenye mabadiliko ambayo hakuna aliyekagua. Kazi inayofuata hurithi kila kitu hicho, nawe unatumia muda wako wa ukaguzi kubaini ni uchafu upi unatokana na kila run. Agent anayefanya mabadiliko machache huacha mabaki machache tangu mwanzo. Kwa hiyo, kuoanisha mashine ya muda mfupi na skill inayomsukuma agent kufanya mabadiliko madogo zaidi yanayofanya kazi huweka diff na hali iliyobaki katika kiwango kidogo kinachoweza kukaguliwa.

Njia rahisi na ya gharama ndogo ni kutumia checkout mpya kwa kila kazi.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Njia imara zaidi ni kuchukua provider snapshot mara moja, baada tu ya mashine kusanidiwa na kabla agent yeyote hajaigusa. Kurejesha snapshot hiyo hurudisha mfumo mzima, pamoja na packages, katika hali inayojulikana. Providers wengi hutoa kipengele hiki kwenye control panel au kupitia API, badala ya kukitoa kama command kwenye mashine. Kwa hiyo, hatua hususa zinategemea provider wako. Kanuni ni kuchukua snapshot wakati mashine bado haina mabadiliko yasiyo ya lazima.

Weka chochote unachokithamini nje ya mashine ya muda mfupi. Kwa kawaida, hii inamaanisha kusukuma branches badala ya kuzikusanya kwenye mashine ya ndani. Ikiwa mashine itaishia kuwa na kitu ambacho ungekihitaji, kifanye backup ipasavyo kwa kutumia restic backups kwenye VPS. Mashine unayoweza kuharibu ni muhimu tu ikiwa kuiharibu hakutasababisha matatizo yasiyotarajiwa.

Ukitaka environments kadhaa zilizotengwa bila kulipia servers kadhaa, VPS moja kubwa inaweza kuendesha guest VMs moja kwa moja. Nested virtualisation kwenye VPS inaeleza jinsi hili linavyofanya kazi, pamoja na jinsi ya kuthibitisha ikiwa provider wako analiruhusu. Isolation inaweza kufanya kazi kwa pande zote mbili hapa. Ikiwa ungependa agents wawili kwenye mashine moja waratibu kazi badala ya kutengwa kabisa, session moja ya Claude Code inaweza kutuma maandishi moja kwa moja kwenye nyingine badala ya kuelekeza kila handoff kupitia kwako.

Wakati laptop inayotunzwa vizuri inapokuwa salama

Kuwa mkweli kuhusu hili, kwa sababu kuzidisha hofu kuhusu kutengwa (isolation) ndiko kunakofanya watu waache kusikiliza.

Ikiwa unakagua kila amri kabla haijatekelezwa, laptop inatosha. Ombi la ruhusa ni udhibiti wa kweli, na kuendesha Claude Code kwa usalama kwenye seva inaelezea kile ambacho kila ngazi ya ruhusa inazuia. Ikiwa kazi yako ni repository moja bila vitambulisho vya production popote kwenye mashine, eneo la athari (blast radius) tayari ni dogo. Ikiwa vipindi vyako vya wakala (agent sessions) ni vifupi na vinasimamiwa, muda wa kuwepo kwa hatari pia ni mfupi.

Jibu hubadilika pale unapoacha kukagua maombi, jambo ambalo ni muhimu kulifikiria sasa kwa kuwa auto mode ndiyo chaguo-msingi la Claude Code na usakinishaji mpya haukuulizi tena kabla ya kuhariri faili au kuendesha amri. Uendeshaji bila kusimamiwa, kazi za usiku kucha, na mtiririko wowote wa kazi ambapo unaidhinisha mpango kisha unaondoka, vyote huondoa ukaguzi wa kibinadamu uliokuwa ukizuia hatari. Hapo ndipo mashine inapaswa kufanya kazi hiyo badala yake. Hali hiyo inatumika kwa chochote kinachopanua uwezo wa wakala, ikiwa ni pamoja na kuendesha wakala wa programu kwenye VPS katika repositories kadhaa kwa wakati mmoja.

Uamuzi si kuhusu kiasi gani unaliamini modeli. Ni kuhusu kile kilichopo karibu nacho wakati modeli inapokosea.

FAQ

Je, container inatosha kwa ajili ya kutenga (isolate) coding agent?

Kwa kazi nyingi, ndiyo, kwa masharti mawili. Container haipaswi kuendeshwa na --privileged, na haipaswi kuwa na /var/run/docker.sock iliyopachikwa (mounted) ndani yake, kwa sababu yoyote kati ya hayo humpa mchakato huo njia ya kufikia root kwenye host. Container hushiriki kernel ya host, kwa hivyo mpaka wake ni dhaifu kuliko ule wa virtual machine. Ikiwa agent inaendesha code isiyoaminika iliyopakuliwa kutoka Internet, ni vyema kutumia VM halisi au seva tofauti.

Je, agent inahitaji sudo kwenye seva?

Hapana, na kuipa sudo kunabatilisha utengaji ulioujenga, kwa sababu root anaweza kusoma akaunti nyingine zote kwenye mashine hiyo. Unda mtumiaji wa agent bila sudo na umpe ruhusa ya kuandika kwenye saraka (directory) yake ya kazi pekee. Ikiwa kazi inahitaji kusakinisha vifurushi (packages), ipatie agent mashine nzima inayomilikiwa nayo badala ya kumpa root kwenye mashine anayoshiriki na wengine.

Ninawezaje kuiruhusu agent kupush kwenye git bila kuweka SSH key yangu kwenye mashine?

Sambaza (forward) SSH agent yako kwa kutumia ssh -A unapounganisha. Maombi ya saini husafiri kupitia muunganisho huo huku private key ikibaki kwenye laptop yako, kwa hivyo ssh -T git@github.com huthibitisha utambulisho na git push hufanya kazi bila private key yoyote kwenye seva. Tahadhari ni kwamba root kwenye seva hiyo anaweza kutumia socket iliyosambazwa wakati umeunganishwa, kwa hivyo tumia deploy key yenye wigo wa repository (repository-scoped) kwenye mashine yoyote unayoshiriki na watu wengine.

Agent inahitaji VPS ya ukubwa gani?

Kazi ya agent mara nyingi ni kuhariri faili, kuendesha builds, na kufanya majaribio (tests), kwa hivyo chagua ukubwa wa mashine kulingana na build badala ya kulingana na model. Model inayohifadhiwa (hosted) huendeshwa kwenye vifaa vya mtoa huduma, jambo ambalo huongeza network traffic lakini haliongezi mzigo wa ndani isipokuwa kidogo sana. Agent yenyewe bado huweka kiwango cha chini: kufikia Oktoba 20, 2026, mahitaji ya mfumo wa Claude Code yanaorodhesha 4 GB ya RAM kama kiwango cha chini. Anza na 4 GB hata kwa kazi za scripting na uongeze hadi 8 GB ikiwa repository inajenga containers au inakusanya (compile) kitu chochote kikubwa.

Ni mara ngapi ninapaswa kuharibu na kujenga upya mashine?

Jenga upya wakati hali ya mfumo inapokuwa haiwezi kufafanulika, na angalau wakati wowote ambapo credential kwenye mashine inaweza kuwa imefichuliwa. Kufanya checkout mpya kati ya kazi moja na nyingine husaidia kudhibiti mabadiliko ya kila siku (drift), na snapshot iliyochukuliwa kabla ya agent kuanza kazi kwa mara ya kwanza hukupa picha safi ya mfumo wa kurudi. Ikiwa kujenga upya kunaonekana kuwa na gharama kubwa, hiyo ni ishara kwamba kitu muhimu kinaishi kwenye mashine uliyoiita ya kutupwa (disposable).