সার্ভারে Claude Code নিরাপদে চালানোর সেরা উপায়

সার্ভারে Claude Code নিরাপদে চালানোর অর্থ কী

সার্ভারে Claude Code নিরাপদে চালাতে permission prompt চালু রাখুন, dedicated unprivileged user হিসেবে এটি চালান, এবং unattended run-এর জন্য শুধু trust-এর ওপর নির্ভর না করে একটি বাস্তব boundary দিন: built-in sandbox, একটি container, অথবা এমন একটি disposable VPS যাতে আপনার গুরুত্বপূর্ণ কোনো ডেটা নেই। --dangerously-skip-permissions flag model এবং আপনার shell-এর মধ্যে approval ধাপটি সরিয়ে দেয়। Unattended কাজের ক্ষেত্রে এই trade-off গ্রহণযোগ্য হতে পারে, তবে কেবল এমন একটি boundary-এর ভেতরে, যা কোনো ভুল command-এর reach সীমিত রাখে। এই guide-এ flag-টি আসলে কী পরিবর্তন করে এবং increasing isolation-এর ধাপে সেই boundary কীভাবে তৈরি করবেন, তা ব্যাখ্যা করা হয়েছে।

আপনার সার্ভারে Claude Code কী করতে পারে

Claude Code একটি coding agent, যা আপনার terminal-এ চলে। এটি file পড়ে, file লেখে এবং যে user এটি চালু করেছে সেই user হিসেবে shell command চালায়। এই tool-এর মূল সুবিধা এটাই: এটি repository clone করতে, code edit করতে, test চালাতে, failure পড়তে এবং loop-এর মধ্যে code ঠিক করতে পারে; আপনাকে প্রতিটি command আলাদাভাবে টাইপ করতে হয় না। আপনি যদি এখনো কোনো server-এ এটি সেট up না করে থাকেন, tmux ব্যবহার করে VPS-এ Claude Code চালানো install এবং session পরিচালনার বিষয়টি ব্যাখ্যা করে। এটি সেট up করার পর আপনি agent-কে যে ক্ষমতা দেন, এই page-এ তা আলোচনা করা হয়েছে।

ঝুঁকিটি একই বাক্যটি দ্বিতীয়বার পড়লেই স্পষ্ট হয়। আপনার user হিসেবে shell command চালানো কোনো process আপনার user যা করতে পারে, তার সবই করতে পারে। এটি ~/.ssh/id_ed25519, ~/.aws/credentials এবং আপনার user যে কোনো .env file খুলতে পারে। এটি curl চালাতে পারে এবং server যে কোনো host-এ পৌঁছাতে পারে সেখানে data পাঠাতে পারে। এটি git push --force চালাতে পারে। Agent-এর নিজস্ব কোনো উদ্দেশ্য নেই। ঝুঁকি তৈরি হয় যখন কোনো task ভুলভাবে সম্পন্ন হয়, অথবা কাজের সময় পড়া text-এ অন্য কারও লেখা নির্দেশনা থাকে: যেমন agent যে web page fetch করেছে, অথবা যে issue ঠিক করতে বলা হয়েছে তার কোনো comment। দ্বিতীয় ঘটনাটিকে prompt injection বলা হয়। তাই “model সাধারণত যুক্তিসংগত আচরণ করে”—এটি কোনো security plan নয়। কাছাকাছি উৎস থেকেও নির্দেশনা আসতে পারে, কারণ একই box-এ দুটি Claude Code session একে অন্যকে text পাঠাতে পারে; sibling session থেকে আসা message-ও receiving agent-এর পড়া আরেকটি text মাত্র। গড় আচরণের জন্য নয়, খারাপ run-এর জন্য পরিকল্পনা করুন।

সহজ ভাষায় পারমিশন সিস্টেম

