সার্ভারে 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-এর জন্য পরিকল্পনা করুন।

সহজ ভাষায় permission system

ডিফল্ট অবস্থায় Claude Code কোনো কাজ করার আগে অনুমতি চায়। Project-এর ভেতরের file পড়া নীরবে হয়, কিন্তু কোনো file edit করা বা shell command চালানোর আগে সঠিক edit বা command দেখিয়ে আপনার অনুমতির জন্য অপেক্ষা করে। আপনি একটি action অনুমোদন করতে পারেন, অথবা session-এর বাকি সময় একই ধরনের action অনুমোদন করতে পারেন। এই অনুমতিগুলো session-ভিত্তিক: CLI বন্ধ করলে পরের session আবার সতর্ক অবস্থায় শুরু হয়। যেসব rule স্থায়ীভাবে রাখতে চান, সেগুলোর জন্য settings file-এ persistent allow, ask এবং deny list থাকে। যেমন: git status অনুমোদন করুন, git push-এ অনুমতি চান, .env পড়া নিষিদ্ধ করুন। Deny rule সব সময় অগ্রাধিকার পায়। এই baseline-ও পরিবর্তন হচ্ছে, কারণ 14 August 2026 থেকে auto mode default হবে। তাই প্রতিটি permission mode আসলে কী অনুমোদন করে তা জানা জরুরি, বিশেষ করে এমন server-এ কোন mode চালাবেন তা ঠিক করার আগে যেটি আপনি পর্যবেক্ষণ করতে পারবেন না।

এই নকশা ধরে নেয় যে terminal-এ একজন মানুষ নজর রাখছেন। Laptop-এ সেটি সাধারণত সত্য। কিন্তু server-এ প্রায়ই কেউ নজর রাখেন না। আপনি tmux-এর ভেতরে একটি দীর্ঘ task শুরু করে ঘুমাতে যান। তখন 2 a.m.-এ কোনো প্রশ্ন করে agent থেমে গেলে সকাল পর্যন্ত কোনো অগ্রগতি হয় না। এতে সময়ের পাশাপাশি অর্থও নষ্ট হয়, কারণ নিষ্ক্রিয় Claude Code session তার warm prompt cache হারায় এবং পরের turn-এ সেটি আবার তৈরি করার খরচ হয়। এটাই server-এ মানুষ skip flag ব্যবহার করার প্রকৃত কারণ, এবং এটি বাস্তব একটি সমস্যার সমাধান করে। এই guide-এর বাকি অংশে প্রতিটি 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-এর অন্তর্নির্মিত sandbox

Rungs-এ যাওয়ার আগে জেনে রাখুন, Claude Code এখন চালানো command-এর জন্য OS-level sandbox সরবরাহ করে। এর ফলে skip flag ব্যবহারের বেশিরভাগ কারণ দূর হয়। Linux-এ filesystem isolation-এর জন্য এটি bubblewrap ব্যবহার করে এবং socat-এর মাধ্যমে network traffic একটি proxy-তে পাঠায়। Sandbox-এর ভিতরে কোনো command শুধু project directory এবং session temp directory-তে লিখতে পারে। এটি কেবল এমন একটি proxy-এর মাধ্যমে network-এ পৌঁছাতে পারে, যা প্রতিটি domain-কে allow list-এর সঙ্গে যাচাই করে। কোনো command প্রথমবার নতুন domain-এ যেতে চাইলে Claude Code আপনার অনুমতি চায়।

একটি session-এর ভিতরে /sandbox command দিয়ে এটি চালু করুন। Ubuntu এবং Debian-এ আগে প্রয়োজনীয় দুটি package install করুন:

sudo apt install bubblewrap socat

Ubuntu 24.04 এবং পরবর্তী সংস্করণে default AppArmor policy bubblewrap-কে প্রয়োজনীয় user namespace তৈরি করতে বাধা দেয়। কোনো উপাদান অনুপস্থিত থাকলে sandbox panel তা জানায়। Claude Code sandboxing documentation-এ সমস্যাটি সমাধানের সংক্ষিপ্ত AppArmor profile দেওয়া আছে।

Sandbox-এ auto-allow mode রয়েছে। Enforced boundary এখন prompt-এর কাজ করে বলে sandboxed command কোনো prompt ছাড়াই চলে। Sandbox-এর ভিতরে চলতে পারে না এমন command স্বাভাবিক permission flow-তে ফিরে যায়। তাই সত্যিই অস্বাভাবিক action-গুলোর জন্য এখনও অনুমতি চাওয়া হয়। বেশিরভাগ server workflow-এর জন্য এটি skip flag-এর সঠিক বিকল্প। কারণ কোনো boundary ছাড়া কাজ চালানোর বদলে OS-enforced boundary ব্যবহার করলে প্রশ্নের সংখ্যা অনেক কমে যায়।

