Coding agents کے لیے disposable VM کیوں بہتر ہے

عارضی VM آپ کے لیپ ٹاپ سے بہتر کیوں ہے

کسی coding agent کو عارضی VM دیں، تو اس کے اختیار میں بدترین کام یہ ہوگا کہ وہ ایسی مشین تباہ کر دے جسے آپ دس منٹ میں دوبارہ بنا سکتے ہیں۔ agent کو پھر بھی root کی رسائی حاصل ہوگی، وہ پھر بھی packages انسٹال کرے گا، اور ہر قدم کے لیے اجازت مانگے بغیر test suite چلائے گا۔ فرق صرف یہ ہے کہ نقصان کہاں ہوگا۔ لیپ ٹاپ پر agent آپ کی SSH keys، browser profile، .env files اور ہر اس repository کے ساتھ home directory شیئر کرتا ہے جسے آپ نے کبھی clone کیا ہے۔ عارضی server پر اس کے پاس shell، checkout اور چرانے کے قابل کوئی اور اہم چیز نہیں ہوتی۔

بات کا خلاصہ یہی ہے، اور یہ امکان کے بجائے عدم تناسب کا معاملہ ہے۔ محتاط لیپ ٹاپ پر محتاط agent تقریباً ہر بار ٹھیک رہتا ہے۔ جب ایک بار ایسا نہ ہو، تو نقصان صرف خراب commit نہیں ہوتا۔ اگر آپ کے پاس backup ہو، تو backup سے restore کرنا پڑتا ہے۔

بحث شروع کرنے سے پہلے نقصان کی حد متعین کریں

نقصان کی حد سے مراد ان چیزوں کا مجموعہ ہے جن تک کوئی عمل رسائی حاصل کر سکتا ہے۔ اگر کوئی agent آپ کی عام مشین پر آپ کے عام user کے طور پر چل رہا ہے، تو یہ مجموعہ عام تصور سے کہیں بڑا ہوتا ہے۔

اس میں ~/.ssh/id_ed25519 شامل ہے، جو عموماً encrypted نہیں ہوتا، کیونکہ آپ passphrase بار بار درج کرتے کرتے اکتا گئے تھے۔ اس میں ~/.aws/credentials اور ~/.config/gh/hosts.yml شامل ہیں، جو ڈیزائن کے لحاظ سے plain text ہوتے ہیں۔ اس میں ~/code کے اندر موجود ہر sibling repository شامل ہے، جن میں وہ repositories بھی شامل ہیں جن کی local env file میں production connection strings موجود ہیں۔ اس میں آپ کی shell history بھی شامل ہے، جس میں وہ tokens محفوظ ہو سکتے ہیں جو آپ نے ایک بار paste کیے تھے۔ اس میں وہ network بھی شامل ہے جس سے آپ کا laptop منسلک ہے۔ یہ اکثر home یا office network ہوتا ہے جس پر unauthenticated services دستیاب ہوتی ہیں۔

اس کے لیے malicious agent درکار نہیں ہوتا۔ صرف ایک ایسا command کافی ہے جو پورے اعتماد کے ساتھ غلط چلایا جائے۔ rm -rf میں unset variable کا / تک expand ہونا، غلط directory میں موجود git clean -xfd، ایسا docker system prune -af --volumes جو آپ کا local database بھی حذف کر دے، یا home directory پر چلایا گیا مددگار chmod -R 777۔ Agents اسی internet کے ڈیٹا پر trained ہوتے ہیں جس نے یہ commands باقی سب کو سکھائے ہیں۔

آپ کو محفوظ رکھنے والا طریقہ agent کی judgement نہیں ہے۔ اصل تحفظ یہ ہے کہ جس machine پر نقصان ہو سکتا ہے، وہ ایسی machine ہے جسے کھو دینے پر آپ آمادہ تھے۔

لاگت کا حساب اکتا دینے والا ہے، اور یہی مقصد ہے

ایک چھوٹے VPS کی ماہانہ لاگت چند ڈالر ہوتی ہے۔ ڈویلپر کے لیپ ٹاپ کو بحال کرنے میں ایک دن لگ سکتا ہے۔ یہ بہترین صورت ہے، جس میں آپ کو مسئلہ فوراً معلوم ہو جائے اور آپ کے پاس backup موجود ہو۔

