অ্যানথ্রোপিক Claude Code-এর জন্য ক্রস-সেশন মেসেজিং এক্সপেরিমেন্টাল ফিচার চালু করেছে, যা বিভিন্ন সেশনের মধ্যে সরাসরি বার্তা পাঠানোর অনুমতি দেয়। এই ফিচারটি পূর্ণাঙ্গ কনটেক্সট পাঠায় না, শুধুমাত্র টাস্কের ফলাফল এবং নির্ভরশীলতা তথ্য পাঠায়, যা ListAgents এবং SendMessage দুটি অভ্যন্তরীণ টুলের মাধ্যমে বাস্তবায়িত। প্রতিটি স্থানীয় সেশন ডিস্কে রেজিস্টার্ড হয় এবং Inbox Socket-এর সাথে বাঁধা থাকে, স্থানীয় বার্তা সরাসরি Socket-এর মাধ্যমে প্রেরিত হয়, আর মেশিনের বাইরের বার্তা Anthropic Server-এর মাধ্যমে প্রেরিত হয়। বার্তা সেশন Idle-এর সময় নতুন Turn-এর জন্য ট্রিগার হয়, এবং Active Turn-এর মধ্যে Tool Call-এর মধ্যবর্তী সময়ে পড়া হয়। গ্রহণকারীপক্ষ Cross-Session বার্তা এবং User Message-কে আলাদাভাবে চিহ্নিত করে, যা ব্যবহারকারীর অনুমতির বিকল্প হতে পারে না, এবং accept/hold/refuse—এই তিনটি Inbound Control মোড সেটআপ করা হয়েছে। এই ফিচারটি Resume Session, Agent Teams, Worktree—এইসব existing capability-এর সাথে মিলেকাজ করে Claude Code-এর জন্য Session-এর মধ্যে কোঅর্ডিনেশন লেয়ার প্রদান করে।

লেখক এবং উৎস: লেইফেঙ্গওয়েন

এই কয়দিনে, Anthropic Claude Code-এ একটি নতুন পরীক্ষামূলক ক্ষমতা যোগ করেছে: ক্রস-সেশন মেসেজিং, অর্থাৎ সেশনের মধ্যে বার্তা পাঠানো।

সহজ কথায়, এটি আপনাকে একসাথে চলমান একাধিক Claude Code Session-এর মধ্যে সরাসরি বার্তা পাঠাতে সক্ষম করে।

ধরুন আপনি 3টি Claude Code সেশন খুলেছেন: একটি ডাটাবেসের জন্য, একটি ব্যাকএন্ড API-এর জন্য এবং একটি টেস্টিং-এর জন্য। আগে এই 3টি সেশন সমান্তরালে কাজ করতে পারত, কিন্তু একে অপরের কোথায় পৌঁছেছে তা জানত না। ডাটাবেস সেশন স্কিমা পরিবর্তন করার পরে, সাধারণত ডেভেলপারকে আরেকটি টার্মিনালে স্যুইচ করে পরিবর্তনগুলি পুনরায় ব্যাকএন্ড সেশনকে জানাতে হত।

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

এটি কী করে তা বুঝতে, একটি বার্তার সম্পূর্ণ পথ অনুসরণ করুন: এটি কী পাঠায়, লক্ষ্যটি কীভাবে খুঁজে পায়, বার্তাটি কখন Claude-এ প্রবেশ করে, এবং গ্রহণকারী কেন সরাসরি এটি করতে পারে না।

01 কনটেক্সট নয়, একটি বার্তা

ক্রস-সেশন মেসেজিং ক্লেড কোডের মূল সেশন আইসোলেশনকে পরিবর্তন করেনি।

সেশন A সেশন B-এ বার্তা পাঠানোর সময়, তার কনভারসেশন হিস্ট্রি, পড়া ফাইল বা সম্পূর্ণ কনটেক্সট উইন্ডো একসাথে পাঠায় না। অফিসিয়াল নিয়ম অনুযায়ী, সেশনের মধ্যে শুধুমাত্র টেক্সট পাঠানো হয়। যদি সম্পূর্ণ কথোপকথন এবং কনটেক্সটকে অন্য একটি ডিভাইসে স্থানান্তর করতে চান, তাহলে Cross-session messaging-এর পরিবর্তে মূল সেশনটি Resume করুন।

এটি বিভিন্ন Claude-এর মধ্যে সহযোগিতার পদ্ধতি নির্ধারণ করে।

ডাটাবেস সেশন মিগ্রেশন সম্পন্ন করতে দশগুণ ফাইল পড়েছে এবং কয়েকটি পদ্ধতি চেষ্টা করেছে, শেষ পর্যন্ত একটি ক্ষেত্র পরিবর্তনের সিদ্ধান্ত নিয়েছে। ব্যাকএন্ড সেশনের পূর্ববর্তী সমস্ত বিশ্লেষণের প্রয়োজন নেই; এটিকে শুধুমাত্র চূড়ান্ত পরিবর্তনগুলি এবং এই পরিবর্তনগুলি এর API-কে কীভাবে প্রভাবিত করবে তা জানার প্রয়োজন।

