سرور پر Claude Code محفوظ طریقے سے کیسے چلائیں

سرور پر Claude Code کو محفوظ طریقے سے چلانے کا مطلب

سرور پر Claude Code محفوظ طریقے سے چلانے کے لیے اس کے permission prompts فعال رکھیں، اسے ایک dedicated unprivileged user کے طور پر چلائیں، اور unattended runs کے لیے اعتماد کے بجائے حقیقی boundary فراہم کریں: built-in sandbox، container، یا disposable VPS جس میں کوئی اہم data موجود نہ ہو۔ --dangerously-skip-permissions flag model اور آپ کے shell کے درمیان approval step ختم کر دیتا ہے۔ unattended کام کے لیے یہ trade-off قابلِ قبول ہو سکتا ہے، لیکن صرف ایسی boundary کے اندر جو کسی ایک خراب command کی رسائی کو محدود کرے۔ یہ guide وضاحت کرتی ہے کہ یہ flag حقیقت میں کیا تبدیل کرتا ہے، اور بڑھتی ہوئی isolation کی سطحوں کے ساتھ یہ boundary کیسے بنائی جائے۔

آپ کے server پر Claude Code کیا کر سکتا ہے

Claude Code ایک coding agent ہے جو آپ کے terminal میں چلتا ہے۔ یہ files پڑھتا ہے، files لکھتا ہے، اور اسے شروع کرنے والے user کے طور پر shell commands چلاتا ہے۔ اس tool کی پوری افادیت یہی ہے: یہ repository clone کر سکتا ہے، code edit کر سکتا ہے، tests چلا سکتا ہے، failure پڑھ سکتا ہے، اور loop میں code ٹھیک کر سکتا ہے، جبکہ آپ کو ہر command خود type نہیں کرنی پڑتی۔ اگر آپ نے اسے ابھی کسی server پر setup نہیں کیا تو VPS پر tmux کے ساتھ Claude Code چلانا installation اور session handling بیان کرتا ہے۔ یہ صفحہ اس بات کا احاطہ کرتا ہے کہ Claude Code چلنے کے بعد آپ اسے کتنے اختیارات دیتے ہیں۔

خطرہ اسی جملے کو دوسری بار پڑھنے سے واضح ہوتا ہے۔ جو process آپ کے user کے طور پر shell commands چلا سکتا ہے، وہ ہر وہ کام کر سکتا ہے جو آپ کا user کر سکتا ہے۔ یہ ~/.ssh/id_ed25519، ~/.aws/credentials، اور وہ تمام .env files پڑھ سکتا ہے جنہیں آپ کا user کھول سکتا ہے۔ یہ curl چلا سکتا ہے اور server کی رسائی میں موجود کسی بھی host کو data بھیج سکتا ہے۔ یہ git push --force چلا سکتا ہے۔ Agent کا اپنا کوئی مقصد نہیں ہوتا۔ خطرہ اس وقت پیدا ہوتا ہے جب task غلط ہو جائے، یا جب کام کے دوران پڑھے گئے text میں کسی دوسرے شخص کی لکھی ہوئی ہدایات شامل ہوں: مثلاً کوئی web page جسے اس نے fetch کیا ہو، یا کسی issue میں موجود comment جسے اسے ٹھیک کرنے کے لیے کہا گیا ہو۔ دوسری صورت کو prompt injection کہا جاتا ہے، اور اسی لیے "model عموماً سمجھ داری سے کام لیتا ہے" security plan نہیں ہے۔ ہدایات قریب کے ذریعہ سے بھی آ سکتی ہیں، کیونکہ ایک ہی box پر Claude Code کے دو sessions ایک دوسرے کو text بھیج سکتے ہیں، اور sibling session کا message بھی receiving agent کے لیے صرف وہی مزید text ہوتا ہے جسے وہ پڑھتا ہے۔ منصوبہ خراب run کے لیے بنائیں، اوسط run کے لیے نہیں۔

اجازتوں کا نظام سادہ الفاظ میں

