Anthropic ने Claude Code के लिए Cross-session messaging प्रयोगात्मक सुविधा लॉन्च की है, जो विभिन्न Session को सीधे एक दूसरे के साथ संदेश भेजने की अनुमति देती है। यह सुविधा पूर्ण Context को नहीं भेजती, बल्कि केवल कार्य परिणाम और निर्भरता जानकारी को भेजती है, जो ListAgents और SendMessage दो आंतरिक उपकरणों के माध्यम से कार्यान्वित की जाती है। प्रत्येक स्थानीय Session डिस्क पर पंजीकृत होता है और Inbox Socket से बंधा जाता है; स्थानीय संदेश सीधे Socket के माध्यम से भेजे जाते हैं, जबकि बहु-मशीन संदेश Anthropic Server के माध्यम से प्रसारित होते हैं। संदेश Session Idle होने पर नया Turn ट्रिगर करते हैं, जबकि Active Turn में Tool Call के बीच पढ़े जाने का प्रतीक्षा किया जाता है। प्राप्तकर्ता Cross-Session संदेशों को User Message से अलग करता है, यह उपयोगकर्ता अधिकृति का स्थान नहीं ले सकता, और accept/hold/refuse तीन Inbound Control मोड सेट किए गए हैं। यह सुविधा Resume Session, Agent Teams, Worktree आदि मौजूदा क्षमताओं के साथ समन्वयित होती है और Claude Code को Session-के-बीच समन्वय परत प्रदान करती है।

लेखक, स्रोत: लेफेंगवेन

इन दिनों, Anthropic ने Claude Code में एक नई प्रयोगात्मक क्षमता जोड़ी है: क्रॉस-सेशन मैसेजिंग, यानी सेशन के बीच संदेश आदान-प्रदान।

सरल शब्दों में, यह आपको एक साथ चल रहे कई Claude Code सेशन के बीच संदेश भेजने की अनुमति देता है।

उदाहरण के लिए, आपने 3 Claude Code सत्र खोले हैं: एक डेटाबेस के लिए, एक बैकएंड API के लिए, और एक परीक्षण के लिए। पहले ये 3 सत्र समानांतर रूप से काम कर सकते थे, लेकिन वे एक-दूसरे के आगमन के बारे में अनजान थे। डेटाबेस सत्र द्वारा Schema में परिवर्तन करने के बाद, विकासक को अक्सर अपने दूसरे टर्मिनल पर स्विच करके परिवर्तनों को बैकएंड सत्र को पुनः बताना पड़ता था।

क्रॉस-सेशन मैसेजिंग जोड़ने के बाद, यह चरण क्लॉड द्वारा सीधे पूरा किया जा सकता है। डेटाबेस सेशन बैकएंड सेशन को बता सकता है कि कौन से क्षेत्र बदल गए हैं, परीक्षण सेशन द्वारा इंटरफ़ेस रिग्रेशन समस्याएँ पाई जाने पर, परिणाम संबंधित कोड में परिवर्तन कर रहे सेशन को भेजे जा सकते हैं। क्लॉड स्वयं निर्णय ले सकता है कि कब अन्य सेशन को सूचित करने की आवश्यकता है, या विकासकर्ता के अनुरोध पर निर्दिष्ट सेशन से संपर्क कर सकता है।

इसे यह समझने के लिए कि यह वास्तव में क्या करता है, एक संदेश की पूरी यात्रा का पालन करें: यह क्या भेजता है, लक्ष्य कैसे ढूंढता है, संदेश कब Claude में प्रवेश करता है, और स्वीकर्ता क्यों सीधे कार्रवाई नहीं कर सकता।

01

क्रॉस-सेशन मैसेजिंग ने क्लॉड कोड के मूल सेशन आइसोलेशन को नहीं बदला है।

जब सेशन A, सेशन B को संदेश भेजता है, तो अपना संवाद इतिहास, पढ़े गए फ़ाइलें या पूरा कॉन्टेक्स्ट विंडो नहीं भेजता। आधिकारिक नियम के अनुसार, सेशन के बीच केवल पाठ ही स्थानांतरित किया जाता है। यदि पूर्ण संवाद और संदर्भ को दूसरे डिवाइस पर स्थानांतरित करना है, तो क्रॉस-सेशन मैसेजिंग के बजाय मूल सेशन को रिजूम करना चाहिए।

