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.

Tambua eneo la athari kabla ya kulijadili

Eneo la athari ni seti ya vitu ambavyo mchakato unaweza kufikia. Kwa agent anayeendesha kama mtumiaji wako wa kawaida kwenye mashine yako ya kawaida, seti hiyo ni kubwa kuliko watu wengi wanavyodhani.

Inajumuisha ~/.ssh/id_ed25519, ambayo kwa kawaida haijasimbwa kwa njia fiche kwa sababu ulichoka kuandika passphrase. Inajumuisha ~/.aws/credentials na ~/.config/gh/hosts.yml, ambazo zimeundwa kuwa plain text. Inajumuisha kila repository iliyo jirani chini ya ~/code, pamoja na zile zenye connection strings za production katika faili ya env ya ndani. Pia inajumuisha historia ya shell yako, iliyo na tokens ulizobandika mara moja. Inajumuisha pia mtandao ambao laptop yako imeunganishwa nao, ambao mara nyingi huwa mtandao wa nyumbani au wa ofisini wenye services zisizohitaji authentication.

Hakuna kati ya hayo inayohitaji agent hasidi. Inahitaji command moja tu yenye makosa lakini inayoonekana kuwa sahihi. rm -rf yenye variable ambayo haijawekwa na inayopanuka kuwa /, git clean -xfd katika directory isiyo sahihi, docker system prune -af --volumes inayochukua database yako ya ndani pamoja nayo, au chmod -R 777 inayotekelezwa kwa nia ya kusaidia kwenye home directory. Agents hufunzwa kwa kutumia Internet ileile iliyowafundisha watu wengine commands hizo.

Utaratibu unaokulinda si uamuzi wa agent. Ni kwamba mashine inayobeba uharibifu huo ni mashine 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 Julai 2026

Kuna majibu matatu ya kuaminika kwa swali la “agent anapaswa kuendeshwa wapi”, na yote yanahusisha kubadilishana kati ya mambo mawili yale yale: nguvu ya mpaka wa usalama, na kiasi cha usanidi unachokubali.

Micro VM ya ndani. Zana za aina hii huwasha virtual machine halisi kwenye hardware yako, huweka repository yako ndani yake, na humruhusu agent kuwa na root ndani ya VM hiyo. clawk ni mfano wa sasa, na wazo lake kuu linaendana kabisa na hoja ya makala hii: wape coding agents Linux VM ya kutupwa, si laptop yako. Kufikia Julai 2026, inalenga macOS 14 na matoleo ya baadaye kwenye Apple silicon, ikiwa na Linux support ya majaribio kupitia Firecracker, na husakinishwa kwa brew install clawkwork/tap/clawk. Unaendesha clawk ndani ya repository ili kuwasha sandbox na kuunganisha agent, clawk down kuisimamisha, na clawk destroy kuiondoa. Mpaka huo ni hypervisor, kwa hiyo ni imara. Kizuizi ni kwamba VM inaishi kwenye mashine unayobeba kila mahali, hivyo hutumia memory yako na husimama unapofunga kifuniko cha laptop.

Container. Docker ni jibu ambalo watu wengi tayari wamekisakinisha, na kwa kweli ni muhimu.

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

--rm huondoa container inapotoka, na --network none huipa network kabisa, jambo ambalo ni default nzuri kwa build au test run. Elewa wazi kile ambacho hii haifanyi: container hushiriki kernel ya host, kwa hiyo bug ya kernel inaweza kuwa njia ya kutoka, na mpaka huo hupotea mara tu unapoongeza --privileged au kuweka /var/run/docker.sock ili agent iweze “kutumia Docker”. Kuweka Docker socket ndani ya container ni sawa na kuipa container hiyo root kwenye host.

VPS ya kawaida unayoweza kujenga upya. Hakuna tool mpya, kuna mpaka halisi wa kernel, snapshots za provider, na huduma huendelea kufanya kazi unapozima laptop yako. Huu ndio muundo unaoelezwa katika mwongozo uliosalia, na ndio unaostahimili agent runs ndefu, kwa sababu job inayochukua saa nne haijali kwamba umeenda nyumbani.

