AI coding agent کے لیے disposable VM کیوں دیں؟

آپ کے laptop سے عارضی VM کیوں زیادہ محفوظ انتخاب ہے

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

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

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

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

اس میں ~/.ssh/id_ed25519 شامل ہے، جو عموماً encrypted نہیں ہوتی، کیونکہ آپ passphrase بار بار درج کرتے درج کرتے اکتا گئے تھے۔ اس میں ~/.aws/credentials اور ~/.config/gh/hosts.yml بھی شامل ہیں، جو design کے لحاظ سے plain text ہوتے ہیں۔ اس میں ~/code کے تحت موجود ہر sibling repository شامل ہے، ان repositories سمیت جن کی local env file میں production connection strings موجود ہیں۔ اس میں آپ کی shell history بھی شامل ہے، جس میں وہ tokens محفوظ ہیں جو آپ نے کبھی ایک بار paste کیے تھے۔ اس میں وہ network بھی شامل ہے جس سے آپ کا laptop منسلک ہے۔ یہ اکثر home یا office network ہوتا ہے جس پر authentication کے بغیر 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 سے تربیت پاتے ہیں جس نے یہ commands باقی سب کو سکھائے ہیں۔

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

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

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

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

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

جولائی 2026 تک منظرنامہ

اس سوال کے کہ "agent کہاں چلنا چاہیے"، تین واضح جواب ہیں۔ ان میں وہی دو چیزیں باہم متوازن ہوتی ہیں: boundary کتنی مضبوط ہے، اور آپ کتنا setup برداشت کر سکتے ہیں۔

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

ایک container۔ Docker وہ جواب ہے جو زیادہ تر لوگوں کے systems پر پہلے سے 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 کے ذریعے باہر نکلنے کا راستہ موجود رہتا ہے، اور جیسے ہی آپ --privileged شامل کرتے ہیں یا /var/run/docker.sock mount کرتے ہیں تاکہ agent "Docker استعمال کر سکے"، boundary ختم ہو جاتی ہے۔ Docker socket کو container میں mount کرنا اس container کو host پر root access دینے کے برابر ہے۔

ایک سادہ VPS جسے آپ دوبارہ rebuild کر سکتے ہیں۔ اس میں کسی نئے 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 کا مطلب ہے کہ اندازے سے کوئی password معلوم نہیں کیا جا سکتا، اور آپ sudo -u agent یا SSH key کے ذریعے اس account تک پہنچتے ہیں۔ یاد رکھیں کہ agent کو جان بوجھ کر sudo group میں شامل نہیں کیا گیا۔ sudo والا agent root رکھتا ہے، اور 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 اس مشین پر copy کر دیں تو disposable machine کا مقصد ہی ختم ہو جاتا ہے۔ اصول سادہ ہے: اس machine پر ایسی کوئی credential نہیں ہونی چاہیے جسے آپ آج دوپہر rotate کرنا پسند نہ کریں۔

git کے لیے key copy کرنے کے بجائے اپنا 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 موجود نہ ہونے کے باوجود کام کرے گا۔ اس کے بعد machine پر ls -la ~/.ssh چلائیں اور تصدیق کریں کہ اس میں کوئی private key موجود نہیں ہے۔

Agent forwarding میں ایک حقیقی caveat ہے، اس لیے اسے واضح طور پر بیان کریں: connection برقرار رہنے کے دوران، اس server پر root رکھنے والا کوئی بھی شخص forwarded socket استعمال کرکے آپ کی حیثیت سے authenticate کر سکتا ہے۔ اگر اس server کا واحد دوسرا user آپ خود ہیں تو یہ قابل قبول trade-off ہے۔ Shared box پر ایسا نہیں ہے، اور صرف ایک repository تک محدود deploy key بہتر حل ہے۔ اختیارات SSH key management کی بنیادی باتیں میں بیان کیے گئے ہیں۔

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

ایجنٹ کی نیٹ ورک تک رسائی محدود کریں

فائل سسٹم کی isolation حدود کا نصف حصہ ہے۔ دوسرا نصف egress ہے: یعنی وہ destinations جن سے process کو network پر بات کرنے کی اجازت ہے۔ Linux اس process کو بنانے والے 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 نے اجازت نہیں دی۔ اسے 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 فوراً جواب دیتی ہے اور connection کو معلق رہنے نہیں دیتی۔ اسی host کو HTTPS request بھیجنے کی کوشش اب بھی کامیاب ہونی چاہیے۔

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

کاموں کے درمیان صاف حالت بحال کریں

