انتخابِ یک محیطِ sandbox

این یک ترجمهٔ غیررسمی از مستندات Claude Code است که توسط مسیر تهیه شده. نسخهٔ مرجع و معتبر، مستندات رسمی انگلیسی است.

ایزوله‌کردنِ Claude Code محدود می‌کند که یک نشست چه چیزی را می‌تواند بخواند، بنویسد، و روی شبکه به آن برسد. این بیش از همه وقتی مهم است که می‌گذاری Claude با درخواست‌های مجوزِ کمتر کار کند، آن را بدونِ نظارت اجرا می‌کنی، یا به کدی نشانه‌اش می‌گیری که کاملاً به آن اعتماد نداری.

Claude Code می‌تواند در چند نوع محیطِ ایزوله اجرا شود، از یک sandbox سبکِ per-command گرفته تا یک ماشینِ مجازیِ کاملاً جدا. این صفحه پوشش می‌دهد که چطور:

• رویکردهای ایزولاسیونِ در دسترس را بر اساسِ اینکه چه چیزی را ایزوله می‌کنند، چه نیاز دارند، و چه‌قدر راه‌اندازی می‌خواهند مقایسه کنی
• رویکردی را که با هدف و مدلِ تهدیدت جور است انتخاب کنی
• با رویکردی که انتخاب کردی شروع کنی، از Bash sandbox داخلی تا یک ماشینِ مجازیِ اختصاصی
• ایزولاسیون را برای هر توسعه‌دهنده در سازمانت اجبار کنی

یادداشت

برای مدلِ امنیتیِ گسترده‌تر، Security را ببین. برای استقرارهای Agent SDK، Secure deployment را ببین.

مقایسه‌ی رویکردهای sandboxing

دو رویکردِ اولِ جدولِ زیر روی سیستم‌عاملِ میزبان بدونِ container اجرا می‌شوند. بقیه Claude Code را درونِ یک container یا ماشینِ مجازی قرار می‌دهند.

رویکرد	چه چیزی ایزوله می‌شود	به Docker نیاز دارد	تلاشِ راه‌اندازی
ابزارِ Bash در sandbox	دستورهای Bash و پروسه‌های فرزندشان	نه	حداقلی روی macOS؛ کم روی Linux و WSL2
Sandbox runtime	کلِ پروسه‌ی Claude Code، از جمله ابزارهای فایل، سرورهای MCP، و hookها	نه	کم
Dev container	محیطِ کاملِ توسعه	بله	متوسط
Custom container	محیطِ کاملِ توسعه	بله	متوسط تا بالا
ماشینِ مجازی	سیستم‌عاملِ کامل	نه	بالا
Claude Code on the web	سیستم‌عاملِ کامل، میزبانی‌شده توسطِ Anthropic	نه	هیچ؛ به یک اشتراکِ Claude و GitHub نیاز دارد

ابزارِ Bash در sandbox در Claude Code تعبیه شده و فقط دستورهای Bash را محدود می‌کند. ابزارهای فایلِ داخلی، سرورهای MCP، و hookها همچنان مستقیم روی میزبانت اجرا می‌شوند. هر رویکردِ دیگری در جدول کلِ پروسه‌ی Claude Code را درونِ مرزِ ایزولاسیون قرار می‌دهد، پس ابزارهای فایل، سرورهای MCP، و hookها هم محدود می‌شوند.

احتیاط

ایزولاسیونِ sandbox تأثیرِ یک نفوذ را کم می‌کند، اما ریسک را از بین نمی‌برد. هر رویکردی که اجازه‌ی خروجِ شبکه می‌دهد همچنان می‌تواند داده‌ای را که agent می‌تواند بخواند نشت دهد، و هر رویکردی که پوشه‌ی پروژه‌ات را قابلِ‌نوشتن mount می‌کند همچنان می‌تواند آن کد را تغییر دهد. پیش از اینکه به یک sandbox به‌عنوانِ یک کنترلِ سفت‌و‌سخت تکیه کنی، محدودیت‌های امنیتی را بازبینی کن.

ایزولاسیون همچنین تغییری در آنچه به مدل فرستاده می‌شود نمی‌دهد. promptهایت و فایل‌هایی که Claude می‌خواند با یا بدونِ sandbox به Claude API یا ارائه‌دهنده‌ی پیکربندی‌شده‌ات منتقل می‌شوند. برای اینکه Claude Code چه می‌فرستد و چطور آن را کم کنی، Data usage را ببین.

انتخابِ یک رویکرد

هدفت را با یک ردیفِ زیر جور کن، بعد بخشِ جزئیاتی را که در پی می‌آید بخوان.

