কোডিং এজেন্টের জন্য কেন ডিসপোজেবল VM ব্যবহার করবেন?

কেন একটি ডিসপোজেবল VM আপনার ল্যাপটপের চেয়ে নিরাপদ

একটি কোডিং এজেন্টকে একটি ডিসপোজেবল VM দিলে সবচেয়ে খারাপ যা ঘটতে পারে তা হলো, এটি এমন একটি মেশিন ধ্বংস করবে যা আপনি 10 মিনিটে পুনরায় তৈরি করতে পারবেন। এজেন্টটি তবুও root অ্যাক্সেস পায়, প্যাকেজ ইনস্টল করতে পারে এবং প্রতিটি ধাপের জন্য অনুমতি না চেয়েই টেস্ট স্যুট চালাতে পারে। পার্থক্যটি হলো ক্ষতির প্রভাব কোথায় পড়ছে তা নিয়ে। ল্যাপটপে, এজেন্টটি আপনার SSH কি (keys), ব্রাউজার প্রোফাইল, আপনার .env ফাইল এবং আপনার ক্লোন করা অন্য সব রিপোজিটরির সাথে একই হোম ডিরেক্টরি শেয়ার করে। একটি থ্রো-অ্যাওয়ে সার্ভারে, এটির কাছে কেবল একটি শেল এবং একটি চেকআউট থাকে, এছাড়া চুরি করার মতো মূল্যবান আর কিছুই থাকে না।

পুরো যুক্তিটি এটাই, এবং এটি সম্ভাবনার চেয়ে বরং অসামঞ্জস্যতা (asymmetry) নিয়ে একটি যুক্তি। একটি সতর্ক ল্যাপটপে একটি সতর্ক এজেন্ট প্রায় প্রতিবারই ঠিকঠাক কাজ করে। কিন্তু যে একবার এটি করে না, তখন তার মূল্য কেবল একটি খারাপ কমিট নয়। যদি আপনার ব্যাকআপ থাকে, তবে এটি ব্যাকআপ থেকে রিস্টোর করার বিষয় হয়ে দাঁড়ায়।

ব্লাস্ট রেডিয়াস নিয়ে তর্ক করার আগে সেটির নাম নির্ধারণ করুন

ব্লাস্ট রেডিয়াস বলতে বোঝায় একটি প্রসেস যে সমস্ত জিনিসের নাগাল পেতে পারে। আপনার সাধারণ মেশিনে আপনার সাধারণ ইউজার হিসেবে চলমান কোনো এজেন্টের ক্ষেত্রে, এই পরিধিটি অধিকাংশ মানুষের ধারণার চেয়েও বড়।

এর মধ্যে অন্তর্ভুক্ত রয়েছে ~/.ssh/id_ed25519, যা সাধারণত এনক্রিপ্ট করা থাকে না, কারণ আপনি বারবার পাসফ্রেজ টাইপ করতে বিরক্ত বোধ করেন। এর মধ্যে রয়েছে ~/.aws/credentials এবং ~/.config/gh/hosts.yml, যা নকশা অনুযায়ীই প্লেইন টেক্সট হিসেবে থাকে। এর মধ্যে রয়েছে ~/code-এর অধীনে থাকা প্রতিটি সিবলিং রিপোজিটরি, যার মধ্যে লোকাল env ফাইলে প্রোডাকশন কানেকশন স্ট্রিং থাকা রিপোজিটরিগুলোও অন্তর্ভুক্ত। এর মধ্যে রয়েছে আপনার শেল হিস্ট্রি, যেখানে আপনি একবার পেস্ট করা টোকেনগুলো জমা থাকে। এছাড়া এর মধ্যে রয়েছে আপনার ল্যাপটপ যে নেটওয়ার্কে যুক্ত আছে সেটিও, যা প্রায়শই এমন একটি হোম বা অফিস নেটওয়ার্ক যেখানে অথেন্টিকেশন ছাড়া অনেক সার্ভিস চালু থাকে।

