استفاده از VM یک‌بارمصرف برای عامل‌های کدنویسی هوش مصنوعی

چرا یک VM یک‌بارمصرف از لپ‌تاپ شما بهتر است

اگر به یک عامل کدنویسی (coding agent) یک VM یک‌بارمصرف بدهید، بدترین اتفاقی که ممکن است رخ دهد، نابودی ماشینی است که می‌توانید در عرض 10 دقیقه دوباره آن را بسازید. این عامل همچنان دسترسی root دارد، بسته‌ها را نصب می‌کند و بدون نیاز به اجازه برای هر مرحله، مجموعه تست‌ها را اجرا می‌کند. تفاوت در این است که آسیب به کجا وارد می‌شود. روی لپ‌تاپ، عامل با دایرکتوری home شما که شامل کلیدهای SSH، پروفایل مرورگر، فایل‌های .env و تمام مخازنی است که تا به حال clone کرده‌اید، مشترک است. روی یک سرور یک‌بارمصرف، عامل فقط یک shell و یک checkout دارد و هیچ چیز دیگری که ارزش سرقت داشته باشد وجود ندارد.

این تمام استدلال است و این استدلال بیش از آنکه درباره احتمال باشد، درباره عدم تقارن است. یک عامل محتاط روی یک لپ‌تاپ محتاط، تقریباً همیشه بی‌خطر است. اما آن یک باری که این‌طور نیست، هزینه آن فقط یک commit بد نیست؛ بلکه بازگردانی از نسخه پشتیبان است، البته اگر نسخه‌ای داشته باشید.

پیش از بحث درباره شعاع انفجار، آن را تعریف کنید

شعاع انفجار به مجموعه‌ای از منابع گفته می‌شود که یک پردازش به آن‌ها دسترسی دارد. برای عاملی (agent) که با کاربر عادی شما روی سیستم معمولی‌تان اجرا می‌شود، این مجموعه بسیار بزرگ‌تر از آن چیزی است که اکثر افراد تصور می‌کنند.

این مجموعه شامل ~/.ssh/id_ed25519 است که معمولاً رمزنگاری‌نشده باقی می‌ماند، چون از تایپ مداوم عبارت عبور خسته شده‌اید. همچنین شامل ~/.aws/credentials و ~/.config/gh/hosts.yml است که ذاتاً به صورت متن ساده (plain text) هستند. این شعاع شامل تمام مخازن هم‌تراز در مسیر ~/code نیز می‌شود، از جمله مخازنی که رشته‌های اتصال به محیط عملیاتی (production) را در یک فایل env محلی دارند. تاریخچه shell شما نیز بخشی از این محدوده است که توکن‌هایی را که زمانی در آن کپی کرده‌اید، در خود نگه می‌دارد. علاوه بر این، شامل شبکه‌ای است که لپ‌تاپ شما به آن متصل است؛ شبکه‌ای که اغلب یک شبکه خانگی یا اداری با سرویس‌های فاقد احراز هویت است.

