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

معنای اجرای ایمن Claude Code روی یک سرور

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

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

Claude Code یک عامل برنامه‌نویسی (coding agent) است که در terminal شما اجرا می‌شود. این ابزار فایل‌ها را می‌خواند، فایل‌ها را می‌نویسد و دستورات shell را با همان دسترسی کاربری که آن را اجرا کرده است، اجرا می‌کند. تمام ارزش این ابزار در همین است: می‌تواند یک repository را clone کند، کد را ویرایش کند، تست‌ها را اجرا کند، خطا را بخواند و در یک حلقه کد را اصلاح کند، بدون اینکه شما هر دستور را تایپ کنید. اگر هنوز آن را روی سرور تنظیم نکرده‌اید، اجرای Claude Code روی یک VPS با tmux مراحل نصب و مدیریت session را پوشش می‌دهد. این صفحه توانایی‌هایی را پوشش می‌دهد که پس از نصب، در اختیار آن می‌گذارید.

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

سیستم اجازه (permission) به زبان ساده

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

این طراحی فرض می‌کند که یک انسان در حال تماشای terminal است، که در یک لپ‌تاپ اینطور است. در یک سرور، نکته اینجاست که معمولاً کسی تماشاچی نیست. شما یک وظیفه طولانی را در tmux شروع می‌کنید و می‌خوابید، و عاملی که ساعت 2 صبح برای پرسیدن یک سوال متوقف می‌شود، تا صبح هیچ پیشرفتی نمی‌کند. این توقف هم هزینه زمانی و هم هزینه مالی دارد، زیرا یک session فعال Claude Code cache گرم خود را از دست می‌دهد و مرحله بعدی باید هزینه بازسازی آن را بپردازد. این دلیل واقعی استفاده مردم از پرچم skip در سرورهاست و مشکلی که حل می‌کند واقعی است. بقیه این راهنما درباره حل این مشکل بدون از دست دادن تمام حفاظ‌ها (guardrails) است.

تغییرات پرچم --dangerously-skip-permissions

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

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

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

Sandbox داخلی Claude Code

قبل از مراحل، بدانید که Claude Code اکنون یک sandbox در سطح سیستم‌عامل برای دستوراتی که اجرا می‌کند ارائه می‌دهد و بیشتر دلایلی که باعث استفاده مردم از پرچم skip می‌شد را از بین برده است. در Linux از bubblewrap برای ایزولاسیون فایل‌سیستم و از socat برای هدایت ترافیک شبکه از طریق یک proxy استفاده می‌کند. در داخل sandbox، یک دستور فقط می‌تواند در دایرکتوری پروژه و یک دایرکتوری موقت session بنویسد و فقط می‌تواند از طریق یک proxy که هر دامنه را با یک لیست مجاز چک می‌کند، به شبکه دسترسی داشته باشد. اولین باری که یک دستور بخواهد به دامنه جدیدی متصل شود، Claude Code از شما سوال می‌پرسد.

آن را با دستور /sandbox در داخل یک session روشن کنید. در Ubuntu و Debian، ابتدا دو پکیجی که نیاز دارد را نصب کنید:

sudo apt install bubblewrap socat

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

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

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

نردبان محصور کردن (The containment ladder)

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

مرحله 1: یک کاربر اختصاصی فاقد دسترسی مدیریتی. عامل یک حساب کاربری، یک home directory، یک دایرکتوری پروژه اختصاصی دریافت می‌کند و دسترسی sudo ندارد:

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

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

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

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

مراحل روی هم انباشته می‌شوند. یک عامل sandboxed که به عنوان یک کاربر فاقد دسترسی مدیریتی روی یک VPS موقت اجرا می‌شود، تقریباً هیچ هزینه اضافی ندارد و داستان‌های شکست را خسته‌کننده می‌کند. هدف، خسته‌کننده بودن است.

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

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

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

