راهنمای اجرای ایمن Claude Code روی سرور

اجرای ایمن Claude Code روی سرور به چه معناست

برای اجرای ایمن Claude Code روی سرور، اعلان‌های مجوز (permission prompts) آن را فعال نگه دارید، آن را با یک کاربر اختصاصی و بدون امتیاز (unprivileged user) اجرا کنید، و برای اجراهای بدون نظارت (unattended)، به‌جای اعتماد مطلق، یک مرز واقعی ایجاد کنید: استفاده از sandbox داخلی، یک container، یا یک VPS یک‌بارمصرف که هیچ دادهٔ مهمی در آن وجود ندارد. فلگ --dangerously-skip-permissions مرحلهٔ تأیید بین مدل و shell شما را حذف می‌کند. این معامله برای کارهای بدون نظارت می‌تواند منطقی باشد، اما فقط در صورتی که درون مرزی قرار گیرد که دسترسی یک دستور مخرب را محدود کند. این راهنما توضیح می‌دهد که این فلگ دقیقاً چه چیزی را تغییر می‌دهد و چگونه می‌توان این مرز را در سطوح مختلف ایزولاسیون ایجاد کرد.

کارهایی که Claude Code می‌تواند روی سیستم شما انجام دهد

Claude Code یک عامل برنامه‌نویسی است که در ترمینال شما اجرا می‌شود. این ابزار فایل‌ها را می‌خواند، فایل می‌نویسد و دستورات shell را با دسترسی کاربری که آن را اجرا کرده است، اجرا می‌کند. تمام ارزش این ابزار در همین است: می‌تواند یک مخزن را clone کند، کد را ویرایش کند، تست‌ها را اجرا کند، خطاها را بخواند و کد را در یک چرخه اصلاح کند، بدون اینکه شما نیاز داشته باشید تک‌تک دستورات را تایپ کنید. اگر هنوز آن را روی سرور راه‌اندازی نکرده‌اید، اجرای Claude Code روی VPS با استفاده از tmux مراحل نصب و مدیریت نشست‌ها را پوشش می‌دهد. این صفحه به قدرت‌هایی می‌پردازد که پس از نصب، در اختیار این ابزار قرار می‌دهید.

ریسک موجود همان جمله‌ای است که دوباره خوانده می‌شود. فرآیندی که دستورات shell را با دسترسی کاربر شما اجرا می‌کند، می‌تواند هر کاری که کاربر شما قادر به انجام آن است را انجام دهد. این ابزار می‌تواند ~/.ssh/id_ed25519، ~/.aws/credentials و هر فایل .env که کاربر شما اجازه باز کردن آن را دارد، بخواند. این ابزار می‌تواند curl را اجرا کرده و داده‌ها را به هر میزبانی که سرور به آن دسترسی دارد، ارسال کند. همچنین می‌تواند git push --force را اجرا نماید. این عامل هیچ انگیزه شخصی ندارد. خطر در این است که یک وظیفه با شکست مواجه شود، یا متنی که در حین کار خوانده است حاوی دستوراتی باشد که توسط شخص دیگری نوشته شده باشد: یک صفحه وب که توسط ابزار دریافت شده، یا نظری در یک issue که از ابزار خواسته شده آن را اصلاح کند. مورد دوم "تزریق دستور" (prompt injection) نامیده می‌شود و به همین دلیل است که "مدل معمولاً منطقی است" یک طرح امنیتی محسوب نمی‌شود. دستورات همچنین می‌توانند از منابع نزدیک‌تر ارسال شوند، زیرا دو نشست Claude Code روی یک سیستم می‌توانند برای یکدیگر متن ارسال کنند و پیامی که از یک نشست هم‌خانواده می‌آید، صرفاً متنی است که عامل دریافت‌کننده آن را می‌خواند. شما باید برای اجرای ناموفق برنامه‌ریزی کنید، نه برای حالت عادی.

سیستم مجوزها به زبان ساده