اپنے اعداد و شمار سے حساب لگائیں۔ اپنی فی گھنٹہ شرح کو ان گھنٹوں کی تعداد سے ضرب دیں جو operating system دوبارہ انسٹال کرنے، home directory بحال کرنے، SSH key تبدیل کرنے، personal access token تبدیل کرنے، اور بیس repositories کو دوبارہ clone کرنے میں درکار ہوں گے۔ اس رقم کا موازنہ آپ کے provider کے فراہم کردہ سب سے چھوٹے server کے بارہ ماہ کے خرچ سے کریں۔ کئی سالوں میں ایک واقعے سے کم پر لاگت پوری ہو جاتی ہے۔ اس کے لیے واقعہ تباہ کن ہونا ضروری نہیں۔ مقامی environment کے خراب ہونے سے ضائع ہونے والی ایک دوپہر بھی پورے سال کی لاگت پوری کر دیتی ہے۔

اس حساب کا دوسرا حصہ snapshots ہیں۔ کسی خطرناک run سے پہلے snapshot لینے سے خراب نتیجہ "میری پوری زندگی بحال کریں" کے بجائے "واپس پچھلی حالت پر جائیں اور مختلف prompt آزمائیں" بن جاتا ہے۔ آپ جس لیپ ٹاپ پر یہ متن لکھ رہے ہیں، اس میں یہ اختیار موجود نہیں، کیونکہ جب آپ اسے اپنی میز کے طور پر استعمال کر رہے ہوں تو آپ اس machine کا snapshot نہیں لے سکتے۔

جولائی 2026 تک صورتِ حال

"ایجنٹ کہاں چلنا چاہیے؟" کے تین دیانت دار جواب ہیں۔ ان میں ہمیشہ انہی دو چیزوں کا توازن ہوتا ہے: حد بندی کتنی مضبوط ہے، اور آپ کتنی ترتیب قبول کرتے ہیں۔

مقامی micro VM۔ اس زمرے کے ٹولز آپ کے اپنے hardware پر ایک حقیقی virtual machine شروع کرتے ہیں، اس میں آپ کی repository mount کرتے ہیں، اور ایجنٹ کو اس کے اندر root کی اجازت دیتے ہیں۔ clawk اس وقت کی مثال ہے، اور اس کا بنیادی مؤقف اسی تحریر کے مرکزی خیال کے عین مطابق ہے: coding agents کو آپ کے laptop کے بجائے ایک عارضی Linux VM دیں۔ جولائی 2026 تک یہ Apple silicon پر macOS 14 اور بعد کے ورژنز کو ہدف بناتا ہے، جبکہ Firecracker کے ذریعے experimental Linux support بھی فراہم کرتا ہے، اور اسے brew install clawkwork/tap/clawk سے install کیا جاتا ہے۔ آپ sandbox شروع کرنے اور ایجنٹ attach کرنے کے لیے repository کے اندر clawk چلاتے ہیں، اسے روکنے کے لیے clawk down، اور اسے remove کرنے کے لیے clawk destroy چلاتے ہیں۔ حد بندی hypervisor ہے، اس لیے مضبوط ہے۔ حد یہ ہے کہ VM اسی machine پر چلتی ہے جسے آپ ساتھ لے کر چلتے ہیں۔ اس لیے یہ آپ کی memory کے لیے مقابلہ کرتی ہے اور lid بند کرنے پر رک جاتی ہے۔

Container۔ Docker وہ جواب ہے جو زیادہ تر لوگوں کے پاس پہلے ہی install ہوتا ہے، اور یہ واقعی مفید ہے۔

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

--rm خارج ہونے پر container کو ختم کر دیتا ہے، جبکہ --network none اسے network تک بالکل رسائی نہیں دیتا۔ build یا test run کے لیے یہ ایک اچھا default ہے۔ یہ بات واضح رہنی چاہیے کہ یہ کیا نہیں کرتا: container host kernel کو share کرتا ہے، اس لیے kernel bug باہر نکلنے کا راستہ بن سکتا ہے۔ جیسے ہی آپ --privileged شامل کرتے ہیں یا /var/run/docker.sock mount کرتے ہیں تاکہ ایجنٹ "Docker استعمال کر سکے"، حد بندی ختم ہو جاتی ہے۔ Docker socket کو container میں mount کرنا اس container کو host پر root دینے کے برابر ہے۔

