Claude Code session-এ একে অপরকে বার্তা পাঠাবেন কীভাবে

Claude Code session-গুলো একে অপরকে বার্তা পাঠালে এর অর্থ

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

এই 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 আগে থেকেই enabled থাকে; আলাদা করে কিছু enable করতে হয় না। নিচের আচরণটি cross-session messaging নিয়ে Anthropic documentation থেকে নেওয়া।

VPS-এ এই feature-এর ব্যবহার গুরুত্বপূর্ণ, কারণ session-গুলো সেখানে দীর্ঘ সময় চলে এবং সেগুলোকে বার্তা পাঠানোর প্রয়োজন হয়। 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-এর প্রায় দ্বিগুণ খরচ হয়। Claude যে message পাঠায়, সেটিও আপনার টাইপ করা prompt-এর মতোই usage-এর মধ্যে গণনা হয়। Coordination বিনামূল্যে নয়। প্রকৃতপক্ষে একটিই ধারাবাহিক ধাপের কাজকে একাধিক session-এ ভাগ করলে তা ধীর এবং ব্যয়বহুল হয়।

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

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

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

ব্যবহার করার পরিকল্পনা করার আগে feature-টি আছে কি না যাচাই করুন

প্রথমে version দেখুন:

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 অবস্থায় বন্ধ থাকে। 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 behaviour চালু করে, যার মধ্যে 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 পড়ার প্রয়োজন হয় না।

পুনরুৎপাদনযোগ্য দুই-session tmux layout

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

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 চালান। সেখানে ~/src/api-review working directory-সহ reviewer-api দেখতে পাওয়ার কথা। এটি না থাকলে reviewer session এখনো start হওয়া শেষ করেনি, অথবা পরের section-এর দুটি সমস্যার একটি প্রযোজ্য। এরপর সাধারণ ভাষায় কাজটি পাঠান:

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

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

একটি 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 শুরু করতে পারে না।

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

সাধারণ কারণটির সঙ্গে নেটওয়ার্কের কোনো সম্পর্ক নেই। গ্রহণকারী 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 permission available আছে, সেখানে Plan mode-কে bypassing হিসেবে গণ্য করা হয়। কোনো session কোন class-এ পড়ে তা নিশ্চিত না হলে প্রতিটি permission mode আসলে কী করে আগে পড়ে নেওয়া ভালো। কারণ বর্তমানে অধিকাংশ session auto mode দিয়ে শুরু হয়, আর এই বিভাজনে auto prompting দিকের অন্তর্ভুক্ত। এরপর নিয়মটি symmetric:

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

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

কোনো session-কে unattendedভাবে বার্তা নিতে দিতে crossSessionInbound-কে accept-এ সেট করুন। কোথায় সেট করছেন, তার ওপর এটি কোথায় প্রযোজ্য হবে তা নির্ভর করে। Claude Code প্রথমে managed settings, তারপর --settings flag, এরপর user settings পড়ে এবং প্রথম যে value পায় সেটিই প্রয়োগ করে। Project বা local settings-এর value কেবল তখনই প্রযোজ্য হয়, যখন সেটি accept < hold < refuse ladder অনুযায়ী আরও strict হয়। .claude/settings.json-এ থাকা একটি accept যেকোনো কিছুর চেয়ে 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 থাকা বার্তা পরবর্তী কোনো mode বা settings পরিবর্তনের মাধ্যমে অনুমোদিত না হওয়া পর্যন্ত held-ই থাকে। উপরের --settings line ব্যবহার করেই এমন worker-কে বার্তা নিতে দেওয়া যায়। bare mode-এ শুরু করা session কোনো socket bind করে না। তাই এটি বার্তা receive করতে পারে না এবং list-এও দেখা যায় না।

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

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

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

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

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

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

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

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

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

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

ব্রিজ এবং shared memory MCP server

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

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

FAQ

/list-agents আমার session-এ শনাক্ত হচ্ছে না কেন?

এই session-এ cross-session messaging সক্রিয় নেই। প্রথমে claude --version-এর মান 2.1.224 বা তার বেশি কি না পরীক্ষা করুন, কারণ এই feature-এর জন্য ওই version বা পরের version প্রয়োজন। এরপর 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 বন্ধ করে দেয়, যার ওপর এই feature নির্ভর করে, ফলে এটি off থাকে।

অন্য session-এ পাঠানো আমার message কখনও পৌঁছায়নি কেন?

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

Docker-এর একটি Claude Code session কি host-এ চলা অন্য session-এ message পাঠাতে পারে?

না। Session-গুলো disk-এর registration file এবং প্রতিটি session-এর per-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 হিসেবে বিবেচনা করুন। কারণ sender session কোনো web page, README বা অন্য কারও লেখা issue comment পড়ে থাকতে পারে। Claude Code নিজে থেকেই message-কে স্বয়ংক্রিয়ভাবে কাজ করানো থেকে বিরত রাখে। এটি pending permission prompt approve করতে পারে না, অনুরোধের ভিত্তিতে permission settings বা CLAUDE.md পরিবর্তন করতে পারে না, এবং text-এর slash command plain text হিসেবে আসে ও কখনও চালু হয় না। এই সুরক্ষাগুলো permission-কে নিয়ন্ত্রণ করে, বিচারবোধকে নয়। তাই receiving session-কে কাজ করতে বলার আগে আসা text পড়ে নিন।

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

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