Claude Code সেশনের মধ্যে message পাঠানোর নিয়ম

Claude Code session-গুলো একে অন্যকে message করতে পারলে তার অর্থ কী

একই machine-এ, একই operating system user-এর অধীনে চললে দুটি Claude Code session একে অন্যকে message করতে পারে। একটি message হলো একটি Claude-এর লেখা অন্য Claude-এর জন্য plain text-এর একটি অংশ। এতে কোনো conversation history বা file থাকে না। Claude ListAgents tool ব্যবহার করে অন্য session খুঁজে বের করে এবং SendMessage দিয়ে text পাঠায়, তাই আপনাকে কোনো tool হাতে চালাতে হয় না। অন্য session-কে কী জানা দরকার তা আপনি বলেন, আর Claude নিজেই message লিখে।

এই feature-টির নাম cross-session messaging। August 2026 অনুযায়ী এর জন্য Claude Code v2.1.224 বা পরবর্তী version প্রয়োজন। এটি macOS এবং Linux-এ চলে, যার মধ্যে WSL 2-এর ভিতরের Linux-ও অন্তর্ভুক্ত। এর native Windows support নেই। Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform বা Microsoft Foundry-তেও এটি উপলভ্য নয়। কোনো session এই requirements পূরণ করলে messaging আগে থেকেই চালু থাকে; আলাদাভাবে enable করার কিছু নেই। নিচে বর্ণিত আচরণটি cross-session messaging নিয়ে Anthropic documentation-এর ভিত্তিতে দেওয়া হয়েছে।

VPS-এ এই feature-টির প্রয়োজনীয়তা স্পষ্ট হয়, কারণ session সেখানে যথেষ্ট সময় চালু থাকে এবং সেগুলোকে address করার বাস্তব কারণ থাকে। Laptop-এ আপনি lid বন্ধ করে দেন। কিন্তু tmux-এর অধীনে server-এ Monday-তে শুরু করা session Thursday-তেও চলতে থাকে এবং একটি repository-এর context ধরে রাখে। এমন দুটি session থাকলে তারা কীভাবে একে অন্যের সঙ্গে যোগাযোগ করে, তা আর কেবল তাত্ত্বিক বিষয় থাকে না। আপনি যদি এখনও এটি সেট up না করে থাকেন, তাহলে tmux-এর অধীনে VPS-এ Claude Code চালানো দিয়ে শুরু করুন। এই guide-এ ধরে নেওয়া session setup সেখানে ব্যাখ্যা করা হয়েছে।

যখন দ্বিতীয় session-এর খরচ সার্থক

প্রথমে খরচ বিবেচনা করুন। প্রতিটি session নিজস্ব context window-সহ একটি পৃথক Claude instance, তাই একই সময়ে দুটি session চালালে একটি session-এর তুলনায় খরচ প্রায় দ্বিগুণ হয়। আপনি যে message পাঠান, delivered message-ও usage-এর হিসাবে prompt-এর মতোই গণনা হয়। সমন্বয় বিনামূল্যে নয়। প্রকৃতপক্ষে যদি কাজটি একটিই ধারাবাহিক ধাপ হয়, সেটিকে একাধিক session-এ ভাগ করলে কাজ ধীর এবং ব্যয়বহুল হয়।

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

• একটি session breaking change শনাক্ত করে, আর অন্যটি সেই পরিবর্তনে ভেঙে যাওয়া code-এর ওপর কাজ চালিয়ে যায়। অন্য terminal-এ আপনাকে পরিবর্তনটি আবার লিখে দিতে হয় না; Claude পরিবর্তনটির সারাংশ পাঠিয়ে দেয়।
• দুটি session পৃথক git worktree-তে একই repository নিয়ে কাজ করে, এবং একটির জানতে হয় অন্যটিতে কী যুক্ত হয়েছে।
• একটি দীর্ঘ migration বা test run তার ফলাফল আপনি যে session পর্যবেক্ষণ করছেন, সেখানে পাঠায়।
• একটি builder session এবং একটি reviewer session থাকে। reviewer builder-এর তৈরি output পড়ে এবং তার পর্যবেক্ষণ পাঠায়।