Mtindo wa VPS: mpe agent mtumiaji wake

Anza na mfumo uliolindwa. Dakika kumi za kwanza kwenye VPS mpya zinaeleza sehemu ambazo hazihusu agent pekee: masasisho, kuingia bila root, SSH inayotumia key pekee, na firewall.

Kisha unda account inayotumiwa na agent pekee, ili kosa ndani yake lisiweze kugusa kitu kingine 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 password ya kubashiri, na unafikia account hiyo kwa sudo -u agent au SSH key. Kumbuka kwamba agent haijaongezwa kimakusudi kwenye group ya sudo. Agent mwenye sudo ana root, na root anaweza kusoma files za kila mtumiaji mwingine, kwa hiyo utenganishaji uliouunda unakuwa wa kuonekana tu. Ikiwa agent inahitaji kweli kusakinisha packages, hilo ni sababu ya kuitengea server nzima, si sababu ya kumpa sudo kwenye server inayoshirikiwa. Sheria za jumla ziko katika least privilege kwa watumiaji wa Linux kwenye VPS.

Thibitisha mpaka wa utenganishaji kabla ya kuiamini. Ukiwa mtumiaji wa agent, jaribu kusoma file linalomilikiwa na account yako mwenyewe:

sudo -u agent cat /home/you/.ssh/id_ed25519

Unapaswa kuona cat: /home/you/.ssh/id_ed25519: Permission denied. Ukiona key material badala yake, home directory yako ina mode 755 na utenganishaji bado si halisi. Rekebisha kwa sudo chmod 700 /home/you.

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 kile ambacho agent anaweza kufikia kwenye mtandao

Kutenga mfumo wa faili ni nusu ya mpaka wa usalama. Nusu nyingine ni egress: maeneo ambayo mchakato unaruhusiwa kuwasiliana nayo. Linux inaweza kuchuja traffic ya kutoka kulingana na user aliyeianzisha, jambo linalolingana kikamilifu na mpangilio 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

Rules husomwa kwa mpangilio, kwa hiyo REJECT ya mwisho hushughulikia kila kitu ambacho mistari ya awali haikuruhusu. Ijaribu ukiwa kama agent:

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

Hilo linapaswa kushindwa kwa curl: (7) Failed to connect to example.com port 80: Connection refused, kwa sababu rule ya reject hujibu mara moja badala ya kuacha connection ikining'inia. Ombi la HTTPS kwenda kwenye host hiyo hiyo bado linapaswa kufanikiwa.

Kuna mipaka miwili ya kuzingatia. Kwanza, rules hizi hupotea wakati wa reboot inayofuata usipozihifadhi, kwa kutumia sudo apt install -y iptables-persistent na kisha sudo netfilter-persistent save. Pili, hii huchuja ports na anwani, si majina. Rule inayoruhusu port 443 inaruhusu kila host ya HTTPS kwenye Internet. Hiyo inatosha kufikia model API na pia inatosha kufikia pastebin. Allow-list halisi ya domain inahitaji traffic ipitie kwenye proxy inayosoma hostname iliyoombwa. Huo ni usanidi mkubwa zaidi kuliko ambao setups nyingi za developer mmoja zinahitaji. Dai tu kiwango cha ulinzi ulicho nacho: udhibiti wa egress kwa 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 yenye uangalizi inatosha kweli

Kuwa mkweli kuhusu hili, kwa sababu kuzidisha madai kuhusu isolation huwafanya watu waache kusikiliza.

Ukikagua kila command kabla haijaendeshwa, laptop inatosha. Ombi la permission ni control halisi, na kuendesha Claude Code kwa usalama kwenye server hueleza kila kiwango chake kinachozuiwa. Ikiwa kazi yako iko kwenye repository moja na hakuna credentials za production popote kwenye mashine, blast radius tayari ni ndogo. Ikiwa sessions za agent ni fupi na unasimamia uendeshaji wake, muda wa exposure pia ni mfupi.

