Coding agent-এর জন্য disposable VM কেন ব্যবহার করবেন

আপনার ল্যাপটপের চেয়ে disposable VM কেন ভালো

একটি coding agent-কে disposable VM দিলে তার সবচেয়ে খারাপ কাজের ফল হতে পারে এমন একটি মেশিন নষ্ট করা, যেটি আপনি দশ মিনিটে পুনর্নির্মাণ করতে পারবেন। Agent-টি তবুও root access পাবে, package install করবে এবং প্রতিটি ধাপের জন্য অনুমতি না চেয়ে test suite চালাবে। পার্থক্য হলো, ক্ষতিটি কোথায় ঘটবে। ল্যাপটপে agent আপনার SSH key, browser profile, .env file এবং আপনি কখনও clone করেছেন এমন প্রতিটি repository-সহ একই home directory ব্যবহার করে। Throwaway server-এ তার কাছে থাকবে একটি shell, একটি checkout এবং নেওয়ার মতো মূল্যবান আর কিছু নয়।

এটাই মূল যুক্তি। এটি সম্ভাবনার চেয়ে ঝুঁকির অসম বণ্টন নিয়ে যুক্তি। সতর্ক ল্যাপটপে সতর্ক agent প্রায় সব সময়ই ঠিকভাবে কাজ করে। কিন্তু যে একবার তা করে না, তখন ক্ষতি শুধু একটি খারাপ commit নয়। আপনার backup থাকলে backup থেকে restore করতে হবে।

বিতর্কের আগে ক্ষতির পরিধি নির্ধারণ করুন

Blast radius বলতে কোনো process যে জিনিসগুলোতে পৌঁছাতে পারে, সেগুলোর সমষ্টিকে বোঝায়। আপনার স্বাভাবিক machine-এ স্বাভাবিক user হিসেবে চলা কোনো agent-এর ক্ষেত্রে এই পরিধি অধিকাংশ মানুষের ধারণার চেয়ে বড়।

এর মধ্যে ~/.ssh/id_ed25519 রয়েছে, যা সাধারণত unencrypted থাকে, কারণ passphrase বারবার টাইপ করতে আপনার বিরক্ত লাগে। এর মধ্যে ~/.aws/credentials এবং ~/.config/gh/hosts.yml রয়েছে, যেগুলো নকশাগতভাবেই plain text। ~/code-এর অধীনে থাকা প্রতিটি sibling repository-ও এর অন্তর্ভুক্ত, যার মধ্যে local env file-এ production connection string থাকা repository-ও রয়েছে। আপনার shell history-ও এর মধ্যে পড়ে, যেখানে একবার paste করা token রয়ে গেছে। আপনার laptop যে network-এ সংযুক্ত, সেটিও এর অন্তর্ভুক্ত; এটি প্রায়ই এমন home বা office network, যেখানে unauthenticated service চালু থাকে।