می‌خواهی	شروع کن با
درخواست‌های مجوز را در کارِ روزمره روی ماشینِ خودت کم کنی	ابزارِ Bash در sandbox، فعال‌شده با /sandbox
بگذاری Claude بدونِ نظارت با --dangerously-skip-permissions یا auto mode کار کند	dev container از‌پیش‌پیکربندی‌شده، هر container یا VM، یا sandbox runtime
سرورهای MCP و hookها را هم مثلِ Bash، بدونِ Docker ایزوله کنی	sandbox runtime
روی یک مخزنِ غیرِقابلِ‌اعتماد کار کنی	یک ماشینِ مجازیِ اختصاصی، یا Claude Code on the web اگر یک اشتراکِ Claude و یک حسابِ GitHub متصل داری
یک محیطِ sandbox‌شده را در سراسرِ یک تیم استاندارد کنی	dev container از‌پیش‌پیکربندی‌شده، کپی‌شده در مخزنت
از Claude Code از دستگاهی بدونِ راه‌اندازیِ محلی استفاده کنی	Claude Code on the web، که به یک اشتراکِ Claude و یک حسابِ GitHub متصل نیاز دارد
ایزولاسیون را برای هر توسعه‌دهنده در سازمانت اجبار کنی	اجبارِ ایزولاسیون در سراسرِ یک سازمان
روی یک میزبانِ بومیِ Windows کار کنی	یک container یا VM، یا اجرای Bash sandbox درونِ WSL2

ایزولاسیون چطور به permission modeها مربوط می‌شود

Permission modeها تصمیم می‌گیرند که یک فراخوانیِ ابزار اجرا شود یا نه و آیا اول از تو پرسیده می‌شود. ایزولاسیون محدود می‌کند که یک دستور وقتی اجرا شد به چه چیزی می‌تواند دسترسی پیدا کند. این دو با هم کار می‌کنند: وقتی یک permission mode اجازه می‌دهد اکشن‌ها بدونِ پرسیدن از تو اجرا شوند، یک مرزِ ایزولاسیون محدود می‌کند که آن اکشن‌ها به چه چیزی می‌توانند برسند.

--dangerously-skip-permissions بازبینیِ per-action را غیر از ask ruleهای صریح برمی‌دارد، پس یک مرزِ ایزولاسیون تنها چیزی است که آنچه Claude می‌تواند بکند را محدود می‌کند. همیشه آن را درونِ یک container، یک VM، یا sandbox runtime اجرا کن، تا ابزارهای فایل، سرورهای MCP، و hookها هم درونِ مرز باشند.

Auto mode درخواست را با یک طبقه‌بند جایگزین می‌کند که اکشن‌ها را بازبینی می‌کند و آن‌هایی را که فراتر از درخواست بالا می‌روند، زیرساختِ ناشناخته را هدف می‌گیرند، یا به‌نظر می‌رسد محتوای خصمانه‌ای که Claude خوانده آن‌ها را پیش می‌برد، مسدود می‌کند. طبقه‌بند یک کنترلِ per-action است، نه یک مرزِ ایزولاسیون، پس یک مرزِ ایزولاسیون همچنان برای runهای بدونِ نظارت دفاع در عمق اضافه می‌کند، و آن‌طور که برای --dangerously-skip-permissions لازم است الزامی نیست.

ابزارِ Bash در sandbox به‌تنهایی فقط Bash را محدود می‌کند، پس برای runهای کاملاً بدونِ نظارت در هیچ‌یک از دو mode کافی نیست. می‌توانی رویکردها را لایه‌لایه کنی: اجرای ابزارِ Bash در sandbox درونِ یک container یا VM به تو محدودیت‌های دستورِ سطحِ OS را روی مرزِ محیطِ بیرونی می‌دهد. برای اینکه خودِ Bash sandbox چطور با قواعد و modeهای permission تعامل می‌کند، نحوه‌ی ارتباطِ sandboxing با permissions و permission modeها را ببین.

ابزارِ Bash در sandbox

یادداشت

این گزینه از Windows بومی پشتیبانی نمی‌کند. روی میزبان‌های Windows، از WSL2 یا یکی از رویکردهای container یا VM زیر استفاده کن.

ابزارِ Bash در sandbox در Claude Code تعبیه شده. از primitiveهای سیستم‌عامل استفاده می‌کند تا دسترسیِ filesystem و شبکه‌ی هر دستورِ Bash که Claude اجرا می‌کند را محدود کند: Seatbelt، sandbox داخلیِ macOS، و bubblewrap روی Linux و WSL2. به‌صورتِ پیش‌فرض نوشتن در پوشه‌ی کاری را مجاز می‌کند و اولین باری که یک دستور به یک دامنه‌ی شبکه‌ی جدید نیاز دارد می‌پرسد.

