कोडिंग एजंटसाठी नष्ट करता येणारे VM का वापरावे

लॅपटॉपपेक्षा नष्ट करून पुन्हा तयार करता येणारे VM का चांगले आहे

कोडिंग एजंटला नष्ट करून पुन्हा तयार करता येणारे VM दिल्यास, तो सर्वांत वाईट परिस्थितीत दहा मिनिटांत पुन्हा तयार करता येणारे मशीन नष्ट करू शकतो. एजंटला तरीही root प्रवेश मिळतो, तो तरीही पॅकेजेस स्थापित करतो आणि प्रत्येक टप्प्यासाठी परवानगी न मागता test suite चालवतो. फरक एवढाच असतो की नुकसान कुठे होते. लॅपटॉपवर एजंट तुमच्या SSH keys, browser profile, तुमच्या .env files आणि तुम्ही यापूर्वी clone केलेल्या इतर प्रत्येक repository सोबत home directory सामायिक करतो. तात्पुरत्या सर्व्हरवर त्याच्याकडे shell, checkout आणि चोरण्यासारखे महत्त्वाचे दुसरे काहीही नसते.

हा संपूर्ण युक्तिवाद आहे. तो संभाव्यतेपेक्षा जोखीम-असमतोलाबद्दल आहे. काळजीपूर्वक वापरलेल्या लॅपटॉपवरील काळजीपूर्वक एजंट जवळपास प्रत्येक वेळी सुरक्षित असतो. पण एकदा तो सुरक्षित राहिला नाही, तर नुकसान फक्त चुकीचा commit नसते. तुमच्याकडे backup असल्यास, backup मधून restore करावे लागते.

विवाद करण्यापूर्वी संभाव्य नुकसानाची व्याप्ती निश्चित करा

Blast radius म्हणजे एखादी प्रक्रिया ज्या गोष्टींपर्यंत पोहोचू शकते त्यांचा संच. तुमच्या नेहमीच्या मशीनवर तुमच्या नेहमीच्या user म्हणून चालणाऱ्या agent साठी हा संच बहुतेक लोकांच्या कल्पनेपेक्षा मोठा असतो.

यामध्ये ~/.ssh/id_ed25519 समाविष्ट असते. तुम्हाला passphrase पुन्हा पुन्हा टाइप करण्याचा कंटाळा आल्यामुळे ते सहसा unencrypted असते. यामध्ये ~/.aws/credentials आणि ~/.config/gh/hosts.yml समाविष्ट असतात. ही दोन्ही रचना हेतुपुरस्सर plain text मध्ये असते. ~/code अंतर्गत असलेले प्रत्येक sibling repository यामध्ये समाविष्ट असते. त्यात local env file मध्ये production connection strings असलेली repositories देखील येतात. तुमची shell history देखील यात समाविष्ट असते. त्यामध्ये तुम्ही एकदा paste केलेले tokens असू शकतात. तुमचा laptop ज्या network वर असतो ते network देखील यात समाविष्ट असते. ते बहुतेक वेळा home किंवा office network असते आणि त्यावर unauthenticated services चालू असू शकतात.

यापैकी कशासाठीही malicious agent आवश्यक नसतो. एक चुकीचा command आत्मविश्वासाने चालवणे पुरेसे असते. unset variable मुळे / मध्ये expand होणारा rm -rf, चुकीच्या directory मधील git clean -xfd, तुमचा local database देखील हटवणारा docker system prune -af --volumes किंवा home directory वर चालवलेला उपयुक्त वाटणारा chmod -R 777. Agents ला देखील इतरांप्रमाणे तेच commands शिकवणाऱ्या internet वरील डेटावर प्रशिक्षण दिलेले असते.

तुमचे संरक्षण agent च्या judgement मुळे होत नाही. नुकसान झाले तरी गमावण्याची तुमची तयारी असलेली machine ते नुकसान धारण करते, हीच यामागची यंत्रणा आहे.