এর কোনোটির জন্য malicious agent প্রয়োজন হয় না। একটি আত্মবিশ্বাসের সঙ্গে দেওয়া ভুল command-ই যথেষ্ট। BUILD_DIR unset অবস্থায় rm -rf "$BUILD_DIR"/* চালালে সেটি /*-এ expand হয় এবং GNU rm-এর default হিসেবে / নিজেকেই delete না করার refusal এড়িয়ে যায়। ভুল directory-তে একটি git clean -xfd, এমন একটি docker system prune -af --volumes যা আপনার local database-সহ সবকিছু সরিয়ে দেয়, অথবা home directory-তে একটি সহায়ক chmod -R 777—এসবই যথেষ্ট। Agent-গুলোও সেই একই Internet-এর ওপর প্রশিক্ষিত, যে Internet অন্য সবাইকে ওই command-গুলো শিখিয়েছে।

আপনাকে রক্ষা করে agent-এর judgement নয়। আপনাকে রক্ষা করে এই বিষয়টি যে, ক্ষতি ধারণকারী machine-টি এমন একটি machine, যেটি হারিয়ে গেলেও আপনি মেনে নিতে প্রস্তুত ছিলেন।

খরচের হিসাব একঘেয়ে। সেটিই মূল কথা।

একটি ছোট VPS-এর খরচ মাসে কয়েক ডলার। কোনো developer laptop পুনরুদ্ধার করতে এক দিন লাগে। এটি তখনই তুলনামূলক ভালো পরিস্থিতি, যখন আপনি সমস্যাটি সঙ্গে সঙ্গে বুঝতে পারেন এবং আপনার backup থাকে।

নিজের সংখ্যাগুলো দিয়ে হিসাব করুন। আপনার প্রতি ঘণ্টার rate নিন। সেটিকে সেই সময়ের ঘণ্টা দিয়ে গুণ করুন, যত সময় লাগবে operating system পুনরায় install করতে, home directory restore করতে, SSH key rotate করতে, personal access token rotate করতে এবং বিশটি repository আবার clone করতে। এর সঙ্গে আপনার provider-এর বিক্রি করা সবচেয়ে ছোট server-এর বারো মাসের খরচ তুলনা করুন। কয়েক বছরে একটিরও কম incident ঘটলেই খরচের সমতা অতিক্রম করে, এবং সেই সীমা অতিক্রম করার জন্য incident-টি বিপর্যয়কর হওয়ার দরকার নেই। corrupted local environment-এর কারণে একটি বিকেল নষ্ট হলেও এক বছরের server খরচ উঠে যায়।

এই হিসাবের দ্বিতীয় অংশ হলো snapshot। ঝুঁকিপূর্ণ run-এর আগে snapshot নিলে খারাপ ফলাফলের পর "আমার পুরো কাজ restore করুন" পরিস্থিতির বদলে "rollback করে অন্য prompt চেষ্টা করুন" করা যায়। আপনি যে laptop-এ এটি লিখছেন, সেখানে এই সুবিধা নেই। কারণ সেটিকে আপনার কাজের ডেস্ক হিসেবে ব্যবহার করার সময় machine-এর snapshot নেওয়া যায় না।

2026 সালের অক্টোবরের চিত্র

“Agent কোথায় চালানো উচিত”—এই প্রশ্নের সৎ উত্তর তিনটি। এগুলো একই দুটি বিষয়ে ভারসাম্য তৈরি করে: boundary কতটা শক্তিশালী এবং আপনি কতটা setup মেনে নিতে প্রস্তুত।

একটি local micro VM। এই শ্রেণির tool আপনার নিজের hardware-এ একটি বাস্তব virtual machine boot করে, repository-টি সেখানে mount করে এবং agent-কে তার ভিতরে root access দেয়। clawk বর্তমানে এর উদাহরণ, এবং এর মূল বক্তব্য এই post-এর thesis-এর সঙ্গেই মেলে: coding agent-কে আপনার laptop নয়, একটি disposable Linux VM দিন। 2026 সালের অক্টোবর অনুযায়ী এটি Apple silicon-এ macOS 14 এবং পরবর্তী সংস্করণ লক্ষ্য করে; Firecracker-এর মাধ্যমে experimental Linux support-ও রয়েছে। এটি brew install clawkwork/tap/clawk দিয়ে install করা যায়। কোনো repository-এর ভিতরে clawk চালালে sandbox boot হয় এবং একটি agent সংযুক্ত হয়, clawk down দিয়ে এটি stop করা যায়, আর clawk destroy দিয়ে remove করা যায়। Boundary হলো hypervisor, তাই এটি শক্তিশালী। সীমাবদ্ধতা হলো VM-টি আপনার সঙ্গে বহন করা machine-এই চলে; ফলে এটি আপনার memory ব্যবহার করে এবং আপনি lid বন্ধ করলে থেমে যায়।

একটি container। Docker এমন একটি উত্তর, যা বেশিরভাগ মানুষের system-এ আগে থেকেই install করা থাকে, এবং এটি বাস্তবেই কার্যকর।

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

--rm exit করার সময় container মুছে ফেলে, আর --network none এটিকে কোনো network access দেয় না। Build বা test run-এর জন্য এটি একটি ভালো default। তবে এটি কী করে না, তা স্পষ্টভাবে বুঝুন: container host kernel share করে। তাই kernel-এর bug ব্যবহার করে container থেকে বেরিয়ে আসা সম্ভব। আপনি --privileged যোগ করলে বা /var/run/docker.sock mount করলে boundary আর থাকে না, যাতে agent “Docker ব্যবহার” করতে পারে। কোনো container-এর ভিতরে Docker socket mount করা সেই container-কে host-এর উপর root access দেওয়ার সমতুল্য।

একটি পুনর্নির্মাণযোগ্য plain VPS। এতে নতুন কোনো tool প্রয়োজন হয় না, একটি বাস্তব kernel boundary পাওয়া যায়, provider snapshot ব্যবহার করা যায়, এবং আপনি laptop বন্ধ করলেও এটি চলতে থাকে। এই guide-এর বাকি অংশে এই pattern বর্ণনা করা হয়েছে। দীর্ঘ সময় চলা agent-এর ক্ষেত্রেও এটি কার্যকর থাকে, কারণ কোনো job শেষ হতে চার ঘণ্টা লাগলেও আপনি বাড়ি চলে গেছেন কি না, তাতে তার কিছু যায় আসে না।

VPS প্যাটার্ন: agent-এর জন্য আলাদা user দিন

একটি harden করা box দিয়ে শুরু করুন। নতুন VPS-এ প্রথম দশ মিনিট অংশে agent-নিরপেক্ষ বিষয়গুলো রয়েছে: update, non-root login, key-only SSH এবং firewall।

এরপর শুধু agent-এর জন্য একটি account তৈরি করুন। এতে agent-এর ভেতরের কোনো ভুল সার্ভারের অন্য কিছুতে প্রভাব ফেলতে পারবে না।

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-এর অর্থ হলো অনুমান করার মতো কোনো password নেই। sudo -u agent অথবা SSH key ব্যবহার করে account-এ প্রবেশ করবেন। মনে রাখবেন, agent-কে ইচ্ছাকৃতভাবে sudo group-এ রাখা হয়নি। sudo থাকা কোনো agent-এর root access থাকে, আর root অন্য সব user-এর file পড়তে পারে। তাই আপনি যে separation তৈরি করেছেন, তা কেবল বাহ্যিক থাকে। Agent-এর সত্যিই package install করার প্রয়োজন হলে, সেটি তার নিজস্ব একটি সম্পূর্ণ server ব্যবহারের পক্ষে যুক্তি; shared server-এ তাকে sudo দেওয়ার পক্ষে নয়। সাধারণ নিয়মগুলো VPS-এ Linux user-এর জন্য least privilege অংশে রয়েছে।

Agent-কে বিশ্বাস করার আগে boundary পরীক্ষা করুন। agent user হিসেবে নিজের account-এর home directory তালিকাভুক্ত করার চেষ্টা করুন:

sudo -u agent ls /home/you

আপনার ls: cannot open directory '/home/you': Permission denied দেখা উচিত। এর বদলে file listing দেখা গেলে, অন্য user-রা আপনার home directory পড়তে পারছে। ফলে agent এমন যেকোনো file পড়তে পারবে, যেটি আলাদাভাবে সীমাবদ্ধ করা নেই; যেমন world-readable .env file। sudo chmod 700 /home/you দিয়ে এটি ঠিক করুন। আপনার private SSH key এই test দ্বারা সুরক্ষিত হয় না। অন্য user-রা access করতে পারে এমন private key file ssh উপেক্ষা করে। তাই আপনার জন্য বাস্তবে কাজ করে এমন যেকোনো key ইতিমধ্যে agent-এর কাছে unreadable, home directory-এর mode যা-ই হোক না কেন।

ক্রেডেনশিয়াল সম্পূর্ণভাবে মেশিনের বাইরে রাখুন

আপনি production secret মেশিনে কপি করলে disposable machine ব্যবহারের উদ্দেশ্য নষ্ট হয়। নিয়মটি সহজ: ওই মেশিনে এমন কোনো credential থাকা উচিত নয়, যা আজ বিকেলেই rotate করতে আপত্তি হবে।

git-এর জন্য key কপি না করে আপনার SSH agent forward করুন। private key আপনার laptop-এই থাকবে, এবং connection-এর মাধ্যমে শুধু signature request যাবে।

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

দ্বিতীয় command-এর উত্তর হওয়া উচিত Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.। এতে প্রমাণ হয় যে git push সার্ভারে কোনো key file না থাকলেও কাজ করবে। এরপর মেশিনে ls -la ~/.ssh চালিয়ে নিশ্চিত করুন, সেখানে কোনো private key নেই।

Agent forwarding-এর একটি গুরুত্বপূর্ণ ঝুঁকি আছে, তাই বিষয়টি স্পষ্টভাবে বুঝে নিন: আপনি সংযুক্ত থাকা অবস্থায় ওই সার্ভারে root access থাকা যে কেউ forwarded socket ব্যবহার করে আপনার পরিচয়ে authenticate করতে পারে। যে সার্ভারে অন্য কোনো user নেই এবং user একমাত্র আপনি, সেখানে এটি গ্রহণযোগ্য trade-off হতে পারে। Shared machine-এ এটি গ্রহণযোগ্য নয়; সে ক্ষেত্রে একটি repository-নির্দিষ্ট deploy key ব্যবহার করাই ভালো। বিকল্পগুলো SSH key management-এর মৌলিক বিষয়-এ ব্যাখ্যা করা হয়েছে।

API key-এর জন্য agent-কে আলাদা spending limit-সহ নিজস্ব key দিন। এই key এমন একটি file-এ রাখুন, যার owner agent user এবং mode 600। মেশিনটি ধ্বংস করার সময় key-টি revoke করুন, এটি ফাঁস হয়েছে কি না তা নিয়ে অনিশ্চিত থাকবেন না। প্রতিটি key-এর model spend আলাদাভাবে দৃশ্যমান রাখলে VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ-এর সংখ্যাগুলোও পূর্বানুমানযোগ্য থাকে।

এজেন্ট নেটওয়ার্কে যেসব গন্তব্যে পৌঁছাতে পারে, তা সীমিত করুন

Filesystem isolation সীমানার অর্ধেক তৈরি করে। বাকি অর্ধেক হলো egress: প্রক্রিয়াটি কোন গন্তব্যে সংযোগ করতে পারবে। Linux যে user প্রক্রিয়াটি তৈরি করেছে, তার ভিত্তিতে outbound traffic filter করতে পারে। এই ব্যবহারের ধরনটির জন্য এটি উপযুক্ত।

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

Rules-গুলো ক্রমানুসারে পড়া হয়। তাই শেষের REJECT আগের lines যেগুলো allow করেনি, সেগুলো সবকিছুকে ধরে। এজেন্ট হিসেবে এটি পরীক্ষা করুন:

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

এটি সঙ্গে সঙ্গে curl: (7) Failed to connect to example.com error-এ ব্যর্থ হওয়ার কথা। এরপরের wording আপনার curl version অনুযায়ী ভিন্ন হতে পারে। কারণ reject rule সংযোগ ঝুলিয়ে না রেখে সঙ্গে সঙ্গে উত্তর দেয়। একই host-এ HTTPS request এখনও সফল হওয়ার কথা।

এখানে দুটি গুরুত্বপূর্ণ সীমাবদ্ধতা আছে। প্রথমত, save না করলে পরবর্তী reboot-এ এই rules-গুলো হারিয়ে যাবে। এজন্য sudo apt install -y iptables-persistent এবং তারপর sudo netfilter-persistent save ব্যবহার করুন। দ্বিতীয়ত, এটি ports ও addresses filter করে, names নয়। Port 443 allow করা হলে Internet-এর প্রতিটি HTTPS host-এ পৌঁছানো যায়। এতে model API-তে পৌঁছানো সম্ভব হয়, কিন্তু pastebin-এ পৌঁছানোও সম্ভব হয়। প্রকৃত domain allow-list প্রয়োগ করতে হলে traffic এমন একটি proxy-এর মধ্য দিয়ে যেতে হবে, যা requested hostname পড়ে। অধিকাংশ single-developer setup-এর জন্য এটি প্রয়োজনের তুলনায় বেশি ব্যবস্থা। আপনার নিয়ন্ত্রণের সীমা যতটুকু, ততটুকুই দাবি করুন: port-level egress control, এমন একটি machine-এ যেটি হারিয়ে গেলেও আপনি প্রস্তুত ছিলেন।

কাজের মধ্যে পরিষ্কার অবস্থায় ফিরিয়ে নেওয়া

প্রতিটি কাজের জন্য পরিষ্কার অবস্থা রাখা একটি অবমূল্যায়িত সুবিধা। আগের টিকিটে তিন ঘণ্টা কাজ করা একটি agent ইনস্টল করা package, আংশিকভাবে প্রয়োগ করা migration, পুরোনো node_modules এবং এমন একটি git working tree রেখে গেছে, যাতে কেউ review না করা পরিবর্তন রয়েছে। পরের কাজটি এগুলো সব উত্তরাধিকারসূত্রে পায়। কোন জটিলতা কোন run-এর কারণে তৈরি হয়েছে, তা বোঝার পেছনেই আপনার review budget খরচ হয়। সংকীর্ণ পরিসরের agent শুরুতেই কম অবশিষ্ট রাখে। তাই disposable machine-এর সঙ্গে agent-কে কাজের জন্য প্রয়োজনীয় সর্বনিম্ন পরিবর্তনের দিকে পরিচালিত করে এমন একটি skill ব্যবহার করলে diff এবং অবশিষ্ট state—দুটিই review করার মতো ছোট থাকে।

এর সহজতম পদ্ধতি হলো প্রতিটি কাজের জন্য fresh checkout ব্যবহার করা।

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

আরও শক্তিশালী পদ্ধতি হলো machine সেটআপ করার পর, কোনো agent তাতে কাজ করার আগে একবার provider snapshot নেওয়া। এই snapshot restore করলে package-সহ পুরো system একটি পরিচিত অবস্থায় ফিরে আসে। অধিকাংশ provider এটি machine-এর command হিসেবে নয়, control panel বা API-এর মাধ্যমে দেয়। তাই নির্দিষ্ট ধাপ আপনার provider-এর ওপর নির্ভর করবে। মূল নিয়ম হলো machine এখনও কোনো পরিবর্তন ছাড়াই পরিষ্কার থাকা অবস্থায় snapshot নেওয়া।

যে কোনো গুরুত্বপূর্ণ জিনিস disposable machine-এর বাইরে রাখুন। সাধারণত এর অর্থ branch স্থানীয়ভাবে জমিয়ে না রেখে push করা। machine-এ এমন কিছু থেকে গেলে যা হারালে সমস্যা হবে, VPS-এ restic backup ব্যবহার করে সঠিকভাবে backup নিন। যে machine ধ্বংস করা যায়, সেটি তখনই কার্যকর যখন ধ্বংস করলেও বাস্তবে কোনো জটিলতা তৈরি হয় না।

একাধিক server-এর জন্য অর্থ খরচ না করে কয়েকটি isolated environment চাইলে একটি বড় VPS সরাসরি guest VM host করতে পারে। VPS-এ nested virtualisation-এ এটি কীভাবে কাজ করে এবং আপনার provider এটি অনুমোদন করে কি না কীভাবে যাচাই করবেন, তা ব্যাখ্যা করা হয়েছে। এখানে isolation উভয় দিকেই কাজ করে। একই box-এ দুটি agent-কে সমন্বয় করাতে চাইলে, একে অপরের কাছ থেকে সম্পূর্ণ বিচ্ছিন্ন না রেখে, একটি Claude Code session সরাসরি অন্যটিতে text পাঠাতে পারে। এতে প্রতিটি handoff আপনার মাধ্যমে পাঠানোর প্রয়োজন হয় না।

যখন সতর্কতার সঙ্গে ব্যবহৃত laptop সত্যিই যথেষ্ট

এ বিষয়ে সৎ থাকুন, কারণ isolation-এর সুবিধা অতিরঞ্জিত করলে মানুষ আপনার কথা শোনা বন্ধ করে দেয়।

প্রতিটি command চালানোর আগে যাচাই করলে laptop যথেষ্ট নিরাপদ। permission prompt একটি কার্যকর নিয়ন্ত্রণব্যবস্থা, এবং সার্ভারে Claude Code নিরাপদে চালানো নির্দেশিকায় প্রতিটি স্তর আসলে কী আটকায় তা ব্যাখ্যা করা হয়েছে। আপনার কাজ যদি এমন একটি repository-তেই সীমাবদ্ধ থাকে, যেখানে machine-এ কোনো production credential নেই, তাহলে সম্ভাব্য ক্ষতির পরিধি আগে থেকেই ছোট। agent session সংক্ষিপ্ত এবং আপনার তত্ত্বাবধানে হলে exposure window-ও ছোট থাকে।

আপনি prompt এড়িয়ে গেলেই সিদ্ধান্ত বদলে যায়। এখন এটি বিবেচনা করা জরুরি, কারণ auto mode এখন Claude Code-এর default এবং নতুন installation files edit করা বা command চালানোর আগে আর আপনার অনুমতি চায় না। Unattended run, overnight job এবং এমন workflow-এ, যেখানে plan অনুমোদন করে আপনি সরে যান, containment নিশ্চিত করা human check আর থাকে না। তখন machine-কেই সেই কাজ করতে হয়। একই কথা agent-এর reach বাড়ায় এমন যেকোনো ব্যবহারের ক্ষেত্রেও প্রযোজ্য, যার মধ্যে একসঙ্গে একাধিক repository-তে VPS-এ coding agent চালানো অন্তর্ভুক্ত।

সিদ্ধান্তটি আসলে model-কে আপনি কতটা trust করেন, তা নিয়ে নয়। model ভুল করলে তার পাশে কী ধরনের নিয়ন্ত্রণব্যবস্থা সক্রিয় থাকে, সিদ্ধান্তটি তা নিয়ে।

FAQ

একটি container কি coding agent-এর জন্য যথেষ্ট isolation দেয়?

বেশিরভাগ কাজের জন্য দেয়, তবে 2টি শর্ত আছে। container-টি --privileged নিয়ে চালানো যাবে না এবং এর মধ্যে /var/run/docker.sock mount করা যাবে না, কারণ যেকোনো একটি process-কে host-এর root account-এ পৌঁছানোর পথ দেয়। একটি container host kernel share করে, তাই এর isolation boundary virtual machine-এর তুলনায় দুর্বল। agent যদি Internet থেকে আনা untrusted code চালায়, তাহলে প্রকৃত VM বা আলাদা server ব্যবহার করুন।

server-এ agent-এর কি sudo দরকার?

না। agent-কে sudo দিলে তৈরি করা isolation নষ্ট হয়, কারণ root account server-এর অন্য সব account পড়তে পারে। sudo ছাড়া agent user তৈরি করুন এবং শুধু তার নিজস্ব work directory-তে write access দিন। কাজের জন্য সত্যিই package installation প্রয়োজন হলে, agent যে সম্পূর্ণ machine-এর মালিক সেটি দিন; অন্যদের সঙ্গে share করা machine-এ root access দেবেন না।

server-এ আমার SSH key না রেখে agent-কে git-এ push করার অনুমতি কীভাবে দেব?

সংযোগ করার সময় ssh -A দিয়ে আপনার SSH agent forward করুন। private key আপনার laptop-এই থাকে এবং signature request connection-এর মাধ্যমে যায়। তাই ssh -T git@github.com authentication করতে পারে এবং git push server-এ কোনো private key ছাড়াই কাজ করে। তবে আপনি connected থাকা অবস্থায় ওই server-এর root account forwarded socket ব্যবহার করতে পারে। তাই অন্যদের সঙ্গে share করা যেকোনো machine-এ repository-সীমাবদ্ধ deploy key ব্যবহার করুন।

agent-এর জন্য কী আকারের VPS দরকার?

agent-এর কাজ মূলত file edit করা, build চালানো এবং test চালানো। তাই model-এর জন্য নয়, build-এর জন্য machine-এর আকার নির্ধারণ করুন। hosted model provider-এর hardware-এ চলে। এতে network traffic বাড়ে, কিন্তু local load প্রায় বাড়ে না। agent নিজে অবশ্য একটি ন্যূনতম resource requirement তৈরি করে। October 20, 2026 অনুযায়ী, Claude Code-এর system requirements-এ minimum হিসেবে 4 GB RAM উল্লেখ আছে। Scripting-এর কাজ হলেও 4 GB দিয়ে শুরু করুন। Repository container build করলে বা উল্লেখযোগ্য compilation চালালে 8 GB-এ যান।

কত ঘন ঘন machine ধ্বংস করে আবার build করা উচিত?

state-এর কারণ ব্যাখ্যা করা না গেলে rebuild করুন। box-এ থাকা কোনো credential exposed হয়ে থাকতে পারে এমন পরিস্থিতিতে অন্তত rebuild করুন। দৈনন্দিন পরিবর্তন সামলাতে task-এর মাঝখানে fresh checkout ব্যবহার করুন। প্রথম agent run-এর আগে নেওয়া snapshot আপনাকে ফিরে যাওয়ার জন্য একটি পরিষ্কার system image দেবে। Rebuild ব্যয়বহুল মনে হলে বুঝতে হবে, disposable বলে চিহ্নিত machine-এ গুরুত্বপূর্ণ কোনো কিছু রাখা আছে।