यह कई Claude के बीच सहयोग के तरीके को निर्धारित करता है।

मान लीजिए कि डेटाबेस सेशन को माइग्रेशन पूरा करने के लिए दर्जनों फाइलों को पढ़ना पड़ा और कई योजनाओं का प्रयास किया गया, जिसके बाद अंततः यह निर्णय लिया गया कि किसी फील्ड में परिवर्तन की आवश्यकता है। बैकएंड सेशन को पिछली सभी विश्लेषण प्रक्रियाओं की आवश्यकता नहीं है; इसे केवल अंतिम परिवर्तन और इन परिवर्तनों के अपने API पर क्या प्रभाव पड़ेगा, यह जानना है।

इसलिए, Cross-session messaging के माध्यम से कार्य परिणाम और निर्भरता जानकारी प्रेषित की जाती है, न कि पूर्ण कार्य स्मृति।

इसका फायदा यह है कि विभिन्न कार्यों से उत्पन्न स्थानीय जानकारी अन्य सत्रों में लगातार प्रवाहित नहीं होती। डेटाबेस से संबंधित विवरण डेटाबेस सत्र में रह सकते हैं, परीक्षण प्रक्रिया परीक्षण सत्र में रह सकती है, और केवल तभी जानकारी सत्र सीमा के पार जाती है जब कोई परिवर्तन अन्य कार्यों को प्रभावित करना शुरू होता है।

यह "सभी एजेंट एक साझा बड़ा कॉन्टेक्स्ट शेयर करते हैं" से अलग दृष्टिकोण है। क्रॉस-सेशन मैसेजिंग चुनता है कि सेशन स्वतंत्र रहें, और जब कार्यों में निर्भरता उत्पन्न हो, तो आवश्यक स्थिति को स्पष्ट रूप से समन्वयित किया जाए।

चूंकि एक स्पष्ट संदेश भेजा जा रहा है, अगला प्रश्न यह है: सेशन A, सेशन B कैसे ढूंढे?

02 पहले एक अन्य सेशन ढूंढना होगा

Claude Code ने क्रॉस-सेशन मैसेजिंग को समर्थन करने वाले सेशन के लिए अपना संचार प्रवेश बिंदु जोड़ा।

प्रत्येक स्थानीय सत्र संबंधित जानकारी को डिस्क पर रजिस्टर करता है और एक इनबॉक्स सॉकेट से बांधता है। Claude ListAgents के माध्यम से वर्तमान में संपर्क करने योग्य सत्र ढूंढ सकता है, और फिर SendMessage के माध्यम से संदेश निर्दिष्ट लक्ष्य को भेज सकता है।

उपयोगकर्ता को इन आंतरिक उपकरणों को स्वयं संचालित करने की आवश्यकता नहीं है, बस Claude को बताएं कि वह किस सेशन से संपर्क करना चाहता है, या इसे अपने कार्य में निर्भरता उत्पन्न होने पर स्वयं दूसरे को सूचित करने के लिए कहें।

इसलिए सत्र के नाम को भी पता लगाने में शामिल किया जाता है। क्लॉड नाम के आधार पर लक्ष्य को ढूंढ सकता है; यदि नाम दोहराए जाते हैं, तो सिस्टम अलग करने के लिए छोटा पहचानकर्ता जोड़ देता है, और प्रत्येक सत्र द्वारा किस प्रोजेक्ट या डायरेक्टरी को संभाला जा रहा है, इसे जानने में मदद करने के लिए Working Directory दिखाता है।

लक्ष्य को खोजने के बाद, संबंधित सेशन के माध्यम से स्थानीय संदेश सीधे सॉकेट पर प्रेषित किए जाते हैं, जिससे Anthropic सर्वर की आवश्यकता नहीं होती। दूसरी मशीन या Claude Code Web पर सेशन केवल Anthropic सर्वर और रिमोट कंट्रोल से संबंधित कनेक्शन के माध्यम से संचार करते हैं।