Manual মোডে, Claude Code কোনো কাজ করার আগে অনুমতি চায়। প্রজেক্টের ফাইল পড়া নীরবে সম্পন্ন হয়, কিন্তু কোনো ফাইল এডিট করা বা শেল কমান্ড চালানোর আগে এটি আপনাকে সুনির্দিষ্ট এডিট বা কমান্ডটি দেখায় এবং আপনার সম্মতির জন্য অপেক্ষা করে। আপনি একটি নির্দিষ্ট কাজের অনুমোদন দিতে পারেন, অথবা এটিকে আর জিজ্ঞাসা না করার নির্দেশ দিতে পারেন। ফাইল এডিটের ক্ষেত্রে এই দ্বিতীয় বিকল্পটি শুধুমাত্র বর্তমান সেশন পর্যন্ত কার্যকর থাকে, কিন্তু শেল কমান্ডের ক্ষেত্রে এটি ওই রিপোজিটরি এবং কমান্ডের জন্য স্থায়ীভাবে সংরক্ষিত হয়; ফলে সার্ভারে একবার দেওয়া সম্মতি সেশন শেষ হওয়ার পরেও বজায় থাকে। আপনি যদি কোনো নিয়ম স্থায়ীভাবে রাখতে চান, তবে সেটিংস ফাইলে persistent allow, ask এবং deny লিস্ট রাখা যায়। উদাহরণস্বরূপ: git status অনুমোদন করা, git push-এর ক্ষেত্রে জিজ্ঞাসা করা, এবং .env পড়া নিষিদ্ধ করা। Deny নিয়ম সবসময় অগ্রাধিকার পায়। এই মূল ভিত্তিটিও পরিবর্তিত হয়েছে। 14 আগস্ট 2026 থেকে Pro, Max এবং Team প্ল্যানের নতুন সেশনের জন্য Auto মোড ডিফল্ট হিসেবে সেট করা হয়েছে, যেখানে আপনার পরিবর্তে একটি ক্লাসিফায়ার কাজগুলো পর্যালোচনা করে। এছাড়া Claude Code v2.1.283 সংস্করণ থেকে, যদি আপনি কোনো ডিফল্ট মোড পিন করে না রাখেন, তবে সব প্ল্যানের ইন্টারঅ্যাক্টিভ টার্মিনাল এবং VS Code সেশনের জন্য এটিই বিল্ট-ইন স্টার্টিং মোড। তাই আপনি যে সার্ভারটি সার্বক্ষণিক পর্যবেক্ষণ করতে পারবেন না, সেখানে কোন মোড চালানো উচিত তা নির্ধারণ করার আগে প্রতিটি পারমিশন মোড আসলে কী অনুমতি দেয় তা জেনে রাখা জরুরি।

এই ডিজাইনটি ধরে নেয় যে একজন মানুষ টার্মিনালটি পর্যবেক্ষণ করছেন, যা ল্যাপটপের ক্ষেত্রে সত্য। কিন্তু সার্ভারের ক্ষেত্রে প্রায়শই কেউ এটি পর্যবেক্ষণ করে না। আপনি tmux-এর ভেতরে একটি দীর্ঘ কাজ শুরু করে ঘুমিয়ে পড়লেন, আর যে এজেন্ট রাত 2টার সময় প্রশ্ন করার জন্য থেমে যায়, সেটি সকাল পর্যন্ত কোনো অগ্রগতি করতে পারে না। এই বিরতি সময় এবং অর্থ উভয়ই নষ্ট করে, কারণ একটি নিষ্ক্রিয় Claude Code সেশন তার warm prompt cache হারিয়ে ফেলে এবং পরবর্তী ধাপে সেটি পুনরায় তৈরি করতে খরচ হয়। সার্ভারে মানুষ কেন skip ফ্ল্যাগ ব্যবহার করতে চায়, এটিই তার প্রকৃত কারণ এবং এটি একটি বাস্তব সমস্যা। এই গাইডের বাকি অংশে আলোচনা করা হয়েছে কীভাবে প্রতিটি নিরাপত্তা ব্যবস্থা (guardrail) বজায় রেখে এই সমস্যার সমাধান করা যায়।

--dangerously-skip-permissions কী পরিবর্তন করে

claude --dangerously-skip-permissions approval ধাপটি বন্ধ করে দেয়। কোনো prompt ছাড়াই edit করা হয়। কোনো prompt ছাড়াই shell command চালানো হয়। সাধারণত সংবেদনশীল location সুরক্ষিত রাখা protected-path check-গুলোও এড়িয়ে যাওয়া হয়। আপনার নির্দিষ্ট deny rule-গুলো কার্যকর থাকে, এবং কয়েকটি অত্যন্ত ঝুঁকিপূর্ণ action চালানোর আগে এখনও অনুমতি চাওয়া হয়। তবে ব্যবহারিক সারাংশ সহজ: model যে command চালানোর সিদ্ধান্ত নেয়, সেটিই চালানো হয়।