بنیادی ترتیب میں Claude Code کوئی کارروائی کرنے سے پہلے اجازت مانگتا ہے۔ پروجیکٹ کے اندر فائلیں پڑھنے کا عمل خاموشی سے ہوتا ہے، لیکن فائل میں ترمیم کرنے یا shell command چلانے سے پہلے یہ عین ترمیم یا command دکھاتا ہے اور آپ کے ہاں کہنے کا انتظار کرتا ہے۔ آپ کسی ایک کارروائی کی اجازت دے سکتے ہیں، یا سیشن کے باقی حصے کے لیے اسی نوعیت کی کارروائی کی اجازت دے سکتے ہیں۔ یہ اجازتیں سیشن تک محدود ہوتی ہیں: CLI سے باہر نکلنے پر اگلا سیشن دوبارہ محتاط طرز سے شروع ہوتا ہے۔ جن قواعد کو برقرار رکھنا ہو، ان کے لیے settings file میں مستقل allow، ask اور deny lists موجود ہوتی ہیں۔ مثال کے طور پر: git status کی اجازت دیں، git push پر پوچھیں، اور .env کو پڑھنے سے انکار کریں۔ deny کے قواعد ہمیشہ غالب رہتے ہیں۔ یہ بنیادی طرز بھی تبدیل ہو رہا ہے، کیونکہ 14 August 2026 کو auto mode default بن جائے گا۔ اس لیے یہ فیصلہ کرنے سے پہلے کہ ایسے server پر کون سا permission mode چلانا ہے جس کی آپ نگرانی نہیں کر سکتے، یہ جاننا مفید ہے کہ ہر permission mode حقیقت میں کیا اجازت دیتا ہے۔

یہ ڈیزائن اس مفروضے پر مبنی ہے کہ کوئی انسان terminal کی نگرانی کر رہا ہے، اور laptop پر یہ مفروضہ درست ہوتا ہے۔ server پر اکثر مقصد ہی یہ ہوتا ہے کہ کوئی نگرانی نہ کر رہا ہو۔ آپ tmux کے اندر ایک طویل task شروع کر کے سو جاتے ہیں، لیکن اگر agent رات 2 بجے سوال پوچھنے کے لیے رک جائے تو صبح تک کوئی پیش رفت نہیں ہوتی۔ اس توقف سے وقت کے ساتھ پیسہ بھی ضائع ہوتا ہے، کیونکہ غیر فعال Claude Code session اپنا warm prompt cache کھو دیتا ہے اور اگلی turn میں اسے دوبارہ بنانے کی لاگت ادا کرنا پڑتی ہے۔ یہی اصل وجہ ہے کہ لوگ server پر skip flag استعمال کرتے ہیں، اور یہ حقیقی مسئلہ حل کرتا ہے۔ اس guide کے باقی حصے میں بتایا گیا ہے کہ ہر حفاظتی رکاوٹ ختم کیے بغیر یہ مسئلہ کیسے حل کیا جائے۔

--dangerously-skip-permissions کیا تبدیل کرتا ہے

claude --dangerously-skip-permissions منظوری کا مرحلہ بند کر دیتا ہے۔ ترامیم کسی prompt کے بغیر ہو جاتی ہیں۔ Shell commands بھی کسی prompt کے بغیر چلتے ہیں۔ وہ protected-path checks بھی نظرانداز ہو جاتے ہیں جو عام طور پر حساس مقامات کی حفاظت کرتے ہیں۔ آپ کے صریح deny rules بدستور نافذ رہتے ہیں، اور چند انتہائی خطرناک actions پر پھر بھی منظوری طلب کی جاتی ہے، لیکن عملی خلاصہ سادہ ہے: model جو بھی چلانے کا فیصلہ کرے، وہ چل جاتا ہے۔

Server پر اس flag کے بارے میں دو باتیں اہم ہیں۔ پہلی یہ کہ Linux اور macOS پر Claude Code کو root کے طور پر یا sudo کے تحت چلانے پر یہ blocked رہتا ہے، کیونکہ بغیر prompts کے root machine کی کسی بھی file یا service کو تبدیل کر سکتا ہے۔ Agent کو بہرحال اپنے unprivileged account کی ضرورت ہوتی ہے، اور یہ flag اسی شرط کو نافذ کرتا ہے۔ دوسری یہ کہ یہ flag model کے behaviour کو کسی بھی طرح تبدیل نہیں کرتا۔ یہ صرف انسان کو loop سے نکالتا ہے اور باقی کچھ تبدیل نہیں کرتا، اس لیے prompt جس غلطی کو روک سکتا تھا، وہ اب execute ہو جاتی ہے۔