آن را با دستورِ /sandbox فعال کن. راهنمای Sandboxing حالت‌های تأیید، مرزِ پیش‌فرض، و نحوه‌ی گشاد یا تنگ‌کردنش را پوشش می‌دهد.

sandbox per-command همه‌ی آنچه را در یک نشست اجرا می‌شود پوشش نمی‌دهد:

• سایرِ ابزارهای داخلی مثلِ Read، Edit، و WebFetch درونِ پروسه‌ی Claude Code اجرا می‌شوند و کدِ دلخواه spawn نمی‌کنند. به‌جایش قواعدِ permission برای مسیر یا دامنه آن‌ها را gate می‌کنند.
• سرورهای MCP و hookها پروسه‌های جدایی‌اند که بدونِ محدودیت روی میزبان اجرا می‌شوند.

برای قراردادنِ ابزارهای داخلی، سرورهای MCP، و hookها همگی پشتِ یک مرزِ OS، کلِ پروسه‌ی Claude Code را درونِ sandbox runtime، dev container، یا یک custom container اجرا کن.

Sandbox runtime

پکیجِ @anthropic-ai/sandbox-runtime کلِ یک پروسه را در همان ایزولاسیونِ Seatbelt یا bubblewrap که Bash sandbox داخلی استفاده می‌کند می‌پیچد. اجرای Claude Code از طریقِ آن هر ابزار، hook، و سرورِ MCP در نشست را محدود می‌کند، نه فقط Bash. این runtime یک research preview بتا است، و فرمتِ پیکربندی‌اش ممکن است با تکاملِ پکیج تغییر کند.

این runtime به‌صورتِ پیش‌فرض همه‌ی دسترسیِ نوشتن و شبکه را انکار می‌کند، پس قبل از launch‌کردنِ Claude Code از طریقِ آن پیکربندی‌اش کن. در ~/.srt-settings.json، یا فایلی که با --settings پاس می‌دهی، دسترسیِ نوشتن را دستِ‌کم به پوشه‌ی پروژه‌ات و مسیرهای پیکربندیِ Claude Code یعنی ~/.claude و ~/.claude.json مجاز کن. دامنه‌های شبکه‌ای را که نشستت نیاز دارد مجاز کن، از جمله api.anthropic.com یا endpointِ ارائه‌دهنده‌ی پیکربندی‌شده‌ات. برای schema کاملِ پیکربندی، README پکیج را ببین.

وقتی فایلِ تنظیمات سرِ جایش بود، Claude Code را با npx launch کن و claude را به‌عنوانِ دستوری که باید پیچیده شود پاس بده:

npx @anthropic-ai/sandbox-runtime claude

Claude Code درونِ sandbox با مرزهای filesystem و شبکه‌ای که پیکربندی کردی شروع می‌شود. همان دستور برای sandbox‌کردنِ سرورهای MCP مستقل یا سایرِ پروسه‌های کمکی هم کار می‌کند.

Dev containerها

یک dev container، Claude Code را درونِ یک container Docker که VS Code یا یک ویرایشگرِ سازگار مدیریتش می‌کند اجرا می‌کند، با پروژه‌ات mount‌شده در آن. می‌توانی مالِ خودت را با یک پوشه‌ی .devcontainer/ در مخزنت تعریف کنی.

مخزنِ claude-code یک نمونه dev container با یک firewall iptables از‌نوعِ default-deny به‌عنوانِ نقطه‌ی شروع منتشر می‌کند. آن را در مخزنت کپی کن و allowlist firewall، image پایه، و نسخه‌ی pin‌شده‌ی Claude Code را برای جورشدن با محیطت تنظیم کن. چون firewall خروجِ تأییدنشده را مسدود می‌کند، پیکربندی‌ای مثلِ این، اجرای Claude Code با --dangerously-skip-permissions را برای کارِ بدونِ نظارت پشتیبانی می‌کند.

Custom container

می‌توانی Claude Code را در هر image container از‌نوعِ Docker یا OCI با سیاست‌های شبکه، volumeهای mount‌شده، و profileهای seccomp خودت اجرا کنی. این رایج‌ترین مسیر برای سازمان‌هایی است که زیرساختِ container موجود یا CI runner دارند.

چند سرویسِ sandbox مدیریت‌شده و اجرای راهِ دور می‌توانند container را برایت میزبانی کنند. همان چک‌لیستی که برای هر containerی که اداره می‌کنی صدق می‌کند: بازبینی کن چه چیزی قابلِ‌نوشتن mount شده، چه اعتبارها و توکن‌هایی درونش قابلِ دسترس‌اند، و سیاستِ خروجِ شبکه چه چیزی را مجاز می‌کند.