به‌صورت پیش‌فرض، Claude Code پیش از هر اقدامی از شما اجازه می‌گیرد. خواندن فایل‌ها در پروژه به‌صورت بی‌صدا انجام می‌شود، اما ویرایش یک فایل یا اجرای یک دستور shell، ابتدا ویرایش یا دستور دقیق را به شما نشان می‌دهد و منتظر تأیید می‌ماند. شما می‌توانید یک اقدام خاص را تأیید کنید یا اجازه دهید آن نوع اقدام برای باقی‌ماندهٔ نشست (session) مجاز باشد. این تأییدیه‌ها محدود به همان نشست هستند: با خروج از CLI، نشست بعدی دوباره با احتیاط شروع می‌شود. برای قوانینی که می‌خواهید حفظ شوند، فایل تنظیمات شامل لیست‌های دائمی برای allow، ask و deny است. برای مثال: اجازه به git status، پرسش در مورد git push، و مسدود کردن خواندن .env. قوانین deny همیشه اولویت دارند. این مبنا در حال تغییر است، چرا که حالت auto از تاریخ 14 August 2026 به حالت پیش‌فرض تبدیل می‌شود؛ بنابراین پیش از آنکه تصمیم بگیرید سروری که نمی‌توانید آن را نظارت کنید باید با کدام حالت اجرا شود، ارزشش را دارد که بدانید هر حالت مجوز دقیقاً چه اجازه‌ای می‌دهد.

این طراحی فرض را بر این می‌گذارد که یک انسان در حال نظارت بر ترمینال است، که در لپ‌تاپ صادق است. در سرور، نکته اینجاست که اغلب کسی نظارت نمی‌کند. شما یک وظیفهٔ طولانی را داخل tmux شروع می‌کنید و می‌خوابید، و عاملی که ساعت 2 بامداد برای پرسیدن یک سوال متوقف می‌شود، تا صبح هیچ پیشرفتی نخواهد داشت. این توقف هم هزینهٔ مالی دارد و هم زمان، زیرا یک نشست غیرفعال Claude Code کش prompt گرم خود را از دست می‌دهد و نوبت بعدی برای بازسازی آن هزینه می‌پردازد. این دلیل صادقانه‌ای است که افراد در سرورها به سراغ فلگ skip می‌روند و مشکلی که حل می‌کند واقعی است. باقی این راهنما دربارهٔ حل این مسئله بدون کنار گذاشتن تمام محافظ‌ها است.

تغییرات اعمال‌شده توسط --dangerously-skip-permissions

claude --dangerously-skip-permissions مرحله تأیید را غیرفعال می‌کند. ویرایش‌ها بدون پرسش انجام می‌شوند. دستورات Shell بدون درخواست تأیید اجرا می‌گردند. بررسی مسیرهای محافظت‌شده که به‌طور معمول از مکان‌های حساس مراقبت می‌کنند نیز نادیده گرفته می‌شوند. قوانین صریح deny شما همچنان اعمال می‌شوند و برخی اقدامات بسیار خطرناک همچنان متوقف شده و درخواست تأیید می‌کنند، اما خلاصه عملکرد ساده است: هر آنچه مدل تصمیم به اجرای آن بگیرد، اجرا می‌شود.

دو نکته درباره این flag در سرور اهمیت دارد. نخست اینکه، وقتی Claude Code به‌عنوان root یا با sudo در Linux و macOS اجرا شود، این flag مسدود می‌شود؛ زیرا دسترسی root بدون پرسش می‌تواند هر فایل یا سرویسی را در سیستم تغییر دهد. عامل (agent) در هر صورت به حساب کاربری بدون امتیاز (unprivileged) خود نیاز دارد و این flag همان را اعمال می‌کند. دوم اینکه، این flag به هیچ وجه رفتار مدل را تغییر نمی‌دهد. این گزینه فقط انسان را از حلقه تصمیم‌گیری حذف می‌کند و هیچ چیز دیگری را تغییر نمی‌دهد؛ بنابراین هر اشتباهی که یک پرسش تأیید می‌توانست جلوی آن را بگیرد، اکنون اجرا می‌شود.

بنابراین محاسبه صادقانه به این صورت است: اگر مجوزها را نادیده بگیرید، پرسش امنیتی از «آیا عامل کار بدی انجام می‌دهد» به «یک اقدام بد چقدر می‌تواند خسارت وارد کند» تغییر می‌یابد. شما تلاش برای کنترل تک‌تک تصمیمات را متوقف می‌کنید و شروع به کنترل شعاع انفجار (blast radius) می‌کنید. پاسخ در مهار کردن (containment) است که در سطوح مختلف انجام می‌شود.

سندباکس داخلی Claude Code