এর কোনোটির জন্যই ক্ষতিকারক এজেন্টের প্রয়োজন হয় না। এর জন্য প্রয়োজন কেবল আত্মবিশ্বাসের সাথে ভুল কোনো কমান্ড দেওয়া। /-এ প্রসারিত হওয়া একটি আনসেট ভেরিয়েবলসহ rm -rf, ভুল ডিরেক্টরিতে একটি git clean -xfd, আপনার লোকাল ডাটাবেসসহ মুছে ফেলা একটি docker system prune -af --volumes, অথবা হোম ডিরেক্টরিতে একটি সহায়ক chmod -R 777। এজেন্টদের সেই একই ইন্টারনেট থেকে প্রশিক্ষণ দেওয়া হয়, যা অন্য সবাইকে এই কমান্ডগুলো শিখিয়েছে।

যে মেকানিজমটি আপনাকে রক্ষা করে তা এজেন্টের বিচারবুদ্ধি নয়। বরং সেটি হলো, যে মেশিনে ক্ষতি হওয়ার সম্ভাবনা রয়েছে সেটি এমন একটি মেশিন যা আপনি হারানোর ঝুঁকি নিতে প্রস্তুত ছিলেন।

খরচের হিসাবটি বিরক্তিকর, আর এটাই এর মূল কথা

একটি ছোট VPS-এর মাসিক খরচ মাত্র কয়েক ডলার। একটি ডেভেলপার ল্যাপটপ পুনরুদ্ধার করতে অন্তত একদিন সময় লাগে, আর এটি হলো সবচেয়ে ভালো পরিস্থিতি, যেখানে আপনি তাৎক্ষণিকভাবে বিষয়টি বুঝতে পারেন এবং আপনার কাছে ব্যাকআপ থাকে।

আপনার নিজের হিসাব দিয়ে এটি যাচাই করুন। আপনার প্রতি ঘণ্টার পারিশ্রমিক নিন, এবং অপারেটিং সিস্টেম পুনরায় ইনস্টল করা, হোম ডিরেক্টরি পুনরুদ্ধার করা, SSH key পরিবর্তন করা, personal access token পরিবর্তন করা এবং বিশটি রিপোজিটরি পুনরায় ক্লোন করার জন্য প্রয়োজনীয় ঘণ্টার সাথে গুণ করুন। এই খরচের সাথে আপনার প্রোভাইডারের সবচেয়ে ছোট সার্ভারের বারো মাসের খরচের তুলনা করুন। কয়েক বছরে একটি ঘটনার চেয়ে কম সময়েই এই খরচ উঠে আসে, এবং এই খরচ পুষিয়ে নেওয়ার জন্য ঘটনাটিকে বিপর্যয়কর হওয়ার প্রয়োজন নেই। একটি নষ্ট হয়ে যাওয়া লোকাল এনভায়রনমেন্টের পেছনে নষ্ট হওয়া একটি বিকেলই পুরো বছরের খরচ তুলে দেয়।

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

2026 সালের জুলাই মাসের প্রেক্ষাপট

"এজেন্ট কোথায় চালানো উচিত" এই প্রশ্নের তিনটি সৎ উত্তর রয়েছে, এবং এগুলোর ক্ষেত্রে দুটি বিষয়ের মধ্যে ভারসাম্য বজায় রাখতে হয়: সীমানা কতটা শক্তিশালী এবং আপনি কতটা সেটআপ সহ্য করতে পারবেন।

একটি লোকাল মাইক্রো VM। এই ক্যাটাগরির টুলগুলো আপনার নিজস্ব হার্ডওয়্যারে একটি প্রকৃত ভার্চুয়াল মেশিন বুট করে, সেটিতে আপনার রিপোজিটরি মাউন্ট করে এবং এজেন্টকে ভেতরে রুট (root) অ্যাক্সেস দেয়। clawk হলো বর্তমান উদাহরণ এবং এর মূল বক্তব্য ঠিক এই পোস্টের থিসিসের মতোই: কোডিং এজেন্টকে আপনার ল্যাপটপ নয়, বরং একটি ডিসপোজেবল Linux VM দিন। 2026 সালের জুলাই মাস অনুযায়ী এটি Apple সিলিকনে macOS 14 এবং তার পরবর্তী সংস্করণগুলোকে সাপোর্ট করে, Firecracker-এর মাধ্যমে পরীক্ষামূলক Linux সাপোর্ট রয়েছে এবং এটি brew install clawkwork/tap/clawk দিয়ে ইনস্টল করা যায়। স্যান্ডবক্স বুট করতে এবং এজেন্ট সংযুক্ত করতে আপনি রিপোজিটরির ভেতরে clawk চালান, এটি বন্ধ করতে clawk down এবং এটি মুছে ফেলতে clawk destroy ব্যবহার করুন। এর সীমানা হলো একটি হাইপারভাইজার, যা বেশ শক্তিশালী। সীমাবদ্ধতা হলো, VM-টি আপনার বহন করা মেশিনের ভেতরেই থাকে, তাই এটি আপনার মেমরির জন্য প্রতিযোগিতা করে এবং ল্যাপটপের ঢাকনা বন্ধ করলে এটিও বন্ধ হয়ে যায়।