অতএব, ক্রস-সেশন মেসেজিং পূর্ণ কাজের স্মৃতি নয়, বরং কাজের ফলাফল এবং নির্ভরশীলতার তথ্য প্রেরণ করে।

এর সুবিধা হলো, বিভিন্ন কাজ থেকে উৎপন্ন স্থানীয় তথ্য অন্যান্য সেশনের মধ্যে নিয়মিত প্রবাহিত হবে না। ডাটাবেস-সংক্রান্ত বিস্তারিতগুলি ডাটাবেস সেশনে রাখা যেতে পারে, টেস্টিং প্রক্রিয়াগুলি টেস্টিং সেশনে রাখা যেতে পারে, এবং শুধুমাত্র যখন কোনো পরিবর্তন অন্যান্য কাজকে প্রভাবিত করতে শুরু করে, তখনই সংশ্লিষ্ট তথ্যগুলি সেশনের সীমানা পার হয়।

এটি "সমস্ত এজেন্ট একটি বড় কনটেক্সট শেয়ার করে" এর সাথে দুটি ভিন্ন ধারণা। ক্রস-সেশন মেসেজিং সেশনগুলিকে স্বাধীন রাখে এবং কাজগুলির মধ্যে নির্ভরশীলতা তৈরি হলে প্রয়োজনীয় অবস্থা প্রকাশ্যে সিঙ্ক্রোনাইজ করে।

যেহেতু একটি স্পষ্ট বার্তা প্রেরণ করা হয়েছে, পরবর্তী প্রশ্নটি হল: সেশন A কীভাবে সেশন B খুঁজে পাবে?

02 অন্য একটি সেশন খুঁজে বার করতে হবে

ক্লড কোড ক্রস-সেশন মেসেজিং সমর্থনকারী সেশনে নিজের যোগাযোগ এন্ট্রি যোগ করেছে।

প্রতিটি স্থানীয় সেশন সংশ্লিষ্ট তথ্য ডিস্কে রেজিস্টার করে এবং একটি ইনবক্স সকেট বাঁধে। Claude ListAgents ব্যবহার করে বর্তমানে যোগাযোগযোগ্য সেশনগুলি খুঁজে পায়, তারপর SendMessage ব্যবহার করে নির্দিষ্ট লক্ষ্যে বার্তা পাঠায়।

ব্যবহারকারীদের এই অভ্যন্তরীণ টুলগুলি নিজেদের দ্বারা পরিচালনা করার প্রয়োজন নেই, শুধুমাত্র Claude-কে বলুন যে কোন সেশনের সাথে যোগাযোগ করতে চান, অথবা এটিকে কাজের উপর নির্ভরশীলতা তৈরি হলে স্বয়ংক্রিয়ভাবে অপরকে নোটিফাই করতে বলুন।

সেশনের নাম এখন ঠিকানা নির্ধারণে অংশগ্রহণ করে। ক্লড নামের ভিত্তিতে লক্ষ্য খুঁজে পায়; যদি নামগুলি পুনরাবৃত্ত হয়, তবে সিস্টেম সংক্ষিপ্ত পরিচয়করণ যোগ করে এবং প্রতিটি সেশন কোন প্রকল্প বা ডিরেক্টরি প্রক্রিয়াকরণ করছে তা বুঝতে কাজের ডিরেক্টরি দেখায়।

লক্ষ্য খুঁজে পাওয়ার পর, স্থানীয় বার্তাগুলি সংশ্লিষ্ট সেশনের সকেটের মাধ্যমে প্রেরিত হয়, যা Anthropic সার্ভারের মাধ্যমে পাঠানোর প্রয়োজন হয় না। অন্য কোনো মেশিন বা Claude Code Web-এর সেশনগুলি কেবলমাত্র Anthropic সার্ভার এবং রিমোট কন্ট্রোল সংশ্লিষ্ট কানেকশনের মাধ্যমে যোগাযোগ করে।

এই আবিষ্কার ব্যবস্থা স্থানীয় যোগাযোগের সীমানা নির্ধারণ করে।

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

ইনবক্স সকেট অপারেটিং সিস্টেমের ব্যবহারকারী অনুমতির সীমাবদ্ধতার অধীনে, শেয়ারড সার্ভারের অন্যান্য OS ব্যবহারকারীরা আপনার সেশনে সরাসরি অ্যাক্সেস করতে পারবেন না।

