سینڈ باکس اور سیکیورٹی

cc_server بوٹ کے وقت ہوسٹ کا جائزہ لیتا ہے اور جہاں کوئی دستیاب ہو وہاں ایجنٹ کی کمانڈ ایگزیکیوشن کو OS کے نیٹو سینڈ باکس میں لپیٹ دیتا ہے — macOS پر Seatbelt، Linux اور WSL2 پر bubblewrap (جس کے لیے PATH پر bwrap اور socat درکار ہیں)۔ جہاں کوئی بیک اینڈ موجود نہیں — Windows، یا وہ Linux باکس جس میں یہ ٹولز نہ ہوں — وہاں رنز نیچے دی گئی دیگر سرحدوں پر واپس چلے جاتے ہیں اور سرور اپنے اسٹارٹ اپ لاگ میں یہ بتا دیتا ہے۔ --sandbox off اسے جان بوجھ کر بند کر دیتا ہے۔

دو خلا سینڈ باکس کے باوجود برقرار رہتے ہیں اور انہیں ذہن میں رکھنا چاہیے:

بلٹ اِن ہارنس کے اِن پروسیس فائل ٹولز (read, write, edit, apply_patch, search, find, search_files) سرور پروسیس کے اندر چلتے ہیں، اس لیے صرف bash لپیٹا جاتا ہے۔ ان کو باندھنے والی چیز خود ٹولز میں پاتھ کنفائنمنٹ اور ایکشن گارڈریلز ہے۔
Claude Code کو --dangerously-skip-permissions کے ساتھ لانچ کیا جاتا ہے، کیونکہ غیر تعاملی claude -p ورنہ اپنے پرامپٹ پر ہمیشہ کے لیے بلاک ہو جاتا۔ اس لیے اس کی فائل کالز Control Center کے گارڈریلز سے نہیں گزرتیں، اور شیل کمانڈز صرف ایک ہک سے گزرتی ہیں جو کمانڈ لائن پڑھتا ہے — OS سینڈ باکس ان کے گرد سرحد ہے۔

تنہائی یہاں کیوں اہمیت رکھتی ہے

ایجنٹ آپ کی طرف سے فائلیں پڑھتا ہے، شیل کمانڈز چلاتا ہے اور بیرونی APIs کال کرتا ہے۔ جس ناکامی کی آپ کو فکر ہے وہ شاذ و نادر ہی بددیانتی ہوتی ہے — وہ ایسا ایجنٹ ہوتا ہے جو کسی پاتھ کو غلط پڑھ کر آپ کا ورکنگ چیک آؤٹ دوبارہ لکھ دیتا ہے، یا ایسی برانچ پش کر دیتا ہے جس کا ریویو آپ نے مکمل نہیں کیا تھا۔ چنانچہ پروڈکٹ کو جس سوال کا جواب دینا ہے وہ یہ نہیں کہ “کیا ایجنٹ قابلِ اعتماد ہے” بلکہ یہ کہ “جب یہ غلط ہو تو نقصان کا دائرہ کیا ہوتا ہے”۔

Control Center اس کا جواب تہوں میں دیتا ہے اور یہ تہیں جان بوجھ کر آزاد ہیں۔ اگر ایک غائب ہو تو باقی پھر بھی قائم رہتی ہیں۔ یہ اہم ہے، کیونکہ سب سے بیرونی تہہ — OS سینڈ باکس — واحد مشروط تہہ ہے: یہ اس پر منحصر ہے کہ ہوسٹ کوئی بیک اینڈ پیش کرے، اور Windows پر کوئی ہوسٹ ایسا نہیں کرتا۔

ایک ایجنٹ کو اصل میں کیا محدود کرتا ہے

ہر ہوسٹ پر، سینڈ باکس ہو یا نہ ہو، پانچ چیزیں ایجنٹ کے رن کو باندھتی ہیں۔ ان میں سے کوئی کرنل کی حد نہیں؛ سب حقیقی ہیں۔ جہاں ہوسٹ کوئی بیک اینڈ پیش کرتا ہے وہاں OS سینڈ باکس ان کے اوپر بیٹھتا ہے اور نیچے “سینڈ باکس کیا اضافہ کرتا ہے اور کہاں رک جاتا ہے” بتاتا ہے کہ اس سے کیا بدلتا ہے۔