একটি কন্টেইনার। Docker হলো সেই উত্তর যা অধিকাংশ মানুষের কাছে ইতিমধ্যেই ইনস্টল করা আছে এবং এটি সত্যিই কার্যকর।

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

--rm এক্সিট করার সময় কন্টেইনারটিকে মুছে ফেলে এবং --network none এটিকে কোনো নেটওয়ার্ক অ্যাক্সেস দেয় না, যা বিল্ড বা টেস্ট রানের জন্য একটি ভালো ডিফল্ট সেটিংস। এটি কী করে না তা পরিষ্কারভাবে বুঝে নিন: একটি কন্টেইনার হোস্ট কার্নেল শেয়ার করে, তাই কার্নেলের কোনো বাগ থাকলে তা থেকে বেরিয়ে আসা সম্ভব। এছাড়া আপনি যখন --privileged যোগ করেন বা /var/run/docker.sock মাউন্ট করেন যাতে এজেন্ট "Docker ব্যবহার করতে পারে", তখন এই সীমানা আর থাকে না। একটি কন্টেইনারে Docker সকেট মাউন্ট করা মানে হলো সেই কন্টেইনারকে হোস্ট মেশিনে রুট (root) অ্যাক্সেস দিয়ে দেওয়া।

একটি সাধারণ VPS যা আপনি পুনরায় তৈরি করতে পারেন। কোনো নতুন টুলের প্রয়োজন নেই, একটি প্রকৃত কার্নেল সীমানা রয়েছে, প্রোভাইডার স্ন্যাপশট সুবিধা আছে এবং আপনি ল্যাপটপ বন্ধ করলেও এটি চলতে থাকে। এই নির্দেশিকার বাকি অংশে এই পদ্ধতিটিই বর্ণনা করা হয়েছে এবং দীর্ঘ সময় ধরে চলা এজেন্টের কাজের জন্য এটিই টিকে থাকে, কারণ চার ঘণ্টা সময় নেওয়া কোনো কাজের ক্ষেত্রে আপনি বাড়ি ফিরে গেছেন কি না তা কোনো প্রভাব ফেলে না।

VPS প্যাটার্ন: এজেন্টকে নিজস্ব ইউজার প্রদান করা

একটি হার্ডেনড (hardened) সার্ভার থেকে শুরু করুন। নতুন VPS-এ প্রথম দশ মিনিট অংশে এমন বিষয়গুলো আলোচনা করা হয়েছে যা এজেন্ট-নির্দিষ্ট নয়: আপডেট, নন-রুট লগইন, শুধুমাত্র কি (key)-ভিত্তিক SSH এবং ফায়ারওয়াল।

এরপর এমন একটি অ্যাকাউন্ট তৈরি করুন যা শুধুমাত্র এজেন্টের জন্য থাকবে, যাতে এর ভেতরে কোনো ভুল হলে তা সার্ভারের অন্য কোনো কিছুকে প্রভাবিত করতে না পারে।

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) অ্যাক্সেস থাকে এবং রুট অন্য যেকোনো ইউজারের ফাইল পড়তে পারে, তাই আপনি যে বিভাজন তৈরি করেছেন তা কেবল নামমাত্র। যদি এজেন্টের সত্যিই প্যাকেজ ইনস্টল করার প্রয়োজন হয়, তবে তার জন্য একটি আলাদা সার্ভার ব্যবহার করা উচিত, শেয়ার্ড সার্ভারে তাকে sudo সুবিধা দেওয়া ঠিক নয়। সাধারণ নিয়মগুলো VPS-এ লিনাক্স ইউজারদের জন্য ন্যূনতম প্রিভিলেজ-এ দেওয়া আছে।