खर्चाचे गणित कंटाळवाणे आहे. हाच त्याचा मुद्दा आहे.

लहान VPS साठी दरमहा काही डॉलर खर्च होतात. विकासकाचा laptop पूर्ववत करण्यासाठी एक दिवस लागतो. तेही चांगले प्रकरण आहे, ज्यात समस्या लगेच लक्षात येते आणि तुमच्याकडे backup असतो.

तुमचे स्वतःचे आकडे वापरून हे गणित करा. तुमचा प्रति-तास दर घ्या आणि operating system पुन्हा install करणे, home directory restore करणे, SSH key rotate करणे, personal access token rotate करणे आणि वीस repositories पुन्हा clone करणे यासाठी लागणाऱ्या तासांनी तो गुणा. त्याची तुलना तुमचा provider विकत असलेल्या सर्वात लहान serverच्या बारा महिन्यांच्या खर्चाशी करा. समतोलबिंदू अनेक वर्षांत एका incidentपेक्षाही कमी वारंवारतेवर येतो. हा खर्च भरून निघण्यासाठी incident catastrophic असण्याची गरज नाही. स्थानिक environment खराब झाल्यामुळे वाया गेलेली एकच दुपार त्या वर्षाचा खर्च भरून काढते.

या गणिताचा दुसरा भाग snapshots आहे. जोखमीचे काम सुरू करण्यापूर्वी घेतलेला snapshot खराब परिणामाला "माझे संपूर्ण काम restore करा" याऐवजी "roll back करा आणि वेगळा prompt वापरून पुन्हा प्रयत्न करा" इतके सोपे बनवतो. तुम्ही हे लिहित असलेला laptop वापरत असताना त्याचा snapshot घेता येत नाही. कारण तोच laptop तुम्ही काम करण्यासाठी वापरत आहात.

जुलै 2026 मधील स्थिती

“एजंट कुठे चालवावा?” या प्रश्नाची तीन प्रामाणिक उत्तरे आहेत. या सर्व पर्यायांमध्ये दोनच बाबींमध्ये तडजोड करावी लागते: सीमा किती मजबूत आहे आणि तुम्ही किती सेटअप स्वीकारू शकता.

स्थानिक micro VM. या प्रकारची साधने तुमच्या स्वतःच्या हार्डवेअरवर प्रत्यक्ष virtual machine सुरू करतात, त्यामध्ये तुमचे repository mount करतात आणि एजंटला त्यात root प्रवेश देतात. clawk हे सध्याचे उदाहरण आहे. या लेखाचा मुख्य मुद्दाही हाच आहे: coding agents साठी तुमच्या laptop ऐवजी वापरून झाल्यावर काढून टाकता येणारी Linux VM द्या. जुलै 2026 पर्यंत हे Apple silicon वरील macOS 14 आणि त्यानंतरच्या आवृत्त्यांना लक्ष्य करते. Firecracker द्वारे Linux समर्थन experimental आहे. हे brew install clawkwork/tap/clawk ने install होते. sandbox सुरू करून agent जोडण्यासाठी repository मध्ये clawk चालवा. ते थांबवण्यासाठी clawk down आणि काढून टाकण्यासाठी clawk destroy चालवा. ही सीमा hypervisor ची असल्याने मजबूत आहे. मात्र VM तुम्ही सोबत बाळगता त्या मशीनवरच चालते. त्यामुळे ती तुमच्या memory साठी स्पर्धा करते आणि laptop चे झाकण बंद केल्यावर थांबते.

Container. Docker हे बहुतेक लोकांकडे आधीपासून install असलेले उत्तर आहे आणि ते प्रत्यक्षात उपयुक्त आहे.

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