اس لیے حقیقی حساب یہ ہے: اگر آپ permissions skip کرتے ہیں تو security کا سوال "کیا agent کچھ نقصان دہ کرے گا؟" سے بدل کر "ایک غلط action کتنا نقصان پہنچا سکتا ہے؟" ہو جاتا ہے۔ آپ ہر فیصلے کو control کرنے کی کوشش ترک کر کے blast radius کو control کرنا شروع کرتے ہیں۔ اس کا جواب containment ہے، اور یہ کئی درجوں میں آتا ہے۔

Claude Code کا built-in sandbox

درجات سے پہلے یہ جان لیں کہ Claude Code اب اپنے چلائے گئے commands کے لیے OS-level sandbox فراہم کرتا ہے، اور اس سے skip flag استعمال کرنے کی زیادہ تر وجوہات ختم ہو جاتی ہیں۔ Linux پر یہ filesystem isolation کے لیے bubblewrap اور network traffic کو proxy کے ذریعے route کرنے کے لیے socat استعمال کرتا ہے۔ Sandbox کے اندر کوئی command صرف project directory اور session temp directory میں لکھ سکتی ہے، اور network تک رسائی صرف ایسے proxy کے ذریعے ہوتی ہے جو ہر domain کو allow list کے خلاف جانچتا ہے۔ پہلی بار جب کسی command کو نئے domain کی ضرورت ہو گی، Claude Code آپ سے اجازت مانگے گا۔

Session کے اندر /sandbox command سے اسے فعال کریں۔ Ubuntu اور Debian پر پہلے اس کے لیے درکار دونوں packages انسٹال کریں:

sudo apt install bubblewrap socat

Ubuntu 24.04 اور اس کے بعد کے versions میں default AppArmor policy bubblewrap کو مطلوبہ user namespaces بنانے سے روکتی ہے۔ Sandbox panel آپ کو بتاتا ہے کہ کیا چیز missing ہے، اور Claude Code کی sandboxing documentation میں مختصر AppArmor profile موجود ہے جو اس مسئلے کو حل کرتی ہے۔

Sandbox میں auto-allow mode موجود ہے۔ Sandboxed commands بغیر کسی prompt کے چلتی ہیں، کیونکہ اب enforced boundary وہ کام کرتی ہے جو پہلے prompt کرتا تھا۔ جو commands sandbox کے اندر نہیں چل سکتیں، وہ normal permission flow پر واپس آ جاتی ہیں، اس لیے واقعی غیر معمولی actions اب بھی اجازت مانگتے ہیں۔ زیادہ تر server workflows کے لیے یہ skip flag کا درست متبادل ہے، کیونکہ آپ کو OS-enforced boundary کے ساتھ کہیں کم سوالات کا سامنا ہوتا ہے، نہ کہ بالکل کوئی boundary نہ ہونے کی صورت میں۔

اس کی حدود کے بارے میں واضح رہیں۔ By default sandboxed command اب بھی filesystem کے بیشتر حصے پڑھ سکتی ہے، جن میں credential files بھی شامل ہیں، جب تک آپ ان paths کو deny نہ کریں؛ sandbox.credentials setting اسی مقصد کے لیے موجود ہے۔ Network proxy domain names کی جانچ کرتا ہے، لیکن traffic کا خود معائنہ نہیں کرتا۔ اس لیے github.com جیسی وسیع allow setting اب بھی data باہر منتقل کرنے کی گنجائش چھوڑتی ہے۔ Docker اس کے اندر کام نہیں کرتا۔ Sandbox بنیادی تحفظ کی سطح کو کافی بلند کرتا ہے۔ یہ مکمل isolation boundary نہیں ہے، اسی لیے ذیل کے درجات اب بھی اہم ہیں۔

تنہائی کی سطحیں

تین سطحیں ہیں، اور ہر اگلی سطح میں تنہائی زیادہ ہے۔ وہ کم ترین سطح منتخب کریں جو اس بات کے مطابق ہو کہ اس سرور پر اور کیا چل رہا ہے۔

سطح 1: مخصوص غیر مراعات یافتہ صارف۔ Agent کے لیے اپنا account، اپنی home directory، اپنی project directory بنائیں، اور اسے sudo کی اجازت نہ دیں:

sudo adduser --disabled-password --gecos "" agent

