AI coding agent साठी नष्ट करून पुन्हा तयार करता येणारे 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 वर जोडलेला आहे तेही यात समाविष्ट असते. ते अनेकदा home किंवा office network असते आणि त्यावर unauthenticated services चालू असतात.

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

तुम्हाला वाचवणारी यंत्रणा agent चे judgement नाही. नुकसान झाले तरी गमावण्याची तुमची तयारी असलेल्या मशीनवरच ते नुकसान मर्यादित राहते.

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

लहान 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 support उपलब्ध आहे आणि ते brew install clawkwork/tap/clawk वापरून install करता येते. repository मध्ये clawk चालवल्यावर sandbox सुरू होतो आणि एजंट जोडला जातो. तो थांबवण्यासाठी 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 प्रवेश देण्यासारखे आहे.

पुन्हा build करता येणारा साधा VPS. यासाठी नवीन साधनाची गरज नाही, वास्तविक kernel boundary मिळते, provider snapshots उपलब्ध असतात आणि laptop बंद केल्यानंतरही तो चालू राहतो. या मार्गदर्शकाच्या उर्वरित भागात याच पद्धतीचे वर्णन केले आहे. दीर्घकाळ चालणाऱ्या agent jobs साठी ही पद्धत टिकाऊ ठरते, कारण चार तास चालणाऱ्या 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 access असतो. root इतर प्रत्येक user च्या files वाचू शकतो. त्यामुळे तुम्ही नुकतेच तयार केलेले विभाजन केवळ दिखाऊ ठरते. Agent ला खरोखर packages install करण्याची गरज असल्यास, shared server वर त्याला sudo देण्याऐवजी त्याच्या मालकीचा स्वतंत्र server वापरणे योग्य ठरते. सर्वसाधारण नियम VPS वरील Linux users साठी least privilege येथे दिले आहेत.

Agent वर विश्वास ठेवण्यापूर्वी ही सीमा तपासा. agent user म्हणून स्वतःच्या account ची home directory list करण्याचा प्रयत्न करा:

sudo -u agent ls /home/you

तुम्हाला ls: cannot open directory '/home/you': Permission denied दिसले पाहिजे. त्याऐवजी files ची listing दिसल्यास, तुमची home directory इतर users ना वाचता येत आहे. त्यामुळे agent त्यातील स्वतंत्रपणे प्रतिबंधित नसलेल्या कोणत्याही गोष्टी वाचू शकतो, उदाहरणार्थ world-readable .env file. sudo chmod 700 /home/you वापरून हे दुरुस्त करा. तुमची private SSH key या चाचणीद्वारे संरक्षित होत नाही. इतर users ना उपलब्ध असलेली private key file ssh वापरत नाही. त्यामुळे तुमच्यासाठी प्रत्यक्षात कार्य करणारी कोणतीही key आधीपासून agent साठी unreadable असते, तुमच्या home directory चा mode काहीही असो.

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

तुमच्या 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 ची आहे: प्रक्रियेला कोणाशी network traffic करण्याची परवानगी आहे. Linux ज्या 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

नियम क्रमाने वाचले जातात. त्यामुळे आधीच्या ओळींनी परवानगी न दिलेल्या सर्व गोष्टी अंतिम REJECT नियम अडवतो. एजंट म्हणून याची चाचणी घ्या:

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

ही कमांड लगेच अयशस्वी झाली पाहिजे आणि curl: (7) Failed to connect to example.com error दिसला पाहिजे. त्यानंतरचे wording तुमच्या curl version नुसार बदलू शकते. Reject rule लगेच उत्तर देतो आणि connection hang होऊ देत नाही. त्याच host कडे केलेली HTTPS request यशस्वी झाली पाहिजे.

या पद्धतीला दोन स्पष्ट मर्यादा आहेत. पहिली, हे नियम save न केल्यास पुढील reboot नंतर नाहीसे होतात. ते save करण्यासाठी sudo apt install -y iptables-persistent आणि त्यानंतर sudo netfilter-persistent save वापरा. दुसरी, हे names नव्हे तर ports आणि addresses filter करते. Port 443 ला परवानगी देणारा नियम इंटरनेटवरील प्रत्येक 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 सुरक्षितपणे चालवणे या प्रत्येक permission स्तरामुळे नेमके काय प्रतिबंधित होते, हे स्पष्ट करते. तुमचे काम एका repository पुरते मर्यादित असेल आणि machine वर production credentials कुठेही नसतील, तर संभाव्य परिणामक्षेत्र आधीपासूनच लहान असते. Agent sessions लहान आणि तुमच्या देखरेखीखाली असतील, तर exposure window देखील लहान असते.

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

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

FAQ

कोडिंग agent साठी container मधील isolation पुरेसे आहे का?

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

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

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

माझी SSH key server वर न ठेवता agent ला 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 वापरा.

agent ला किती आकाराचा VPS आवश्यक आहे?

agent चे काम प्रामुख्याने files edit करणे, builds चालवणे आणि tests चालवणे असे असते. त्यामुळे machine चा आकार model साठी नव्हे, तर build साठी ठरवा. Hosted model provider च्या hardware वर चालतो. त्यामुळे network traffic वाढतो, पण local load जवळजवळ वाढत नाही. agent स्वतः काही किमान संसाधने आवश्यक करतो. October 20, 2026 रोजी उपलब्ध असलेल्या माहितीनुसार, Claude Code च्या system requirements मध्ये 4 GB RAM ही minimum आवश्यकता दिली आहे. Scripting work साठीसुद्धा 4 GB पासून सुरुवात करा. Repository containers build करत असल्यास किंवा मोठ्या प्रमाणावर compilation करत असल्यास 8 GB वर जा.

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

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