কাজ ধারাবাহিক হলে, অথবা দুটি session-ই একই file সম্পাদনা করলে, একটি session ব্যবহার করুন। একটি task-এর মধ্যে Claude যে সমন্বিত group তৈরি ও তদারক করে, সেটি agent teams—এটি পৃথক এবং এখনও experimental feature। শুধু অন্য terminal-এ একই conversation চালিয়ে যেতে চাইলে session resume করুন। Cross-session messaging সেই independent session-গুলোর জন্য, যেগুলো আপনি নিজে শুরু করেন এবং পরিচালনা করেন।

কাজটির ওপর নির্ভর করার আগে বৈশিষ্ট্যটি আছে কি না পরীক্ষা করুন

প্রথমে সংস্করণ দেখুন:

claude --version

সংখ্যাটি 2.1.224-এর সঙ্গে তুলনা করুন। এরপর একটি session-এর মধ্যে /list-agents লিখুন; এই কমান্ডটি /peers নামেও কাজ করে। এটি এই session যে সব agent-এ পৌঁছাতে পারে, তাদের প্রত্যেকটির নাম এবং যে নামে তারা সাড়া দেয় তা দেখায়। কমান্ডটি একেবারেই শনাক্ত না হলে, এই session-এ cross-session messaging নেই; কোনো settings file পরিবর্তন করলেও তা যোগ হবে না। /status লিখে Peer address row খুঁজুন। এখানে এই session-এর নিজস্ব inbox address থাকে, যার শুরুতে uds: থাকে।

একটি সমস্যা বিশেষভাবে VPS ব্যবহারকারীদের ক্ষেত্রে দেখা যায়। Cross-session messaging feature-flag evaluation-এর ওপর নির্ভর করে। কয়েকটি privacy variable এই evaluation বন্ধ করে দেয়, ফলে feature-টি default অবস্থায় off থাকে। DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC এবং DISABLE_GROWTHBOOK—সবগুলোই এটি করে। অনেকে নতুন server harden করতে এগুলো ~/.bashrc-এ paste করেন, পরে অবাক হন কেন /list-agents নেই। একই value কোনো settings file-এর env map থেকেও আসতে পারে, অথবা managed settings থেকেও আসতে পারে। তাই প্রথমে shell পরীক্ষা করুন।

env | grep -E 'DO_NOT_TRACK|DISABLE_TELEMETRY|DISABLE_GROWTHBOOK|NONESSENTIAL'

যে variable-এর value দেখা যায়, সেটি unset করুন। DISABLE_TELEMETRY এবং CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC-এর ক্ষেত্রে যেকোনো non-empty value এই আচরণ চালু করে; এর মধ্যে 0 string-ও রয়েছে। তাই DISABLE_TELEMETRY=0 দেখতে যেমন মনে হয়, তেমন কাজ করে না। Variable-টি unset করে অথবা empty string সেট করে এটি বন্ধ করতে হয়।

আপনার session-এর নাম দিন, নইলে Claude সেগুলো আলাদা করে সম্বোধন করতে পারবে না

Claude নামের মাধ্যমে কোনো message-কে একটি session-এ পাঠায়। Session শুরু করার সময় নাম সেট করুন:

claude --name builder-api

চলমান session-এর ভেতরেও /rename ব্যবহার করে নাম সেট করতে পারেন। কোনো নাম সেট না করলে Claude Code working directory-এর folder name থেকে নাম তৈরি করে, যেমন myapp-3f। একটি session-এর ক্ষেত্রে এটি ঠিক আছে, কিন্তু চারটি session থাকলে বিভ্রান্তিকর হয়। একই নামের দুটি session-ও তৈরি হতে পারে। /list-agents output প্রতিটি local session-এর working directory দেখায়। এতে একই নামের session আলাদা করা যায়। নামের সংঘর্ষ হলে Claude-এর নিজস্ব listing address-এর সঙ্গে একটি সংক্ষিপ্ত identifier যোগ করে। নিজে নাম দেওয়া identifier পড়ার চেয়ে সহজ।

পুনরুৎপাদনযোগ্য দুই-সেশন tmux বিন্যাস

এটি একই repository-তে একটি builder session এবং একটি reviewer session। reviewer আলাদা git worktree-তে কাজ করে, তাই দুটি session কখনও একই file-এ লিখবে না। git worktree add-এর সঙ্গে HEAD ব্যবহার করলে detached checkout তৈরি হয়। কমিট না করে শুধু পড়ার session-এর জন্য এটিই প্রয়োজন।