সার্ভারে এই flag সম্পর্কে দুটি বিষয় গুরুত্বপূর্ণ। প্রথমত, Linux এবং macOS-এ Claude Code root হিসেবে বা sudo-এর অধীনে চললে এটি block করা হয়। কারণ prompt ছাড়া root account মেশিনের যেকোনো file বা service পরিবর্তন করতে পারে। Agent-এর জন্য যেকোনো ক্ষেত্রেই নিজস্ব unprivileged account ব্যবহার করা উচিত, এবং এই flag সেই সীমা কার্যকর করে। দ্বিতীয়ত, এই flag model-এর আচরণ কোনোভাবেই পরিবর্তন করে না। এটি human approval loop থেকে সরিয়ে দেয়, কিন্তু অন্য কিছু পরিবর্তন করে না। ফলে prompt যে ভুলটি আগে থামাতে পারত, সেটিও এখন execute হয়।

তাই বাস্তব হিসাবটি এমন। আপনি permission skip করলে security প্রশ্নটি "agent কি ক্ষতিকর কিছু করবে" থেকে বদলে "একটি ভুল action কতটা ক্ষতি করতে পারে"-তে পরিণত হয়। আপনি প্রতিটি সিদ্ধান্ত নিয়ন্ত্রণের চেষ্টা বন্ধ করে blast radius নিয়ন্ত্রণ করতে শুরু করেন। এর উত্তর হলো containment, এবং containment কয়েকটি স্তরে প্রয়োগ করা যায়।

Claude Code-এর বিল্ট-ইন স্যান্ডবক্স

কমান্ডগুলো চালানোর আগে জেনে রাখুন, Claude Code এখন তার চালানো কমান্ডগুলোর জন্য একটি OS-লেভেল স্যান্ডবক্স ব্যবহার করে। এর ফলে skip ফ্ল্যাগ ব্যবহারের প্রয়োজনীয়তা অনেকাংশেই কমে গেছে। Linux-এ এটি ফাইলসিস্টেম আইসোলেশনের জন্য bubblewrap এবং নেটওয়ার্ক ট্রাফিক প্রক্সির মাধ্যমে রাউট করার জন্য socat ব্যবহার করে। স্যান্ডবক্সের ভেতরে একটি কমান্ড শুধুমাত্র প্রজেক্ট ডিরেক্টরি এবং একটি সেশন টেম্প ডিরেক্টরিতে লিখতে পারে। এটি শুধুমাত্র এমন একটি প্রক্সির মাধ্যমে নেটওয়ার্ক অ্যাক্সেস করতে পারে যা প্রতিটি ডোমেইনকে একটি অ্যালাউ লিস্টের সাথে যাচাই করে। কোনো কমান্ড যখন প্রথমবারের মতো নতুন কোনো ডোমেইনে সংযোগ করতে চায়, Claude Code আপনাকে জিজ্ঞাসা করবে; অটো মোডে, ক্লাসিফায়ার নতুন হোস্টটিকে যাচাই করে নেয়।

একটি সেশনের ভেতরে /sandbox কমান্ড দিয়ে এটি চালু করুন। Ubuntu এবং Debian-এ, এটি চালানোর জন্য প্রয়োজনীয় দুটি প্যাকেজ আগে ইনস্টল করে নিন:

sudo apt install bubblewrap socat

Ubuntu 24.04 এবং পরবর্তী ভার্সনগুলোতে, ডিফল্ট AppArmor পলিসি bubblewrap-কে তার প্রয়োজনীয় ইউজার নেমস্পেস তৈরি করতে বাধা দেয়। কোনো কিছু অনুপস্থিত থাকলে স্যান্ডবক্স প্যানেল আপনাকে তা জানিয়ে দেবে এবং Claude Code স্যান্ডবক্সিং ডকুমেন্টেশনে একটি ছোট AppArmor প্রোফাইল দেওয়া আছে যা এই সমস্যার সমাধান করে।

স্যান্ডবক্সটিতে একটি অটো-অ্যালাউ মোড রয়েছে: স্যান্ডবক্সড কমান্ডগুলো কোনো প্রম্পট ছাড়াই চলে, কারণ প্রম্পট যে নিরাপত্তা নিশ্চিত করত, এখন কার্যকর করা বাউন্ডারি সেই কাজটিই করে। যে কমান্ডগুলো স্যান্ডবক্সের ভেতরে চলতে পারে না, সেগুলো সাধারণ পারমিশন ফ্লোতে ফিরে যায়, তাই অস্বাভাবিক কাজগুলোর ক্ষেত্রে এখনও অনুমতি চাওয়া হয়। বেশিরভাগ সার্ভার ওয়ার্কফ্লোর জন্য এটি skip ফ্ল্যাগের সঠিক বিকল্প, কারণ কোনো বাউন্ডারি না থাকার চেয়ে OS-এনফোর্সড বাউন্ডারি থাকলে আপনাকে অনেক কম প্রশ্নের সম্মুখীন হতে হবে।