यह खोज तंत्र स्थानीय संचार की सीमाओं को भी निर्धारित करता है।

क्लॉड कोड को डिस्क पर अन्य सेशन द्वारा लिखे गए रजिस्ट्रेशन डेटा को पढ़ने की आवश्यकता होती है, इसलिए दो क्लॉड यदि भौतिक रूप से एक ही कंप्यूटर पर चल रहे हों, लेकिन फाइल सिस्टम एक-दूसरे से अलग हों, तो वे एक-दूसरे को खोजने में असमर्थ हो सकते हैं। एक सामान्य स्थिति Host और स्वतंत्र Container है; यदि दोनों सेशन एक ही Container में चल रहे हैं, तो वे सामान्य रूप से संचार कर सकते हैं।

इनबॉक्स सॉकेट ऑपरेटिंग सिस्टम उपयोगकर्ता अधिकारों के प्रतिबंध के अधीन है, इसलिए शेयर्ड सर्वर पर अन्य OS उपयोगकर्ता आपके सेशन को सीधे नहीं एक्सेस कर सकते।

इसलिए यहाँ उल्लिखित “स्थानीय संचार” वास्तव में रजिस्ट्रेशन जानकारी की उपलब्धता, सॉकेट की उपलब्धता और ऑपरेटिंग सिस्टम द्वारा एक्सेस की अनुमति पर निर्भर करता है।

मैसेज अब लक्ष्य तक पहुंच गया है और इनबॉक्स में भेज दिया गया है, अब Claude Code के Runtime की बारी है: यह तय करे कि इस मैसेज को मॉडल को कब देना है।

03 सूचना पहुँचने के बाद

मान लीजिए कि बैकएंड सत्र फ़ाइल को संशोधित कर रहा है, इस समय परीक्षण सत्र संदेश भेजता है कि उसने एक इंटरफ़ेस रिग्रेशन समस्या का पता लगाया है।

Claude Code चल रहे टूल को तुरंत नहीं रोकेगा।

यदि लक्ष्य सेशन आलस्यावस्था में है, तो संदेश एक नया टर्न शुरू कर सकता है; यदि क्लॉड पहले से ही सक्रिय टर्न में है, तो संदेश दो टूल कॉल के बीच पढ़ा जाएगा।

इसका कारण Coding Agent के कार्यान्वयन से संबंधित है। Claude संभवतः फ़ाइल लिख रहा है, परीक्षण चला रहा है, माइग्रेशन निष्पादित कर रहा है या अन्य समय-लेने वाले कार्यों को संभाल रहा है। यदि बाहरी संदेश किसी भी समय वर्तमान क्रिया को बलपूर्वक बदल सकते हैं, तो आसानी से ऐसा हो सकता है कि उपकरण केवल एक हिस्सा ही निष्पादित करे, जबकि Agent पहले से ही नए जानकारी के आधार पर पुनः योजना बना रहा हो।

इसलिए संदेश Claude के अगले निर्णय को प्रभावित करता है, लेकिन वर्तमान में चल रहे कार्यों को सीधे विस्थापित नहीं करता है।

इसका अर्थ है कि Cross-session messaging को Claude Code के Agentic Loop में एक असिंक्रोनस इनपुट स्रोत के रूप में एकीकृत कर दिया गया है। और यह इनपुट केवल अन्य Claude Session के लिए ही सीमित नहीं है।

Claude Code वर्तमान सेशन के Messaging Socket को Hook और Bash द्वारा शुरू किए गए बच्चे प्रक्रियाओं को प्रदान करता है। एक लंबे समय तक चलने वाले बैकग्राउंड कार्य के समाप्त होने के बाद, यह परिणाम वापस वर्तमान सेशन में भेज सकता है, बिना Claude के इसके पूरा होने की निरंतर जांच किए।