নির্ভর করার আগে বাউন্ডারি বা সীমানা পরীক্ষা করে নিন। agent ইউজার হিসেবে, আপনার নিজের অ্যাকাউন্টের একটি ফাইল পড়ার চেষ্টা করুন:

sudo -u agent cat /home/you/.ssh/id_ed25519

আপনার cat: /home/you/.ssh/id_ed25519: Permission denied দেখা উচিত। যদি এর পরিবর্তে কি (key) সংক্রান্ত তথ্য দেখা যায়, তবে আপনার হোম ডিরেক্টরির মোড 755 এবং আইসোলেশনটি এখনো কার্যকর হয়নি। sudo chmod 700 /home/you ব্যবহার করে এটি ঠিক করুন।

আপনার মেশিনে কোনো ক্রেডেনশিয়াল রাখবেন না

একটি ডিসপোজেবল বা অস্থায়ী মেশিনে আপনার প্রোডাকশন সিক্রেট কপি করলে তার মূল উদ্দেশ্যই ব্যর্থ হয়। নিয়মটি সহজ: সেই বক্সে এমন কোনো ক্রেডেনশিয়াল রাখবেন না যা আজ বিকেলে পরিবর্তন করতে আপনার আপত্তি থাকে।

git-এর জন্য, কি (key) কপি না করে আপনার SSH এজেন্ট ফরওয়ার্ড করুন। প্রাইভেট কি আপনার ল্যাপটপেই থাকবে এবং শুধুমাত্র সিগনেচার রিকোয়েস্টগুলো কানেকশনের মাধ্যমে আদান-প্রদান হবে।

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 চালান এবং নিশ্চিত করুন যে সেখানে কোনো প্রাইভেট কি নেই।

এজেন্ট ফরওয়ার্ডিংয়ের একটি বড় সীমাবদ্ধতা আছে, যা স্পষ্টভাবে বলা প্রয়োজন: আপনি কানেক্টেড থাকা অবস্থায়, সেই সার্ভারে root অ্যাক্সেস থাকা যে কেউ আপনার ফরওয়ার্ড করা সকেট ব্যবহার করে আপনার পরিচয়ে অথেন্টিকেট করতে পারবে। এমন সার্ভারে যেখানে আপনি ছাড়া অন্য কোনো ব্যবহারকারী নেই, সেখানে এটি একটি গ্রহণযোগ্য ঝুঁকি। কিন্তু শেয়ারড বক্সে এটি নিরাপদ নয়, সেক্ষেত্রে একটি নির্দিষ্ট রিপোজিটরির জন্য তৈরি deploy key ব্যবহার করাই উত্তম। এই বিকল্পগুলো SSH কি ম্যানেজমেন্টের মৌলিক বিষয়সমূহ-এ আলোচনা করা হয়েছে।

API কি-এর ক্ষেত্রে, এজেন্টকে তার নিজস্ব স্পেন্ডিং লিমিটসহ একটি আলাদা কি দিন, যা agent ব্যবহারকারীর মালিকানাধীন এবং 600 মোডে থাকা ফাইলে সংরক্ষিত থাকবে। মেশিনটি ধ্বংস করার সময় সেই কি-টি বাতিল করে দিন, যাতে সেটি ফাঁস হয়েছে কি না তা নিয়ে ভাবতে না হয়। প্রতিটি কি-এর জন্য মডেলের খরচ দৃশ্যমান রাখলে VPS-এ AI এজেন্টের খরচ নিয়ন্ত্রণ-এর সংখ্যাগুলোও অনুমানযোগ্য থাকে।

এজেন্ট নেটওয়ার্কে কী কী অ্যাক্সেস করতে পারবে তা সীমাবদ্ধ করুন

ফাইলসিস্টেম আইসোলেশন বা বিচ্ছিন্নকরণ হলো সীমানার অর্ধেক। বাকি অর্ধেক হলো ইগ্রেস (egress): প্রসেসটি কার সাথে যোগাযোগ করতে পারবে। লিনাক্স (Linux) আউটবাউন্ড ট্রাফিককে সেই ব্যবহারকারীর ভিত্তিতে ফিল্টার করতে পারে যিনি এটি তৈরি করেছেন, যা এই প্যাটার্নের সাথে পুরোপুরি মানানসই।

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 আগের লাইনগুলোতে যা অনুমোদিত হয়নি তার সবগুলোকে আটকে দেয়। এজেন্ট হিসেবে এটি পরীক্ষা করুন:

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