ایسا plain VPS جسے آپ دوبارہ بنا سکتے ہیں۔ اس میں کوئی نیا tool درکار نہیں، حقیقی kernel boundary موجود ہوتی ہے، provider snapshots دستیاب ہوتے ہیں، اور laptop بند کرنے کے بعد بھی یہ چلتا رہتا ہے۔ اس guide کا باقی حصہ اسی pattern کو بیان کرتا ہے۔ طویل agent runs کے لیے بھی یہی طریقہ برقرار رہتا ہے، کیونکہ چار گھنٹے لینے والے job کو اس بات سے کوئی فرق نہیں پڑتا کہ آپ گھر چلے گئے ہیں۔

VPS کا طریقہ: agent کے لیے اپنا user بنائیں

ایک hardened box سے شروع کریں۔ نئے VPS پر پہلے دس منٹ میں وہ اقدامات شامل ہیں جو agent سے مخصوص نہیں ہیں: updates، non-root login، key-only SSH، اور firewall۔

اب ایک ایسا account بنائیں جو صرف 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 موجود نہیں، اور آپ sudo -u agent یا SSH key کے ذریعے اس account تک پہنچتے ہیں۔ یاد رکھیں کہ agent کو جان بوجھ کر sudo group میں شامل نہیں کیا گیا۔ sudo رکھنے والے agent کے پاس root access ہوتا ہے، اور root ہر دوسرے user کی files پڑھ سکتا ہے، اس لیے ابھی بنائی گئی علیحدگی محض ظاہری رہ جاتی ہے۔ اگر agent کو واقعی packages install کرنے کی ضرورت ہے، تو اس کی بنیاد ایک ایسے پورے server کے استعمال کا جواز ہے جس کا مالک وہ خود ہو، نہ کہ shared server پر اسے sudo دینا۔ عمومی اصول VPS پر Linux users کے لیے کم سے کم مراعات میں موجود ہیں۔

اس boundary کو اس پر اعتماد کرنے سے پہلے چیک کریں۔ 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 اس مشین پر نقل کر دیں تو عارضی مشین کا مقصد ہی ختم ہو جاتا ہے۔ اصول سادہ ہے: اس مشین پر ایسی کوئی credential نہیں ہونی چاہیے جسے آپ آج دوپہر کو تبدیل کرنا پسند نہ کریں۔

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 رہنے کے دوران، اس server پر root رکھنے والا کوئی بھی شخص forwarded socket استعمال کرکے آپ کے طور پر authenticate کر سکتا ہے۔ ایسی مشین پر جس کا واحد دوسرا user آپ خود ہوں، یہ قابل قبول سمجھوتا ہے۔ مشترکہ مشین پر ایسا نہیں ہے، اور صرف ایک repository تک محدود deploy key بہتر انتخاب ہے۔ اختیارات SSH key management کی بنیادی باتیں میں بیان کیے گئے ہیں۔

API keys کے لیے agent کو اپنی الگ key دیں، جس کی اپنی spending limit ہو، اور اسے ایسی file میں محفوظ کریں جس کا مالک agent user ہو اور mode 600 ہو۔ مشین تباہ ہونے پر اس key کو revoke کر دیں، بجائے اس کے کہ یہ سوچتے رہیں کہ شاید یہ leak ہو گئی ہو۔ ہر key کے لحاظ سے model spend کو نمایاں رکھنا ہی وہ طریقہ ہے جس سے VPS پر AI agent کے اخراجات کا کنٹرول میں موجود اعداد قابل پیش گوئی رہتے ہیں۔

نیٹ ورک پر agent کی رسائی محدود کریں

فائل سسٹم کی تنہائی حد کا نصف حصہ ہے۔ دوسرا نصف outbound 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

Rules کو ترتیب وار پڑھا جاتا ہے، اس لیے آخری REJECT ان تمام کنکشنز کو روکتا ہے جن کی پہلے والی سطروں نے اجازت نہیں دی۔ اسے agent کے طور پر test کریں:

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

اسے curl: (7) Failed to connect to example.com port 80: Connection refused کے ساتھ fail ہونا چاہیے، کیونکہ reject rule کنکشن کو معلق رہنے دینے کے بجائے فوراً جواب دیتی ہے۔ اسی host کو HTTPS request پھر بھی کامیاب ہونی چاہیے۔