پیش از بررسی مراحل، بدانید که Claude Code اکنون یک سندباکس در سطح سیستم‌عامل برای دستوراتی که اجرا می‌کند ارائه می‌دهد و اکثر دلایلی که کاربران را به استفاده از فلگ skip سوق می‌داد، حذف کرده است. در لینوکس، این ابزار از bubblewrap برای ایزوله‌سازی فایل‌سیستم و از socat برای هدایت ترافیک شبکه از طریق یک پروکسی استفاده می‌کند. درون سندباکس، یک دستور فقط می‌تواند در دایرکتوری پروژه و یک دایرکتوری موقت نشست (session) بنویسد و تنها از طریق پروکسی که هر دامنه را با یک لیست مجاز (allow list) تطبیق می‌دهد، به شبکه دسترسی دارد. اولین باری که یک دستور به دامنه‌ای جدید نیاز داشته باشد، Claude Code از شما سوال خواهد کرد.

آن را با دستور /sandbox در طول یک نشست فعال کنید. در Ubuntu و Debian، ابتدا دو بسته‌ای که به آن نیاز دارد را نصب کنید:

sudo apt install bubblewrap socat

در Ubuntu 24.04 و نسخه‌های بعد از آن، پالیسی پیش‌فرض AppArmor مانع از ایجاد namespaceهای کاربری مورد نیاز توسط bubblewrap می‌شود. پنل سندباکس در صورت کمبود هر چیزی به شما اطلاع می‌دهد و مستندات سندباکسینگ Claude Code حاوی پروفایل کوتاه AppArmor برای رفع این مشکل است.

سندباکس دارای حالت auto-allow است: دستورات سندباکس‌شده بدون هیچ پرسشی اجرا می‌شوند، زیرا مرز اعمال‌شده اکنون کاری را انجام می‌دهد که پیش‌تر بر عهده پرسش بود. دستوراتی که نمی‌توانند درون سندباکس اجرا شوند، به جریان مجوزهای عادی بازمی‌گردند، بنابراین اقدامات واقعاً غیرمعمول همچنان نیاز به تایید دارند. برای اکثر گردش‌کارهای سرور، این جایگزین مناسبی برای فلگ skip است، زیرا به جای حذف کامل پرسش‌ها، با یک مرز اعمال‌شده توسط سیستم‌عامل، تعداد سوالات بسیار کمتری دریافت می‌کنید.

در مورد محدودیت‌های آن صادق باشید. به‌طور پیش‌فرض، یک دستور سندباکس‌شده همچنان می‌تواند اکثر فایل‌سیستم، از جمله فایل‌های حاوی اعتبارنامه‌ها (credentials) را بخواند، مگر اینکه آن مسیرها را مسدود کنید؛ تنظیم sandbox.credentials دقیقاً برای همین منظور وجود دارد. پروکسی شبکه نام دامنه‌ها را بررسی می‌کند و خود ترافیک را بازرسی نمی‌کند، بنابراین یک اجازه کلی مانند github.com همچنان امکان انتقال داده به خارج را باقی می‌گذارد. Docker درون آن کار نمی‌کند. سندباکس سطح امنیت را به‌طور قابل‌توجهی ارتقا می‌دهد. این یک مرز ایزوله‌سازی کامل نیست و به همین دلیل است که مراحل زیر همچنان اهمیت دارند.

نردبان ایزوله‌سازی

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

پله 1: یک کاربر غیرمجاز (unprivileged) اختصاصی. عامل (agent) حساب کاربری، دایرکتوری home، دایرکتوری پروژه و دسترسی sudo مخصوص به خود را دارد:

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

مرز حساب کاربری، عامل را از فایل‌های شما دور نگه می‌دارد: کلیدهای SSH و سایر پروژه‌های موجود روی ماشین. این کار همچنین باعث می‌شود پرچم skip قابل استفاده باشد، چرا که این پرچم از اجرا شدن به عنوان root خودداری می‌کند. این همان اصل اجرای هر سرویس با یک کاربر غیرمجاز است که برای یک عامل اعمال می‌شود. آنچه پله 1 محدود نمی‌کند: شبکه و هر چیزی روی ماشین که برای همه قابل خواندن (world-readable) باشد.