cd ~/src/api
git worktree add ../api-review HEAD
tmux new-session -d -s agents -n builder -c ~/src/api
tmux new-window -t agents -n reviewer -c ~/src/api-review
tmux send-keys -t agents:builder 'claude --name builder-api' C-m
tmux send-keys -t agents:reviewer 'claude --name reviewer-api' C-m
tmux attach -t agents

এরপর Ctrl+b চালিয়ে w ব্যবহার করলে নাম অনুযায়ী window-গুলোর তালিকা দেখা যায়, যাতে একটি বেছে নিতে পারেন। builder window-তে /list-agents চালান। সেখানে reviewer-api এবং তার working directory হিসেবে ~/src/api-review দেখা উচিত। এটি না থাকলে reviewer session চালু হওয়া শেষ হয়নি, অথবা পরের section-এ বর্ণিত দুটি সমস্যার একটি প্রযোজ্য। এরপর সাধারণ ভাষায় একটি hand-off পাঠান:

Tell reviewer-api which files I changed for the rate limiter and what to look at first.

Claude summary লিখে সেটি পাঠায়। বার্তার text আপনি লিখবেন না, এবং Claude কী পাঠাবে তা পরিবর্তিত হতে পারে। reviewer window-তে প্রেরকের নামসহ conversation-এর মধ্যে বার্তাটি দেখা যায়। সেই session idle থাকলে Claude সঙ্গে সঙ্গে সেখানে নতুন turn শুরু করে। session মাঝপথে থাকলে tool call-গুলোর মধ্যবর্তী সময় পর্যন্ত বার্তাটি অপেক্ষা করে, তাই চলমান command কখনও বাধাপ্রাপ্ত হয় না। Claude বার্তাটি পড়ে নিলে সেটি এক লাইনের Message from row-তে সংকুচিত হয়, যা Ctrl+O প্রসারিত করে। builder ছোট ছোট পরিবর্তন রাখলে এই জোড়া আরও ভালো কাজ করে, কারণ সীমিত diff ছোট hand-off তৈরি করে এবং অন্য session একটি turn-এই review শেষ করতে পারে। এই অভ্যাসটি অলস senior dev দক্ষতা গড়ে তোলার জন্যই রয়েছে।

একটি VPS-এ কে কাকে দেখতে পারে

একই মেশিনে বার্তা পাঠানো কখনো Anthropic server-এর মধ্য দিয়ে যায় না। প্রতিটি session disk-এ registration file লেখে এবং নিজের inbox socket bind করে। Claude Code এই file পড়ে আপনার অন্য session খুঁজে পায়। এর দুটি ফল আছে। server-এ দুটিই গুরুত্বপূর্ণ।

Socket-এ আপনার operating system user-এর জন্য সীমাবদ্ধতা থাকে। root হিসেবে চালানো একটি session এবং deploy হিসেবে চালানো একটি session একে অপরকে দেখতে পারে না। একই tmux server-এ পাশাপাশি থাকলেও এটি প্রযোজ্য। কারণ একটি user-এর session অন্য user-এর socket-এ পৌঁছাতে পারে না। দুটি session একই user হিসেবে চালান।

একটি container-এর নিজস্ব filesystem থাকে। Docker-এর ভিতরের একটি session এবং host-এর একটি session একে অপরের কাছে পৌঁছাতে পারে না। কারণ তারা একই registration file পড়ে না। একই container-এর ভিতরের দুটি session স্বাভাবিকভাবে একে অপরকে message পাঠাতে পারে। isolation-এর জন্য যদি আপনি container-এ agent রাখেন, যেমন disposable VM-এ coding agent চালানো, তাহলে container-এর ভিতরে messaging কাজ করবে, কিন্তু container boundary পেরিয়ে কাজ করবে না—এটাই প্রত্যাশিত।

অন্য machine-এ এবং web-এ থাকা আপনার session listing-এ দেখা যাবে শুধু Remote Control connected থাকা অবস্থায়। সেগুলো আলাদাভাবে চিহ্নিত থাকবে। এখানে Claude কেবল ওই session-গুলোর কোনো একটি থেকে আসা message-এর উত্তর দিতে পারে। সে নিজে থেকে সেই exchange শুরু করতে পারে না।

আপনার বার্তা কেন কখনো পৌঁছায়নি

