Coding agent साठी disposable VM कशी तयार करावी

डिस्पोजेबल VM तुमच्या लॅपटॉपपेक्षा का अधिक सुरक्षित आहे

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

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

त्यावर वाद घालण्यापूर्वी परिणामक्षेत्र निश्चित करा

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

यामध्ये ~/.ssh/id_ed25519 समाविष्ट असते. पासफ्रेज वारंवार टाइप करण्याचा कंटाळा आल्यामुळे ते सहसा 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 वर train केले जाते.

तुमचे संरक्षण करणारी यंत्रणा agent चे judgement नाही. नुकसान झाले तरी चालेल अशी मशीन तुम्ही वापरत आहात, हीच ती यंत्रणा आहे.

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

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

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

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

जुलै 2026 पर्यंतची स्थिती

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

स्थानिक micro VM. या श्रेणीतील साधने तुमच्या स्वतःच्या हार्डवेअरवर वास्तविक virtual machine सुरू करतात, तुमचे repository त्यात mount करतात आणि एजंटला त्याच्या आत root प्रवेश देतात. clawk हे सध्याचे उदाहरण आहे. या लेखाचा मुख्य मुद्दा त्याच्या मांडणीत स्पष्ट आहे: coding agents साठी तुमचा laptop नव्हे, तर वापरून झाल्यावर हटवता येणारा Linux VM द्या. जुलै 2026 पर्यंत हे Apple silicon वरील macOS 14 आणि त्यानंतरच्या आवृत्त्यांना लक्ष्य करते. Firecracker द्वारे यामध्ये प्रायोगिक Linux support आहे आणि ते brew install clawkwork/tap/clawk वापरून install करता येते. sandbox सुरू करून एजंट जोडण्यासाठी 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 केल्यावर ही सीमारेषा नाहीशी होते. Docker socket container मध्ये mount करणे म्हणजे त्या container ला host वरील root प्रवेश देण्यासारखे आहे.

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

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

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

त्यानंतर केवळ agent साठी असलेले account तयार करा. त्यामुळे त्या 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 अधिकार असतात. root इतर प्रत्येक user च्या files वाचू शकतो. त्यामुळे तुम्ही तयार केलेले विभाजन केवळ नावापुरते राहते. Agent ला packages install करण्याची खरोखर गरज असल्यास, shared server वर त्याला sudo देण्याऐवजी त्याच्या मालकीचा स्वतंत्र server वापरणे योग्य आहे. सर्वसाधारण नियम VPS वरील Linux users साठी किमान अधिकार येथे दिले आहेत.

तुमचा विश्वास ठेवण्यापूर्वी ही सीमा तपासा. 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 कॉपी केले. नियम सोपा आहे: त्या मशीनवर अशी कोणतीही क्रेडेन्शियल ठेवू नका, जी तुम्हाला आज दुपारी 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 सर्व्हरवर key file नसतानाही कार्य करेल, हे सिद्ध होते. त्यानंतर त्या मशीनवर ls -la ~/.ssh चालवा आणि त्यात कोणतीही private key नाही, याची खात्री करा.

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

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

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

फाइलसिस्टमचे अलगाव हा संरक्षणाचा अर्धा भाग आहे. दुसरा अर्धा भाग egress आहे: प्रक्रियेला कोणाशी network traffic करण्याची परवानगी आहे. Linux ही outbound traffic निर्माण करणाऱ्या user नुसार फिल्टर करू शकते. हा नमुना यासाठी योग्य आहे.

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

नियम क्रमाने वाचले जातात. त्यामुळे आधीच्या ओळींनी परवानगी न दिलेली प्रत्येक गोष्ट शेवटचा 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 connection hang होऊ देण्याऐवजी त्वरित उत्तर देते. त्याच host कडे केलेली HTTPS request मात्र यशस्वी झाली पाहिजे.

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

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

प्रत्येक कार्यासाठी स्वच्छ स्थिती ठेवणे हा अनेकदा दुर्लक्षित होणारा लाभ आहे. मागील तिकिटावर तीन तास काम केलेल्या एजंटने स्थापित केलेली पॅकेजेस, अर्धवट लागू केलेली migrations, जुना node_modules आणि कोणीही पुनरावलोकन न केलेले बदल असलेले git working tree मागे ठेवले. पुढील कार्याला हे सर्व वारशाने मिळते. त्यानंतर कोणता गोंधळ कोणत्या रनचा आहे हे ठरवण्यात तुमचा पुनरावलोकनाचा वेळ खर्च होतो.

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

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

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

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

अनेक servers साठी पैसे न देता अनेक isolated environments हवे असल्यास, एक मोठा VPS guest VMs थेट host करू शकतो. VPS वरील Nested virtualisation याची कार्यपद्धती स्पष्ट करते. तुमचा provider ही सुविधा अनुमत करतो की नाही हे तपासण्याची पद्धतही त्यात दिली आहे.

काळजीपूर्वक वापरल्यास laptop खरोखर योग्य ठरतो

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

प्रत्येक command चालण्यापूर्वी त्याचा आढावा घेत असाल, तर laptop योग्य आहे. परवानगीचा prompt हे खरे नियंत्रण आहे. server वर Claude Code सुरक्षितपणे चालवणे या प्रक्रियेत प्रत्येक स्तर नेमके काय अवरोधित करतो, हे स्पष्ट केले आहे. तुमचे काम एका repositoryपुरते मर्यादित असेल आणि machineवर कुठेही production credentials नसतील, तर संभाव्य परिणामांची व्याप्ती आधीच कमी असते. तुमची agent sessions लहान आणि देखरेखीखाली असतील, तर जोखीम असण्याचा कालावधीही कमी असतो.

तुम्ही prompts वगळता त्या क्षणी उत्तर बदलते. देखरेखीशिवाय चालणारे runs, रात्रभर चालणारी jobs आणि plan मंजूर करून दूर जाणारी कोणतीही workflow यामुळे जोखीम मर्यादित ठेवणारी मानवी तपासणीच काढून टाकली जाते. अशा वेळी machineनेच ते नियंत्रण करणे आवश्यक असते. agentची पोहोच वाढवणाऱ्या कोणत्याही बाबीलाही हेच लागू होते. यामध्ये एकाच वेळी अनेक repositoriesवर VPS वर coding agent चालवणे याचाही समावेश आहे.

निर्णय खरोखर modelवर तुमचा किती विश्वास आहे यावर अवलंबून नसतो. modelकडून चूक झाल्यावर त्याच्या शेजारी काय उभे आहे, यावर तो अवलंबून असतो.

FAQ

कोडिंग एजंटसाठी container पुरेसे विलगीकरण देते का?

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

Server वर एजंटला sudo आवश्यक आहे का?

नाही. त्याला sudo दिल्यास तुम्ही तयार केलेले isolation निष्प्रभ होते, कारण root ला server वरील इतर प्रत्येक account वाचता येतो. sudo शिवाय agent user तयार करा आणि त्याला केवळ त्याच्या स्वतःच्या work directory मध्ये write access द्या. Package installation ची खरोखर गरज असल्यास, एजंटला root access असलेला shared machine देण्याऐवजी त्याच्या मालकीचे संपूर्ण machine द्या.

Server वर माझी SSH key न ठेवता एजंटला git वर push कसे करू द्यावे?

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

एजंटला कोणत्या आकाराचा VPS आवश्यक आहे?

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

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

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