اپنا copy-on-write worktree۔ ہر گفتگو ہر منسلک ریپو کا اپنا چیک آؤٹ تیار کرتی ہے، جو بائٹ بائٹ کاپی ہونے کے بجائے بنڈل شدہ rift نیٹو کے ذریعے copy-on-write کلون ہوتا ہے، اس لیے تنہائی اتنی سستی ہے کہ ڈیفالٹ بن سکے۔ جو رجسٹرڈ ریپوزٹری آپ نے ورک اسپیس میں شامل کی وہ وہ ڈائریکٹری نہیں جس میں ایجنٹ کام کرتا ہے — ایک ہی ریپو کو چھونے والی دو گفتگوئیں ایک دوسرے کی تبدیلیاں نہیں دیکھ سکتیں اور نہ ہی کوئی آپ کا چیک آؤٹ ایڈٹ کر رہی ہوتی ہے۔

اس دانے کو درست رکھنا چاہیے: worktree ہر گفتگو کے لیے ہوتا ہے، ہر ایجنٹ کے لیے نہیں۔ ایک ہی گفتگو میں دو ایجنٹس کو الگ الگ اوورلے ورکنگ ڈائریکٹریاں ملتی ہیں جو اس گفتگو کی repos/ کو شیئر کرتی ہیں — اور یہی مقصود ہے، کیونکہ وہ ایک ہی تبدیلی پر مل کر کام کر رہے ہیں — جبکہ ان کی نجی ایجنٹ ڈائریکٹریاں الگ رہتی ہیں۔ جہاں بھی rift جہاز ہوتا ہے وہاں copy-on-write ہی واحد بیک اینڈ ہے: جو فائل سسٹم reflink نہ کر سکے، یا جس کا ڈیٹا ڈائر ریپو سے مختلف والیوم پر ہو، وہ پروویژننگ ناکام کرتا ہے، فال بیک نہیں کرتا۔ Windows استثنا ہے — وہاں کوئی copy-on-write بیک اینڈ نہیں، اس لیے git worktree بیک اینڈ ہے، خاموش کمی نہیں۔

بلٹ اِن ہارنس کے فائل ٹولز میں پاتھ کنفائنمنٹ۔ ہارنس کے read، write، edit، apply_patch، search، find اور search_files ٹولز ہر پاتھ کو رن کی ورکنگ ڈائریکٹری کے علاوہ مشترکہ روٹس — گفتگو کی repos/ ڈائریکٹری، جہاں worktrees رہتی ہیں، اور اسپیس کی attachments ڈائر جب موجود ہو — کے مقابلے میں حل کرتے ہیں اور باہر پڑنے والی کسی بھی چیز سے انکار کر دیتے ہیں۔ مطلق پاتھ صرف اسی صورت قبول ہوتے ہیں جب وہ پہلے سے اندر ہوں۔ worktree کے اندر سے باہر کی طرف اشارہ کرنے والا symlink بھی حل ہو کر مسترد ہوتا ہے۔ اسی لیے ایجنٹ، سینڈ باکس بالکل تصویر میں نہ ہونے کے باوجود، ~/.ssh میں write نہیں کر سکتا۔

موڈ کا ٹول سرفیس۔ ایک گفتگو کا موڈ فیصلہ کرتا ہے کہ رن کے لیے کون سے ٹولز میٹیریلائز ہوں گے ہی نہیں۔ ریڈ-اونلی موڈز (plan, review, orchestrate) میں میوٹیٹنگ ٹولز محض رجسٹری میں نہیں ہوتے اور ان موڈز کی شیل کمانڈ پالیسی ہر میوٹیٹنگ کمانڈ سے براہِ راست انکار کرتی ہے — git commit، git push، npm install، docker وغیرہ — بجائے اس کے کہ ان کے لیے پرامپٹ کرے۔ جو ٹول موجود ہی نہ ہو اسے کال نہیں کیا جا سکتا، اور یہ ضمانت اس ٹول سے مضبوط ہے جو موجود ہو مگر گیٹ شدہ ہو۔

متحدہ ایکشن گارڈریلز۔ ہر میوٹیٹنگ ٹول اعلان کرتا ہے کہ وہ کون سی effect کلاسز پیدا کر سکتا ہے اور پالیسی انجن ہر ایک کو کال چلنے سے پہلے allow، prompt یا deny میں حل کرتا ہے۔ کوئی prompt جس سے کوئی منظوری دینے والا منسلک نہ ہو، denied میں حل ہوتا ہے — جس سوال کا کوئی جواب نہ دے سکے وہ کبھی ہاں نہیں ہوتا۔ ریزولوشن ماڈل کے لیے گارڈریلز دیکھیں۔