সাধারণ কারণটির সঙ্গে network-এর কোনো সম্পর্ক নেই। receiving session বার্তাটির সঙ্গে কী করা হবে তা নির্ধারণ করেছে, এবং সিদ্ধান্ত হয়েছে সেটি deliver করা হবে না। প্রতিটি আগত বার্তা তিনটির একটিতে শেষ হয়: delivered, held (আপনি অনুমোদন না করা পর্যন্ত deliver না করে আলাদা রাখা), অথবা refused (deliver না করেই বাতিল করা)।

যখন কোনো crossSessionInbound value প্রযোজ্য নয়, তখন Claude Code দুই session-এর permission mode তুলনা করে প্রতিটি বার্তার জন্য সিদ্ধান্ত নেয়। যে session-গুলো permission prompt এড়িয়ে চলে, সেগুলোকে একটি class-এ এবং বাকি সব session-কে অন্য class-এ রাখা হয়। auto, acceptEdits এবং dontAsk-কে prompting হিসেবে গণনা করা হয়। যে session-এ bypass permissions available থাকে, সেখানে Plan mode-কে bypassing হিসেবে গণনা করা হয়। এরপর নিয়মটি উভয় দিকেই একইভাবে প্রযোজ্য:

• যে receiving session permission prompt দেখায়, সেখানে প্রতিটি বার্তা deliver করা হয়। sending session নিজেকে prompting bypass করছে বলে শনাক্ত করলেই কেবল সেটি held রাখা হয়।
• যে receiving session prompting bypass করে, সেখানে আপনার approval-এর জন্য প্রতিটি বার্তা held রাখা হয়। sender-ও bypassing হলেই কেবল একটি বার্তা deliver করা হয়।

তাই অধিকাংশ মানুষ যে প্রথম workflow তৈরি করে, সেটিই কাজ করে না। আপনি unattended চালানোর জন্য --permission-mode bypassPermissions দিয়ে একটি builder শুরু করেন, reviewer-কে default settings-এ রাখেন, এবং builder-এর পাঠানো প্রতিটি বার্তা এমন একটি approval dialog-এ অপেক্ষা করতে থাকে যা কেউ দেখছে না। dialogExpiry deadline পার হলে dialog-টি বন্ধ হয়ে যায়; এর default value হলো 5m, এবং বার্তাটি বাতিল হয়ে যায়। একই machine-এ sending session তার বার্তা held হলে একটি notice পায়, এবং receiver পরে সেটি deliver, deny বা expire করলে একটি follow-up পায়। তাই socket-কে দোষ দেওয়ার আগে sender-এর screen দেখুন।

কোনো session-কে unattended অবস্থায় বার্তা গ্রহণ করাতে crossSessionInbound-এর value accept সেট করুন। কোথায় সেট করছেন, তার ওপর এটি কোথায় প্রযোজ্য হবে তা নির্ভর করে। Claude Code প্রথমে managed settings, এরপর --settings flag, তারপর user settings পড়ে এবং প্রথম যে value খুঁজে পায় সেটিই প্রয়োগ করে। project বা local settings-এর কোনো value কেবল তখনই প্রযোজ্য হয় যখন সেটি accept < hold < refuse ladder অনুযায়ী আরও কঠোর হয়। .claude/settings.json-এ থাকা accept যেকোনো value-এর চেয়ে looser, তাই trusted source কোনো value সেট করলে এটি উপেক্ষা করা হয়। এটি ~/.claude/settings.json-এ রাখুন, অথবা একটি session-এর জন্য pass করুন:

claude --name runner --settings '{"crossSessionInbound":"accept"}'

একটি headless claude -p worker interactive session-এর মতো inbox socket bind করে এবং listing-এ দেখা যায়, কিন্তু এটি approval dialog দেখাতে পারে না। সেখানে held message পরবর্তী কোনো mode বা settings change সেটি allow না করা পর্যন্ত held থাকে। উপরের --settings line-ই এমন worker-কে বার্তা গ্রহণ করতে দেওয়ার পদ্ধতি। bare mode-এ শুরু করা session কোনো socket bind করে না, তাই এটি বার্তা receive করতে বা list-এ দেখা যেতে পারে না।

যেখানে hand-off deadlock তৈরি হয়