دو اہم حدود ہیں۔ پہلی، اگلے reboot پر یہ rules ختم ہو جاتی ہیں، جب تک کہ آپ انہیں sudo apt install -y iptables-persistent اور پھر sudo netfilter-persistent save کے ذریعے save نہ کریں۔ دوسری، یہ names کے بجائے ports اور addresses کو filter کرتا ہے۔ Port 443 کی اجازت دینے والا rule internet پر موجود ہر HTTPS host کی اجازت دیتا ہے۔ اس سے model API تک رسائی بھی ممکن ہے اور pastebin تک بھی۔ حقیقی domain allow-list کے لیے traffic کو ایسے proxy سے گزرنا ہوگا جو requested hostname پڑھ سکے۔ یہ زیادہ تر single-developer setups کے لیے مطلوبہ اضافی پیچیدگی سے زیادہ ہے۔ صرف وہی دعویٰ کریں جو آپ نے حقیقتاً نافذ کیا ہے: port-level egress control، ایسی machine پر جسے کھونے کے لیے آپ تیار تھے۔

کاموں کے درمیان صاف حالت پر واپس جائیں

ہر کام کے لیے صاف حالت ایک کم سمجھی جانے والی سہولت ہے۔ ایک agent نے پچھلے ٹکٹ پر تین گھنٹے کام کیا، انسٹال شدہ packages، جزوی طور پر لاگو کی گئی migrations، ایک پرانا node_modules، اور ایسی git working tree چھوڑ دی جس میں کسی نے تبدیلیوں کا جائزہ نہیں لیا تھا۔ اگلا کام یہ سب کچھ وراثت میں حاصل کرتا ہے، اور آپ اپنا review budget یہ معلوم کرنے میں صرف کرتے ہیں کہ کون سا مسئلہ کس run سے متعلق ہے۔

آسان طریقہ یہ ہے کہ ہر کام کے لیے نیا 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 کرنے سے پورا system، packages سمیت، معلوم حالت میں واپس آ جاتا ہے۔ زیادہ تر providers یہ سہولت control panel یا API کے ذریعے دیتے ہیں، نہ کہ machine پر چلنے والی command کے طور پر، اس لیے درست طریقہ آپ کے provider پر منحصر ہے۔ اصول یہ ہے کہ snapshot اس وقت لیا جائے جب machine ابھی بالکل سادہ حالت میں ہو۔

جس چیز کی آپ کو ضرورت ہے، اسے disposable machine سے باہر رکھیں۔ عموماً اس کا مطلب یہ ہے کہ branches کو مقامی طور پر محفوظ رکھنے کے بجائے push کریں۔ اگر machine پر ایسی کوئی چیز موجود ہو جائے جس کے ضائع ہونے پر آپ کو افسوس ہو، تو VPS پر restic backups کے ذریعے اس کا مناسب backup لیں۔ ایسی machine جسے آپ destroy کر سکتے ہیں، صرف اسی وقت مفید ہے جب اسے destroy کرنا واقعی بے پیچیدگی ہو۔

اگر آپ کئی servers کے لیے ادائیگی کیے بغیر کئی isolated environments چاہتے ہیں، تو ایک بڑا VPS براہ راست guest VMs host کر سکتا ہے۔ VPS پر Nested virtualisation میں اس کا طریقہ بتایا گیا ہے، جس میں یہ جانچنا بھی شامل ہے کہ آیا آپ کا provider اس کی اجازت دیتا ہے۔

جب احتیاط کے ساتھ استعمال ہونے والا لیپ ٹاپ واقعی کافی ہو

اس بارے میں دیانت دار رہیں، کیونکہ تنہائی کو بڑھا چڑھا کر پیش کرنے سے لوگ سننا چھوڑ دیتے ہیں۔

اگر آپ ہر کمانڈ کے چلنے سے پہلے اس کا جائزہ لیتے ہیں تو لیپ ٹاپ کافی ہے۔ اجازت کا اشارہ ایک حقیقی کنٹرول ہے، اور سرور پر Claude Code کو محفوظ طریقے سے چلانا یہ واضح کرتا ہے کہ اس کی ہر سطح حقیقتاً کیا چیز روکتی ہے۔ اگر آپ کا کام ایک ہی repository تک محدود ہے اور مشین پر کہیں بھی production credentials موجود نہیں ہیں تو ممکنہ نقصان کا دائرہ پہلے ہی محدود ہے۔ اگر آپ کے agent sessions مختصر اور زیرِ نگرانی ہیں تو خطرے کی مدت بھی مختصر رہتی ہے۔