پله 2: یک کانتینر. شرکت Anthropic یک devcontainer مرجع منتشر کرده است که Claude Code را به عنوان یک کاربر غیر root اجرا می‌کند، همراه با قوانین فایروالی که میزبان‌های قابل دسترسی برای عامل را محدود می‌کند؛ کانتینری که خودتان می‌سازید نیز همین کار را انجام می‌دهد. سیستم فایل به volumeهایی که mount می‌کنید محدود می‌شود و خروجی شبکه (egress) به قوانینی که برای کانتینر تعیین کرده‌اید محدود می‌گردد. این پله میانی مناسب زمانی است که سرور میزبان سرویس‌های دیگری است که برایتان اهمیت دارند. محدودیت آن این است که کانتینرها از هسته (kernel) میزبان مشترک استفاده می‌کنند و یک mount بی‌دقت، مرز را از بین می‌برد؛ اگر به کانتینر /var/run/docker.sock بدهید، می‌تواند به کل میزبان دسترسی پیدا کند.

پله 3: یک VPS اختصاصی. قوی‌ترین پله، صریح‌ترین آن‌هاست: به عامل یک ماشین کامل بدهید که هیچ چیز مهمی در آن وجود ندارد. هزینه یک VPS کوچک چند دلار در ماه است. آن را با کتابچه راهنمای ده دقیقه اول روی یک VPS جدید راه‌اندازی کنید، از وضعیت تمیز آن snapshot بگیرید و اجازه دهید عامل کار کند. هیچ چیز دیگری در آنجا وجود ندارد. نه کلید SSH شخصی، فقط یک deploy key که محدود به همان مخزن (repository) است. نه اعتبارنامه‌های ابری، نه داده‌های تولیدی. وقتی کاری اشتباه پیش می‌رود، یا زمانی که صرفاً می‌خواهید همه چیز را به حالت اولیه برگردانید، snapshot را بازیابی کنید یا ماشین را در عرض چند دقیقه نابود و دوباره بسازید. شعاع انفجار (blast radius) به اندازه هزینه اجاره است. این همان تنظیماتی است که در آن --dangerously-skip-permissions دیگر ترسناک نیست، زیرا بدترین نتیجه واقع‌بینانه، بازسازی سرور و ابطال یک توکن است.

این پله‌ها روی هم قرار می‌گیرند. یک عامل در محیط sandbox، که به عنوان یک کاربر غیرمجاز روی یک VPS یک‌بارمصرف اجرا می‌شود، تقریباً هزینه اضافی ندارد و باعث می‌شود داستان‌های شکست، خسته‌کننده باشند. خسته‌کننده بودن، هدف نهایی است.

محافظت از اعتبارنامه‌ها

قانونی که ضامن امنیت سایر بخش‌هاست: کاربرِ agent نباید بتواند به اسرار متعلق به سایر بخش‌ها دسترسی داشته باشد.