সুতরাং এখানে উল্লিখিত “স্থানীয় যোগাযোগ” বাস্তবে রেজিস্ট্রেশন তথ্য দৃশ্যমান কিনা, সকেট অ্যাক্সেসযোগ্য কিনা এবং অপারেটিং সিস্টেম অ্যাক্সেসের অনুমতি দেয় কিনা এর উপর নির্ভর করে।

বার্তাটি এখন লক্ষ্যে পৌঁছে গেছে এবং ইনবক্সে পাঠানো হয়েছে, এখন ক্লড কোডের রানটাইমের পালা: এই বার্তাটি কখন মডেলের কাছে পাঠাবে।

03 তথ্য পৌঁছানোর পর

ধরুন ব্যাকএন্ড সেশন ফাইলটি পরিবর্তন করছে, এই সময় টেস্টিং সেশন একটি বার্তা পাঠিয়েছে যে এটি একটি ইন্টারফেস রিগ্রেশন সমস্যা আবিষ্কার করেছে।

ক্লড কোড চলমান টুলকে তাত্ক্ষণিকভাবে বন্ধ করবে না।

যদি লক্ষ্য সেশন ইডল অবস্থায় থাকে, তবে বার্তাটি একটি নতুন টার্ন ট্রিগার করতে পারে; যদি Claude ইতিমধ্যে একটি এক্টিভ টার্ন-এ থাকে, তবে বার্তাটি দুটি টুল কলের মধ্যে পড়ার জন্য অপেক্ষা করবে।

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

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

এর অর্থ হলো Cross-session messaging এখন Claude Code-এর Agentic Loop-এ যুক্ত হয়েছে এবং এটি একটি অ্যাসিঙ্ক্রোনাস ইনপুট সোর্স হয়ে উঠেছে। এই ইনপুট শুধুমাত্র অন্যান্য Claude Session-এর জন্যই সীমাবদ্ধ নয়।

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

এই চ্যানেলটি নিজেই একটি নির্ভরযোগ্য মেসেজ কিউ নয়। পুনরাবৃত্ত মেসেজগুলি লিমিট করা হবে, এবং সংক্ষিপ্ত সময়ের মধ্যে একই কনটেন্ট বাদ দেওয়া যেতে পারে; যে মেসেজগুলি ইতিমধ্যে গ্রহণ করা হয়েছে কিন্তু Claude এখনও পড়েনি, প্রতিটি সেশনে সর্বোচ্চ ৫০টি রাখা হবে, এবং Hold অবস্থায় যাওয়া মেসেজগুলির জন্য আলাদা বাফার ব্যবহার করা হবে, যা সর্বোচ্চ ১০০টি মেসেজ রাখতে পারে।

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

মেসেজ রানটাইমে প্রবেশ করার পরেও এটিকে সরাসরি কার্যক্রমে রূপান্তরিত করা যায় না, কারণ গ্রহণকারীকে প্রথমে বিচার করতে হবে: অন্য ক্লাউড দ্বারা প্রেরিত কনটেন্টটির প্রকৃতপক্ষে কতটা অধিকার রয়েছে।

04 অনুমতি কীভাবে উত্তরাধিকারসূত্রে প্রাপ্ত হয়

Claude Code ব্যবহারকারীর বার্তা এবং পিয়ার সেশন বার্তা স্পষ্টভাবে পৃথক করে।

অন্য একটি সেশন থেকে আসা কন্টেন্টকে ব্যবহারকারীর অনুমতি হিসাবে বিবেচনা করা হবে না, তাই ব্যবহারকারীর পক্ষে পারমিশন প্রম্পট অনুমোদন করা যাবে না, এবং বার্তার মাধ্যমে গ্রহণকারীকে পারমিশন সেটিংস, CLAUDE.md বা অন্যান্য কনফিগারেশন পরিবর্তনের জন্য অনুরোধ করা যাবে না। বার্তায় Claude Code Command থাকলেও তা শুধুমাত্র সাধারণ টেক্সট হিসাবে প্রক্রিয়া করা হবে।

ধরুন, সেশন A সেশন B কে একটি ফাইল মুছে ফেলার অনুরোধ করে, এবং এই অপারেশনটি সেশন B-এ ব্যবহারকারীর অনুমতি প্রয়োজন, তাহলে মূল অনুমতি প্রম্পটটি এখনও দেখানো হবে।

ক্লড কোড অন্য একটি অনুমতি পারিপার্শ্বিক উপায়কেও সীমাবদ্ধ করে: যদি কোনো অপারেশনটি বর্তমান সেশনে পারমিশন সিস্টেম দ্বারা অস্বীকৃত হয়ে থাকে, তবে ক্লড অন্য একটি সেশনের মাধ্যমে নিজের জন্য এটি চালানোর জন্য অনুরোধ করবে না।