--rm exit झाल्यावर container काढून टाकते आणि --network none त्याला कोणतेही network access देत नाही. Build किंवा test run साठी हा चांगला default आहे. मात्र यामुळे काय होत नाही हे स्पष्ट असावे: container host kernel share करते. त्यामुळे kernel मधील bug द्वारे बाहेर पडण्याचा मार्ग उपलब्ध होऊ शकतो. तसेच --privileged जोडल्यावर किंवा एजंटला “Docker वापरता यावे” म्हणून /var/run/docker.sock mount केल्यावर सीमा नाहीशी होते. Container मध्ये Docker socket mount करणे म्हणजे त्या container ला host वर root प्रवेश देण्यासारखेच आहे.

पुन्हा तयार करता येणारा साधा VPS. यासाठी नवीन साधनाची गरज नाही, प्रत्यक्ष kernel boundary मिळते, provider snapshots उपलब्ध असतात आणि laptop बंद केल्यानंतरही तो चालू राहतो. या मार्गदर्शकाच्या उर्वरित भागात याच पद्धतीचे वर्णन केले आहे. दीर्घकाळ चालणाऱ्या agent प्रक्रियांसाठी ही पद्धत टिकाऊ आहे, कारण चार तास लागणाऱ्या job ला तुम्ही घरी गेला आहात की नाही याची पर्वा नसते.

VPS पद्धत: agent साठी स्वतंत्र user द्या

सुरक्षित केलेल्या system पासून सुरुवात करा. नवीन VPS वरील पहिली दहा मिनिटे या मार्गदर्शकात agent-विशिष्ट नसलेले भाग दिले आहेत: updates, non-root login, key-only SSH आणि firewall.

त्यानंतर फक्त agent साठी असलेले account तयार करा. त्यामुळे त्यातील एखाद्या चुकीमुळे server वरील इतर कोणत्याही गोष्टीवर परिणाम होणार नाही.

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 मुळे अंदाज लावता येईल असा password नसतो. या account मध्ये sudo -u agent किंवा SSH key वापरून प्रवेश करता येतो. agent ला जाणूनबुजून sudo group मध्ये ठेवलेले नाही. sudo असलेल्या agent कडे root access असतो. root इतर सर्व users च्या files वाचू शकतो. त्यामुळे नुकतेच तयार केलेले separation केवळ दिखाऊ ठरते. Agent ला packages install करण्याची खरोखर गरज असल्यास, त्यासाठी shared server वर sudo देण्याऐवजी त्याच्या मालकीचा स्वतंत्र पूर्ण server वापरणे योग्य आहे. सर्वसाधारण नियम VPS वरील Linux users साठी least privilege येथे दिले आहेत.

या सीमारेषेवर विश्वास ठेवण्यापूर्वी तिची पडताळणी करा. agent user म्हणून, स्वतःच्या account शी संबंधित file वाचण्याचा प्रयत्न करा:

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

तुम्हाला cat: /home/you/.ssh/id_ed25519: Permission denied दिसले पाहिजे. त्याऐवजी key material दिसत असल्यास, तुमच्या home directory चा mode 755 आहे आणि isolation अद्याप प्रत्यक्षात आलेले नाही. sudo chmod 700 /home/you वापरून ते दुरुस्त करा.

प्रमाणपत्रे मशीनवर अजिबात ठेवू नका

तुमच्या production secrets ची प्रत मशीनवर केली, तर disposable machine चा उद्देशच निष्फळ होतो. नियम सोपा आहे: त्या मशीनवर अशी कोणतीही credential नसावी, जी आज दुपारी rotate करावी लागली तरी तुम्हाला हरकत वाटेल.

git साठी key ची प्रत करण्याऐवजी तुमचा SSH agent forward करा. private key तुमच्या laptop वरच राहते आणि connection मधून फक्त signature requests जातात.

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

दुसऱ्या command ने Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. असे उत्तर दिले पाहिजे. यावरून git push server वर key file नसतानाही कार्य करेल, हे सिद्ध होते. त्यानंतर मशीनवर ls -la ~/.ssh चालवा आणि त्यात कोणतीही private key नाही, याची खात्री करा.