می‌توانی Bash sandbox داخلی را درونِ container برای محدودیت‌های per-command لایه کنی. containerهای غیرِ‌privileged به تنظیمِ nested-sandbox که در عیب‌یابیِ Sandboxing شرح داده شده نیاز دارند.

ماشینِ مجازی

یک ماشینِ مجازیِ اختصاصی قوی‌ترین جدایی را فراهم می‌کند، با کرنلِ خودش و، در استقرارهای ابری یا microVM، سخت‌افزارِ مجازی‌سازی‌شده‌ی خودش. گزینه‌ها شاملِ instanceهای ابری، hypervisorهای محلی، و microVMها مثلِ Firecracker می‌شوند.

از این رویکرد وقتی استفاده کن که کدِ غیرِقابلِ‌اعتماد را ارزیابی می‌کنی، وقتی سیاستِ امنیتی‌ات جداییِ سطحِ کرنل بینِ agent و میزبان را لازم می‌داند، یا وقتی هیچ رویکردِ سطحِ میزبان الزاماتِ انطباقت را برآورده نمی‌کند. قابلیتِ sandboxهای Docker Desktop یک microVM با daemon Docker و sync workspace خودش فراهم می‌کند، که می‌تواند Claude Code را روی میزبان‌هایی که از قبل Docker Desktop دارند اجرا کند.

Claude Code on the web

Claude Code on the web هر نشست را در یک ماشینِ مجازیِ ایزوله و مدیریت‌شده‌ی Anthropic اجرا می‌کند. یک proxy شبکه یک allowlist پیش‌فرض را اجبار می‌کند، و یک proxy جدا توکنِ GitHub تو را بیرونِ sandbox نگه می‌دارد در حالی که اعتبارهای scope‌دار برای دسترسیِ مخزن درونِ آن صادر می‌کند.

از این رویکرد وقتی استفاده کن که ایزولاسیونِ کاملِ VM می‌خواهی بدونِ اینکه خودت زیرساخت provision کنی، یا وقتی کارها را از دستگاهی که محیطِ توسعه‌ی محلی ندارد واگذار می‌کنی. به یک اشتراکِ Claude و یک حسابِ GitHub متصل نیاز دارد، و نشست‌ها مخزنت را از GitHub clone می‌کنند. برای در دسترس‌بودنِ پلن و گزینه‌های احرازِ هویتِ GitHub، Claude Code on the web را ببین.

اجبارِ ایزولاسیون در سراسرِ یک سازمان

توسعه‌دهنده‌های منفرد می‌توانند هر رویکردِ بالا را انتخاب کنند. اینکه یک سازمان چه چیزی را می‌تواند اجبار کند، و با کدام ابزارها، به رویکرد بستگی دارد:

• Bash sandbox داخلی: تنها رویکردی که Claude Code خودش اجبار می‌کند. کلیدهای تنظیماتِ sandbox را از طریقِ managed settings تحویل بده، یا به‌صورتِ فایلی که MDM تو مدیریتش می‌کند یا از طریقِ server-managed settings روی Claude.ai. برای کلیدهایی که باید deploy کنی و نحوه‌ی جلوگیری از گشادکردنِ سیاست توسطِ توسعه‌دهنده‌ها، اجبارِ sandboxing با managed settings را ببین.
• Dev containerها: نمونه dev container را در مخزن‌هایت کامیت کن تا محیط را در سراسرِ یک تیم استاندارد کنی. این یک قرارداد است نه یک مرزِ اجبار، چون Claude Code container را الزامی نمی‌کند. اگر توسعه‌دهنده‌ها نباید بتوانند Claude Code را بیرونِ آن اجرا کنند، آن را با ابزارهای مدیریتِ دستگاه یا allowlistingِ نرم‌افزارِ سازمانت اجبار کن.
• Custom containerها و VMها: Claude Code را از طریقِ image تأییدشده توزیع کن و از ابزارهای مدیریتِ دستگاه یا allowlistingِ نرم‌افزارِ سازمانت استفاده کن تا از نصب بیرونِ آن جلوگیری کنی.

همچنین ببین

این صفحات جزئیاتِ پیکربندی و سیاستِ رویکردهای بالا را پوشش می‌دهند.

• Sandboxing: ابزارِ Bash در sandbox داخلی را پیکربندی کن
• Dev container: container توسعه‌ی Docker از‌پیش‌پیکربندی‌شده
• Security: مدلِ امنیتیِ کاملِ Claude Code
• Secure deployment: راهنماییِ ایزولاسیون برای اپلیکیشن‌های Agent SDK
• Settings: همه‌ی کلیدهای پیکربندیِ sandbox، از جمله تحویلِ managed settings