Jibu hubadilika mara tu unapoacha kukagua prompts. Hili linafaa kufikiriwa sasa, kwa sababu auto mode inakuwa chaguo-msingi la Claude Code tarehe 14 August 2026 na installation mpya haiulizi tena kabla ya kuhariri files au kuendesha commands. Runs zisizosimamiwa, jobs za usiku, na workflow yoyote ambayo unaidhinisha plan kisha unaondoka huondoa ukaguzi wa binadamu uliokuwa ukifanya containment. Hapo ndipo mashine yenyewe inapaswa kufanya hivyo. Hali hiyo hiyo inatumika kwa chochote kinachopanua reach ya agent, ikiwa ni pamoja na kuendesha coding agent kwenye VPS kwenye repositories kadhaa kwa wakati mmoja.

Uamuzi hauhusu hasa ni kwa kiwango gani unaiamini model. Unahusu kilicho karibu nayo wakati model inapokosea.

FAQ

Je, container inatosha kutoa isolation kwa coding agent?

Kwa kazi nyingi, ndiyo, kwa masharti mawili. Container haipaswi kuendeshwa kwa --privileged, na /var/run/docker.sock haipaswi ku-mountiwa ndani yake, kwa sababu mojawapo ya hayo huipa process njia ya kufikia root kwenye host. Container hushiriki kernel ya host, kwa hiyo boundary yake ni dhaifu kuliko ya virtual machine. Ikiwa agent inaendesha code isiyoaminika iliyopakuliwa kutoka Internet, tumia VM halisi au seva tofauti.

Je, agent anahitaji sudo kwenye seva?

Hapana. Kumpa sudo kunabatilisha isolation uliyojenga, kwa sababu root inaweza kusoma kila account nyingine kwenye mashine. Unda user wa agent bila sudo na mpe write access kwenye work directory yake pekee. Ikiwa task inahitaji kweli usakinishaji wa package, mpe agent mashine nzima anayomiliki badala ya root kwenye mashine anayoshiriki na wengine.

Ninawezaje kumruhusu agent kufanya push kwenye git bila kuweka SSH key yangu kwenye mashine?

Forward SSH agent yako kwa ssh -A unapounganisha. Maombi ya kusaini hupitia kwenye connection huku private key ikibaki kwenye laptop yako, kwa hiyo ssh -T git@github.com hufanya authentication na git push hufanya kazi bila private key kwenye server. Tahadhari ni kwamba root kwenye server hiyo inaweza kutumia forwarded socket wakati umeunganishwa, kwa hiyo tumia deploy key inayohusishwa na repository kwenye mashine yoyote unayoshiriki na watu wengine.

Agent anahitaji VPS ya ukubwa gani?

Kazi ya agent mara nyingi ni kuhariri files, kuendesha builds na kuendesha tests, kwa hiyo pima ukubwa wa mashine kulingana na build, si model. Model inayohostiwa huendeshwa kwenye hardware ya provider, jambo linaloongeza network traffic lakini karibu haliongezi load ya ndani. Anza na 2 GB RAM kwa scripting work, kisha ongeza hadi 8 GB ikiwa repository inajenga containers au inacompile kitu kikubwa.

Ninapaswa kuharibu na kujenga upya mashine mara ngapi?

Jenga upya hali yake inapokosa kuelezeka, na angalau kila mara credential iliyo kwenye mashine inaweza kuwa imefichuka. Fresh checkout kati ya tasks hushughulikia drift ya kila siku, na snapshot iliyochukuliwa kabla ya agent kuanza kufanya kazi kwa mara ya kwanza hukupa system image safi ya kurejea. Ikiwa kujenga upya kunaonekana kuwa na gharama kubwa, hiyo ni ishara kwamba kuna kitu muhimu kinachoishi kwenye mashine uliyoita ya matumizi ya muda.