Message loop আপনার জন্য পরিচালিত হয়। Claude Code প্রতিটি sender-এর repeated message-এর rate limit প্রয়োগ করে, অল্প সময়ের মধ্যে আসা identical repeat বাতিল করে এবং প্রতি session-এ পড়ার অপেক্ষায় থাকা accepted message-এর সংখ্যা 50-এ সীমাবদ্ধ রাখে। তাই দুটি session অনির্দিষ্টকাল ping-pong করতে পারে না। Held message-এর সীমা 100; এই সীমা ছাড়ালে সবচেয়ে পুরোনোগুলো বাদ পড়ে।

যে failure বাস্তবে ঘটে, তা আরও নীরব এবং এটি loop নয়, hand-off। Session A চালিয়ে যাওয়ার আগে প্রয়োজন এমন একটি প্রশ্ন Session B-কে করে, তারপর idle হয়ে যায়। B message ধরে রাখে, অথবা দীর্ঘ কোনো কাজের মাঝখানে থাকে, অথবা A আসলে যে প্রশ্ন করেনি তার উত্তর দেয়। A অপেক্ষা করে। এক ঘণ্টা পরে ফিরে এসে আপনি দুটি idle session দেখতে পান, কিন্তু কোনো কাজ সম্পন্ন হয়নি।

এমন hand-off লিখুন যার reply প্রয়োজন হয় না। ভালো message-এ একটি fact বা decision থাকে: কী পরিবর্তন হয়েছে এবং ফলাফল কী হয়েছে। খারাপ message-এ অন্য session-এর কাছে permission চাওয়া হয়, অথবা sender যে উত্তরের ওপর নির্ভরশীল এবং যার কারণে কাজ আটকে আছে, সেই উত্তর চাওয়া হয়। Claude-কে ইতিমধ্যে নির্দেশ দেওয়া আছে যে অন্য session-এর কাছে এমন action চাইবে না, যা তার নিজের permission settings-এর কারণে blocked হবে; এর বদলে সেই কাজ আপনার কাছে ফিরিয়ে দেবে। এই নিয়মটি নিজেও প্রয়োগ করুন। কোনো session উত্তর ছাড়া অগ্রসর হতে না পারলে, উত্তরটি আপনারই দেওয়া উচিত। Context discipline এখানেও সহায়ক। কারণ thread হারিয়ে ফেলা session সাধারণত অস্পষ্ট message লেখে; Claude Code-এ context পরিচালনা এই দিকটি ব্যাখ্যা করে।

আগত বার্তাকে অবিশ্বস্ত ইনপুট হিসেবে বিবেচনা করুন

Claude Code গ্রহণকারী Claude-কে জানায় যে বার্তাটি আপনার কাছ থেকে নয়, অন্য একটি session থেকে এসেছে। এটি ওই বার্তাটি কী করতে পারে, তাও সীমিত করে। অন্য একটি session-এর সম্মতি আপনার সম্মতি নয়। তাই কোনো বার্তা আপনার পক্ষ থেকে অপেক্ষমাণ permission prompt-এর উত্তর দিতে পারে না। অন্য একটি session অনুরোধ করলেও এটি permission setting, CLAUDE.md বা অন্য কোনো configuration পরিবর্তন করতে পারে না। পাঠ্যের ভেতরের slash command, যেমন /compact, plain text হিসেবেই আসে এবং কখনো execute হয় না। বার্তাটি কার্যকর করতে receiving session-এর কাছে কোনো permission না থাকলে, অন্য যেকোনো কাজের মতো একই prompt দেখা যায়। auto mode-এ delivery-এর আগে একটি classifier প্রতিটি বার্তাও পরীক্ষা করে। classifier কোনো বার্তা block করলে সেটি recipient-এর কাছে পৌঁছায় না। এই সীমাগুলো permissive mode-এও কার্যকর থাকে। তাই bypass করা session inbound message-কে default হিসেবে ধরে রাখে, বিশ্বাস করে না।

এটি permission-এর বিষয়টি ব্যাখ্যা করে। তবে content-এর বিষয়টি ব্যাখ্যা করে না। sending session হয়তো কোনো অপরিচিত ব্যক্তির লেখা pull request description, web page, dependency README বা issue comment পড়েছে। সে যা পড়েছে, তা আপনার অন্য session-এ পাঠানো text-কে প্রভাবিত করতে পারে। বার্তাটি data। session-এর বাইরে থেকে আসা অন্য যেকোনো text-এর মতো এটিকেও সন্দেহের চোখে দেখুন। আপনার AI agent-এর বাইরে secret রাখুন-এ বর্ণিত নিয়মটি অনুসরণ করুন: trust boundary অতিক্রম করা যেকোনো কিছু ভুল হতে পারে ধরে নিন, এবং কখনো সেটিকে নিজেকে authorise করার সুযোগ দেবেন না।