এটি curl: (7) Failed to connect to example.com port 80: Connection refused এর সাথে ব্যর্থ হওয়া উচিত, কারণ রিজেক্ট রুলটি সংযোগ ঝুলিয়ে না রেখে তাৎক্ষণিকভাবে উত্তর দেয়। একই হোস্টের প্রতি একটি HTTPS অনুরোধ সফল হওয়া উচিত।

দুটি গুরুত্বপূর্ণ সীমাবদ্ধতা রয়েছে। প্রথমত, আপনি যদি sudo apt install -y iptables-persistent এবং তারপর sudo netfilter-persistent save দিয়ে এগুলো সংরক্ষণ না করেন, তবে পরবর্তী রিবুটের সময় এই নিয়মগুলো মুছে যাবে। দ্বিতীয়ত, এটি পোর্ট এবং অ্যাড্রেস ফিল্টার করে, নাম নয়। পোর্ট 443 অনুমোদনের একটি নিয়ম ইন্টারনেটের প্রতিটি HTTPS হোস্টকে অনুমতি দেয়, যা মডেল API-তে পৌঁছানোর জন্য যথেষ্ট এবং একই সাথে কোনো পেস্টবিনে (pastebin) পৌঁছানোর জন্যও যথেষ্ট। একটি প্রকৃত ডোমেইন অ্যালাউ-লিস্টের জন্য ট্রাফিককে এমন একটি প্রক্সির মধ্য দিয়ে যেতে হয় যা অনুরোধকৃত হোস্টনাম পড়তে পারে, যা বেশিরভাগ একক-ডেভেলপার সেটআপের চেয়ে বেশি জটিল। আপনার যা আছে তা দাবি করুন: পোর্ট-লেভেল ইগ্রেস কন্ট্রোল, এমন একটি মেশিনে যা আপনি হারানোর জন্য প্রস্তুত ছিলেন।

প্রতিটি কাজের মাঝে ক্লিন স্টেটে ফিরে আসা

প্রতিটি কাজের জন্য ক্লিন স্টেট বা পরিচ্ছন্ন অবস্থা বজায় রাখা একটি অত্যন্ত গুরুত্বপূর্ণ কিন্তু অবহেলিত সুবিধা। একটি এজেন্ট যে গত তিনটি ঘণ্টা একটি টিকিটে ব্যয় করেছে, সে হয়তো কিছু প্যাকেজ ইনস্টল করে রেখেছে, অসম্পূর্ণ মাইগ্রেশন ফেলে রেখেছে, একটি পুরনো node_modules রেখে গেছে এবং এমন একটি git ওয়ার্কিং ট্রি তৈরি করেছে যার পরিবর্তনগুলো কেউ পর্যালোচনা করেনি। পরবর্তী কাজটি এই সবকিছুর উত্তরাধিকারী হয়, ফলে আপনাকে আপনার পর্যালোচনার সময় ব্যয় করতে হয় এটি বুঝতে যে কোন জঞ্জালটি কোন রান থেকে এসেছে।

এর সহজ সমাধান হলো প্রতিটি কাজের জন্য নতুন করে চেকআউট করা।

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

এর চেয়ে কার্যকর পদ্ধতি হলো প্রোভাইডার স্ন্যাপশট ব্যবহার করা, যা মেশিন সেটআপ করার ঠিক পরপরই এবং কোনো এজেন্ট কাজ শুরু করার আগেই নেওয়া হয়। সেই স্ন্যাপশটটি রিস্টোর করলে প্যাকেজসহ পুরো সিস্টেমটি একটি পরিচিত অবস্থায় ফিরে আসে। বেশিরভাগ প্রোভাইডার এটি তাদের কন্ট্রোল প্যানেল বা API-এর মাধ্যমে প্রদান করে, সরাসরি মেশিনের কোনো কমান্ড হিসেবে নয়, তাই সঠিক ধাপগুলো আপনার প্রোভাইডারের ওপর নির্ভর করবে। নিয়মটি হলো, মেশিনটি যখন একদম সাধারণ অবস্থায় থাকে, তখনই স্ন্যাপশটটি নিয়ে রাখা।