অন্যথায়, শুধু কয়েকটি সেশনের অনুমতি ভিন্ন হলেই, নিম্ন অনুমতি সম্পন্ন সেশনগুলি নিজেদের করতে অক্ষম অপারেশনগুলি উচ্চ অনুমতি সম্পন্ন সেশনগুলিকে হস্তান্তর করতে থাকবে, যার ফলে মূল অনুমতি সীমানা বাতিল হয়ে যাবে।

অনুমতির বাইরে, বার্তাটির একটি অতিরিক্ত Inbound Control স্তর রয়েছে। গ্রহণকারী সেশন-পার্থক্যযুক্ত বার্তাগুলিকে accept、hold বা refuse হিসাবে সেট করতে পারে: সরাসরি Claude-এর কাছে পাঠানো, আরও নিশ্চিতকরণের জন্য সময়সীমা ধরে রাখা, বা সরাসরি বাতিল করা।

যদি ব্যবহারকারী স্পষ্টভাবে নিয়ম কনফিগার না করেন, তবে Claude Code প্রেরক এবং গ্রহীতার বর্তমান Permission Mode-এর সন্দর্ভ নেয়। সাধারণ Permission Prompt-কে পার করার ক্ষমতা থাকা Session-টি সাধারণ Session-এর সঙ্গে সম্পূর্ণভাবে একই মেসেজ সোর্স হিসেবে বিবেচিত হয় না; যখন গ্রহীতার নিজস্ব অনুমতি উচ্চতর হয়, তখন বাহ্যিক মেসেজগুলি একইভাবে Hold-এ প্রবেশ করতে পারে।

এখানে আসলে দুটি নির্ণয় রয়েছে: প্রথমে সিদ্ধান্ত নিন যে বার্তাটি ক্লাউডে প্রবেশ করতে পারে কিনা, তারপর সিদ্ধান্ত নিন যে ক্লাউড এই বার্তার ভিত্তিতে যে কার্যটি সম্পাদনের প্রস্তুতি নিচ্ছে তার অনুমতি আছে কিনা।

এই পদক্ষেপের মাধ্যমে একটি ক্রস-সেশন বার্তার সম্পূর্ণ পথ সম্পন্ন হয়েছে: বার্তা তৈরি, লক্ষ্য খুঁজে পাওয়া, বিতরণ সম্পন্ন করা, রানটাইমের মাধ্যমে বার্তা পড়া, এবং গ্রহণকারীর নিজস্ব অনুমতি নিয়ন্ত্রণের মাধ্যমে।

05 সেশনের মধ্যে সমন্বয় স্তর

এই লিঙ্কটিকে ক্লড কোডের বর্তমান সক্ষমতার মধ্যে ফিরিয়ে আনা হলে, ক্রস-সেশন মেসেজিংয়ের অবস্থানটি পরিষ্কার হয়ে যায়।

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

ক্রস-সেশন মেসেজিং একটি অন্যান্য পরিস্থিতি প্রক্রিয়া করে: কয়েকটি মূলত স্বাধীনভাবে চলমান সেশন, যেগুলো কাজের সময় পরস্পরের উপর নির্ভরশীল হয়ে যায়, সেগুলোর মধ্যে প্রয়োজনীয় তথ্য কীভাবে প্রেরণ করা হয়।

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

ক্রস-সেশন মেসেজিং একাধিক Claude কে একটি এজেন্টে সংযুক্ত করেনি, বরং মূল Context, কাজের ডিরেক্টরি এবং অনুমতির সীমানার বাইরে একটি যোগাযোগের ক্ষমতা যোগ করেছে।

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

যখন এজেন্টের সংখ্যা বাড়তে থাকবে, তখন প্রশ্নটি ধীরে ধীরে “একটি এজেন্ট কতটা করতে পারে” থেকে “এই এজেন্টগুলির মধ্যে স্থিতিশীলভাবে অবস্থা, নির্ভরশীলতা এবং হস্তান্তর বিনিময় করা যাবে কি”-এ পরিণত হবে।

ক্রস-সেশন মেসেজিং যদিও শুধু একটি ধাপ সমাধান করেছে, তবুও এটি Claude Code-এর মাল্টি-সেশন কাজের পদ্ধতিকে আরও সম্পূর্ণ ইঞ্জিনিয়ারিং কাঠামো দিয়েছে। ভবিষ্যতে, এই লোকাল নেটওয়ার্কের মধ্যে ক্রস-সেশন মেকানিজম যদি মেশিন-পার্থক্য এবং ইকোসিস্টেম-পার্থক্যের মধ্যে Agent-to-Agent কমিউনিকেশন প্রোটোকলে পরিণত হয়, তবে আজকের এই দুটি Claude-এর মধ্যকার সংক্ষিপ্ত কথোপকথনই উচ্চ-স্বয়ংক্রিয় সফটওয়্যার ফ্যাক্টরির গঠনের জন্য একটি গুরুত্বপূর্ণ পদক্ষেপ হবে।