এ ধরনের বার্তা কমাতে চাইলে 2টি control ব্যবহার করতে পারেন। crossSessionInbound-কে refuse-এ সেট করলে inbound peer message delivery ছাড়াই বাতিল হয়। project বা local setting থেকে এই value সেট করলে তা অন্য সব source-এর ওপর প্রাধান্য পায়, কারণ এটি ladder-এর সবচেয়ে strict অবস্থান। এই session যেন message পাঠাতে বা message-এর তালিকা দেখাতে না পারে, তার জন্য SendMessage এবং ListAgents-এর নাম উল্লেখ করে permission deny rule যোগ করুন। উভয়টিই কোনো specifier ছাড়া bare tool name হিসেবে লিখতে হবে। isolatePeerMachines-কে true-এ সেট করলে এই machine-এর বাইরে থাকা কোনো session-এ message পৌঁছানোর আগে আপনার explicit approval প্রয়োজন হয়। bypassPermissions mode-এও এই approval প্রয়োজন।

{
  "crossSessionInbound": "refuse",
  "isolatePeerMachines": true
}

SendMessage deny করলেও subagent-এ messaging বন্ধ হয়, কারণ উভয়ের জন্য একই tool ব্যবহৃত হয়। কোনো session message প্রত্যাখ্যান করলে তার নিজের /status-এ বা অন্য session-এর listing-এ দৃশ্যমান কোনো পরিবর্তন দেখা যায় না। তাই screen দেখে নয়, session-এর configuration পরীক্ষা করে setting নিশ্চিত করুন।

ব্রিজ এবং শেয়ার করা মেমরি MCP সার্ভার

একই সময়ে কয়েকটি third-party project কাছাকাছি ধরনের কাজ নিয়ে এসেছে: local agent-to-agent bridge, যা চলমান agent-গুলোর মধ্যে text relay করে, এবং MCP (model context protocol) server, যা একাধিক agent-কে পড়া ও লেখার জন্য একটি shared store ব্যবহার করতে দেয়। এগুলোকে প্রতিদ্বন্দ্বী না ভেবে ভিন্ন ধরনের সমাধান হিসেবে মূল্যায়ন করুন। কোনো install command চালানোর আগে সংশ্লিষ্ট project-এর নিজস্ব README-র সঙ্গে তা যাচাই করুন। Messaging হলো push, কারণ sender receiver-এর turn-এ text ঢুকিয়ে দেয়। Shared store হলো pull, কারণ এতে কাউকে interrupt করা হয় না এবং session পরবর্তীবার note দেখতে গেলে তা পায়। ধীরে পরিবর্তিত status-এর জন্য pull বেশি শান্তিপূর্ণ। তবে এটি কেবল তখনই কাজ করে, যখন কোনো session সত্যিই তা দেখে।

আপনি যদি এই পদ্ধতি বেছে নেন, তাহলে feature list-এর বদলে process নিয়ে প্রশ্ন করা বেশি গুরুত্বপূর্ণ। Server কোন user হিসেবে চলে, এবং সার্ভারের host-এ এটি কী কী পড়তে পারে? VPS-এ MCP server চালানো-এ এই setup বর্ণনা করা হয়েছে। repo-গুলোর মধ্যে agent skill share করা-এ সেই সহজ পরিস্থিতি ব্যাখ্যা করা হয়েছে, যেখানে session-গুলোর মধ্যে আপনি live state নয়, instructions share করতে চান। এতে অন্যথায় পাঠাতে হতো এমন অনেক message বাদ দেওয়া যায়। বৃহত্তর প্রেক্ষাপটের জন্য VPS-এ coding agent চালানো দিয়ে শুরু করুন।

FAQ

/list-agents আমার সেশনে স্বীকৃত হচ্ছে না কেন?