এর সীমাবদ্ধতাগুলো সম্পর্কে সচেতন থাকুন। ডিফল্টভাবে, একটি স্যান্ডবক্সড কমান্ড এখনও ফাইলসিস্টেমের বেশিরভাগ অংশ পড়তে পারে, যার মধ্যে ক্রেডেনশিয়াল ফাইলও অন্তর্ভুক্ত, যদি না আপনি সেই পাথগুলো ডিনাই (deny) করে দেন; sandbox.credentials সেটিংটি ঠিক এই কাজের জন্যই তৈরি। নেটওয়ার্ক প্রক্সি শুধুমাত্র ডোমেইন নাম যাচাই করে, এটি ট্রাফিকের ভেতরের বিষয়বস্তু পরীক্ষা করে না। তাই github.com-এর মতো বিস্তৃত অ্যালাউ লিস্ট ব্যবহার করলে ডেটা বাইরে পাঠানোর সুযোগ থেকে যায়। এর ভেতরে Docker কাজ করে না। স্যান্ডবক্স নিরাপত্তার মান অনেক বাড়িয়ে দেয়, তবে এটি সম্পূর্ণ আইসোলেশন বাউন্ডারি নয়। তাই নিচের ধাপগুলো এখনও গুরুত্বপূর্ণ।

নিয়ন্ত্রণের ধাপ

বিচ্ছিন্নতার মাত্রা বাড়ার ক্রমে এখানে তিনটি ধাপ রয়েছে। সার্ভারে আর কী কী চলছে, তার ভিত্তিতে সবচেয়ে কম মাত্রার উপযুক্ত ধাপটি বেছে নিন।

ধাপ 1: একটি নির্দিষ্ট unprivileged user। Agent-এর জন্য আলাদা account, আলাদা home directory, আলাদা project directory তৈরি করুন এবং sudo অনুমতি দেবেন না:

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

এই account boundary agent-কে আপনার ফাইল থেকে দূরে রাখে: আপনার SSH key এবং মেশিনের অন্য সব project থেকেও। এটি skip flag ব্যবহার করাও সম্ভব করে, কারণ এই flag root হিসেবে চলতে অস্বীকার করে। এটি প্রতিটি service unprivileged user হিসেবে চালানোর একই নীতি, যা এখানে agent-এর ক্ষেত্রে প্রয়োগ করা হয়েছে। ধাপ 1 যে বিষয়গুলো সীমাবদ্ধ করে না: network এবং সার্ভারে থাকা world-readable যেকোনো কিছু।

ধাপ 2: একটি container। Anthropic একটি reference devcontainer প্রকাশ করে, যেখানে Claude Code non-root user হিসেবে চলে এবং firewall rule agent কোন কোন host-এ পৌঁছাতে পারবে তা সীমিত করে। আপনি নিজে তৈরি করা container-ও একই কাজ করে। আপনি যে volume mount করেন, filesystem মূলত সেগুলোতেই সীমিত থাকে। Container-এর rule যতটুকু অনুমতি দেয়, egress-ও ততটুকুতেই সীমিত থাকে। সার্ভারে আপনার গুরুত্বপূর্ণ অন্য service চললে এটি উপযুক্ত মধ্যবর্তী ধাপ। এর সীমাবদ্ধতা হলো, container host kernel ভাগ করে ব্যবহার করে, এবং অসতর্কভাবে করা একটি mount এই boundary নষ্ট করতে পারে; container-কে /var/run/docker.sock দিলে এটি পুরো host-এ পৌঁছাতে পারে।