بروکر کے ذریعے جاری کریڈنشلز اور صاف شدہ ماحول۔ کریڈنشلز ہر لانچ پر تیار ہوتے ہیں اور رن ختم ہونے پر منسوخ کر دیے جاتے ہیں؛ رن کے پاس موجود GitHub ٹوکن پڑھ سکتا ہے مگر پش نہیں کر سکتا — نیچے “پش Control Center سے گزرتے ہیں” دیکھیں۔ ACP، ہارنس bash اور نیٹو رَیپ کے تحت Claude Code کو پروسیس شروع ہونے سے پہلے ایسا ماحول ملتا ہے جس سے ڈائنامک لنکر اور انٹرپریٹر انجیکشن ویکٹرز (LD_PRELOAD، DYLD_INSERT_LIBRARIES، NODE_OPTIONS، GIT_SSH_COMMAND اور ان کے ہم شکل) ہٹا دیے گئے ہوں۔ NoSandboxAdapter کے ذریعے Claude Code ہوسٹ کا ماحول ورثے میں پاتا ہے۔

جہاں یہ حدیں پتلی پڑ جاتی ہیں

ہارنس کے فائل ٹولز سرور پروسیس میں چلتے ہیں، کسی چائلڈ پروسیس میں نہیں، اس لیے کوئی بھی سینڈ باکس پروفائل انہیں محدود نہیں کر سکتا، چاہے منسلک ہو بھی — صرف bash سینڈ باکس شدہ کمانڈ رنر سے گزرتا ہے۔ ان کی محدودیت اوپر بیان کردہ پاتھ چیک ہے اور اسی لیے وہ چیک بوجھ اٹھانے والا ہے، دفاع کی دوسری لکیر نہیں۔

bash ٹول دوسری جگہ ہے جہاں درست رہنا چاہیے۔ اس کی کمانڈز موڈ کی کمانڈ پالیسی کے مقابلے میں جانچی جاتی ہیں اور پھر صاف شدہ ماحول اور worktree بحیثیت ورکنگ ڈائریکٹری اسپان کی جاتی ہیں۔ جہاں بیک اینڈ موجود ہو وہاں یہ اسپان لپیٹا جاتا ہے، چنانچہ سینڈ باکس ہی وہ چیز ہے جو شیل کمانڈ کو worktree سے باہر لکھنے سے روکتی ہے؛ جہاں کوئی نہ ہو — Windows، یا bwrap اور socat کے بغیر Linux — وہاں کمانڈ پالیسی ہی کمانڈ اور باقی ڈسک کے درمیان واحد چیز ہے۔ chat موڈ میں پالیسی ایک مقررہ فہرست سے سختی سے انکار کرتی ہے (استحقاق میں اضافہ، سسٹم اور ڈسک کی تباہی، کنٹینر اور نین اسپیس فرار) اور ریموٹ-اسٹیٹ تبدیلیوں پر پرامپٹ کرتی ہے (git push، gh pr create، پیکیج پبلش اور انسٹالز)۔ جو کسی بھی فہرست میں نہ ہو وہ چل جاتا ہے۔ پائپ لائنز، چینز اور سب شیلز پارس ہوتی ہیں اور ہر ذیلی کمانڈ الگ الگ جانچی جاتی ہے، اور سب سے پابند کن فیصلہ جیتتا ہے۔

Claude Code، جب بطور اڈاپٹر استعمال ہو، وہ معاملہ ہے جہاں سینڈ باکس سب سے زیادہ وزن اٹھاتا ہے۔ Control Center اسے --dangerously-skip-permissions کے ساتھ لانچ کرتا ہے، کیونکہ غیر تعاملی claude -p ورنہ اپنے منظوری پرامپٹ پر ہمیشہ کے لیے بلاک ہو جائے گا۔ اس کی read، write اور edit کالز اس کے اپنے پروسیس کے اندر ہوتی ہیں اور Control Center انہیں کبھی نہیں دیکھتا۔ اس کی Bash کالز چلنے سے پہلے سرور پر ایک ہک تک پہنچتی ہیں، جو کمانڈ لائن کی درجہ بندی کر کے متعلقہ قاعدے سے پوچھتا ہے؛ وہ mcp__* ٹولز جو Control Center خود پیش کرتا ہے معمول کے مطابق گیٹ سے گزرتے ہیں۔ جہاں بیک اینڈ موجود ہو، وہ ان دیکھی کالز پھر بھی سینڈ باکس رَیپ کے اندر ہوتی ہیں، اس لیے OS ان کے گرد سرحد ہے۔ جہاں کوئی نہ ہو، وہاں کچھ بھی نہیں۔ ہر اڈاپٹر یہ اپنی نافذ کاری میٹرکس میں بیان کرتا ہے — اڈاپٹر ایمانداری میٹرکس دیکھیں۔