সেশনে cross-session messaging সক্রিয় নেই। প্রথমে claude --version-এর মান 2.1.224 বা তার পরের সংস্করণ কি না যাচাই করুন, কারণ এই সুবিধার জন্য ওই সংস্করণ বা পরের সংস্করণ প্রয়োজন। এরপর platform যাচাই করুন, কারণ এটি macOS ও Linux-এ চলে, কিন্তু native Windows-এ চলে না। এছাড়া Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform এবং Microsoft Foundry-তেও এটি উপলভ্য নয়। উভয়ই ঠিক থাকলে shell-এ DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC অথবা DISABLE_GROWTHBOOK আছে কি না দেখুন। এগুলোর প্রতিটি feature-flag evaluation বন্ধ করে দেয়, যার ওপর এই সুবিধাটি নির্ভর করে, ফলে এটি বন্ধ থাকে।

অন্য সেশনে পাঠানো আমার message কখনও পৌঁছাল না কেন?

/list-agents কাজ করলে messaging সক্রিয় আছে এবং আরও নির্দিষ্ট কোনো কারণে ওই message আটকে গেছে। সাধারণ কারণ হলো permission mode। যে session permission prompt bypass করে, সেটি প্রতিটি inbound message আপনার অনুমোদনের জন্য আটকে রাখে, যদি প্রেরকও bypass না করে। dialogExpiry deadline পার হলে, যা ডিফল্টভাবে five minutes, সেই approval dialog বাতিল হয়ে যায়। প্রেরণকারী session-এ held notice দেখুন। সমাধানের জন্য ~/.claude/settings.json-এ crossSessionInbound-এর মান accept সেট করুন, অথবা --settings দিয়ে এটি pass করুন। কারণ project বা local settings-এ থাকা কোনো accept বেশি শিথিল মান হলে তা উপেক্ষা করা হয়।

Docker-এর একটি Claude Code session কি host-এর একটি session-এ message পাঠাতে পারে?

না। Session-গুলো disk-এ থাকা registration file এবং প্রতি-session inbox socket-এর মাধ্যমে একে অপরকে খুঁজে পায়। Container-এর নিজস্ব filesystem থাকে, তাই দুটি session একই file দেখতে পারে না। একই container-এর ভেতরের দুটি session স্বাভাবিকভাবে একে অপরকে message পাঠাতে পারে। একই নিয়মের কারণে root হিসেবে চলা একটি session এবং আপনার normal user হিসেবে চলা একটি session একে অপরের কাছে পৌঁছাতে পারে না। কারণ socket-টি সেটির মালিক operating system user-এর জন্য সীমাবদ্ধ।

অন্য Claude Code session থেকে আসা message কি নিরাপদে অনুসরণ করা যায়?

Text-টিকে untrusted input হিসেবে বিবেচনা করুন, কারণ প্রেরণকারী session কোনো web page, README অথবা অন্য কারও লেখা issue comment পড়ে থাকতে পারে। Claude Code নিজে থেকেই message-টিকে সরাসরি কাজ করার ক্ষমতা থেকে বিরত রাখে। এটি pending permission prompt অনুমোদন করতে পারে না, অনুরোধের ভিত্তিতে permission settings বা CLAUDE.md পরিবর্তন করতে পারে না, এবং text-এর মধ্যে থাকা slash command plain text হিসেবে আসে ও কখনও চালু হয় না। এই সুরক্ষাগুলো permissions নিয়ন্ত্রণ করে, judgement নয়। তাই receiving session-কে কাজ করতে বলার আগে আসা text পড়ে নিন।

Cross-session messaging কি আমার code Anthropic-এ পাঠায়?

একই machine-এর দুটি session-এর মধ্যে হলে না। Message ওই machine-এর প্রতি-session socket দিয়ে যায় এবং কখনও Anthropic server-এর মধ্য দিয়ে যায় না। শুধু Claude যে text লিখেছে সেটিই পাঠানো হয়; conversation history বা file কখনও পাঠানো হয় না। আপনার অন্য কোনো machine-এর session-এ, অথবা web-এর কোনো session-এ পাঠানো message Anthropic server-এর মধ্য দিয়ে Remote Control connection ব্যবহার করে যায়। ওই দিকের ক্ষেত্রে Claude শুধু আসা message-এর উত্তর দিতে পারে, নিজে থেকে message শুরু করতে পারে না। Machine-এর বাইরে কিছু পাঠানোর আগে আপনার অনুমোদন বাধ্যতামূলক করতে isolatePeerMachines-এর মান true সেট করুন।