এর সীমাবদ্ধতা সম্পর্কে বাস্তবসম্মত থাকুন। Default হিসেবে sandboxed command এখনও credential file-সহ filesystem-এর বেশিরভাগ অংশ পড়তে পারে, যদি না আপনি ওই path-গুলো নিষিদ্ধ করেন। sandbox.credentials setting-এর উদ্দেশ্যই এটি নিয়ন্ত্রণ করা। Network proxy domain name যাচাই করে, কিন্তু নিজে traffic পরিদর্শন করে না। তাই github.com-এর মতো বিস্তৃত allow rule থাকলে data বাইরে পাঠানোর সুযোগ থেকে যায়। এর ভিতরে Docker কাজ করে না। Sandbox নিরাপত্তার ন্যূনতম স্তর অনেক বাড়ায়। তবে এটি সম্পূর্ণ isolation boundary নয়। এ কারণেই নিচের rungs এখনও গুরুত্বপূর্ণ।

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

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

ধাপ 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-এর জন্য অতিরিক্ত খরচ প্রায় নেই এবং ব্যর্থতার ঘটনাগুলোকে সহজ ও একঘেয়ে করে তোলে। লক্ষ্যই হলো একঘেয়েমি।

শংসাপত্র সুরক্ষিত করুন

অন্য সবকিছুর ভিত্তি হলো এই নিয়ম: agent-এর user যেন অন্য কোনো কিছুর secret পড়তে না পারে।

API key শুধু agent-কে দিন, অন্য কাউকে নয়। এটি agent-এর user-এর মালিকানাধীন একটি file-এ mode 600 দিয়ে রাখুন এবং shell শুরু হলে load করুন:

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 প্রায়ই সিস্টেমের সব user-এর জন্য readable অবস্থায় তৈরি হয়। তাই নিজের home directory-এর permission কঠোর করুন: chmod 750 /home/youruser। ls -ld /home/* দিয়ে পরীক্ষা করুন এবং agent-এর account যে file বা directory list করতে পারে, সেগুলোর permission ঠিক করুন।

প্রতিটি token-এর scope সীমিত রাখুন। একটি repository-তে সীমাবদ্ধ fine-grained GitHub token অথবা প্রতিটি repository-র জন্য আলাদা deploy key ব্যবহার করলে credential ফাঁস হলেও শুধু একটি project ক্ষতিগ্রস্ত হবে, পুরো account নয়। sandbox ব্যবহার করলে এর credential settings-এ এমন ব্যবস্থা করুন, যাতে read operation-এর ক্ষেত্রেও ~/.ssh এবং ~/.aws নিষিদ্ধ থাকে। Production credential সম্পূর্ণভাবে এই box-এর বাইরে রাখুন। কারণ কোনো secret কখনো এখানে না থাকলে agent সেটি ফাঁস করতে পারে না। Secret-গুলো self-hosted password manager-এ থাকলে সেটি agent-এর ভিন্ন একটি box-এ রাখুন এবং এর জন্য আলাদা review প্রক্রিয়া চালু করুন। কারণ Vaultwarden-এর দুর্বল দিক হলো admin token ও backup file, encrypted vault নিজে নয়।

Git হলো নিরাপত্তার জাল

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

git switch -c agent/refactor-auth

এরপর git diff main...agent/refactor-auth দিয়ে run-টির পর্যালোচনা করুন, ভালো পরিবর্তনগুলো merge করুন, এবং run-টি কোনো কার্যকর ফল না দিলে branch মুছে দিন। তিনটি file-এ পরিবর্তন করা run, module-এর অর্ধেক নতুন করে লেখার run-এর তুলনায় সকালের সময় পড়ে দেখা অনেক সহজ। বাস্তবে তাই যে skill এজেন্টকে কাজের জন্য প্রয়োজনীয় সর্বনিম্ন পরিবর্তনের মধ্যে সীমাবদ্ধ রাখে, সেটিই বেশি কার্যকর। forge-এ main branch-এর protection চালু রাখুন, যাতে এজেন্টের token সেখানে push করতে না পারে এবং কোনো branch-এ force-push-ও করতে না পারে। commit history-কে কী ঘটেছিল তার audit log হিসেবেও ব্যবহার করা যায়, বিশেষ করে আপনি ঘুমানোর সময় এজেন্ট কাজ করলে; এটি terminal-এর পুরোনো output-এর চেয়ে অনেক বেশি মূল্যবান।

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

একটি 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 প্রভাবিত হবে না।