यह चैनल स्वयं एक विश्वसनीय मैसेज क्यू नहीं है। दोहराए गए संदेशों पर लिमिट लगाई जाएगी, और छोटे समय अंतराल में समान सामग्री को हटा दिया जा सकता है; प्रत्येक सेशन में स्वीकार किए गए लेकिन Claude द्वारा अभी तक पढ़े नहीं गए संदेशों को अधिकतम 50 तक रखा जाएगा, जबकि Hold स्थिति में आए संदेशों के लिए एक अलग बफर का उपयोग किया जाएगा, जिसमें अधिकतम 100 संदेश रखे जा सकते हैं।

इसलिए यह स्थिति परिवर्तन, कार्य परिणाम और सहयोग सूचनाएँ भेजने के लिए अधिक उपयुक्त है। लंबे समय तक संग्रहित किए जाने वाले तथ्यों को अभी भी Git, फ़ाइल, डेटाबेस या किसी अन्य स्थायी प्रणाली में दर्ज किया जाना चाहिए।

मैसेज रनटाइम में प्रवेश करने के बाद, इसे सीधे एक्शन में नहीं बदला जा सकता क्योंकि रिसीवर को पहले यह निर्णय लेना होगा कि दूसरा Claude द्वारा भेजा गया सामग्री कितनी अधिकारिता रखता है।

04 अधिकार कैसे विरासत में मिलते हैं

Claude Code यूजर संदेश और पीयर सेशन संदेश को स्पष्ट रूप से अलग करता है।

अन्य सेशन से आने वाली सामग्री को उपयोगकर्ता अधिकृति के रूप में नहीं माना जाएगा, इसलिए इसे उपयोगकर्ता के लिए Permission Prompt को स्वीकृत नहीं किया जा सकता, और न ही संदेश के माध्यम से प्राप्तकर्ता को Permission Settings, CLAUDE.md या अन्य कॉन्फ़िगरेशन बदलने के लिए अनुरोध किया जा सकता है। भले ही संदेश में Claude Code Command शामिल हो, उसे केवल सामान्य पाठ के रूप में ही संभाला जाएगा।

यदि सेशन A सेशन B से एक फाइल हटाने का अनुरोध करता है और इस ऑपरेशन के लिए सेशन B में उपयोगकर्ता अनुमति की आवश्यकता होती है, तो मूल अनुमति प्रॉम्प्ट अभी भी प्रदर्शित होगा।

Claude Code ने एक अन्य अनुमति बाईपास तरीके को भी सीमित किया है: यदि कोई कार्रवाई वर्तमान सत्र में अनुमति प्रणाली द्वारा अस्वीकार कर दी गई है, तो Claude को अपने लिए दूसरे सत्र का अनुरोध नहीं करना चाहिए।

अन्यथा, यदि कुछ सेशन के अधिकार भिन्न हैं, तो कम अधिकार वाला सेशन अपने द्वारा पूरा न किए जा सकने वाले कार्यों को लगातार उच्च अधिकार वाले सेशन को सौंपता रहेगा, जिससे मूल अधिकार सीमाएँ अमान्य हो जाएँगी।

अधिकृत निष्पादन के बाहर, संदेश स्वयं में एक अतिरिक्त Inbound Control होता है। प्राप्तकर्ता एक सत्र से दूसरे सत्र में संदेश को accept、hold या refuse के रूप में सेट कर सकता है: सीधे Claude को सौंप दें, आगे की पुष्टि के लिए अस्थायी रूप से रोक लें, या सीधे अनदेखा कर दें।

यदि उपयोगकर्ता ने स्पष्ट रूप से नियम नहीं बनाए हैं, तो Claude Code भेजने वाले और प्राप्तकर्ता के वर्तमान Permission Mode का भी संदर्भ लेता है। एक सामान्य Permission Prompt को छोड़ने में सक्षम Session, सामान्य Session के समान संदेश स्रोत के रूप में नहीं माना जाता है; जब प्राप्तकर्ता की स्वयं की अधिकृति उच्च होती है, तो बाहरी संदेश भी Hold में पहले आ सकते हैं।