هیچ‌کدام از این موارد نیازی به یک عامل مخرب ندارند. تنها کافی است یک دستور با اطمینانِ اشتباه صادر شود. اجرای rm -rf "$BUILD_DIR"/* در حالی که BUILD_DIR تنظیم نشده است و به /* بسط می‌یابد و از سد محافظت پیش‌فرض GNU rm برای حذف نکردن / عبور می‌کند، یا یک git clean -xfd در دایرکتوری اشتباه، یا یک docker system prune -af --volumes که دیتابیس محلی شما را نیز پاک می‌کند، یا یک chmod -R 777 مفید روی دایرکتوری home. عامل‌ها روی همان اینترنتی آموزش دیده‌اند که این دستورات را به دیگران یاد داده است.

مکانیزمی که شما را نجات می‌دهد، قضاوتِ عامل نیست. بلکه این واقعیت است که دستگاهی که آسیب را متحمل می‌شود، دستگاهی است که شما از قبل آمادگی از دست دادن آن را داشته‌اید.

محاسبات هزینه خسته‌کننده است، و دقیقاً همین نکته اصلی است

یک VPS کوچک ماهانه چند دلار هزینه دارد. بازیابی لپ‌تاپ یک توسعه‌دهنده یک روز کامل زمان می‌برد، و این در بهترین حالت است؛ یعنی زمانی که بلافاصله متوجه مشکل می‌شوید و نسخه پشتیبان هم دارید.

این محاسبات را با اعداد خودتان انجام دهید. نرخ ساعتی خود را در تعداد ساعاتی که برای نصب مجدد سیستم‌عامل، بازیابی دایرکتوری home، تغییر کلید SSH، تغییر توکن دسترسی شخصی و کلون کردن مجدد 20 مخزن کد نیاز دارید، ضرب کنید. این عدد را با هزینه 12 ماه استفاده از کوچک‌ترین سروری که ارائه‌دهنده شما می‌فروشد مقایسه کنید. نقطه سر‌به‌سر هزینه، کمتر از یک حادثه در هر چند سال است و برای رسیدن به این حد نصاب، لازم نیست حادثه فاجعه‌بار باشد. تنها یک بعدازظهر که به دلیل خرابی محیط محلی از دست می‌رود، هزینه یک سال سرور را پوشش می‌دهد.

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

چشم‌انداز در اکتبر 2026

سه پاسخ صادقانه برای پرسش «عامل (agent) کجا باید اجرا شود» وجود دارد که همگی میان دو فاکتور تعادل برقرار می‌کنند: قدرت مرز امنیتی و میزان تنظیمات مورد نیاز.

یک میکرو ماشین مجازی (Micro VM) محلی. ابزارهای این دسته، یک ماشین مجازی واقعی را روی سخت‌افزار شما بوت می‌کنند، مخزن (repository) شما را درون آن mount می‌کنند و به عامل اجازه می‌دهند دسترسی root داشته باشد. clawk نمونه فعلی این دسته است و هدف آن دقیقاً همان تز این مقاله است: به عامل‌های کدنویسی یک ماشین مجازی لینوکس یک‌بارمصرف بدهید، نه لپ‌تاپ خودتان. تا اکتبر 2026، این ابزار macOS 14 و نسخه‌های بعد از آن را روی تراشه‌های Apple silicon هدف قرار می‌دهد و پشتیبانی آزمایشی از لینوکس را از طریق Firecracker ارائه می‌دهد و با brew install clawkwork/tap/clawk نصب می‌شود. شما clawk را درون یک مخزن اجرا می‌کنید تا sandbox بوت شود و عامل به آن متصل گردد، clawk down برای متوقف کردن آن است و clawk destroy برای حذف آن. مرز امنیتی در اینجا یک hypervisor است که بسیار قوی است. محدودیت این است که ماشین مجازی روی دستگاهی که با خود حمل می‌کنید اجرا می‌شود، بنابراین با حافظه شما رقابت می‌کند و با بستن درب لپ‌تاپ متوقف می‌شود.

یک کانتینر. Docker پاسخی است که اکثر افراد از قبل نصب کرده‌اند و واقعاً مفید است.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm کانتینر را پس از خروج دور می‌اندازد و --network none هیچ دسترسی شبکه‌ای به آن نمی‌دهد، که برای یک build یا اجرای تست، تنظیم پیش‌فرض مناسبی است. شفاف باشید که این کار چه چیزی را انجام نمی‌دهد: یک کانتینر از هسته (kernel) میزبان استفاده می‌کند، بنابراین یک باگ در هسته راهی برای خروج است و مرز امنیتی در لحظه‌ای که --privileged را اضافه می‌کنید یا /var/run/docker.sock را mount می‌کنید تا عامل بتواند «از Docker استفاده کند»، از بین می‌رود. mount کردن سوکت Docker درون یک کانتینر، معادل دادن دسترسی root میزبان به آن کانتینر است.

یک VPS ساده که می‌توانید آن را بازسازی کنید. بدون نیاز به ابزار جدید، با مرز امنیتی هسته واقعی، قابلیت snapshot گرفتن توسط ارائه‌دهنده، و این‌که وقتی لپ‌تاپ خود را خاموش می‌کنید، همچنان به کار خود ادامه می‌دهد. این همان الگویی است که در ادامه این راهنما شرح داده شده و تنها روشی است که در اجرای طولانی‌مدت عامل‌ها دوام می‌آورد، زیرا کاری که چهار ساعت طول می‌کشد، اهمیتی نمی‌دهد که شما به خانه رفته‌اید.

الگوی VPS: اختصاص یک کاربر مجزا به عامل (agent)

با یک سرور ایمن‌شده شروع کنید. راهنمای ده دقیقه نخست روی یک VPS جدید بخش‌هایی را پوشش می‌دهد که مختص عامل نیستند: به‌روزرسانی‌ها، ورود غیر-root، استفاده از SSH key و فایروال.

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

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password به این معناست که هیچ رمز عبوری برای حدس‌زدن وجود ندارد و شما با استفاده از sudo -u agent یا یک SSH key به حساب دسترسی پیدا می‌کنید. توجه داشته باشید که agent عمداً در گروه sudo قرار ندارد. عاملی که sudo دارد، دسترسی root خواهد داشت و root می‌تواند فایل‌های تمام کاربران دیگر را بخواند؛ بنابراین تفکیکی که ایجاد کرده‌اید صرفاً ظاهری خواهد بود. اگر عامل واقعاً نیاز به نصب پکیج دارد، این دلیلی برای اختصاص یک سرور کامل به آن است، نه اعطای sudo روی یک سرور اشتراکی. قوانین کلی در اصل حداقل امتیاز برای کاربران لینوکس روی VPS آمده است.

پیش از اعتماد به مرز امنیتی، آن را بررسی کنید. به عنوان کاربر agent، سعی کنید محتویات دایرکتوری home حساب خود را لیست کنید:

sudo -u agent ls /home/you

شما باید ls: cannot open directory '/home/you': Permission denied را ببینید. اگر به جای آن لیست فایل‌ها را مشاهده کردید، دایرکتوری home شما برای سایر کاربران قابل خواندن است و عامل می‌تواند هر چیزی که به طور جداگانه قفل نشده باشد (مانند فایل‌های world-readable در .env) را بخواند. این مشکل را با sudo chmod 700 /home/you برطرف کنید. کلید خصوصی SSH شما هدف این تست نیست: ssh فایل کلید خصوصی که توسط کاربران دیگر قابل دسترسی باشد را نادیده می‌گیرد، بنابراین هر کلیدی که برای شما کار می‌کند، فارغ از سطح دسترسی دایرکتوری home، برای agent غیرقابل خواندن است.

اعتبارنامه‌ها را به‌طور کامل از روی ماشین دور نگه دارید

اگر اسرار تولید (production secrets) خود را روی یک ماشین یک‌بارمصرف کپی کنید، هدف از استفاده از چنین ماشینی از بین می‌رود. قاعده ساده است: هیچ‌چیز روی آن ماشین نباید اعتبارنامه‌ای باشد که نگران تغییر فوری آن در همین بعدازظهر باشید.

برای git، به‌جای کپی کردن کلید، SSH agent خود را forward کنید. کلید خصوصی روی لپ‌تاپ شما باقی می‌ماند و تنها درخواست‌های امضا از طریق اتصال منتقل می‌شوند.

ssh -A agent@203.0.113.10
ssh -T git@github.com

دستور دوم باید پاسخ Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. را بدهد. این ثابت می‌کند که git push بدون وجود فایل کلید روی سرور کار خواهد کرد. پس از آن ls -la ~/.ssh را روی ماشین اجرا کنید و تأیید کنید که هیچ کلید خصوصی در آن وجود ندارد.

Forward کردن agent یک هشدار جدی دارد که باید صریح بیان شود: تا زمانی که متصل هستید، هر کسی که دسترسی root روی آن سرور داشته باشد، می‌تواند از سوکت forward شده برای احراز هویت به جای شما استفاده کند. روی سروری که تنها کاربر دیگر آن خود شما هستید، این یک معامله قابل‌قبول است. روی یک ماشین اشتراکی این‌طور نیست و یک deploy key که محدود به یک مخزن (repository) خاص باشد، پاسخ بهتری است. گزینه‌ها در اصول مدیریت کلید SSH پوشش داده شده‌اند.

برای کلیدهای API، به agent کلید مخصوص خودش را با محدودیت هزینه مشخص بدهید که در فایلی با مالکیت کاربر agent و با مجوز 600 ذخیره شده باشد. وقتی ماشین از بین می‌رود، آن کلید را ابطال کنید تا نگران نشت احتمالی آن نباشید. قابل‌مشاهده نگه داشتن هزینه‌های مدل به تفکیک هر کلید، همان روشی است که باعث می‌شود اعداد در کنترل هزینه عامل هوش مصنوعی روی VPS قابل پیش‌بینی باقی بمانند.

محدود کردن دسترسی عامل به شبکه

ایزوله‌سازی فایل‌سیستم نیمی از مرزبندی است. نیمه دیگر، خروجی شبکه (egress) است: یعنی فرآیند مجاز است با چه چیزی ارتباط برقرار کند. لینوکس می‌تواند ترافیک خروجی را بر اساس کاربری که آن را ایجاد کرده است فیلتر کند، که دقیقاً با این الگو مطابقت دارد.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

قوانین به ترتیب خوانده می‌شوند، بنابراین REJECT نهایی هر چیزی را که خطوط قبلی اجازه نداده‌اند، مسدود می‌کند. آن را با کاربریِ عامل (agent) تست کنید:

sudo -u agent curl -sS -m 5 http://example.com

این دستور باید بلافاصله با خطای curl: (7) Failed to connect to example.com شکست بخورد، که به دنبال آن عبارتی می‌آید که بسته به نسخه curl شما متفاوت است، زیرا قانون reject به‌جای معلق نگه داشتن اتصال، بلافاصله پاسخ می‌دهد. یک درخواست HTTPS به همان میزبان همچنان باید موفقیت‌آمیز باشد.

دو محدودیت صادقانه وجود دارد. اول اینکه، این قوانین در reboot بعدی از بین می‌روند مگر اینکه آن‌ها را با sudo apt install -y iptables-persistent و سپس sudo netfilter-persistent save ذخیره کنید. دوم اینکه، این روش پورت‌ها و آدرس‌ها را فیلتر می‌کند، نه نام‌ها را. قانونی که اجازه دسترسی به پورت 443 را می‌دهد، اجازه دسترسی به تمام میزبان‌های HTTPS در اینترنت را صادر می‌کند، که هم برای رسیدن به API مدل کافی است و هم برای رسیدن به یک pastebin. یک لیست مجاز (allow-list) واقعی برای دامین‌ها نیاز دارد که ترافیک از پروکسی‌ای عبور کند که نام میزبان درخواستی را می‌خواند، که این خود نیازمند زیرساخت بیشتری نسبت به چیزی است که اکثر توسعه‌دهندگان انفرادی می‌خواهند. فقط ادعای چیزی را داشته باشید که دارید: کنترل خروجی در سطح پورت، روی ماشینی که آماده از دست دادن آن بوده‌اید.

بازگشت به وضعیت پاک بین وظایف

داشتن وضعیت پاک برای هر وظیفه، مزیتی است که اغلب نادیده گرفته می‌شود. عاملی (agent) که سه ساعت روی تیکت قبلی کار کرده، ممکن است بسته‌های نصب‌شده، migrationهای نیمه‌کاره، یک node_modules قدیمی و یک working tree در git با تغییراتی که هیچ‌کس بازبینی نکرده، بر جای بگذارد. وظیفهٔ بعدی تمام این موارد را به ارث می‌برد و شما باید بودجهٔ بازبینی خود را صرف تشخیص این کنید که کدام آشفتگی مربوط به کدام اجراست. یک عامل محدودتر، در وهلهٔ اول ردپای کمتری بر جای می‌گذارد؛ بنابراین ترکیب یک ماشین یک‌بارمصرف با مهارتی که عامل را به سمت کوچک‌ترین تغییرِ کارآمد سوق می‌دهد، باعث می‌شود هم diff و هم وضعیت باقی‌مانده به اندازهٔ کافی کوچک و قابل‌بازبینی باقی بمانند.

نسخهٔ ارزان‌تر، یک checkout تازه برای هر وظیفه است.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

نسخهٔ قوی‌تر، استفاده از snapshot ارائه‌دهنده (provider) است که دقیقاً پس از راه‌اندازی ماشین و پیش از آنکه هیچ عاملی به آن دسترسی پیدا کند، گرفته می‌شود. بازگردانی آن snapshot، کل سیستم—از جمله بسته‌ها—را به وضعیتی شناخته‌شده برمی‌گرداند. اکثر ارائه‌دهندگان این قابلیت را در پنل کنترل یا از طریق API ارائه می‌دهند و نه به عنوان یک دستور داخل ماشین؛ بنابراین مراحل دقیق کار به ارائه‌دهندهٔ شما بستگی دارد. انضباط کاری حکم می‌کند که snapshot را زمانی بگیرید که ماشین هنوز در وضعیت اولیه و بدون تغییر است.

هر چیزی که برایتان اهمیت دارد را خارج از ماشین یک‌بارمصرف نگه دارید؛ این یعنی به جای انباشتن branchها به صورت محلی، آن‌ها را push کنید. اگر ماشین نهایتاً حاوی چیزی شد که از دست دادن آن برایتان دشوار است، با استفاده از پشتیبان‌گیری restic روی یک VPS به درستی از آن نسخهٔ پشتیبان تهیه کنید. ماشینی که می‌توانید آن را نابود کنید، تنها زمانی مفید است که نابود کردنش واقعاً بی‌دردسر باشد.

اگر می‌خواهید چندین محیط ایزوله داشته باشید بدون اینکه هزینهٔ چندین سرور را بپردازید، یک VPS بزرگ‌تر می‌تواند مستقیماً میزبان ماشین‌های مجازی مهمان باشد. مجازی‌سازی تو در تو (Nested virtualisation) روی یک VPS نحوهٔ عملکرد این موضوع و چگونگی بررسی مجاز بودن آن توسط ارائه‌دهنده را پوشش می‌دهد. ایزولاسیون در اینجا دو جنبه دارد؛ اگر ترجیح می‌دهید دو عامل روی یک ماشین به جای ایزوله بودن از یکدیگر، با هم هماهنگ شوند، یک نشست Claude Code می‌تواند متن را مستقیماً به نشست دیگر بفرستد و نیازی نیست هر انتقال (handoff) از طریق شما انجام شود.

چه زمانی استفاده از لپ‌تاپ با رعایت نکات ایمنی مناسب است

در این مورد صادق باشید، زیرا اغراق در مورد ایزوله‌سازی باعث می‌شود افراد دیگر به توصیه‌ها توجه نکنند.

اگر پیش از اجرای هر دستور، آن را بررسی می‌کنید، استفاده از لپ‌تاپ مشکلی ندارد. اعلان مجوز (permission prompt) یک کنترل واقعی است و مطلب اجرای ایمن Claude Code روی سرور توضیح می‌دهد که هر سطح از این اعلان‌ها دقیقاً چه چیزی را مسدود می‌کند. اگر کار شما محدود به یک مخزن (repository) است و هیچ اعتبارنامه (credential) محیط production روی دستگاه وجود ندارد، شعاع انفجار (blast radius) از قبل کوچک است. اگر نشست‌های (session) ایجنت شما کوتاه و تحت نظارت باشد، پنجرهٔ در معرض خطر بودن نیز کوتاه است.

پاسخ به محض اینکه اعلان‌ها را نادیده بگیرید تغییر می‌کند؛ موضوعی که اکنون با توجه به اینکه حالت خودکار (auto mode) تنظیم پیش‌فرض Claude Code است و در نصب جدید دیگر پیش از ویرایش فایل‌ها یا اجرای دستورات از شما سوال نمی‌شود، ارزش فکر کردن دارد. اجراهای بدون نظارت، کارهای شبانه و هر گردش کاری که در آن طرحی را تأیید می‌کنید و سیستم را به حال خود رها می‌کنید، همگی باعث حذف عامل انسانی می‌شوند که وظیفهٔ مهار (containment) را بر عهده داشت. در این شرایط، ماشین باید خود این وظیفه را انجام دهد. همین موضوع در مورد هر چیزی که دسترسی ایجنت را گسترش می‌دهد، از جمله اجرای یک ایجنت کدنویسی روی VPS که همزمان به چندین مخزن دسترسی دارد، صدق می‌کند.

تصمیم نهایی در واقع دربارهٔ میزان اعتماد شما به مدل نیست؛ بلکه دربارهٔ این است که وقتی مدل دچار اشتباه می‌شود، چه چیزی در کنار آن قرار دارد تا جلوی خسارت را بگیرد.

FAQ

آیا کانتینر برای ایزوله‌سازی یک عامل کدنویسی (coding agent) کافی است؟

برای اکثر کارها، بله، با دو شرط. کانتینر نباید با --privileged اجرا شود و نباید /var/run/docker.sock در آن mount شده باشد، زیرا هر یک از این دو، مسیری برای دسترسی به root روی میزبان (host) در اختیار پردازش قرار می‌دهد. کانتینر از هسته (kernel) میزبان استفاده می‌کند، بنابراین مرز امنیتی آن ضعیف‌تر از یک ماشین مجازی (VM) است. اگر عامل در حال اجرای کدهای غیرقابل‌اعتماد دریافت‌شده از اینترنت است، از یک VM واقعی یا یک سرور مجزا استفاده کنید.

آیا عامل به sudo روی سرور نیاز دارد؟

خیر، و اعطای دسترسی sudo تمام ایزوله‌سازی‌هایی که ایجاد کرده‌اید را از بین می‌برد، زیرا کاربر root می‌تواند تمام حساب‌های دیگر روی سیستم را بخواند. کاربر عامل را بدون sudo ایجاد کنید و فقط به دایرکتوری کاری خودش دسترسی نوشتن بدهید. اگر وظیفه واقعاً به نصب پکیج نیاز دارد، به جای دادن دسترسی root روی یک ماشین اشتراکی، یک ماشین کامل در اختیار عامل قرار دهید.

چگونه بدون قرار دادن کلید SSH روی سرور، به عامل اجازه push به git بدهم؟

هنگام اتصال، SSH agent خود را با ssh -A فوروارد کنید. درخواست‌های امضا از طریق اتصال ارسال می‌شوند در حالی که کلید خصوصی روی لپ‌تاپ شما باقی می‌ماند، بنابراین ssh -T git@github.com احراز هویت می‌شود و git push بدون نیاز به کلید خصوصی روی سرور کار می‌کند. نکته مهم این است که کاربر root روی آن سرور می‌تواند در زمانی که شما متصل هستید از سوکت فوروارد شده استفاده کند، بنابراین روی هر ماشینی که با دیگران به اشتراک می‌گذارید، از یک deploy key با دامنه محدود به مخزن (repository-scoped) استفاده کنید.

یک عامل به چه اندازه VPS نیاز دارد؟

کار عامل عمدتاً ویرایش فایل‌ها، اجرای buildها و اجرای تست‌ها است، بنابراین اندازه ماشین را بر اساس build تنظیم کنید، نه بر اساس مدل. یک مدل میزبانی‌شده روی سخت‌افزار ارائه‌دهنده اجرا می‌شود که ترافیک شبکه را افزایش می‌دهد و تقریباً هیچ بار محلی (local load) ندارد. خود عامل همچنان یک حداقل نیاز دارد: تا تاریخ 20 اکتبر 2026، نیازمندی‌های سیستم Claude Code حداقل 4 GB رم را ذکر کرده‌اند. حتی برای کارهای اسکریپت‌نویسی از 4 GB شروع کنید و اگر مخزن، کانتینر می‌سازد یا هر چیز قابل‌توجهی را کامپایل می‌کند، به 8 GB ارتقا دهید.

هر چند وقت یک‌بار باید ماشین را تخریب و بازسازی کنم؟

زمانی که وضعیت سیستم دیگر قابل توضیح نیست، و حداقل هر زمان که ممکن است یک اعتبارنامه (credential) روی سیستم لو رفته باشد، آن را بازسازی کنید. یک checkout تازه بین وظایف، تغییرات روزمره را مدیریت می‌کند و snapshot گرفته‌شده پیش از اولین اجرای عامل، یک image تمیز از سیستم برای بازگشت در اختیار شما قرار می‌دهد. اگر بازسازی ماشین هزینه‌بر به نظر می‌رسد، این نشانه‌ای است که چیزی مهم روی ماشینی که آن را disposable (یک‌بارمصرف) نامیده‌اید، در حال اجراست.