Coding agents के लिए disposable VM का उपयोग कैसे करें

डिस्पोजेबल VM आपके लैपटॉप से बेहतर क्यों है

किसी कोडिंग एजेंट को डिस्पोजेबल VM देने पर सबसे बुरा यह हो सकता है कि वह ऐसी मशीन को नष्ट कर दे जिसे आप दस मिनट में फिर से बना सकते हैं। एजेंट को अभी भी root एक्सेस मिलता है, वह पैकेज इंस्टॉल करता है और बिना हर कदम पर अनुमति मांगे टेस्ट सूट चलाता है। अंतर केवल इस बात का है कि नुकसान कहाँ होता है। लैपटॉप पर, एजेंट आपके SSH keys, ब्राउज़र प्रोफाइल, .env फाइलों और आपके द्वारा क्लोन की गई हर दूसरी रिपॉजिटरी के साथ होम डायरेक्टरी साझा करता है। एक थ्रोअवे सर्वर पर, उसके पास केवल एक शेल और एक चेकआउट होता है, और वहां लेने लायक कुछ भी नहीं होता।

यही पूरा तर्क है, और यह संभावना के बजाय विषमता (asymmetry) के बारे में है। एक सावधान लैपटॉप पर एक सावधान एजेंट लगभग हर बार ठीक काम करता है। जिस एक बार यह नहीं होता, उस समय नुकसान केवल एक खराब कमिट नहीं होता। यदि आपके पास बैकअप है, तो यह उससे रिस्टोर करने की नौबत होती है।

तर्क करने से पहले blast radius निर्धारित करें

Blast radius का अर्थ उन सभी चीजों का समूह है, जिन तक कोई process पहुंच सकता है। आपकी सामान्य machine पर आपके सामान्य user के रूप में चल रहे agent के लिए यह समूह अधिकांश लोगों की कल्पना से बड़ा होता है।

इसमें ~/.ssh/id_ed25519 शामिल है, जो आम तौर पर unencrypted होता है, क्योंकि आप passphrase बार-बार type करते-करते थक गए। इसमें ~/.aws/credentials और ~/.config/gh/hosts.yml शामिल हैं, जो design के अनुसार plain text होते हैं। इसमें ~/code के अंतर्गत मौजूद हर sibling repository शामिल है, जिसमें वे repositories भी हैं जिनकी local env file में production connection strings हैं। इसमें आपकी shell history भी शामिल है, जिसमें आपके द्वारा एक बार paste किए गए tokens मौजूद हो सकते हैं। इसमें वह network भी शामिल है, जिस पर आपका laptop connected है। वह अक्सर home या office network होता है, जिसमें unauthenticated services चल रही होती हैं।