Account کی حد agent کو آپ کی files، آپ کی SSH keys اور machine کے دیگر تمام projects سے دور رکھتی ہے۔ اس سے skip flag بھی قابل استعمال ہو جاتا ہے، کیونکہ یہ flag root کے طور پر چلنے سے انکار کرتا ہے۔ یہی اصول ہر service کو غیر مراعات یافتہ صارف کے طور پر چلانے کا ہے، جسے agent پر لاگو کیا گیا ہے۔ سطح 1 network اور server پر موجود ہر وہ چیز محدود نہیں کرتی جو تمام users کے لیے readable ہو۔

سطح 2: container۔ Anthropic ایک reference devcontainer فراہم کرتا ہے جو Claude Code کو non-root user کے طور پر چلاتا ہے۔ اس میں firewall rules شامل ہیں جو ان hosts کو محدود کرتے ہیں جن تک agent پہنچ سکتا ہے۔ آپ کا بنایا ہوا container بھی یہی کام کرتا ہے۔ Filesystem صرف ان volumes تک محدود رہتا ہے جنہیں آپ mount کرتے ہیں، اور outbound network access ان حدود تک محدود رہتا ہے جن کی اجازت container کے rules دیتے ہیں۔ جب server پر دوسری اہم services بھی چل رہی ہوں تو یہ مناسب درمیانی سطح ہے۔ اس کی حد یہ ہے کہ containers host kernel کا اشتراک کرتے ہیں، اور ایک غیر محتاط mount اس حد کو ختم کر دیتا ہے؛ container کو /var/run/docker.sock دیں تو یہ پورے host تک پہنچ سکتا ہے۔

سطح 3: مخصوص VPS۔ سب سے مضبوط سطح سب سے سادہ بھی ہے: agent کو ایک پوری ایسی machine دیں جس پر کوئی اہم چیز موجود نہ ہو۔ ایک چھوٹے VPS کی لاگت ماہانہ چند dollars ہوتی ہے۔ اسے نئے VPS کے پہلے دس منٹ کا runbook استعمال کرتے ہوئے تیار کریں، صاف حالت کا snapshot بنائیں، اور agent کو کام کرنے دیں۔ وہاں کوئی اور چیز موجود نہ ہو۔ ذاتی SSH key نہ رکھیں؛ صرف اسی ایک repository تک محدود deploy key رکھیں۔ Cloud credentials اور production data بھی نہ رکھیں۔ اگر کوئی run غلط ہو جائے، یا آپ صرف صاف حالت سے دوبارہ شروع کرنا چاہیں، تو snapshot restore کریں یا چند منٹ میں machine کو destroy کرکے دوبارہ build کریں۔ نقصان کی زیادہ سے زیادہ حد VPS کا کرایہ ہے۔ اس setup میں --dangerously-skip-permissions خوف ناک نہیں رہتا، کیونکہ بدترین قابل عمل نتیجہ ایک rebuilt server اور ایک revoked token ہوتا ہے۔

یہ سطحیں ایک دوسرے کے ساتھ استعمال کی جا سکتی ہیں۔ Disposable VPS پر غیر مراعات یافتہ user کے طور پر چلنے والا sandboxed agent تقریباً کوئی اضافی لاگت نہیں لیتا اور failure کی صورت حال کو معمولی بنا دیتا ہے۔ مقصد یہی ہے کہ صورتحال معمولی رہے۔

اسنادِ رسائی کی حفاظت کریں

وہ اصول جو باقی تمام اقدامات کی بنیاد ہے: agent کا user کسی دوسری چیز سے متعلق secrets کو پڑھنے کے قابل نہیں ہونا چاہیے۔

API key صرف agent کو دیں، کسی اور کو نہیں۔ اسے agent کے user کی ملکیت والی file میں mode 600 کے ساتھ رکھیں، اور shell شروع ہونے پر اسے load کریں:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