Agent forwarding मध्ये एक महत्त्वाची मर्यादा आहे. ती स्पष्टपणे लक्षात ठेवा: तुम्ही connected असताना त्या server वर root access असलेली कोणतीही व्यक्ती forwarded socket वापरून तुमच्याप्रमाणे authenticate करू शकते. त्या server वर तुमच्याशिवाय दुसरा user नसल्यास हा स्वीकारार्ह तडजोडीचा पर्याय आहे. Shared machine वर तो स्वीकारार्ह नाही. अशा वेळी एका repository पुरती मर्यादित deploy key हा अधिक योग्य पर्याय आहे. पर्यायांची माहिती SSH key management ची मूलभूत माहिती येथे दिली आहे.

API keys साठी agent ला स्वतंत्र spending limit असलेली स्वतंत्र key द्या. ती key agent user च्या मालकीच्या mode 600 असलेल्या file मध्ये साठवा. मशीन नष्ट केल्यावर ती key लीक झाली आहे की नाही याचा अंदाज लावण्याऐवजी ती revoke करा. प्रत्येक key साठी model spend दृश्यमान ठेवणे हेदेखील VPS वरील AI agent च्या खर्चाचे नियंत्रण मधील आकडे अंदाजे स्थिर ठेवण्याचा मार्ग आहे.

एजंटला नेटवर्कवर कुठे पोहोचता येईल यावर मर्यादा घाला

Filesystem isolation ही सीमारेषेची अर्धी बाजू आहे. दुसरी बाजू egress आहे: process ला कोणाशी संवाद साधण्याची परवानगी आहे. Linux process सुरू करणाऱ्या user नुसार outbound traffic filter करू शकतो. ही पद्धत या रचनेसाठी योग्य आहे.

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 क्रमाने वाचले जातात. त्यामुळे आधीच्या ओळींनी परवानगी न दिलेल्या सर्व गोष्टी शेवटचा REJECT पकडतो. Agent म्हणून त्याची चाचणी घ्या:

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

हे curl: (7) Failed to connect to example.com port 80: Connection refused सह अपयशी ठरले पाहिजे. कारण reject rule कनेक्शन लोंबकळत ठेवण्याऐवजी त्वरित उत्तर देते. त्याच host कडे केलेली HTTPS request तरीही यशस्वी झाली पाहिजे.

दोन महत्त्वाच्या मर्यादा आहेत. पहिली, या rules जतन केल्या नाहीत तर पुढील reboot वेळी नष्ट होतात; त्यासाठी sudo apt install -y iptables-persistent आणि त्यानंतर sudo netfilter-persistent save वापरा. दुसरी, हे names नव्हे तर ports आणि addresses filter करते. Port 443 ला परवानगी देणारा rule इंटरनेटवरील प्रत्येक HTTPS host साठी परवानगी देतो. त्यामुळे model API पर्यंत पोहोचता येते, पण pastebin पर्यंतही पोहोचता येते. खऱ्या domain allow-list साठी requested hostname वाचणाऱ्या proxy मधून traffic जाणे आवश्यक आहे. बहुतेक single-developer setup साठी ही अधिकची यंत्रणा नकोशी ठरते. तुमच्याकडे प्रत्यक्षात जे आहे तेवढाच दावा करा: port-level egress control, आणि अशी machine जिचे नुकसान झाले तरी तुम्ही तयार होता.

कामांदरम्यान स्वच्छ स्थितीवर परत या

प्रत्येक कामासाठी स्वच्छ स्थिती हा कमी लेखला जाणारा फायदा आहे. मागील तिकिटावर तीन तास काम केलेल्या agent ने स्थापित packages, अर्धवट लागू झालेल्या migrations, जुना node_modules आणि कोणीही पुनरावलोकन न केलेले बदल असलेले git working tree मागे ठेवले. पुढील काम या सर्व स्थितीचा वारसा घेते आणि कोणता गोंधळ कोणत्या run चा आहे हे समजून घेण्यासाठी तुमचा review budget खर्च होतो. अधिक मर्यादित agent सुरुवातीपासूनच कमी अवशेष ठेवतो. त्यामुळे disposable machine ला agent ला कार्य करणारा सर्वात छोटा बदल करण्यास प्रवृत्त करणाऱ्या skill सोबत वापरल्यास diff आणि उरलेली स्थिती दोन्ही पुनरावलोकनासाठी पुरेशी लहान राहतात.