ধাপ 3: একটি নির্দিষ্ট VPS। সবচেয়ে শক্তিশালী ধাপটিই সবচেয়ে সরল: agent-এর জন্য এমন একটি সম্পূর্ণ machine দিন, যেখানে আপনার গুরুত্বপূর্ণ কোনো কিছু নেই। একটি ছোট VPS-এর মাসিক খরচ কয়েক dollar। নতুন VPS-এ প্রথম দশ মিনিটের runbook অনুসরণ করে সেটি প্রস্তুত করুন, পরিষ্কার অবস্থার snapshot নিন, এবং agent-কে কাজ করতে দিন। সেখানে অন্য কিছু থাকবে না। কোনো ব্যক্তিগত SSH key নয়; শুধু একটি repository-তে সীমাবদ্ধ deploy key থাকবে। কোনো cloud credential বা production data থাকবে না। কোনো run-এ সমস্যা হলে, অথবা আপনি নতুন করে পরিষ্কার অবস্থায় শুরু করতে চাইলে, কয়েক মিনিটের মধ্যে snapshot restore করুন অথবা machine ধ্বংস করে আবার তৈরি করুন। ঝুঁকির পরিধি হলো VPS-এর ভাড়া। এই ব্যবস্থায় --dangerously-skip-permissions আর ভয়ংকর থাকে না, কারণ বাস্তবসম্মত সবচেয়ে খারাপ ফল হলো server পুনর্নির্মাণ করা এবং একটি token revoke করা।

এই ধাপগুলো একসঙ্গে ব্যবহার করা যায়। Disposable VPS-এ unprivileged user হিসেবে চলা sandboxed agent-এর জন্য অতিরিক্ত খরচ প্রায় নেই এবং ব্যর্থতার ঘটনাগুলোকে সহজ ও একঘেয়ে করে তোলে। লক্ষ্যই হলো একঘেয়েমি।

ক্রেডেনশিয়াল সুরক্ষিত রাখা

অন্য সবকিছুর ভিত্তি হলো এই নিয়মটি: এজেন্টের ব্যবহারকারীর অন্য কোনো কিছুর গোপন তথ্য (secrets) পড়ার অনুমতি থাকা উচিত নয়।