جس لمحے آپ prompts کو نظرانداز کرتے ہیں، فیصلہ بدل جاتا ہے۔ Unattended runs، رات بھر چلنے والے jobs، اور ایسا ہر workflow جس میں آپ plan منظور کرکے وہاں سے چلے جاتے ہیں، اس انسانی جانچ کو ختم کر دیتے ہیں جو containment فراہم کر رہی تھی۔ اس صورت میں یہ کام مشین کو خود کرنا ہوتا ہے۔ یہی بات agent کی رسائی بڑھانے والی ہر چیز پر لاگو ہوتی ہے، جس میں ایک ساتھ متعدد repositories پر VPS پر coding agent چلانا بھی شامل ہے۔

فیصلہ دراصل اس بات پر منحصر نہیں کہ آپ model پر کتنا اعتماد کرتے ہیں۔ اصل سوال یہ ہے کہ جب model غلط ہو تو اس کے ساتھ موجود کنٹرول کیا ہے۔

FAQ

کیا coding agent کے لیے container کافی isolation فراہم کرتا ہے؟

زیادہ تر کاموں کے لیے ہاں، لیکن 2 شرائط کے ساتھ۔ container کو --privileged کے ساتھ نہیں چلنا چاہیے، اور /var/run/docker.sock کو اس میں mount نہیں کرنا چاہیے، کیونکہ ان میں سے کوئی بھی عمل کو host کے root تک پہنچنے کا راستہ فراہم کرتا ہے۔ container، host kernel کا اشتراک کرتا ہے، اس لیے اس کی حد virtual machine کے مقابلے میں کمزور ہوتی ہے۔ اگر agent انٹرنیٹ سے حاصل کیا گیا untrusted code چلا رہا ہو، تو حقیقی VM یا الگ server استعمال کریں۔

کیا agent کو server پر sudo کی ضرورت ہے؟

نہیں۔ اسے sudo دینے سے آپ کی بنائی ہوئی isolation ختم ہو جاتی ہے، کیونکہ root، machine کے ہر دوسرے account کو پڑھ سکتا ہے۔ agent user کو sudo کے بغیر بنائیں اور اسے صرف اپنی work directory میں write access دیں۔ اگر کام کے لیے واقعی package installation درکار ہو، تو agent کو ایسی پوری machine دیں جس کا وہ مالک ہو، بجائے اس کے کہ مشترکہ machine پر اسے root access دیں۔

میں agent کو server پر اپنی SSH key رکھے بغیر 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 کو کس سائز کے VPS کی ضرورت ہوتی ہے؟

agent کا کام زیادہ تر files edit کرنا، builds چلانا، اور tests چلانا ہوتا ہے۔ اس لیے machine کا سائز model کے بجائے build کے مطابق مقرر کریں۔ hosted model provider کے hardware پر چلتا ہے، جس سے network traffic بڑھتا ہے لیکن local load تقریباً نہیں بڑھتا۔ scripting کے کام کے لیے 2 GB RAM سے شروع کریں، اور اگر repository containers build کرتی ہے یا کوئی بڑا compilation چلاتی ہے تو 8 GB تک بڑھائیں۔

مجھے machine کو کتنی بار تباہ کرکے دوبارہ بنانا چاہیے؟

جب state کی وضاحت ممکن نہ رہے، اور کم از کم اس وقت machine کو rebuild کریں جب اس پر موجود کوئی credential exposed ہو سکتا ہو۔ روزمرہ کی تبدیلیوں کے لیے tasks کے درمیان fresh checkout کافی ہوتا ہے۔ پہلے agent run سے قبل لیا گیا snapshot آپ کو واپس آنے کے لیے clean system image فراہم کرتا ہے۔ اگر rebuilding مہنگی محسوس ہو، تو یہ اس بات کی علامت ہے کہ کوئی اہم چیز ایسی machine پر موجود ہے جسے آپ نے disposable کہا تھا۔