इनमें से किसी के लिए malicious agent की आवश्यकता नहीं है। इसके लिए केवल एक ऐसा command पर्याप्त है, जो पूरे confidence के साथ गलत चलाया गया हो। rm -rf "$BUILD_DIR"/* को BUILD_DIR unset होने पर चलाना, जिससे वह /* में expand हो जाता है और GNU rm के default रूप से / को स्वयं delete करने से इनकार करने वाले व्यवहार से बच निकलता है; गलत directory में मौजूद git clean -xfd; ऐसा docker system prune -af --volumes, जो आपके local database को भी अपने साथ delete कर दे; या home directory पर चलाया गया कोई मददगार chmod -R 777। Agents को उसी internet पर train किया जाता है, जिसने ये commands बाकी सभी लोगों को भी सिखाए हैं।

आपको बचाने वाला mechanism agent का judgement नहीं है। सुरक्षा इस बात से आती है कि जिस machine पर नुकसान हो सकता है, वह ऐसी machine है जिसे खोने का जोखिम आप स्वीकार कर चुके थे।

लागत का गणित उबाऊ है, और यही इसका मुख्य उद्देश्य है

एक छोटा VPS हर महीने कुछ डॉलर का खर्च लाता है। एक developer laptop को रिकवर करने में पूरा दिन लग जाता है, और यह तब है जब सब कुछ ठीक रहे, यानी आपको तुरंत पता चल जाए और आपके पास backup मौजूद हो।

इसे अपने आंकड़ों के साथ समझें। अपनी प्रति घंटा दर (hourly rate) लें, और उसे उन घंटों से गुणा करें जो एक operating system को reinstall करने, home directory को restore करने, SSH key को rotate करने, personal access token को rotate करने और बीस repositories को फिर से clone करने में लगेंगे। इसकी तुलना अपने provider द्वारा बेचे जाने वाले सबसे छोटे सर्वर के 12 महीनों के खर्च से करें। break-even बिंदु हर कुछ वर्षों में एक incident से भी कम पर आ जाता है, और उस incident का विनाशकारी होना भी जरूरी नहीं है। एक corrupted local environment के कारण बर्बाद हुई एक दोपहर ही पूरे साल का खर्च निकाल देती है।

इस गणित का दूसरा हिस्सा snapshots हैं। किसी जोखिम भरे काम को करने से पहले लिया गया snapshot एक बुरे परिणाम को "मेरी पूरी मेहनत वापस लाओ" से बदलकर "roll back करो और दूसरा तरीका आजमाओ" में बदल देता है। यह विकल्प उस laptop पर मौजूद नहीं होता जिस पर आप अभी टाइप कर रहे हैं, क्योंकि जब आप किसी मशीन का उपयोग अपने डेस्क के रूप में कर रहे होते हैं, तो आप उसका snapshot नहीं ले सकते।

अक्टूबर 2026 की स्थिति

"Agent कहाँ चलना चाहिए" के तीन स्पष्ट उत्तर हैं। इन सभी में वही दो बातें संतुलित करनी होती हैं: boundary कितनी मजबूत है और आप कितना setup स्वीकार कर सकते हैं।

एक local micro VM। इस category के tools आपके अपने hardware पर real virtual machine boot करते हैं, उसमें आपका repository mount करते हैं और agent को उसके अंदर root access देते हैं। clawk इसका वर्तमान example है। इसका मुख्य उद्देश्य इसी लेख के निष्कर्ष के अनुरूप है: coding agents को आपके laptop के बजाय disposable Linux VM दें। अक्टूबर 2026 तक यह Apple silicon वाले macOS 14 और बाद के versions को target करता है। Firecracker के माध्यम से Linux support experimental है और इसे brew install clawkwork/tap/clawk से install किया जाता है। Sandbox boot करने और agent attach करने के लिए किसी repository के अंदर clawk चलाएँ। इसे रोकने के लिए clawk down और हटाने के लिए clawk destroy चलाएँ। इसकी boundary hypervisor है, इसलिए यह मजबूत है। इसकी सीमा यह है कि VM उसी machine पर चलती है जिसे आप साथ लेकर चलते हैं। इसलिए यह आपकी memory के लिए अन्य workloads से प्रतिस्पर्धा करती है और lid बंद करने पर रुक जाती है।

एक container। Docker वह उत्तर है जो अधिकांश लोगों के system पर पहले से installed होता है और यह वास्तव में उपयोगी है।

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 के माध्यम से boundary से बाहर निकलने का रास्ता हो सकता है। जैसे ही आप --privileged जोड़ते हैं या /var/run/docker.sock mount करते हैं, boundary समाप्त हो जाती है, ताकि agent "Docker का उपयोग" कर सके। Docker socket को container में mount करना उस container को host पर root access देने के बराबर है।

एक plain VPS जिसे आप फिर से बना सकें। इसमें किसी नए tool की जरूरत नहीं होती, real kernel boundary और provider snapshots मिलते हैं, और laptop बंद करने पर भी यह चलता रहता है। इस guide का बाकी भाग इसी pattern का वर्णन करता है। लंबे agent runs के लिए यही pattern टिकाऊ रहता है, क्योंकि चार घंटे चलने वाले job को इस बात से कोई फर्क नहीं पड़ता कि आप घर चले गए हैं।

VPS pattern: agent के लिए अपना user दें

Hardened box से शुरू करें। नए VPS पर पहले दस मिनट उन हिस्सों को कवर करते हैं जो agent-विशिष्ट नहीं हैं: updates, non-root login, केवल key से SSH access और firewall।

इसके बाद ऐसा account बनाएँ जो केवल agent के लिए हो। इससे agent के भीतर हुई किसी गलती का असर 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 का अर्थ है कि guess करने के लिए कोई password नहीं है। आप इस account में sudo -u agent या SSH key से पहुँचते हैं। ध्यान दें कि agent को जानबूझकर sudo group में नहीं रखा गया है। sudo वाले agent के पास root access होता है। root हर दूसरे user की files पढ़ सकता है, इसलिए अभी बनाई गई separation केवल दिखावटी रह जाएगी। यदि agent को वास्तव में packages install करने की जरूरत है, तो यह उसके लिए पूरे server का तर्क है, न कि shared server पर उसे sudo देने का। सामान्य नियम VPS पर Linux users के लिए least privilege में दिए गए हैं।

इस पर भरोसा करने से पहले boundary की जाँच करें। agent user के रूप में अपने account की home directory की listing देखें:

sudo -u agent ls /home/you

आपको ls: cannot open directory '/home/you': Permission denied दिखाई देना चाहिए। यदि इसके बजाय files की listing दिखाई दे, तो आपकी home directory अन्य users के लिए readable है। तब agent उसमें मौजूद उन सभी files को पढ़ सकता है जिन्हें अलग से restricted नहीं किया गया है, जैसे world-readable .env file। इसे sudo chmod 700 /home/you से ठीक करें। यह test आपकी private SSH key की सुरक्षा नहीं करता। ssh ऐसी private key file को स्वीकार नहीं करता जिसे अन्य users access कर सकते हों। इसलिए आपके लिए वास्तव में काम करने वाली कोई भी key पहले से ही agent के लिए unreadable है, चाहे आपकी home directory का mode कुछ भी हो।

क्रेडेंशियल्स को मशीन से पूरी तरह दूर रखें

डिस्पोजेबल मशीन का उद्देश्य तब विफल हो जाता है यदि आप उस पर अपने प्रोडक्शन सीक्रेट्स कॉपी कर लेते हैं। नियम सरल है: उस बॉक्स पर ऐसी कोई भी चीज़ क्रेडेंशियल के रूप में नहीं होनी चाहिए जिसे आज दोपहर रोटेट करने में आपको कोई आपत्ति हो।

git के लिए, की (key) कॉपी करने के बजाय अपने SSH agent को फॉरवर्ड करें। प्राइवेट की आपके लैपटॉप पर ही रहती है और केवल सिग्नेचर रिक्वेस्ट ही कनेक्शन के माध्यम से जाती हैं।

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

दूसरा कमांड Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. का उत्तर देना चाहिए। यह साबित करता है कि सर्वर पर कोई की-फाइल मौजूद न होने पर भी git push काम करेगा। इसके बाद बॉक्स पर ls -la ~/.ssh चलाएं और पुष्टि करें कि इसमें कोई प्राइवेट की नहीं है।

एजेंट फॉरवर्डिंग की एक वास्तविक चेतावनी है, इसलिए इसे स्पष्ट रूप से समझें: जब तक आप कनेक्टेड हैं, उस सर्वर पर रूट एक्सेस वाला कोई भी व्यक्ति आपकी ओर से ऑथेंटिकेट करने के लिए फॉरवर्ड किए गए सॉकेट का उपयोग कर सकता है। ऐसे सर्वर पर जिसका एकमात्र अन्य उपयोगकर्ता आप स्वयं हैं, यह एक स्वीकार्य समझौता है। एक शेयर्ड बॉक्स पर ऐसा नहीं है, और एक रिपॉजिटरी तक सीमित 'डिप्लॉय की' (deploy key) बेहतर विकल्प है। इन विकल्पों को SSH key management basics में कवर किया गया है।

API कीज़ के लिए, एजेंट को उसकी अपनी की दें जिसकी अपनी स्पेंडिंग लिमिट हो, जिसे agent उपयोगकर्ता के स्वामित्व वाली फाइल में मोड 600 पर स्टोर किया गया हो। जब मशीन को नष्ट किया जाए, तो उस की को रिवोक (revoke) कर दें, बजाय इसके कि यह सोचें कि क्या वह लीक हो गई है। प्रति की मॉडल खर्च को दृश्यमान रखना ही वह तरीका है जिससे AI agent cost control on a VPS में आंकड़े अनुमानित बने रहते हैं।

Agent की नेटवर्क पहुँच सीमित करें

Filesystem isolation सीमा का केवल आधा भाग है। दूसरा आधा egress है: process किन endpoints से network traffic कर सकता है। Linux उस user के आधार पर outbound traffic filter कर सकता है जिसने इसे शुरू किया है। यह इस pattern के लिए बिल्कुल उपयुक्त है।

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 उन सभी connections को पकड़ लेता है जिन्हें पहले की lines ने allow नहीं किया। इसे agent के रूप में test करें:

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

यह तुरंत curl: (7) Failed to connect to example.com error के साथ fail होना चाहिए। इसके बाद का wording आपके curl version के अनुसार अलग हो सकता है, क्योंकि reject rule connection को hang होने देने के बजाय तुरंत response देती है। उसी host पर HTTPS request फिर भी सफल होनी चाहिए।

दो सीमाएँ स्पष्ट रूप से समझें। पहली, अगला reboot होने पर ये rules समाप्त हो जाते हैं, जब तक आप उन्हें save न करें। इसके लिए पहले sudo apt install -y iptables-persistent और फिर sudo netfilter-persistent save चलाएँ। दूसरी, यह ports और addresses को filter करता है, names को नहीं। Port 443 को allow करने वाली rule internet पर मौजूद हर HTTPS host को allow करती है। इससे model API तक पहुँचना संभव होता है और pastebin तक पहुँचना भी। वास्तविक domain allow-list के लिए traffic को ऐसे proxy से होकर जाना होगा जो requested hostname पढ़ सके। अधिकांश single-developer setups के लिए यह अतिरिक्त machinery उचित नहीं होती। केवल वही दावा करें जो आपने वास्तव में लागू किया है: ऐसी machine पर port-level egress control, जिसे खोने के लिए आप तैयार थे।

कार्यों के बीच क्लीन स्टेट पर रीसेट करना

प्रत्येक कार्य के लिए क्लीन स्टेट (clean state) का होना एक ऐसा लाभ है जिसे अक्सर कम आंका जाता है। जिस एजेंट ने पिछले टिकट पर तीन घंटे बिताए, उसने पीछे इंस्टॉल किए गए पैकेज, आधे-अधूरे लागू किए गए माइग्रेशन, एक पुराना node_modules, और एक ऐसा git वर्किंग ट्री छोड़ दिया जिसके बदलावों की किसी ने समीक्षा नहीं की। अगला कार्य इन सबको विरासत में ले लेता है, और आप अपना समीक्षा बजट यह पता लगाने में खर्च करते हैं कि कौन सी गंदगी किस रन (run) की है। एक सीमित दायरा रखने वाला एजेंट पहली बार में ही कम चीजें पीछे छोड़ता है, इसलिए एक डिस्पोजेबल मशीन को ऐसी स्किल जो एजेंट को सबसे छोटे कार्यशील बदलाव की ओर ले जाती है के साथ जोड़ना, diff और बची हुई स्टेट दोनों को इतना छोटा रखता है कि उनकी समीक्षा की जा सके।

इसका सस्ता संस्करण प्रत्येक कार्य के लिए एक फ्रेश चेकआउट (fresh checkout) है।

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

इसका अधिक प्रभावी संस्करण एक प्रोवाइडर स्नैपशॉट है, जिसे मशीन सेटअप होने के तुरंत बाद और किसी भी एजेंट के उसे छूने से पहले लिया जाता है। उस स्नैपशॉट को रिस्टोर करने से पूरा सिस्टम, जिसमें पैकेज भी शामिल हैं, एक ज्ञात स्टेट में वापस आ जाता है। अधिकांश प्रोवाइडर इसे कंट्रोल पैनल में या API के माध्यम से उपलब्ध कराते हैं, न कि बॉक्स पर किसी कमांड के रूप में, इसलिए सटीक चरण आपके प्रोवाइडर के अनुसार होंगे। अनुशासन यह है कि स्नैपशॉट तब लें जब मशीन अभी भी सामान्य (boring) हो।

ऐसी किसी भी चीज़ को डिस्पोजेबल मशीन पर न रखें जिसकी आपको परवाह है, जिसका मुख्य अर्थ है शाखाओं (branches) को स्थानीय रूप से जमा करने के बजाय उन्हें पुश करना। यदि बॉक्स में वास्तव में कुछ ऐसा रह जाता है जिसे आप खोना नहीं चाहते, तो VPS पर restic बैकअप के साथ उसका उचित बैकअप लें। एक मशीन जिसे आप नष्ट कर सकते हैं, तभी उपयोगी है जब उसे नष्ट करना वास्तव में सामान्य बात हो।

यदि आप कई सर्वरों के लिए भुगतान किए बिना कई अलग-थलग वातावरण चाहते हैं, तो एक बड़ा VPS सीधे गेस्ट VM को होस्ट कर सकता है। VPS पर नेस्टेड वर्चुअलाइजेशन यह बताता है कि यह कैसे काम करता है, जिसमें यह भी शामिल है कि यह कैसे जांचें कि आपका प्रोवाइडर इसकी अनुमति देता है या नहीं। आइसोलेशन यहाँ दोनों तरफ काम करता है, और यदि आप एक ही बॉक्स पर दो एजेंटों को एक-दूसरे से अलग रहने के बजाय समन्वय (coordinate) करने देना चाहते हैं, तो एक Claude Code सेशन सीधे दूसरे को टेक्स्ट भेज सकता है, बजाय इसके कि हर हैंडऑफ को आपके माध्यम से रूट किया जाए।

जब सावधानी के साथ laptop का उपयोग किया जाए, तो वह वास्तव में पर्याप्त है

इस बारे में ईमानदार रहें, क्योंकि isolation को बढ़ा-चढ़ाकर पेश करने से लोग सलाह पर भरोसा करना बंद कर देते हैं।

यदि आप हर command चलने से पहले उसकी समीक्षा करते हैं, तो laptop पर्याप्त है। Permission prompt एक वास्तविक नियंत्रण है, और server पर Claude Code को सुरक्षित रूप से चलाना बताता है कि इसका प्रत्येक स्तर वास्तव में क्या रोकता है। यदि आपका काम एक ही repository तक सीमित है और machine पर कहीं भी production credentials नहीं हैं, तो संभावित नुकसान का दायरा पहले ही छोटा है। यदि आपके agent sessions छोटे और आपकी निगरानी में हैं, तो exposure window भी छोटी रहती है।

जैसे ही आप prompts को skip करते हैं, स्थिति बदल जाती है। यह बात अभी विचार करने योग्य है, क्योंकि auto mode अब Claude Code का default है और fresh install अब files edit करने या commands चलाने से पहले आपसे अनुमति नहीं मांगता। Unattended runs, overnight jobs और ऐसे सभी workflows जिनमें आप plan approve करके चले जाते हैं, उस human check को हटा देते हैं जो containment सुनिश्चित कर रहा था। उस समय यह काम machine को करना पड़ता है। यही बात agent की पहुंच बढ़ाने वाली किसी भी व्यवस्था पर लागू होती है, जिसमें VPS पर coding agent चलाना और एक साथ कई repositories पर काम करना शामिल है।

निर्णय वास्तव में इस बात पर निर्भर नहीं करता कि आप model पर कितना भरोसा करते हैं। यह इस बात पर निर्भर करता है कि model के गलत होने पर उसके पास क्या मौजूद है।

FAQ

क्या coding agent के लिए container पर्याप्त isolation देता है?

अधिकांश काम के लिए हाँ, दो शर्तों के साथ। container को --privileged के साथ run नहीं करना चाहिए और इसमें /var/run/docker.sock mount नहीं होना चाहिए, क्योंकि इनमें से कोई भी process को host के root तक पहुँचने का रास्ता देता है। container host kernel share करता है, इसलिए इसकी boundary virtual machine की तुलना में कमजोर होती है। यदि agent internet से प्राप्त untrusted code चला रहा है, तो वास्तविक VM या अलग server को प्राथमिकता दें।

क्या agent को server पर sudo की जरूरत है?

नहीं। उसे sudo देने से बनाई गई isolation समाप्त हो जाती है, क्योंकि root server पर हर दूसरे account को पढ़ सकता है। agent user को sudo के बिना बनाएँ और उसे केवल अपनी work directory में write access दें। यदि task के लिए वास्तव में package installation चाहिए, तो agent को साझा machine पर root देने के बजाय ऐसी पूरी machine दें जिसका वह स्वयं owner हो।

SSH key को server पर रखे बिना 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 का उपयोग कर सकता है। इसलिए ऐसी किसी machine पर, जिसे आप अन्य लोगों के साथ share करते हैं, repository-scoped deploy key का उपयोग करें।

Agent को किस size का VPS चाहिए?

Agent का काम मुख्यतः files edit करना, builds चलाना और tests चलाना होता है। इसलिए machine का size model के बजाय build के अनुसार तय करें। Hosted model provider के hardware पर चलता है, जिससे network traffic बढ़ता है, लेकिन local load लगभग नहीं बढ़ता। फिर भी agent स्वयं न्यूनतम संसाधन तय करता है: October 20, 2026 तक Claude Code की system requirements में minimum 4 GB RAM दी गई है। Scripting work के लिए भी 4 GB से शुरू करें। यदि repository containers build करती है या कोई substantial compilation करती है, तो 8 GB पर जाएँ।

Machine को कितनी बार destroy और rebuild करना चाहिए?

जब machine की state का कारण स्पष्ट न रहे, तब rebuild करें। कम से कम तब भी rebuild करें, जब box पर मौजूद किसी credential के exposed होने की आशंका हो। रोज़मर्रा के drift को संभालने के लिए tasks के बीच fresh checkout पर्याप्त होता है। पहले agent run से पहले लिया गया snapshot आपको लौटने के लिए clean system image देता है। यदि rebuild करना महँगा लगता है, तो यह संकेत है कि disposable कही गई machine पर कोई महत्वपूर्ण चीज़ रह रही है।