ہر کام کے لیے صاف حالت ایک کم توجہی حاصل کرنے والا فائدہ ہے۔ ایک agent نے پچھلے ticket پر تین گھنٹے کام کیا، لیکن installed packages، ادھوری migrations، ایک پرانا node_modules، اور ایسا git working tree چھوڑ دیا جس میں کسی نے تبدیلیوں کا جائزہ نہیں لیا تھا۔ اگلا کام یہ سب کچھ inherited حالت میں حاصل کرتا ہے، اور آپ اپنا review budget اس بات کا تعین کرنے میں صرف کرتے ہیں کہ کون سی خرابی کس run سے متعلق ہے۔ محدود دائرے والا agent ابتدا ہی میں کم چیزیں پیچھے چھوڑتا ہے۔ اس لیے disposable machine کو ایسی skill کے ساتھ جوڑنا جو agent کو کام کرنے والی سب سے چھوٹی تبدیلی کی طرف لے جائے diff اور باقی ماندہ state، دونوں کو جائزے کے لیے کافی حد تک محدود رکھتا ہے۔

اس کا آسان طریقہ ہر کام کے لیے fresh checkout ہے۔

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

زیادہ مضبوط طریقہ provider snapshot ہے، جو machine set up کرنے کے فوراً بعد اور کسی agent کے اسے استعمال کرنے سے پہلے صرف ایک بار لیا جائے۔ اس snapshot کو restore کرنے سے packages سمیت پورا system ایک معلوم حالت میں واپس آ جاتا ہے۔ زیادہ تر providers یہ سہولت box پر command کے بجائے control panel یا API کے ذریعے دیتے ہیں، اس لیے درست مراحل آپ کے provider پر منحصر ہیں۔ اصول یہ ہے کہ snapshot اس وقت لیا جائے جب machine ابھی غیر تبدیل شدہ ہو۔

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

اگر آپ متعدد servers کے لیے ادائیگی کیے بغیر کئی isolated environments چاہتے ہیں، تو ایک بڑا VPS براہ راست guest VMs host کر سکتا ہے۔ VPS پر nested virtualisation میں اس کا طریقہ بیان کیا گیا ہے، جس میں یہ جانچنا بھی شامل ہے کہ آیا آپ کا provider اسے اجازت دیتا ہے۔ یہاں isolation کے دونوں پہلو ہیں۔ اگر آپ ایک ہی box پر دو agents کو ایک دوسرے سے الگ رہنے کے بجائے باہمی coordination کرنا چاہتے ہیں، تو ایک Claude Code session براہ راست دوسرے کو text بھیج سکتا ہے اور ہر handoff کو اپنے ذریعے route کرنے کی ضرورت نہیں رہتی۔

جب احتیاط کے ساتھ laptop واقعی کافی ہوتا ہے

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

اگر آپ ہر command کے چلنے سے پہلے اس کا جائزہ لیتے ہیں تو laptop کافی ہے۔ اجازت کی prompt ایک حقیقی control ہے، اور server پر Claude Code محفوظ طریقے سے چلانے میں بتایا گیا ہے کہ اس کی ہر سطح حقیقتاً کیا روکتی ہے۔ اگر آپ کا کام ایک ہی repository تک محدود ہے اور machine پر کہیں بھی production credentials موجود نہیں ہیں تو ممکنہ نقصان کا دائرہ پہلے ہی محدود ہے۔ اگر آپ کے agent sessions مختصر اور زیر نگرانی ہیں تو exposure window بھی مختصر رہتی ہے۔

جس لمحے آپ prompts کو نظر انداز کرتے ہیں، جواب بدل جاتا ہے۔ یہ بات اب خاص طور پر اہم ہے، کیونکہ 14 August 2026 کو auto mode Claude Code کا default بن جاتا ہے اور نئی installation files میں ترمیم یا commands چلانے سے پہلے مزید نہیں پوچھتی۔ Unattended runs، رات بھر چلنے والے jobs، اور وہ تمام workflows جن میں آپ plan approve کرکے وہاں سے چلے جاتے ہیں، اس انسانی جانچ کو ختم کر دیتے ہیں جو containment فراہم کر رہی تھی۔ اس کے بعد یہ کام machine کو خود کرنا پڑتا ہے۔ یہی بات agent کی رسائی بڑھانے والی ہر چیز پر لاگو ہوتی ہے، جس میں VPS پر coding agent چلانا اور بیک وقت کئی repositories پر کام کرنا بھی شامل ہے۔

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

FAQ

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

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

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

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

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 استعمال کر سکتا ہے۔ اس لیے ایسی 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 work کے لیے 2 GB RAM سے شروع کریں، اور اگر repository containers build کرتی ہو یا کوئی بڑا codebase compile کرتی ہو تو 8 GB تک جائیں۔

machine کو کتنی بار destroy اور rebuild کرنا چاہیے؟

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