پھر دوسری سمت بھی بند کریں۔ Debian اور Ubuntu میں home directories اکثر سسٹم کے ہر user کے لیے readable بنائی جاتی ہیں، اس لیے اپنی directory کی اجازتیں سخت کریں: chmod 750 /home/youruser۔ ls -ld /home/* سے جانچ کریں اور ایسی ہر چیز کی اجازت درست کریں جسے agent کا account list کر سکتا ہو۔

ہر token کا دائرہ محدود رکھیں۔ ایک repository تک محدود fine-grained GitHub token یا ہر repository کے لیے الگ deploy key استعمال کرنے سے leaked credential کی وجہ سے صرف ایک project متاثر ہوتا ہے، پورا account نہیں۔ اگر آپ sandbox استعمال کرتے ہیں تو اس کی credential settings شامل کریں تاکہ ~/.ssh اور ~/.aws کو read operations کے لیے بھی deny کیا جائے۔ Production credentials کو مکمل طور پر اس box سے باہر رکھیں، کیونکہ agent ایسا secret leak نہیں کر سکتا جو وہاں موجود ہی نہ ہو۔ اگر یہ secrets self-hosted password manager میں محفوظ ہیں تو اسے agent سے مختلف box پر رکھیں اور اس کا الگ review کریں، کیونکہ Vaultwarden کے کمزور مقامات admin token اور backup file ہیں، encrypted vault خود نہیں۔

Git حفاظتی جال ہے

ایجنٹ کی ہر تبدیلی کا جائزہ لینا اور اسے واپس کرنا ممکن ہونا چاہیے۔ اگر ایجنٹ کسی branch پر کام کرے تو Git یہ دونوں سہولتیں بلا معاوضہ فراہم کرتا ہے:

git switch -c agent/refactor-auth

اس کے بعد git diff main...agent/refactor-auth سے run کا جائزہ لیں، اچھی تبدیلیاں merge کریں، اور اگر run سے کوئی مفید نتیجہ نہ نکلا ہو تو branch حذف کر دیں۔ جس run نے تین files میں تبدیلی کی ہو، اسے ناشتے کے وقت پڑھنا اس run کے مقابلے میں کہیں آسان ہوتا ہے جس نے آدھے module کو دوبارہ لکھ دیا ہو۔ عملی طور پر اسی لیے ایسی skill ضروری ہے جو ایجنٹ کو کام کرنے والی کم سے کم تبدیلی تک محدود رکھے۔ Forge کی جانب سے main branch کو protect کریں، تاکہ ایجنٹ کا token اس پر push نہ کر سکے اور نہ ہی کہیں force-push کر سکے۔ Commit history اس دوران ہونے والے کام کا audit log بھی بن جاتی ہے جب آپ سو رہے تھے۔ یہ terminal کے scrollback کی کسی بھی مقدار سے زیادہ مفید ہے۔

نیٹ ورک حملے کے دائرۂ اثر کا حصہ ہے

ایک agent curl چلا سکتا ہے۔ یہی مکمل egress مسئلہ ہے: agent جو کچھ پڑھ سکتا ہے، اسے کہیں بھی بھیج بھی سکتا ہے، اور prompt injection کا شکار agent ایسا کر سکتا ہے۔ عام غیر مراعات یافتہ user اس دائرے کو بالکل محدود نہیں کرتا، کیونکہ ہر user ہر اس چیز تک پہنچ سکتا ہے جہاں server پہنچ سکتا ہے۔ sandbox اپنے proxy کے ذریعے domain کی بنیاد پر اس رسائی کو محدود کرتا ہے۔ container اپنی firewall rules کے ذریعے اسے محدود کر سکتا ہے۔ dedicated VPS ابتدا ہی میں قابلِ افشا ڈیٹا کی مقدار محدود کرتا ہے، اس لیے ان تینوں میں یہ سب سے مضبوط حل ہے۔

صرف ufw کے ذریعے egress کا مسئلہ حل کرنے کی کوشش نہ کریں۔ ufw پہلے سے تمام outgoing traffic کی اجازت دیتا ہے، اور ایسی outbound rules لکھنا جو apt، npm، git اور Claude API کو پھر بھی اجازت دیں، پیچیدہ کام ہے اور خاموشی سے خراب ہو سکتا ہے۔ اس کے بجائے حد sandbox، container یا machine کی سطح پر مقرر کریں، جہاں domain allow list یا ایک bare machine یہی کام صاف اور قابلِ اعتماد طریقے سے انجام دیتی ہے۔

اگر آپ Claude Code چلانے کے بجائے API کے خلاف اپنا agent بنا رہے ہیں، تو یہی اصول بغیر کسی تبدیلی کے لاگو ہوتا ہے۔ VPS پر Claude کے ساتھ AI agent بنانا میں اس طریقے کی وضاحت ہے، اور اس agent کے لیے بھی وہی dedicated user، وہی محدود دائرۂ کار والے tokens اور وہی disposable box استعمال ہونا چاہیے۔

پہلے سرور کو محفوظ بنائیں

آپ جو بھی آپشن منتخب کریں، agent کے کام شروع کرنے سے پہلے خود مشین پر بنیادی حفاظتی اقدامات ضروری ہیں: صرف SSH keys کی اجازت، root login ممنوع، default-deny firewall، اور security updates خودکار طور پر فعال۔ اپنی checklist یہاں تیار کریں اور اسے ایک بار مکمل کریں:

FAQ

کیا سرور پر --dangerously-skip-permissions استعمال کرنا محفوظ ہے؟

اپنے آپ میں نہیں۔ یہ flag منظوری کے ہر prompt کو ہٹا دیتا ہے، اس لیے model کے command تیار کرتے ہی پہلی غلط command چل جاتی ہے۔ یہ فیصلہ اسی وقت قابلِ جواز بنتا ہے جب ممکنہ نقصان کا دائرہ محدود ہو: کم از کم ایک dedicated unprivileged user استعمال کریں، اور حقیقی طور پر unattended کام کے لیے ایک container یا disposable VPS استعمال کریں جس میں صرف ایک project اور ایک محدود دائرۂ اختیار والا token ہو۔ اسے ایسی machine پر کبھی استعمال نہ کریں جس میں production credentials یا ایسا data موجود ہو جسے آپ کھو نہیں سکتے۔

کیا Claude Code میں sandbox موجود ہے؟

ہاں۔ Claude Code میں shell commands کے لیے built-in sandbox شامل ہے، جسے /sandbox command سے کھولا جاتا ہے۔ یہ Linux پر bubblewrap اور macOS پر Seatbelt استعمال کرتا ہے، writes کو project directory تک محدود رکھتا ہے، اور network access کو ایسے proxy کے ذریعے route کرتا ہے جو صرف منظور شدہ domains کی اجازت دیتا ہے۔ اس کا auto-allow mode sandboxed commands کو prompts کے بغیر چلاتا ہے۔ یوں یہ skip flag کی طرح interruptions کم کرتا ہے، جبکہ OS کے نافذ کردہ boundary کو برقرار رکھتا ہے۔ یہ مکمل isolation boundary نہیں ہے، اس لیے unattended runs کے لیے اسے dedicated user یا dedicated machine کے ساتھ استعمال کریں۔

skip flag root کے طور پر چلنے سے انکار کیوں کرتا ہے؟

کیونکہ permission prompts کے بغیر root system کی ہر file اور ہر service میں ترمیم کر سکتا ہے۔ اسی لیے Claude Code Linux اور macOS پر root یا sudo کے تحت چلتے وقت --dangerously-skip-permissions کو block کرتا ہے۔ حل یہ نہیں کہ check کو bypass کرنے کی کوشش کی جائے۔ Agent کے لیے ایک unprivileged user بنائیں اور اسے اسی user کے تحت چلائیں۔ یہ account boundary containment کی پہلی اور کم خرچ layer ہے۔

کیا Claude Code میری SSH keys اور .env files پڑھ سکتا ہے؟

یہ وہ سب کچھ پڑھ سکتا ہے جسے اس user کو پڑھنے کی اجازت ہو جس کے تحت یہ چل رہا ہے۔ حتیٰ کہ sandbox کی default policy بھی credential paths کو پڑھنے کی اجازت دیتی ہے، جب تک آپ انہیں deny نہ کریں۔ اس لیے agent کو اپنے user کے تحت چلائیں، اپنی home directory کو mode 750 یا اس سے زیادہ محدود permission پر رکھیں، sandbox settings میں credential paths کو deny کریں، اور production secrets کو machine سے مکمل طور پر باہر رکھیں۔ جو secret machine پر کبھی موجود ہی نہ ہو، اسے پڑھا یا leak نہیں کیا جا سکتا۔

Claude Code کو unattended چلانے کا محفوظ ترین طریقہ کیا ہے؟

Agent کے کام کے لیے صرف استعمال ہونے والا ایک کم لاگت dedicated VPS بہترین انتخاب ہے۔ اسے دس منٹ میں harden کریں، clean snapshot محفوظ کریں، Claude Code کو sandbox enabled کے ساتھ unprivileged user کے تحت چلائیں، API key کو mode-600 file میں رکھیں، ہر repository کے لیے الگ deploy key استعمال کریں، اور تمام کام ایسی branches پر کریں جنہیں merge کرنے سے پہلے آپ review کریں۔ اگر کوئی run خراب ہو جائے تو ایک token revoke کریں اور snapshot restore کریں۔ آپ کی ملکیت میں موجود کوئی دوسری چیز متاثر نہیں ہوگی۔