API key শুধুমাত্র এজেন্টকে দিন, অন্য কাউকে নয়। এটি এমন একটি ফাইলে রাখুন যার মালিক এজেন্টের ব্যবহারকারী এবং যার মোড 600, এরপর শেল শুরু হলে তা লোড করুন:

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 ইনস্টলেশনে, এবং ইনস্টলেশনের সময় তৈরি করা অ্যাকাউন্টের ক্ষেত্রে, হোম ডিরেক্টরিগুলো সিস্টেমের যেকোনো ব্যবহারকারী পড়তে পারে। তাই আপনার নিজের ডিরেক্টরি সুরক্ষিত করুন: chmod 750 /home/youruser। ls -ld /home/* দিয়ে পরীক্ষা করুন এবং এজেন্টের অ্যাকাউন্ট যা কিছু তালিকাভুক্ত করতে পারে তা ঠিক করুন।

প্রতিটি টোকেনের পরিধি নির্ধারণ করুন। একটি নির্দিষ্ট রিপোজিটরিতে সীমাবদ্ধ GitHub token বা প্রতি-রিপোজিটরি deploy key ব্যবহারের অর্থ হলো, কোনো ক্রেডেনশিয়াল ফাঁস হলে শুধুমাত্র একটি প্রজেক্ট ক্ষতিগ্রস্ত হবে, পুরো অ্যাকাউন্ট নয়। আপনি যদি sandbox ব্যবহার করেন, তবে এর ক্রেডেনশিয়াল সেটিংস এমনভাবে যোগ করুন যাতে ~/.ssh এবং ~/.aws রিড করার জন্যও নিষিদ্ধ থাকে। আর প্রোডাকশন ক্রেডেনশিয়ালগুলো এই বক্সে রাখবেন না, কারণ যে গোপন তথ্য সেখানে নেই, তা এজেন্ট ফাঁস করতে পারে না। যদি সেই গোপন তথ্যগুলো কোনো self-hosted password manager-এ থাকে, তবে সেটিকে এজেন্টের থেকে আলাদা বক্সে রাখুন এবং সেটির জন্য আলাদাভাবে পর্যালোচনা করুন, কারণ Vaultwarden-এর দুর্বল দিক হলো অ্যাডমিন টোকেন এবং ব্যাকআপ ফাইল, এনক্রিপ্ট করা ভল্ট নিজে নয়।

Git হলো সুরক্ষাকবচ

এজেন্ট প্রতিটি পরিবর্তন কমিট করলে তা পর্যালোচনা এবং প্রয়োজনে আগের অবস্থায় ফিরিয়ে আনা সম্ভব। এজেন্ট যদি একটি আলাদা branch-এ কাজ করে এবং নিয়মিত কমিট করতে থাকে, তবে Git এই সুবিধাগুলো বিনামূল্যে প্রদান করে:

git switch -c agent/refactor-auth

যে কাজ এজেন্ট কমিট করে না, তার কোনো সুরক্ষা নেই: একটি git reset --hard কমান্ড ট্র্যাক করা ফাইলের আনকমিটেড পরিবর্তনগুলো মুছে ফেলে এবং Git রিপোজিটরির বাইরের কোনো কিছুর সুরক্ষা দেয় না। রান শেষ হওয়ার পর এজেন্ট কী কমিট করেছে তা দেখতে git diff main...agent/refactor-auth ব্যবহার করুন। এরপর এজেন্ট যা কমিট করেনি তা দেখতে ওই branch-এ git status এবং git diff HEAD চালান। ভালো পরিবর্তনগুলো merge করুন এবং রানটি সফল না হলে branch-টি মুছে ফেলুন। তিনটি ফাইলে পরিবর্তন করা একটি রান সকালে পর্যালোচনা করা অনেক সহজ, মডিউলের অর্ধেক বদলে ফেলা রানের তুলনায়। এটি সবচেয়ে ছোট কার্যকর পরিবর্তনের মাধ্যমে কাজ করার দক্ষতার বাস্তব উদাহরণ। Forge-এর দিক থেকে main branch-কে সুরক্ষিত রাখুন, যাতে এজেন্টের টোকেন সেখানে push করতে না পারে এবং কোথাও force-push করতে না পারে। কমিট হিস্ট্রি আপনার অনুপস্থিতিতে কী ঘটেছে তার অডিট লগ হিসেবে কাজ করে, যা টার্মিনাল স্ক্রলব্যাকের চেয়ে অনেক বেশি মূল্যবান।

নেটওয়ার্কও ক্ষতির পরিধির অংশ

একটি agent curl চালাতে পারে। এই বাক্যেই egress-এর পুরো সমস্যা স্পষ্ট: agent যা পড়তে পারে, তা যেকোনো জায়গায় পাঠাতেও পারে, এবং prompt injection-এর শিকার agent তা পাঠাতে পারে। সাধারণ unprivileged user দিয়ে এই পরিধি মোটেও সীমাবদ্ধ হয় না, কারণ যেকোনো user সার্ভার যে গন্তব্যে পৌঁছাতে পারে, সেখানেই পৌঁছাতে পারে। sandbox তার proxy-এর মাধ্যমে domain অনুযায়ী এই পরিধি সীমাবদ্ধ করে। container নিজস্ব firewall rule ব্যবহার করে এটি সীমিত করতে পারে। dedicated VPS শুরুতেই ফাঁস হওয়ার মতো তথ্যের পরিমাণ সীমিত করে; তিনটির মধ্যে এটিই সবচেয়ে শক্তিশালী পদ্ধতি।

শুধু ufw দিয়ে egress নিয়ন্ত্রণ করার চেষ্টা করবেন না। ufw ডিফল্টভাবে সব outgoing traffic অনুমোদন করে। আবার apt, npm, git এবং Claude API-এর জন্য outbound rule লিখে সেগুলো সচল রাখা জটিল কাজ; এতে নীরবে সমস্যা তৈরি হতে পারে। পরিবর্তে sandbox, container বা machine স্তরে boundary নির্ধারণ করুন। সেখানে domain allow list অথবা একটি bare machine একই কাজ পরিষ্কারভাবে করে।

আপনি যদি Claude Code চালানোর বদলে API ব্যবহার করে নিজস্ব agent তৈরি করেন, একই নীতি প্রযোজ্য থাকবে। VPS-এ Claude দিয়ে একটি AI agent তৈরি করা পদ্ধতিটি ব্যাখ্যা করে। সেই agent-এর জন্যও একই dedicated user, একই সীমিত-পরিসরের token এবং একই সহজে বাতিলযোগ্য machine ব্যবহার করা উচিত।

প্রথমে সার্ভারটি শক্তভাবে সুরক্ষিত করুন

আপনি যে স্তরই বেছে নিন, agent চালু করার আগে মেশিনটির মৌলিক নিরাপত্তা নিশ্চিত করতে হবে: শুধু SSH key ব্যবহার, root login বন্ধ, default-deny firewall এবং স্বয়ংক্রিয় security update। এখানে আপনার checklist তৈরি করুন এবং একবার ধারাবাহিকভাবে প্রতিটি কাজ সম্পন্ন করুন:

FAQ

সার্ভারে --dangerously-skip-permissions ব্যবহার করা কি নিরাপদ?

এটি নিজে থেকে নিরাপদ নয়। এই flag সব approval prompt সরিয়ে দেয়। ফলে model কোনো ক্ষতিকর command তৈরি করলেই সেটি সঙ্গে সঙ্গে চালু হয়। ঝুঁকির প্রভাব সীমিত রাখা গেলে এটি বিবেচনাযোগ্য হতে পারে। অন্তত একটি dedicated unprivileged user ব্যবহার করুন। সত্যিকারের unattended কাজের জন্য একটি container অথবা disposable VPS ব্যবহার করুন, যেখানে শুধু একটি project এবং একটি scoped token থাকবে। এমন কোনো machine-এ এটি কখনো ব্যবহার করবেন না, যেখানে production credential বা হারালে পুনরুদ্ধার করা যাবে না এমন data রয়েছে।

Claude Code-এ কি sandbox আছে?

হ্যাঁ। Claude Code-এ shell command-এর জন্য একটি built-in sandbox রয়েছে। এটি /sandbox command দিয়ে চালু করা হয়। Linux-এ এটি bubblewrap এবং macOS-এ Seatbelt ব্যবহার করে। এটি project directory-তে write সীমিত রাখে এবং এমন একটি proxy-এর মাধ্যমে network access পরিচালনা করে, যা শুধু অনুমোদিত domain-এ প্রবেশের অনুমতি দেয়। এর auto-allow mode prompt ছাড়াই sandboxed command চালায়। তাই এটি skip flag-এর মতো interruption কমায়, তবে OS-enforced boundary বজায় রাখে। এটি সম্পূর্ণ isolation boundary নয়। তাই unattended run-এর জন্য এর সঙ্গে একটি dedicated user অথবা dedicated machine ব্যবহার করুন।

Skip flag root হিসেবে চলতে অস্বীকার করে কেন?

কারণ permission prompt ছাড়া root system-এর যেকোনো file এবং যেকোনো service পরিবর্তন করতে পারে। তাই Linux এবং macOS-এ root হিসেবে অথবা sudo-এর অধীনে চললে Claude Code --dangerously-skip-permissions block করে। এই check এড়ানোর চেষ্টা করবেন না। Agent-এর জন্য একটি unprivileged user তৈরি করে সেটির অধীনে চালান। এই account boundary-ই containment-এর প্রথম এবং সবচেয়ে কম খরচের স্তর।

Claude Code কি আমার SSH key এবং .env file পড়তে পারে?

যে user-এর অধীনে এটি চলে, সেই user যে file পড়তে পারে, এটি সেগুলো পড়তে পারে। এমনকি sandbox-এর default policy-ও আপনি নিষেধ না করা পর্যন্ত credential path পড়ার অনুমতি দেয়। তাই agent-কে নিজস্ব user হিসেবে চালান। আপনার নিজের home directory-এর mode 750 বা তার চেয়ে কঠোর রাখুন। Sandbox settings-এ credential path নিষিদ্ধ করুন। Production secret সম্পূর্ণভাবে machine-এর বাইরে রাখুন। কোনো secret machine-এ না থাকলে সেটি পড়া বা ফাঁস করা সম্ভব নয়।

Claude Code unattended অবস্থায় চালানোর সবচেয়ে নিরাপদ উপায় কী?

Agent-এর কাজের জন্য ব্যবহৃত একটি সস্তা dedicated VPS সবচেয়ে নিরাপদ বিকল্প। এটি দশ মিনিটে harden করুন এবং একটি clean snapshot তৈরি করুন। Claude Code-কে sandbox চালু রেখে একটি unprivileged user-এর অধীনে চালান। API key রাখার file-এর mode 600 রাখুন। প্রতিটি repository-এর জন্য আলাদা deploy key ব্যবহার করুন। সব কাজ এমন branch-এ করুন, যা merge করার আগে আপনি review করবেন। কোনো run-এ সমস্যা হলে একটি token revoke করে snapshot restore করতে পারবেন। এতে আপনার মালিকানাধীন অন্য কোনো resource প্রভাবিত হবে না।