هر توکن را محدود (scope) کنید. یک GitHub token دقیق که فقط به یک repository محدود شده، یا یک deploy key مخصوص هر repository، به این معنی است که در صورت لو رفتن اعتبارنامه، فقط یک پروژه از دست می‌رود و نه کل حساب شما. اگر از sandbox استفاده می‌کنید، تنظیمات اعتبارنامه آن را اضافه کنید تا ~/.ssh و ~/.aws حتی برای خواندن هم deny شوند. و اعتبارنامه‌های production را کاملاً از ماشین دور نگه دارید، زیرا یک عامل نمی‌تواند رازی را لو دهد که هرگز آنجا نبوده است.

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

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

git switch -c agent/refactor-auth

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

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

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

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

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

ابتدا ماشین را مستحکم کنید (Harden)

هر کدام از مراحل را که انتخاب کردید، خودِ ماشین قبل از ورود عامل به آن، به موارد پایه نیاز دارد: فقط کلیدهای SSH، بدون ورود با root، یک فایروال با حالت default-deny، و آپدیت‌های امنیتی خودکار. چک‌لیست خود را اینجا ایجاد کنید و یک بار آن را انجام دهید:

FAQ

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

به تنهایی خیر. این پرچم تمام اعلان‌های تایید را حذف می‌کند، بنابراین اولین دستور اشتباه به محض تولید شدن توسط مدل، اجرا می‌شود. زمانی این یک معامله قابل دفاع است که شعاع انفجار محدود شده باشد: حداقل یک کاربر اختصاصی فاقد دسترسی مدیریتی، و برای کارهای واقعاً بدون نظارت، یک container یا یک VPS موقت که فقط یک پروژه و یک توکن محدود شده را نگه می‌دارد. هرگز از آن روی ماشینی که حاوی اعتبارنامه‌ها یا داده‌های حیاتی است استفاده نکنید.

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

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

چرا پرچم skip از اجرا به عنوان root خودداری می‌کند؟

چون root بدون پرسش‌های اجازه می‌تواند هر فایل و هر سرویسی را در سیستم تغییر دهد، Claude Code در هنگام اجرا به عنوان root یا با sudo در Linux و macOS، --dangerously-skip-permissions را مسدود می‌کند. راه حل این نیست که با این بررسی مبارزه کنید. یک کاربر فاقد دسترسی مدیریتی برای عامل بسازید و آن را در آنجا اجرا کنید؛ آن مرز حساب کاربری، اولین و ارزان‌ترین لایه محصور کردن است.

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

می‌تواند هر آنچه را که کاربری که با آن اجرا می‌شود می‌تواند بخواند، بخواند، و حتی سیاست پیش‌فرض sandbox اجازه خواندن مسیرهای اعتبارنامه را می‌دهد مگر اینکه شما آن‌ها را deny کنید. بنابراین، عامل را به عنوان کاربر خودش اجرا کنید، home directory خود را در mode 750 یا سخت‌تر نگه دارید، مسیرهای اعتبارنامه را در تنظیمات sandbox deny کنید، و اسرار production را کاملاً از ماشین دور نگه دارید. رازی که ماشین هرگز نداشته باشد، قابل خواندن یا لو رفتن نیست.

ایمن‌ترین راه برای اجرای بدون نظارت Claude Code چیست؟

یک VPS اختصاصی ارزان که فقط برای کارهای عامل استفاده می‌شود: در ده دقیقه مستحکم شده، با یک snapshot تمیز، اجرای Claude Code تحت یک کاربر فاقد دسترسی مدیریتی با sandbox روشن، یک فایل mode-600 که حاوی API key است، یک deploy key مخصوص هر repository، و تمام کارها روی branchهایی که قبل از merge بررسی می‌کنید. اگر یک اجرا اشتباه پیش رفت، شما یک توکن را باطل می‌کنید و snapshot را بازیابی می‌کنید، و هیچ چیز دیگری که متعلق به شماست آسیب نمی‌بیند.