کلید API را فقط در اختیار agent قرار دهید و نه هیچ چیز دیگر. آن را در فایلی قرار دهید که مالک آن کاربرِ agent باشد و دسترسی آن روی 600 تنظیم شده باشد؛ سپس هنگام شروع shell، آن را بارگذاری کنید:

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، دایرکتوری‌های خانگی اغلب به‌گونه‌ای ایجاد می‌شوند که برای همه کاربران سیستم قابل خواندن هستند؛ بنابراین دسترسی دایرکتوری خود را محدود کنید: chmod 750 /home/youruser. با استفاده از ls -ld /home/* وضعیت را بررسی کرده و هر موردی که حساب کاربری agent قادر به لیست کردن آن است را اصلاح کنید.

محدوده دسترسی هر توکن را تعیین کنید. یک توکن GitHub با دسترسی محدود به یک مخزن خاص، یا یک کلید deploy مخصوص هر مخزن، باعث می‌شود در صورت نشت اعتبارنامه، تنها یک پروژه به خطر بیفتد و نه کل حساب کاربری شما. اگر از sandbox استفاده می‌کنید، تنظیمات اعتبارنامه آن را به‌گونه‌ای اضافه کنید که ~/.ssh و ~/.aws حتی برای خواندن نیز رد شوند. اعتبارنامه‌های محیط production را به‌طور کامل از روی این سیستم دور نگه دارید، زیرا agent نمی‌تواند رازی را که در سیستم وجود ندارد، فاش کند. اگر این اسرار در یک password manager خودمیزبان (self-hosted) نگهداری می‌شوند، آن را روی سیستمی متفاوت از agent قرار دهید و به‌طور جداگانه بررسی کنید، زیرا نقاط ضعف Vaultwarden، توکن مدیریت و فایل پشتیبان آن است و نه خودِ vault رمزنگاری‌شده.

Git شبکه ایمنی شماست

هر تغییری که agent اعمال می‌کند باید قابل بازبینی و بازگشت باشد؛ اگر agent روی یک branch کار کند، git هر دوی این قابلیت‌ها را به‌صورت رایگان در اختیار شما قرار می‌دهد:

git switch -c agent/refactor-auth

پس از پایان اجرا، تغییرات را با git diff main...agent/refactor-auth بازبینی کنید، آنچه مطلوب است را merge کنید و اگر اجرا نتیجه‌ای نداشت، branch را حذف کنید. خواندن تغییراتی که در سه فایل اعمال شده، هنگام صبحانه بسیار آسان‌تر از بررسی تغییری است که نیمی از یک ماژول را بازنویسی کرده است؛ این همان دلیل عملی برای مهارتی است که agent را به اعمال کوچک‌ترین تغییرِ کارآمد محدود می‌کند. branch اصلی (main) را در پلتفرم میزبانی کد (forge) محافظت کنید تا token مربوط به agent نتواند به آن push کند و امکان force-push در هیچ‌کجا را نداشته باشد. تاریخچه commitها به‌عنوان یک audit log از اتفاقاتی که در زمان خواب شما رخ داده عمل می‌کند؛ ارزشی که این تاریخچه دارد، بسیار بیشتر از هر مقدار اسکرول کردن در ترمینال است.

شبکه بخشی از شعاع انفجار است

یک عامل (agent) می‌تواند curl را اجرا کند. این جمله تمام مشکل خروج داده (egress) را خلاصه می‌کند: هر چیزی که عامل بتواند بخواند، می‌تواند به جایی ارسال کند و یک عامل که دچار تزریق دستور (prompt injection) شده باشد، ممکن است همین کار را انجام دهد. یک کاربر عادی و بدون دسترسی ویژه، این موضوع را محدود نمی‌کند، زیرا هر کاربری می‌تواند به هر چیزی که سرور به آن دسترسی دارد، برسد. محیط sandbox این دسترسی را از طریق پروکسی خود و بر اساس دامنه محدود می‌کند. یک کانتینر می‌تواند با قوانین فایروال اختصاصی خود، این دسترسی را محدود سازد. یک VPS اختصاصی، آنچه را که اساساً امکان نشت دارد محدود می‌کند، که در میان این سه روش، مطمئن‌ترین پاسخ است.

تلاش نکنید مشکل خروج داده را تنها با ufw حل کنید. ufw به‌صورت پیش‌فرض تمام ترافیک خروجی را مجاز می‌شمارد و نوشتن قوانین خروجی که همچنان اجازه دسترسی به apt، npm، git و API مربوط به Claude را بدهد، کاری پیچیده است که به‌سادگی دچار اختلال می‌شود. در عوض، مرز امنیتی را در سطح sandbox، کانتینر یا ماشین تعریف کنید، جایی که یک لیست مجاز از دامنه‌ها یا استفاده از یک ماشین اختصاصی، همین کار را به‌تمیزی انجام می‌دهد.

اگر به‌جای اجرای Claude Code، در حال ساخت عامل هوش مصنوعی خودتان با استفاده از API هستید، همین منطق بدون تغییر صدق می‌کند. ساخت یک عامل هوش مصنوعی با Claude روی یک VPS این مسیر را پوشش می‌دهد و عامل شما نیز به همان کاربر اختصاصی، همان توکن‌های محدودشده و همان محیط ایزوله نیاز دارد.

سخت‌سازی اولیه سرور

صرف‌نظر از مسیری که انتخاب می‌کنید، پیش از نصب هرگونه عامل (agent)، خودِ ماشین باید اصول اولیه امنیتی را رعایت کند: استفاده صرف از SSH keys، غیرفعال کردن ورود کاربر root، تنظیم فایروال بر اساس سیاست default-deny و فعال‌سازی به‌روزرسانی‌های امنیتی خودکار. چک‌لیست خود را در اینجا ایجاد کنید و گام‌به‌گام آن را اجرا نمایید:

FAQ

آیا استفاده از --dangerously-skip-permissions روی سرور امن است؟

به‌تنهایی خیر. این فلگ تمام اعلان‌های تأیید را حذف می‌کند، بنابراین اولین دستور مخرب بلافاصله پس از تولید توسط مدل اجرا می‌شود. استفاده از آن تنها زمانی قابل‌دفاع است که شعاع انفجار محدود باشد: حداقل استفاده از یک کاربر بدون دسترسی (unprivileged) و برای کارهای کاملاً خودکار، استفاده از یک کانتینر یا یک VPS یک‌بارمصرف که فقط شامل یک پروژه و یک توکن محدود است. هرگز از این فلگ روی ماشینی که حاوی اعتبارنامه‌های عملیاتی (production) یا داده‌های غیرقابل‌جایگزین است، استفاده نکنید.

آیا Claude Code دارای sandbox است؟

بله. Claude Code دارای یک sandbox داخلی برای دستورات shell است که با دستور /sandbox باز می‌شود. این قابلیت در لینوکس از bubblewrap و در macOS از Seatbelt استفاده می‌کند، دسترسی نوشتن را به دایرکتوری پروژه محدود کرده و دسترسی شبکه را از طریق پروکسی‌ای هدایت می‌کند که فقط دامنه‌های تأییدشده را مجاز می‌شمارد. حالت auto-allow در این ابزار، دستورات را بدون اعلان در محیط sandbox اجرا می‌کند؛ بنابراین همانند فلگ skip، وقفه‌ها را کاهش می‌دهد و در عین حال یک مرز امنیتی اعمال‌شده توسط سیستم‌عامل را حفظ می‌کند. این یک مرز ایزولاسیون کامل نیست، بنابراین برای اجراهای خودکار، آن را با یک کاربر اختصاصی یا یک ماشین مجزا ترکیب کنید.

چرا فلگ skip اجازه اجرا با دسترسی root را نمی‌دهد؟

از آنجا که root بدون اعلان‌های تأیید دسترسی می‌تواند هر فایل و هر سرویسی را در سیستم تغییر دهد، Claude Code اجرای --dangerously-skip-permissions را هنگام اجرا با root یا تحت sudo در لینوکس و macOS مسدود می‌کند. راه‌حل، دور زدن این بررسی نیست. یک کاربر بدون دسترسی برای عامل (agent) ایجاد کنید و آن را در آنجا اجرا کنید؛ مرز حساب کاربری، اولین و ارزان‌ترین لایه مهار است.

آیا Claude Code می‌تواند کلیدهای SSH و فایل‌های .env من را بخواند؟

این ابزار می‌تواند هر فایلی را که کاربرِ در حال اجرا به آن دسترسی دارد، بخواند؛ حتی سیاست پیش‌فرض sandbox نیز تا زمانی که دسترسی به مسیرهای حاوی اعتبارنامه را مسدود نکنید، اجازه خواندن آن‌ها را می‌دهد. بنابراین، عامل را با کاربر اختصاصی خودش اجرا کنید، دایرکتوری home خود را با مجوز 750 یا محدودتر تنظیم کنید، مسیرهای حاوی اعتبارنامه را در تنظیمات sandbox مسدود کنید و اسرار عملیاتی (production) را به‌کلی از روی آن ماشین دور نگه دارید. رازی که هرگز در آن محیط قرار نگرفته باشد، قابل خواندن یا نشت نیست.

امن‌ترین روش برای اجرای خودکار Claude Code چیست؟

استفاده از یک VPS ارزان و اختصاصی که فقط برای کارهای عامل استفاده می‌شود: در ده دقیقه سخت‌سازی (harden) شود، از وضعیت تمیز آن snapshot گرفته شود، Claude Code تحت یک کاربر بدون دسترسی با sandbox فعال اجرا شود، کلید API در فایلی با مجوز 600 نگهداری شود، از deploy key مخصوص هر مخزن استفاده شود و تمام کارها روی شاخه‌هایی (branches) انجام شود که پیش از merge کردن بررسی می‌کنید. اگر اجرایی با مشکل مواجه شد، یک توکن را ابطال کرده و snapshot را بازیابی می‌کنید؛ به این ترتیب هیچ‌چیز دیگری که متعلق به شماست تحت تأثیر قرار نمی‌گیرد.