আপনার প্রয়োজনীয় যেকোনো কিছু এই ডিসপোজেবল মেশিনের বাইরে রাখুন, যার অর্থ হলো লোকাল মেশিনে ব্রাঞ্চ জমিয়ে না রেখে সেগুলো পুশ করে দেওয়া। যদি মেশিনটিতে এমন কিছু থেকে যায় যা আপনার প্রয়োজন হতে পারে, তবে সেটির যথাযথ ব্যাকআপ নিন restic backups on a VPS ব্যবহার করে। একটি মেশিন তখনই কার্যকর যখন সেটিকে ধ্বংস করা আপনার কাজের ক্ষেত্রে কোনো বড় প্রভাব ফেলে না।

আপনি যদি একাধিক সার্ভারের খরচ না করে বেশ কয়েকটি বিচ্ছিন্ন এনভায়রনমেন্ট পেতে চান, তবে একটি বড় VPS-এ সরাসরি গেস্ট VM হোস্ট করতে পারেন। Nested virtualisation on a VPS অংশে এটি কীভাবে কাজ করে এবং আপনার প্রোভাইডার এটি সমর্থন করে কি না তা কীভাবে যাচাই করবেন, তা আলোচনা করা হয়েছে।

যখন ল্যাপটপ সতর্কতার সাথে ব্যবহার করা হয় তখন তা পুরোপুরি নিরাপদ

এই বিষয়ে সৎ থাকুন, কারণ আইসোলেশন বা বিচ্ছিন্নকরণ নিয়ে অতিরঞ্জিত কথা বললে মানুষ আর গুরুত্ব দেয় না।

আপনি যদি প্রতিটি কমান্ড চালানোর আগে তা যাচাই করেন, তবে ল্যাপটপ ব্যবহার করা নিরাপদ। পারমিশন প্রম্পট একটি কার্যকর নিয়ন্ত্রণ ব্যবস্থা, এবং সার্ভারে নিরাপদে Claude Code চালানো অংশে প্রতিটি স্তর আসলে কী কী ব্লক করে তা বিস্তারিত আলোচনা করা হয়েছে। যদি আপনার কাজ একটি মাত্র রিপোজিটরির মধ্যে সীমাবদ্ধ থাকে এবং মেশিনে কোনো প্রোডাকশন ক্রেডেনশিয়াল না থাকে, তবে ঝুঁকির পরিধি এমনিতেই ছোট। যদি আপনার এজেন্টের সেশনগুলো সংক্ষিপ্ত এবং তত্ত্বাবধানে থাকে, তবে ঝুঁকির সময়কালও কম থাকে।

আপনি যখন প্রম্পটগুলো এড়িয়ে চলেন, তখনই পরিস্থিতি বদলে যায়। আনঅ্যাটেন্ডেড রান, রাতভর চলা জব এবং এমন যেকোনো ওয়ার্কফ্লো যেখানে আপনি একটি পরিকল্পনা অনুমোদন করে চলে যান—সেগুলো সেই মানবিক যাচাই প্রক্রিয়াকে সরিয়ে দেয় যা সুরক্ষার কাজ করছিল। তখনই মেশিনের ওপর সেই দায়িত্ব বর্তায়। একই কথা প্রযোজ্য যেকোনো কিছুর ক্ষেত্রে যা এজেন্টের কাজের পরিধি বাড়িয়ে দেয়, যার মধ্যে রয়েছে একাধিক রিপোজিটরিতে একসাথে কোডিং এজেন্ট চালানো।

সিদ্ধান্তটি আসলে মডেলকে আপনি কতটা বিশ্বাস করেন তার ওপর নির্ভর করে না। বরং মডেলটি ভুল করলে তার পাশে কী কী সম্পদ অরক্ষিত অবস্থায় রয়েছে, সেটিই আসল বিবেচ্য বিষয়।

FAQ

একটি কোডিং এজেন্টের জন্য কি কন্টেইনার আইসোলেশন যথেষ্ট?