याची सोपी पद्धत म्हणजे प्रत्येक कामासाठी fresh checkout वापरणे.

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

अधिक प्रभावी पद्धत म्हणजे machine सेट केल्यानंतर आणि कोणत्याही agent ने त्यावर काम करण्यापूर्वी provider snapshot एकदाच घेणे. हा snapshot restore केल्यावर packages सहित संपूर्ण system ज्ञात स्थितीत परत येते. बहुतेक providers हे box वरील command ऐवजी control panel किंवा API द्वारे उपलब्ध करून देतात. त्यामुळे अचूक पायऱ्या तुमच्या provider वर अवलंबून असतात. Machine अजून कोणताही बदल नसलेल्या स्थितीत असतानाच snapshot घेणे ही शिस्त महत्त्वाची आहे.

ज्या गोष्टींची तुम्हाला आवश्यकता आहे त्या disposable machine वर ठेवू नका. याचा मुख्य अर्थ branches स्थानिक पातळीवर साठवून न ठेवता push करणे असा आहे. Machine वर तुमच्यासाठी महत्त्वाची एखादी गोष्ट राहिलीच, तर VPS वर restic backups वापरून तिचा योग्य backup घ्या. एखादी machine नष्ट करता येणे तेव्हाच उपयुक्त ठरते, जेव्हा ती नष्ट केल्यावर प्रत्यक्षात कोणतीही अडचण निर्माण होत नाही.

अनेक servers साठी खर्च न करता अनेक isolated environments हवे असल्यास, एक मोठा VPS guest VMs थेट host करू शकतो. VPS वरील Nested virtualisation मध्ये ही रचना कशी कार्य करते आणि तुमचा provider तिला परवानगी देतो का हे कसे तपासायचे, याचे वर्णन आहे. येथे isolation चे दोन्ही परिणाम होऊ शकतात. त्यामुळे एकाच box वर दोन agents परस्पर समन्वय साधावेत आणि एकमेकांपासून पूर्णपणे वेगळे राहू नयेत असे तुम्हाला वाटत असल्यास, प्रत्येक handoff तुमच्यामार्फत route करण्याऐवजी एक Claude Code session दुसऱ्या session कडे थेट text पाठवू शकते.

काळजी घेतल्यास laptop खरोखर योग्य ठरतो

याबाबत प्रामाणिक रहा. Isolation चे अतिशयोक्तीपूर्ण महत्त्व सांगितल्यामुळे लोक ऐकणे थांबवतात.

प्रत्येक command चालण्यापूर्वी त्याचा आढावा घेत असाल, तर laptop योग्य आहे. Permission prompt हे खरे नियंत्रण आहे. सर्व्हरवर Claude Code सुरक्षितपणे चालवणे या नियंत्रणाच्या प्रत्येक स्तरामुळे नेमके काय रोखले जाते, हे स्पष्ट करते. मशीनवर production credentials कुठेही नसतील आणि तुमचे काम एका repository पुरते मर्यादित असेल, तर blast radius आधीच कमी असतो. Agent sessions लहान आणि तुमच्या देखरेखीखाली असतील, तर exposure window देखील लहान राहते.