پش Control Center سے گزرتے ہیں

کوئی فی ایجنٹ اجازتی فلیگ نہیں ہے۔ کوئی ایجنٹ کمیٹ بنا سکتا ہے، پش کر سکتا ہے، pull request کھول سکتا ہے، کسی ٹریکر پر لکھ سکتا ہے یا نیٹ ورک تک پہنچ سکتا ہے یا نہیں، یہ گارڈریلز طے کرتے ہیں — اجازت دیں، پہلے پوچھیں یا منع کریں — اور یہی قواعد لاگو ہوتے ہیں چاہے ایجنٹ کو کوئی بھی اڈاپٹر چلائے۔

پش وہ ایکشن ہے جسے ایسے ایجنٹ کے مقابلے میں بھی قائم رہنا ہے جو قاعدے سے بچ نکلنے کی کوشش کرے، اس لیے یہ اس سے نافذ ہوتا ہے جو ایجنٹ کے پاس ہے، نہ کہ اس سے جو وہ چلاتا ہے۔ GitHub App کنفیگر ہونے پر، GitHub worktree میں چلنے والے رن کو ایک ہی ریپو تک محدود انسٹالیشن ٹوکن ملتا ہے جو مواد پڑھ سکتا ہے اور pull requests کے ساتھ کام کر سکتا ہے، مگر پش نہیں کر سکتا۔ رن کی git کنفیگریشن ہر GitHub پش URL (https://github.com/، git@github.com:، ssh://git@github.com/) کو ایجنٹ رن گیٹ وے کی طرف دوبارہ لکھتی ہے — cc_server پر ایک loopback اینڈپوائنٹ۔ گیٹ وے پڑھتا ہے کہ پش کون سے refs اپ ڈیٹ کرتا ہے، ریموٹ پر پش کریں قاعدے سے پوچھتا ہے — اس لیے برانچ تک محدود قواعد جیسے “main پر پش منع کریں” بھی لاگو ہوتے ہیں — اور تبھی پش کو ایک ایسے رائٹ ٹوکن کے ساتھ GitHub تک پہنچاتا ہے جو وہ اسی کام کے لیے جاری کرتا ہے اور ایجنٹ کو کبھی نہیں دیتا۔ مسترد شدہ پش git کے اپنے آؤٹ پٹ میں دکھائی دیتا ہے:

 ! [remote rejected] main -> main (Control Center policy: …)

گیٹ وے پش صرف worktree کے اپنے ریپو یا ورک اسپیس سے منسلک کسی GitHub ریپو تک پہنچاتا ہے۔ fetch صرف پڑھنے والے ٹوکن کے ساتھ براہِ راست GitHub تک جاتے ہیں۔

باقی شیل کمانڈز کو ایک نرم گیٹ کا سامنا ہوتا ہے۔ ہارنس کا bash ٹول، اور ہک کے ذریعے Claude Code کا Bash ٹول، ہر کمانڈ لائن کی درجہ بندی کرتے ہیں اور اُس قاعدے سے پوچھتے ہیں جس سے وہ تعلق رکھتی ہے: git commit، merge، rebase، cherry-pick، revert اور am کا تعلق کمیٹ بنائیں سے ہے؛ gh pr create کا pull request کھولیں سے؛ gh pr merge، review، comment اور close کا ریویو شائع کریں یا مرج کریں سے؛ gh issue create، edit، comment اور close کا بیرونی ٹریکر پر لکھیں سے؛ پیکیج انسٹال کرنے کا پیکیج انسٹال کریں سے؛ اور curl اور wget کا نیٹ ورک تک رسائی سے۔ یہ کسی ایکشن کی عام صورتیں پکڑ لیتا ہے، اور جو ایجنٹ اسے چھپانے پر تُلا ہو (eval، کوئی اسکرپٹ فائل، براہِ راست API کال) وہ ایسا کر سکتا ہے۔ پش اس پر انحصار نہیں کرتا۔

سینڈ باکس میں کوئی ٹکٹنگ API کلید نہیں رکھی جاتی۔ ایجنٹ Control Center کے MCP ٹولز کے ذریعے ٹکٹ لکھتے ہیں، جو بیرونی ٹریکر پر لکھیں قاعدے سے پوچھتے ہیں۔

نیٹ ورک تک رسائی کا قاعدہ رن کے آغاز پر ایک بار پڑھا جاتا ہے۔ سینڈ باکس کا نیٹ ورک صرف آن یا آف ہوتا ہے، اس لیے منع کرنا اسے بند کر دیتا ہے، جبکہ اجازت اور پہلے پوچھیں اسے آن رکھتے ہیں؛ ہارنس کے web_fetch اور web_search ٹولز پھر بھی ہر کال پر پوچھتے ہیں۔ کریڈنشلز رن کے اختتام پر منسوخ کر دیے جاتے ہیں، گیٹ وے کے جاری کردہ ہر رائٹ ٹوکن سمیت، اس لیے کوئی ہینڈل رن سے زیادہ زندہ نہیں رہتا۔

سینڈ باکس کیا اضافہ کرتا ہے اور کہاں رک جاتا ہے

SandboxBackend enum کی تین اقدار ہیں — native (macOS پر Seatbelt، Linux اور WSL2 پر bubblewrap)، none اور microvm۔ ایجنٹ کمانڈ رَیپنگ صرف پہلی دو استعمال کرتی ہے: microvm انٹرایکٹو ٹرمنلز اور رگز کے لیے بند-VM بیک اینڈ ہے، bash رَیپ کی خاموش اپ گریڈ نہیں۔ نیٹو شکل سمجھنا یہ بتاتا ہے کہ جہاں کوئی منسلک ہو وہاں آپ کو کیا ملتا ہے اور وہ کیا تھا جو یہ کبھی دینے والا ہی نہیں تھا۔

cc_server بوٹ پر ایک بار ہوسٹ کا جائزہ لیتا ہے اور جہاں کوئی بیک اینڈ جواب دے وہاں یہ dispatch پاتھ کی دونوں seams کو feed کرتا ہے، کیونکہ ٹرانسپورٹس ایک شیئر نہیں کرتے۔ پہلا (SandboxPort) Claude Code CLI کو لپیٹتا ہے۔ دوسرا (SandboxManager) ACP اڈاپٹرز اور بلٹ اِن ہارنس کے bash ٹول کو لپیٹتا ہے۔ صرف ایک کو feed کرنا باقیوں کو بغیر رَیپ کے اسپان کرنے دیتا، اور پہلے ایسا ہی ہوتا تھا۔ بیک اینڈ کے بغیر ہوسٹ پر، یا --sandbox off کے تحت، وہ سب بغیر رَیپ کے اسپان ہوتے ہیں اور سرور اپنی اسٹارٹ اپ لائن پر بتا دیتا ہے کہ آپ کس صورت میں ہیں۔ ACP اور ہارنس bash پھر بھی ماحول صاف کرتے ہیں؛ NoSandboxAdapter کے ذریعے Claude Code ہوسٹ کا ماحول ورثے میں پاتا ہے۔

ایک سطح جان بوجھ کر باہر رہتی ہے: سرور-ہوسٹڈ ٹرمنل فی سیشن ایک بیک اینڈ آرگیومنٹ قبول کرتا ہے اور cc_server اسے ہوسٹ شیل پر ڈیفالٹ کر کے بناتا ہے، اس لیے ایپ سے کھولا گیا ٹرمنل بغیر سینڈ باکس کے چلتا ہے جب تک کوئی کلائنٹ واضح طور پر native نہ بتائے۔ یہ سرور ہوسٹ پر ایک حقیقی شیل ہے، ایجنٹ رن نہیں۔

Linux پر، bubblewrap ایک ماؤنٹ نین اسپیس بناتا ہے، اس لیے ایجنٹ واقعی صرف وہی دیکھتا ہے جو اس میں بائنڈ کیا گیا ہو۔ macOS پر، sandbox-exec ایسا Seatbelt پروفائل لاگو کرتا ہے جو ڈیفالٹ کے اعتبار سے اجازت دینے والا ہے — مکمل ڈیفالٹ سے انکار کرنے والا پروفائل انٹرایکٹو شیل کو ناقابلِ استعمال بنا دیتا ہے، کیونکہ dyld، XPC اور Mach کالز کی گنتی کرنا غیر عملی ہے۔ اس لیے macOS پروفائل (allow default) سے شروع ہوتا ہے اور انکار تراشتا ہے: خفیہ پاتھوں کی ریڈز، ایک رائٹ پالیسی جو انکار پر ری سیٹ ہو کر اوپر واضح اجازتیں لیتی ہے، ہر انکار شدہ پاتھ اور اس کے آباؤ اجداد پر unlink-blocking تاکہ rename کسی رائٹ سے انکار کو بائی پاس نہ کر سکے، ہمیشہ خطرناک بائنریز کے لیے اور رائٹ ایبل ڈائریکٹری میں کاپی ہونے والی کسی بھی چیز کے لیے exec انکار، اور نیٹ ورک جو loopback proxy پورٹس کے علاوہ DNS تک محدود ہو۔

عملی نتیجہ: Linux پر ایجنٹ کا فائل سسٹم کے بارے میں نظارہ تنگ ہو جاتا ہے؛ macOS پر ایجنٹ پھر بھی ہوسٹ کا بیشتر حصہ پڑھ سکتا ہے اور آپ کے رجسٹرڈ چیک آؤٹس واضح write اور rename انکاروں سے محفوظ رہتے ہیں، نہ کہ نظر نہ آنے سے۔ دونوں نین اسپیس سطح کی تنہائی ہیں، کرنل سیکیورٹی سرحد نہیں — بیک اینڈز یہ اپنے قابلیت نوٹس میں خود کہتے ہیں۔

bind-mount سیٹ وہیں ہے جہاں کراس-ایجنٹ سرحد کھینچی جاتی ہے۔ اوورلے ڈسپیچ (Claude Code اور ACP) زیادہ سے زیادہ چار پاتھ ماؤنٹ کرتا ہے، جو فی رن حل ہوتے ہیں: ایجنٹ کی اوورلے ورکنگ ڈائریکٹری read-write، ایجنٹ کی config ڈائریکٹری read-only، گفتگو کی مشترکہ repos/ ڈائریکٹری read-write جب موجود ہو، اور اسپیس کی attachments ڈائریکٹری read-only جب موجود ہو۔ بہن ایجنٹ کی ڈائریکٹری کبھی ماؤنٹ نہیں ہوتی۔ ہارنس bash رَیپ زیادہ تنگ ہے: یہ صرف رن کی ورکنگ ڈائریکٹری bind-mount کرتا ہے۔ یہ وہی شکل ہے جو ہارنس کا اِن پروسیس پاتھ چیک سافٹ ویئر میں نافذ کرتا ہے، اس لیے دونوں متفق ہیں — لیکن صرف پاتھ چیک ہارنس کے اپنے فائل ٹولز کو ڈھانپتا ہے، جو کبھی کسی ماؤنٹ نین اسپیس تک پہنچتے ہی نہیں۔

آپ کے رجسٹرڈ چیک آؤٹس اس کے اوپر رائٹ سے انکار کے سیٹ میں شامل ہو جاتے ہیں، ہر موڈ میں اور تینوں لپیٹے گئے پاتھوں (Claude Code، ACP، ہارنس bash) پر، اور ہر اصول اپنی لفظی اور symlink-resolved دونوں ہجوں میں خارج ہوتا ہے۔ دوسری ہجے کوئی نزاکت نہیں: کرنل انکار کے اصول کو resolved پاتھ کے مقابلے میں میچ کرتا ہے اور macOS resolution کو غیر معمولی کے بجائے عام صورت بنا دیتا ہے — /tmp دراصل /private/tmp ہے، /var/folders/… دراصل /private/var/folders/… ہے — اس لیے ان میں سے کسی کے ذریعے پہنچا گیا چیک آؤٹ رائٹ ایبل ہوتا جبکہ پروفائل اسے منع کرتا دکھائی دیتا۔

نیٹ ورک، سینڈ باکس کے تحت، فی سیشن domain allowlist ہے جو اِن پروسیس loopback proxies سے نافذ ہوتی ہے۔ ایگریس ڈیفالٹ کے اعتبار سے انکار ہے: نیٹ ورک بند ہونے پر پراکسیز پھر بھی شروع ہوتی ہیں مگر ان کی allowlist خالی ہوتی ہے، اس لیے ہر آؤٹ باؤنڈ کنکشن مسترد ہوتا ہے۔ اس کے آن ہونے پر، ریزالور ایک منتخب بیس لائن سے allowlist بناتا ہے — LLM API فراہم کنندگان، git ہوسٹنگ، پیکیج رجسٹریاں، ماڈل کیٹلاگ — نیز GitHub ڈومینز، اور ہر کنکشن کے ٹارگٹ ہوسٹ کو اس سے میچ کرتا ہے۔ وائلڈ کارڈز کام کرتے ہیں (*.example.com سب ڈومینز سے میچ کرتا ہے، apex سے نہیں)۔ ایک الگ ہمیشہ انکار شدہ فہرست allowlist پر غالب آتی ہے اور کلاؤڈ میٹاڈیٹا اینڈپوائنٹس اور ٹیلی میٹری سنکس کو ڈھانپتی ہے۔ جو چیز قابلِ ترتیب نہیں وہ خود فہرست ہے: spec میں اضافی ڈومینز کے لیے ایک egressAllowlist فیلڈ موجود ہے، لیکن dispatch پاتھ میں کوئی چیز اسے populate نہیں کرتی، اس لیے عملاً ہر رن کو بیس لائن کے علاوہ GitHub ملتا ہے اور بس۔

انکار کے واقعات، macOS پر، قابلِ مشاہدہ ہیں: ایک مانیٹر سینڈ باکس انکاروں کے لیے سسٹم لاگ ٹیپ کرتا ہے، معلوم شور چھانتا ہے، retry storms کو ڈیڈپلیکیٹ کرتا ہے اور ہر ایک کو بطور SandboxViolation سامنے لاتا ہے جو بتاتا ہے کہ کیا کرنے کی کوشش ہوئی اور کیا روکا گیا۔ Linux پر رَیپ پاتھ EPERM، Operation not permitted اور Permission denied کے لیے stderr پارس کرتا ہے اور وہی ایونٹ ٹائپ خارج کرتا ہے — وہاں کوئی سسٹم-لاگ ٹیپ نہیں۔ یہ رن کے اپنے ایونٹ اسٹریم پر آتے ہیں، اس لیے کوئی انکار شدہ syscall صرف لاگ میں نہیں بلکہ ٹرانسکرپٹ میں دکھائی دیتا ہے۔ ٹیلی میٹری صرف اسی وقت موجود ہوتی ہے جب کوئی نیٹو سینڈ باکس واقعی پروسیس کو لپیٹ رہا ہو — بیک اینڈ کے بغیر ہوسٹ پر مشاہدہ کرنے کو کچھ نہیں۔ یہ گارڈریلز سے بھی غیر متعلق ہے: خلاف ورزی ایک انکار شدہ syscall سے آتی ہے، کبھی کسی قاعدے کی تلاش سے نہیں۔

تصدیقیں گارڈریلز سے آتی ہیں، سینڈ باکس سے نہیں

سینڈ باکس میں منظوری کا کوئی راستہ نہیں۔ یہ لانچ کرتا ہے، چلاتا ہے، ایونٹس خارج کرتا ہے اور ٹوٹ کر بند ہو جاتا ہے؛ اس میں کہیں کوئی جگہ نہیں جہاں کوئی انسان کسی سوال کا جواب دے۔ جب آپ کسی اسپیس میں تصدیق دیکھیں — اس پش کی منظوری دیں، اس ڈیلیٹ کی منظوری دیں — تو اسے گارڈریل انجن (یا ہارنس کی کمانڈ پالیسی) نے اس سے پہلے اٹھایا تھا کہ وہ ایکشن رن ٹائم تک پہنچے۔

یہ ترتیب جان بوجھ کر ہے۔ وہ منظوری جو syscall کے بعد ہو وہ آڈٹ ریکارڈ ہوگی، گیٹ نہیں۔ یہی وجہ ہے کہ fail-closed اصول گارڈریلز میں رہتا ہے: کوئی منظوری دینے والا منسلک نہ ہو تو فیصلہ کچھ بھی چلنے سے پہلے ہو جاتا ہے اور وہ انکار ہوتا ہے۔

تشخیص

ایجنٹ کی تشخیص چلائیں واحد جگہ ہے جو بتاتی ہے کہ ہاتھ سے کیا جانچا جا سکتا ہے۔