অধিকাংশ কাজের জন্য এটি যথেষ্ট, তবে দুটি শর্ত প্রযোজ্য। কন্টেইনারটি অবশ্যই --privileged দিয়ে চালানো যাবে না এবং এতে /var/run/docker.sock মাউন্ট করা যাবে না, কারণ এর যেকোনো একটি প্রসেসকে হোস্ট মেশিনে root হওয়ার সুযোগ করে দেয়। একটি কন্টেইনার হোস্ট কার্নেল শেয়ার করে, তাই এর নিরাপত্তা সীমা ভার্চুয়াল মেশিনের তুলনায় দুর্বল। যদি এজেন্ট ইন্টারনেট থেকে আনা অনিরাপদ কোড চালায়, তবে একটি প্রকৃত VM বা আলাদা সার্ভার ব্যবহার করা শ্রেয়।

এজেন্টের কি সার্ভারে sudo প্রয়োজন?

না, এবং একে sudo সুবিধা দেওয়া মানে আপনার তৈরি করা আইসোলেশন বাতিল করা, কারণ root ব্যবহারকারী বক্সের অন্য যেকোনো অ্যাকাউন্টের তথ্য পড়তে পারে। sudo ছাড়া এজেন্ট ব্যবহারকারী তৈরি করুন এবং তাকে শুধুমাত্র তার নিজস্ব কাজের ডিরেক্টরিতে লেখার অনুমতি দিন। যদি কাজের প্রয়োজনে প্যাকেজ ইনস্টল করতেই হয়, তবে এজেন্টকে একটি সম্পূর্ণ আলাদা মেশিন দিন, শেয়ার করা মেশিনে root সুবিধা দেবেন না।

বক্সে আমার SSH key না রেখে এজেন্টকে কীভাবে git-এ পুশ করতে দেব?

কানেক্ট করার সময় ssh -A ব্যবহার করে আপনার SSH agent ফরওয়ার্ড করুন। সিগনেচার রিকোয়েস্টগুলো কানেকশনের মাধ্যমে সম্পন্ন হয় এবং প্রাইভেট কি আপনার ল্যাপটপেই থাকে, ফলে ssh -T git@github.com দিয়ে অথেন্টিকেশন হয় এবং git push কোনো প্রাইভেট কি ছাড়াই কাজ করে। সতর্কতার বিষয় হলো, আপনি কানেক্ট থাকা অবস্থায় ওই সার্ভারের root ব্যবহারকারী ফরওয়ার্ড করা সকেটটি ব্যবহার করতে পারে, তাই অন্যদের সাথে শেয়ার করা মেশিনে রিপোজিটরি-স্কোপড deploy key ব্যবহার করুন।

এজেন্টের জন্য কী আকারের VPS প্রয়োজন?

এজেন্টের কাজ মূলত ফাইল এডিট করা, বিল্ড চালানো এবং টেস্ট করা, তাই মেশিনের আকার মডেলের ওপর ভিত্তি করে নয়, বরং বিল্ডের ওপর ভিত্তি করে নির্ধারণ করুন। একটি হোস্ট করা মডেল প্রোভাইডারের হার্ডওয়্যারে চলে, যা নেটওয়ার্ক ট্রাফিক বাড়ায় কিন্তু লোকাল লোড প্রায় বাড়ায় না। স্ক্রিপ্টিংয়ের কাজের জন্য 2 GB RAM দিয়ে শুরু করুন এবং যদি রিপোজিটরি কন্টেইনার বিল্ড করে বা বড় কোনো কিছু কম্পাইল করে, তবে 8 GB RAM-এ উন্নীত করুন।

কত ঘনঘন মেশিনটি ধ্বংস করে পুনরায় তৈরি করা উচিত?

যখন মেশিনের অবস্থা আর ব্যাখ্যাযোগ্য থাকে না, তখন এটি পুনরায় তৈরি করুন। অন্ততপক্ষে যখনই বক্সে থাকা কোনো ক্রেডেনশিয়াল ফাঁস হওয়ার সম্ভাবনা থাকে, তখনই এটি করুন। কাজের মাঝে নতুন করে চেকআউট করলে দৈনন্দিন পরিবর্তনগুলো সামলানো যায় এবং প্রথমবার এজেন্ট চালানোর আগে একটি স্ন্যাপশট নিয়ে রাখলে আপনি সহজেই একটি ক্লিন সিস্টেম ইমেজে ফিরে আসতে পারবেন। যদি পুনরায় তৈরি করাকে ব্যয়বহুল মনে হয়, তবে বুঝবেন যে আপনি যে মেশিনটিকে অস্থায়ী ভেবেছিলেন, তাতে গুরুত্বপূর্ণ কিছু জমা হয়ে আছে।