راهنمای اجرای ایمن 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 روی یک سیستم می‌توانند برای یکدیگر متن ارسال کنند و پیامی که از یک نشست هم‌خانواده می‌آید، صرفاً متنی است که عامل دریافت‌کننده آن را می‌خواند. شما باید برای اجرای ناموفق برنامه‌ریزی کنید، نه برای حالت عادی.

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

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

این طراحی فرض می‌کند که یک انسان در حال نظارت بر ترمینال است، و در لپ‌تاپ این موضوع صادق است. در سرور، نکته اغلب این است که کسی نظارت نمی‌کند. شما یک وظیفه طولانی را داخل tmux شروع می‌کنید و می‌خوابید، و عاملی که ساعت 2 بامداد برای پرسیدن یک سوال متوقف می‌شود، تا صبح هیچ پیشرفتی نخواهد داشت. این وقفه علاوه بر زمان، هزینه مالی نیز دارد، زیرا یک نشست غیرفعال Claude Code، کش پرامپت گرم خود را از دست می‌دهد و نوبت بعدی باید هزینه بازسازی آن را بپردازد. این دلیل صادقانه‌ای است که افراد در سرورها به سراغ فلگ 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 از شما سوال می‌کند؛ در حالت خودکار (auto mode)، طبقه‌بندی‌کننده (classifier) میزبان جدید را بررسی می‌کند.

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

sudo apt install bubblewrap socat

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

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

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

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

گیت به عنوان شبکه ایمنی

هر تغییری که عامل (agent) ثبت (commit) می‌کند، قابل بازبینی و بازگشت است. اگر عامل روی یک شاخه (branch) کار کند و تغییرات را در حین پیشرفت ثبت نماید، گیت هر دو قابلیت را به‌صورت رایگان در اختیار شما قرار می‌دهد:

git switch -c agent/refactor-auth

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

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

یک عامل (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 را بازیابی می‌کنید؛ به این ترتیب هیچ‌چیز دیگری که متعلق به شماست تحت تأثیر قرار نمی‌گیرد.