यहाँ वास्तव में दो निर्णय हैं: पहले यह तय करें कि संदेश क्लॉड में प्रवेश कर सकता है या नहीं, फिर यह तय करें कि क्लॉड इस संदेश के आधार पर निष्पादित करने की तैयारी कर रहा कार्रवाई के लिए अधिकार हैं या नहीं।

इस बिंदु तक, एक Cross-session संदेश का पूरा पथ पूरा हो चुका है: संदेश के उत्पादन, लक्ष्य की खोज, डिलीवरी पूरी करने, Runtime द्वारा संदेश पढ़ने, और फिर प्राप्तकर्ता के स्वयं के अधिकार नियंत्रण से गुजरने तक।

05 सेशन के बीच का समन्वय स्तर

इस लिंक को Claude Code की वर्तमान क्षमताओं में वापस रखने से क्रॉस-सेशन मैसेजिंग की स्थिति स्पष्ट हो जाती है।

Resume Session मूल Conversation और Context को जारी रखने के लिए उपयोग किया जाता है, Agent Teams एक सहयोगी Agent समूह बनाने और प्रबंधित करने के लिए उपयोग किया जाता है, Worktree विभिन्न Session के कोड में परिवर्तनों को अलग रखता है, और Remote Control अन्य उपकरणों से Session को नियंत्रित करने की समस्या को हल करता है।

क्रॉस-सेशन मैसेजिंग एक अलग स्थिति को संबोधित करता है: कुछ स्वतंत्र रूप से चल रहे सेशन, जो कार्य के दौरान एक-दूसरे पर निर्भर हो जाते हैं, उनके बीच आवश्यक जानकारी कैसे प्रेषित की जाए।

पहले, कई Claude Code सेशन खोलने से मुख्य रूप से समानांतर समस्याओं का समाधान होता था, लेकिन डेवलपर्स को अभी भी प्रत्येक टर्मिनल की प्रगति का निरीक्षण करना पड़ता था और टास्क स्टेटस को इंसान और सेशन के बीच बार-बार संचारित करना पड़ता था। अब, इंटरफेस में परिवर्तन, परीक्षण परिणाम, माइग्रेशन पूर्ण होना आदि जैसी जानकारी सीधे प्रभावित सेशन पर पहुंच जाती है।

क्रॉस-सेशन मैसेजिंग ने कई Claude को एक एजेंट में नहीं एकीकृत किया है, बल्कि मूल Context, कार्य निर्देशिका और अधिकार सीमाओं के बाहर एक संचार क्षमता जोड़ी है।

बड़े प्रोजेक्ट स्केल पर देखने पर, यह डिज़ाइन एक अलग मल्टी-एजेंट दृष्टिकोण प्रदान करता है: विभिन्न एजेंट्स को बढ़ते हुए कॉन्टेक्स्ट को शेयर किए बिना, स्पष्ट संचार इंटरफ़ेस के माध्यम से सहयोग कर सकते हैं। जब कार्य, स्थिति और अधिकारों को अलग कर दिया जाता है, तो सिस्टम अधिक स्केलेबल हो जाता है।

जब एजेंट की संख्या बढ़ती रहेगी, तो प्रश्न “एक एजेंट कितना कर सकता है” से धीरे-धीरे यह प्रश्न बन जाएगा कि “इन एजेंट्स के बीच स्थिति, निर्भरता और हस्तांतरण को स्थिरता से कैसे आदान-प्रदान किया जाए?”

क्रॉस-सेशन मैसेजिंग हालांकि इसने केवल एक चरण ही हल किया है, लेकिन इसने Claude Code के बहु-सेशन कार्य ढांचे को अधिक पूर्ण इंजीनियरिंग संरचना प्रदान करना शुरू कर दिया है। शायद भविष्य में, इस लोकल नेटवर्क के भीतर क्रॉस-सेशन तंत्र का विकास मशीनों और पारिस्थितिकी के बीच Agent-to-Agent संचार प्रोटोकॉल में हो सकता है, और आज की इन दो क्षणिक Claude संवादों को ही उच्च स्तरीय स्वचालित सॉफ्टवेयर फैक्ट्री के गठन का महत्वपूर्ण कदम माना जा सकता है।