तुम्ही prompts वगळताच उत्तर बदलते. 14 August 2026 रोजी auto mode Claude Code चे default होते हे लक्षात घेणे महत्त्वाचे आहे. नवीन install नंतर files edit करण्यापूर्वी किंवा commands चालवण्यापूर्वी confirmation विचारले जात नाही. Unattended runs, overnight jobs आणि plan approve करून तेथेच थांबून न राहता निघून जाणारी कोणतीही workflow, containment करणारी मानवी तपासणी काढून टाकते. अशा वेळी ते काम मशीनने करावे लागते. Agent ची पोहोच वाढवणाऱ्या गोष्टींनाही हेच लागू होते. यामध्ये एकाच वेळी अनेक repositories वर VPS वर coding agent चालवणे याचाही समावेश आहे.

निर्णय हा model वर तुमचा किती विश्वास आहे याबद्दल नाही. Model कडून चूक झाल्यावर त्याच्या शेजारी नेमके काय उपलब्ध आहे, हा खरा प्रश्न आहे.

FAQ

Coding agent साठी container पुरेसे isolation देते का?

बहुतेक कामांसाठी होय, मात्र दोन अटी आहेत. Container --privileged सह चालू नये आणि त्यात /var/run/docker.sock mount केलेले नसावे, कारण यांपैकी कोणतीही गोष्ट process ला host वरील root पर्यंत पोहोचण्याचा मार्ग देते. Container host kernel share करते, त्यामुळे ही boundary virtual machine पेक्षा कमकुवत असते. Agent इंटरनेटवरून आणलेला अविश्वसनीय code चालवत असल्यास, खरी VM किंवा स्वतंत्र server वापरा.

Server वर agent ला sudo आवश्यक आहे का?

नाही. त्याला sudo दिल्यास तुम्ही तयार केलेले isolation निष्प्रभ होते, कारण root ला त्या machine वरील प्रत्येक इतर account वाचता येतो. sudo शिवाय agent user तयार करा आणि त्याला फक्त त्याच्या स्वतःच्या work directory वर write access द्या. Task साठी खरोखर package installation आवश्यक असल्यास, ज्या machine वर त्याचे पूर्ण नियंत्रण असेल अशी machine द्या; ज्या machine वर इतरांसोबत access share करतो त्यावर root देऊ नका.

Server वर माझी SSH key न ठेवता agent ला git वर push कसे करू?

Connect करताना ssh -A वापरून तुमचा SSH agent forward करा. Signature requests connection द्वारे पाठवल्या जातात आणि private key तुमच्या laptop वरच राहते. त्यामुळे ssh -T git@github.com authentication करते आणि git push server वर private key नसतानाही कार्य करते. मात्र, तुम्ही connected असताना त्या server वरील root forwarded socket वापरू शकतो. त्यामुळे इतर लोकांसोबत share केलेल्या कोणत्याही machine वर repository-scoped deploy key वापरा.

Agent ला कोणत्या आकाराचा VPS आवश्यक आहे?

Agent चे काम प्रामुख्याने files edit करणे, builds चालवणे आणि tests चालवणे असे असते. त्यामुळे machine चा आकार model साठी नव्हे, तर build साठी ठरवा. Hosted model provider च्या hardware वर चालते. त्यामुळे network traffic वाढते, पण local load जवळजवळ वाढत नाही. Scripting work साठी 2 GB RAM पासून सुरुवात करा. Repository containers build करत असल्यास किंवा मोठ्या प्रमाणावर compilation करत असल्यास 8 GB पर्यंत वाढवा.

Machine किती वेळाने destroy करून पुन्हा build करावी?

State समजावून सांगता येईनाशी झाली की rebuild करा. तसेच machine वरील एखादे credential उघड झाले असण्याची शक्यता असल्यास किमान त्या वेळी rebuild करा. रोजच्या कामातील drift हाताळण्यासाठी tasks दरम्यान fresh checkout पुरेसा असतो. पहिल्या agent run पूर्वी घेतलेला snapshot तुम्हाला परत जाण्यासाठी clean system image देतो. Rebuilding खर्चिक वाटत असल्यास, disposable म्हणून घोषित केलेल्या machine वर काही महत्त्वाचे टिकून राहिले आहे, याचे ते लक्षण आहे.