Claude Code sessions के बीच मैसेज कैसे भेजें

Claude Code sessions का एक-दूसरे को संदेश भेजने का क्या अर्थ है

दो Claude Code sessions एक ही मशीन पर, एक ही operating system user के अंतर्गत चलने पर एक-दूसरे को संदेश भेज सकते हैं। एक संदेश सादे टेक्स्ट का एक टुकड़ा होता है जिसे एक Claude दूसरे के लिए लिखता है। इसमें कोई conversation history या files नहीं होती हैं। Claude ListAgents tool के साथ दूसरे session को ढूँढता है और SendMessage के साथ टेक्स्ट डिलीवर करता है, इसलिए आपको कभी भी इन tools को मैन्युअल रूप से चलाने की आवश्यकता नहीं होती है। आप बस यह बताते हैं कि दूसरे session को क्या जानने की आवश्यकता है, और Claude स्वयं संदेश लिख देता है।

इस सुविधा को cross-session messaging कहा जाता है। अगस्त 2026 तक, इसके लिए Claude Code v2.1.224 या बाद का संस्करण आवश्यक है, और यह macOS तथा Linux पर चलता है, जिसमें WSL 2 के भीतर का Linux भी शामिल है। इसमें native Windows support नहीं है, और यह Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, या Microsoft Foundry पर उपलब्ध नहीं है। जब कोई session इन आवश्यकताओं को पूरा करता है, तो messaging पहले से ही चालू रहती है और इसे enable करने के लिए कुछ भी करने की आवश्यकता नहीं होती है। नीचे वर्णित व्यवहार Anthropic documentation for cross-session messaging से लिया गया है।

एक VPS पर यह महत्वपूर्ण है, क्योंकि VPS पर ही sessions इतने लंबे समय तक चलते हैं कि उन्हें संबोधित करना सार्थक होता है। लैपटॉप पर आप ढक्कन बंद कर देते हैं। tmux के अंतर्गत एक सर्वर पर, सोमवार को शुरू किया गया session गुरुवार को भी चल रहा होता है, और एक repository का context बनाए रखता है। एक बार जब आपके पास ऐसे दो sessions हो जाते हैं, तो उनका आपस में बात करना सैद्धांतिक नहीं रह जाता। यदि आपने अभी तक इसे set up नहीं किया है, तो running Claude Code on a VPS under tmux से शुरुआत करें, जो उस session plumbing को कवर करता है जिसे यह गाइड आधार मानती है।

जब दूसरा session tokens के लायक होता है

लागत से शुरुआत करें। प्रत्येक session एक अलग Claude instance है जिसका अपना context window होता है, इसलिए दो sessions की लागत समान अवधि में एक session की तुलना में लगभग दोगुनी होती है। एक भेजा गया संदेश उपयोग में बिल्कुल वैसे ही गिना जाता है जैसे आपके द्वारा टाइप किया गया prompt। समन्वय (coordination) मुफ्त नहीं है, और जो काम वास्तव में चरणों का एक ही क्रम है, वह अलग-अलग sessions में विभाजित करने पर धीमा और अधिक महंगा हो जाता है।

जिन मामलों में दूसरा session अपनी लागत वसूल कर लेता है, उनका स्वरूप एक जैसा होता है। काम के दो हिस्से एक ही समय में बिना एक-दूसरे का इंतज़ार किए चलते हैं, और उनमें से एक ऐसी जानकारी प्राप्त करता है जिसकी दूसरे को कार्य के बीच में आवश्यकता होती है।

• एक session एक breaking change ढूंढता है जबकि दूसरा उस कोड पर काम कर रहा है जिसे उसने तोड़ा है। Claude बदलाव का सारांश देता है और उसे भेजता है, बजाय इसके कि आप उसे दूसरे terminal में फिर से टाइप करें।
• दो sessions अलग-अलग git worktrees में एक ही repository पर काम करते हैं, और एक को यह जानने की आवश्यकता होती है कि क्या merge हुआ है।
• एक लंबा migration या test run अपना परिणाम उस session को वापस भेजता है जिसे आप देख रहे हैं।
• एक builder session और एक reviewer session, जहाँ reviewer वह पढ़ता है जो builder ने तैयार किया है और जो उसने पाया है उसे वापस भेजता है।

जब काम क्रमिक (sequential) हो, या जब दोनों sessions एक ही files को edit करेंगे, तो एक ही session का उपयोग करें। जब आप एक ऐसा समन्वित समूह चाहते हैं जिसे Claude एक ही कार्य के भीतर spawn और supervise करे, तो वह agent teams हैं, जो एक अलग और अभी भी प्रयोगात्मक (experimental) feature है। जब आप केवल दूसरे terminal में वही बातचीत चाहते हैं, तो session को resume करें। Cross-session messaging उन स्वतंत्र sessions के लिए है जिन्हें आप स्वयं शुरू करते हैं और निर्देशित करते हैं।

किसी फीचर पर निर्भर होने से पहले सुनिश्चित करें कि वह उपलब्ध है

सबसे पहले version देखें:

claude --version

इस संख्या की तुलना 2.1.224 से करें। फिर, एक session के भीतर, /list-agents टाइप करें, जो /peers के रूप में भी काम करता है। यह उन सभी agents को print करता है जिन तक यह session पहुँच सकता है, साथ ही वह नाम भी दिखाता है जिससे प्रत्येक agent पहचाना जाता है। यदि command बिल्कुल भी recognize नहीं होती है, तो इस session में cross-session messaging की सुविधा नहीं है, और कोई भी settings file इसे बदल नहीं पाएगी। /status टाइप करें और Peer address वाली पंक्ति देखें: इसमें इस session का अपना inbox address होता है, जिसके आगे uds: लगा होता है।

एक समस्या विशेष रूप से VPS users को प्रभावित करती है। Cross-session messaging फीचर-फ्लैग मूल्यांकन (feature-flag evaluation) पर निर्भर करता है, और कई privacy variables इस मूल्यांकन को बंद कर देते हैं, जिससे फीचर अपनी default 'off' स्थिति में रहता है। DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, और DISABLE_GROWTHBOOK सभी ऐसा ही करते हैं। लोग एक नए सर्वर को सुरक्षित (harden) करने के लिए इन्हें ~/.bashrc में paste कर देते हैं, और फिर सोचते हैं कि /list-agents मौजूद क्यों नहीं है। यही values settings file में env map से या managed settings से भी आ सकती हैं, इसलिए सबसे पहले shell की जाँच करें।

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

जो भी variable output देता है, उसे unset करें। DISABLE_TELEMETRY और CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC के लिए, कोई भी non-empty value इस व्यवहार को चालू कर देती है, जिसमें 0 स्ट्रिंग भी शामिल है, इसलिए DISABLE_TELEMETRY=0 वैसा काम नहीं करता जैसा वह दिखता है। आप variable को unset करके या उसे एक empty string पर set करके इसे बंद कर सकते हैं।

अपने sessions को नाम दें, अन्यथा Claude उन्हें संबोधित नहीं कर पाएगा

Claude किसी session को उसके नाम से संबोधित करता है। session शुरू करते समय ही उसका नाम सेट करें:

claude --name builder-api

आप इसे चलते हुए session के भीतर /rename के साथ भी सेट कर सकते हैं। यदि आप कोई नाम सेट नहीं करते हैं, तो Claude Code वर्किंग डायरेक्टरी के फोल्डर नाम से एक नाम निर्धारित करता है, जैसे कि myapp-3f। यह एक session के लिए तो ठीक है, लेकिन चार sessions के लिए भ्रम पैदा करता है, और दो sessions का नाम एक जैसा हो सकता है। /list-agents आउटपुट प्रत्येक लोकल session की वर्किंग डायरेक्टरी दिखाता है, जिससे एक जैसे नाम वाले sessions में अंतर करना संभव होता है, और जब नाम टकराते हैं तो Claude की अपनी लिस्टिंग एड्रेस में एक छोटा आइडेंटिफायर जोड़ देती है। आइडेंटिफायर्स को पढ़ने की तुलना में उन्हें स्वयं नाम देना अधिक सुविधाजनक है।

दो सत्रों वाला tmux लेआउट जिसे आप पुन: उत्पन्न कर सकते हैं

यह एक ही रिपॉजिटरी पर एक बिल्डर सत्र और एक रिव्युअर सत्र है। रिव्युअर एक अलग git worktree में काम करता है, इसलिए दोनों कभी भी एक ही फाइल में नहीं लिखते हैं। git worktree add के साथ HEAD एक detached checkout देता है, जो उस सत्र के लिए आवश्यक है जो कमिट करने के बजाय केवल पढ़ता है। चूंकि दोनों सत्र अलग-अलग कार्य करते हैं, इसलिए रिव्युअर को एक अलग आउटपुट शैली देना उचित है, जो उस सत्र के सिस्टम प्रॉम्प्ट को बदल देता है और इस प्रकार हर टर्न के दौरान बना रहता है, न कि आपके द्वारा एक बार टाइप किए गए निर्देश की तरह फीका पड़ता है।

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 विंडो को नाम के अनुसार सूचीबद्ध करते हैं ताकि आप एक चुन सकें। बिल्डर विंडो में, /list-agents चलाएं। आपको reviewer-api अपने वर्किंग डायरेक्टरी ~/src/api-review के साथ दिखाई देना चाहिए। यदि यह गायब है, तो रिव्युअर सत्र शुरू नहीं हुआ है, या अगले अनुभाग में दी गई दो समस्याओं में से कोई एक लागू होती है। फिर सरल भाषा में कुछ सौंपें:

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

Claude सारांश लिखता है और उसे भेजता है। आप संदेश का टेक्स्ट नहीं लिखते हैं, और जो Claude भेजता है वह अलग-अलग हो सकता है। रिव्युअर विंडो में संदेश भेजने वाले के नाम के साथ बातचीत में दिखाई देता है। यदि वह सत्र निष्क्रिय है, तो Claude तुरंत उस पर एक नया टर्न शुरू करता है। यदि यह टर्न के बीच में है, तो संदेश टूल कॉल के बीच तक प्रतीक्षा करता है, इसलिए चल रही कमांड कभी बाधित नहीं होती है। एक बार जब Claude इसे पढ़ लेता है, तो संदेश एक पंक्ति वाली Message from पंक्ति में सिमट जाता है जिसे Ctrl+O विस्तारित करता है। यह जोड़ी तब बेहतर काम करती है जब बिल्डर अपने परिवर्तनों को छोटा रखता है, क्योंकि एक छोटा diff एक संक्षिप्त हैंड-ऑफ बनाता है और एक ऐसी समीक्षा जिसे दूसरा सत्र एक टर्न में पूरा कर सकता है, जो कि आलसी वरिष्ठ डेवलपर कौशल की आदत को लागू करने के लिए मौजूद है।

एक VPS पर कौन किसे देख सकता है

एक ही मशीन पर डिलीवरी कभी भी Anthropic सर्वर्स के माध्यम से नहीं होती है। प्रत्येक सत्र (session) डिस्क पर रजिस्ट्रेशन फाइलें लिखता है और अपने स्वयं के इनबॉक्स सॉकेट को बाइंड करता है, और Claude Code अन्य सत्रों को खोजने के लिए उन फाइलों को पढ़ता है। इसके दो परिणाम होते हैं, और दोनों ही सर्वर पर प्रभाव डालते हैं।

सॉकेट आपके ऑपरेटिंग सिस्टम यूजर तक सीमित होता है। एक सत्र जिसे आपने root के रूप में शुरू किया है और एक सत्र जिसे आपने deploy के रूप में शुरू किया है, वे एक-दूसरे को नहीं देख सकते, भले ही वे एक ही tmux सर्वर में साथ-साथ हों, क्योंकि एक यूजर के सत्र दूसरे यूजर के सॉकेट तक नहीं पहुँच सकते। दोनों सत्रों को एक ही यूजर के रूप में चलाएँ।

एक कंटेनर का अपना फाइलसिस्टम होता है। Docker के अंदर का एक सत्र और होस्ट पर चल रहा एक सत्र एक-दूसरे तक नहीं पहुँच सकते, क्योंकि वे समान रजिस्ट्रेशन फाइलें नहीं पढ़ रहे होते हैं। एक ही कंटेनर के अंदर के दो सत्र सामान्य रूप से एक-दूसरे को संदेश भेज सकते हैं। यदि आप आइसोलेशन के लिए एजेंट्स को कंटेनर्स में रखते हैं, जैसा कि डिस्पोजेबल VM में कोडिंग एजेंट्स चलाना में बताया गया है, तो उम्मीद रखें कि मैसेजिंग कंटेनर के अंदर काम करेगी, न कि कंटेनर की सीमा के पार।

अन्य मशीनों पर और वेब पर आपके सत्र केवल तभी लिस्टिंग में दिखाई देते हैं जब Remote Control कनेक्टेड हो, और उन्हें उसी के अनुसार लेबल किया जाता है। यहाँ Claude केवल उसी संदेश का उत्तर दे सकता है जो उनमें से किसी एक से आया हो। यह उस एक्सचेंज को शुरू नहीं कर सकता।

आपका संदेश क्यों नहीं पहुँचा

इसका सामान्य कारण नेटवर्क से संबंधित नहीं होता है। प्राप्त करने वाले session ने यह तय किया कि संदेश के साथ क्या करना है, और निर्णय उसे डिलीवर न करने का था। प्रत्येक आने वाला संदेश तीन परिणामों में से एक पर समाप्त होता है: डिलीवर किया गया, होल्ड पर रखा गया (जब तक आप उसे स्वीकार न करें, तब तक डिलीवर नहीं किया गया), या अस्वीकार कर दिया गया (बिना डिलीवर किए हटा दिया गया)।

जब कोई crossSessionInbound मान लागू नहीं होता है, तो Claude Code दोनों sessions के permission modes की तुलना करके प्रति संदेश निर्णय लेता है। यह उन sessions को एक वर्ग में समूहित करता है जो permission prompts को बायपास करते हैं और बाकी सभी sessions को दूसरे वर्ग में रखता है। auto, acceptEdits, और dontAsk को प्रॉम्प्टिंग के रूप में गिना जाता है। Plan mode उस session में बायपासिंग के रूप में गिना जाता है जिसमें बायपास अनुमतियाँ उपलब्ध हैं। यदि आप सुनिश्चित नहीं हैं कि कोई session किस वर्ग में आता है, तो प्रत्येक permission mode वास्तव में क्या करता है को पहले पढ़ना उचित है, क्योंकि auto वह मोड है जहाँ अधिकांश sessions अब शुरू होते हैं और यह उस विभाजन के प्रॉम्प्टिंग पक्ष पर स्थित है। नियम तब सममित (symmetric) होता है:

• एक प्राप्त करने वाला session जो अनुमतियों के लिए प्रॉम्प्ट करता है, उसे प्रत्येक संदेश डिलीवर हो जाता है। यह केवल तब होल्ड करता है जब भेजने वाला session खुद को प्रॉम्प्ट बायपास करने वाले के रूप में पहचानता है।
• एक प्राप्त करने वाला session जो प्रॉम्प्ट को बायपास करता है, वह आपके अनुमोदन के लिए प्रत्येक संदेश को होल्ड पर रखता है। यह केवल तब डिलीवर करता है जब भेजने वाला भी बायपास कर रहा हो।

इसलिए पहला वर्कफ़्लो जो अधिकांश लोग बनाते हैं, वह बिल्कुल वही है जो काम नहीं करता है। आप --permission-mode bypassPermissions के साथ एक builder शुरू करते हैं क्योंकि आप चाहते हैं कि यह बिना निगरानी के चले, आप reviewer को डिफ़ॉल्ट पर छोड़ देते हैं, और builder द्वारा भेजा गया प्रत्येक संदेश एक ऐसे अनुमोदन संवाद (approval dialog) में प्रतीक्षा करता है जिसे कोई नहीं देख रहा है। वह संवाद dialogExpiry समय सीमा के बाद बंद हो जाता है, जो डिफ़ॉल्ट रूप से 5m है, और संदेश हटा दिया जाता है। उसी मशीन पर भेजने वाले session को एक सूचना मिलती है जब उसका संदेश होल्ड पर होता है, और बाद में जब प्राप्तकर्ता उसे डिलीवर, अस्वीकार या एक्सपायर करता है, तो एक फॉलो-अप मिलता है, इसलिए सॉकेट को दोष देने से पहले भेजने वाले की स्क्रीन पढ़ें।

किसी session को बिना निगरानी के संदेश लेने के लिए, crossSessionInbound को accept पर सेट करें। आप इसे कहाँ सेट करते हैं, यह तय करता है कि यह लागू होता है या नहीं। Claude Code पहले managed settings को पढ़ता है, फिर --settings फ्लैग को, फिर user settings को, और जो पहला मान उसे मिलता है उसे लागू करता है। प्रोजेक्ट या local settings में कोई मान केवल तभी लागू होता है जब वह अधिक सख्त हो, सीढ़ी accept < hold < refuse पर। .claude/settings.json में एक accept किसी भी चीज़ से अधिक ढीला होता है, इसलिए जब भी किसी विश्वसनीय स्रोत ने मान सेट किया हो तो इसे अनदेखा कर दिया जाता है। इसे ~/.claude/settings.json में रखें, या एक session के लिए इसे पास करें:

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

एक headless claude -p वर्कर एक इंटरैक्टिव session की तरह एक इनबॉक्स सॉकेट को बाइंड करता है और लिस्टिंग में दिखाई देता है, लेकिन यह अनुमोदन संवाद नहीं दिखा सकता है। वहाँ एक होल्ड किया गया संदेश तब तक होल्ड पर रहता है जब तक कि बाद का मोड या सेटिंग्स परिवर्तन इसकी अनुमति न दे दे। ऊपर दी गई --settings लाइन वह तरीका है जिससे आप ऐसे वर्कर को संदेश लेने देते हैं। bare मोड में शुरू किया गया session बिल्कुल भी सॉकेट बाइंड नहीं करता है, इसलिए यह न तो संदेश प्राप्त कर सकता है और न ही सूची में दिखाई दे सकता है।

जहाँ हैंड-ऑफ डेडलॉक (deadlock) हो जाते हैं

मैसेज लूप्स को आपके लिए हैंडल किया जाता है। Claude Code प्रति सेंडर बार-बार आने वाले मैसेज की दर को सीमित (rate-limit) करता है, एक छोटी अवधि के भीतर आने वाले समान मैसेज को हटा देता है, और प्रति सेशन पढ़े जाने के लिए प्रतीक्षा कर रहे मैसेज की संख्या को 50 पर सीमित करता है, ताकि दो सेशन हमेशा के लिए एक-दूसरे को पिंग-पोंग न कर सकें। होल्ड पर रखे गए मैसेज की सीमा 100 है, और इससे अधिक होने पर सबसे पुराने मैसेज हटा दिए जाते हैं।

जो विफलता वास्तव में होती है वह अधिक शांत होती है, और यह लूप के बजाय एक हैंड-ऑफ की समस्या है। सेशन A, सेशन B से एक ऐसा प्रश्न पूछता है जिसका उत्तर मिलने तक वह आगे नहीं बढ़ सकता, और फिर वह निष्क्रिय (idle) हो जाता है। B मैसेज को होल्ड पर रखता है, या B किसी लंबे कार्य के बीच में है, या B उस प्रश्न का उत्तर देता है जो A ने वास्तव में पूछा ही नहीं था। A प्रतीक्षा करता रहता है। आप एक घंटे बाद वापस आते हैं और देखते हैं कि दोनों सेशन निष्क्रिय हैं और कोई काम पूरा नहीं हुआ है।

ऐसे हैंड-ऑफ लिखें जिन्हें उत्तर की आवश्यकता न हो। एक अच्छा मैसेज कोई तथ्य या निर्णय बताता है: क्या बदला, और परिणाम क्या रहा। एक बुरा मैसेज दूसरे सेशन से अनुमति मांगता है, या किसी ऐसे उत्तर के लिए पूछता है जिस पर भेजने वाला रुका हुआ है। Claude को पहले ही निर्देश दिया गया है कि वह कभी भी किसी दूसरे सेशन से ऐसा कार्य करने के लिए न कहे जिसे उसकी अपनी अनुमति सेटिंग्स ब्लॉक कर देंगी, और इसके बजाय उस कार्य को वापस आप तक पहुँचा दे। इस नियम को आप स्वयं भी लागू करें। यदि कोई सेशन उत्तर के बिना आगे नहीं बढ़ सकता है, तो आपको ही उसका उत्तर देना चाहिए। कॉन्टेक्स्ट अनुशासन (context discipline) भी यहाँ मदद करता है, क्योंकि जो सेशन अपना सूत्र खो देता है वह अस्पष्ट मैसेज लिखता है; Claude Code में कॉन्टेक्स्ट मैनेज करना इस पहलू को कवर करता है।

आने वाले संदेश को untrusted input के रूप में मानें

Claude Code प्राप्त करने वाले Claude को यह बताता है कि संदेश किसी अन्य session से आया है, न कि आपसे, और यह उस संदेश की क्षमताओं को सीमित करता है। यह प्रवर्तन मॉडल की अनुपालन करने की इच्छा के बजाय मॉडल के चारों ओर लिपटे प्रोग्राम में होता है, जो कि व्यावहारिक अंतर है जिसे an agent harness बनाता है। कोई संदेश आपकी ओर से लंबित permission prompt का उत्तर नहीं दे सकता, क्योंकि किसी अन्य session की सहमति आपकी सहमति नहीं है। यह किसी अन्य session के कहने पर permission settings, CLAUDE.md, या अन्य configuration को नहीं बदल सकता। टेक्स्ट के भीतर एक slash command, जैसे कि /compact, plain text के रूप में आता है और कभी निष्पादित नहीं होता है। यदि संदेश पर कार्रवाई करने के लिए ऐसी permission की आवश्यकता होती है जो प्राप्त करने वाले session के पास नहीं है, तो आपको वही prompt दिखाई देता है जो आपको किसी अन्य कार्य के लिए दिखाई देता। Auto mode में, एक classifier डिलीवरी से पहले प्रत्येक संदेश की समीक्षा भी करता है, और जिसे वह ब्लॉक करता है, वह संदेश प्राप्तकर्ता तक कभी नहीं पहुँचता। ये सीमाएँ permissive modes में भी बनी रहती हैं, यही कारण है कि एक bypassing session इनबाउंड संदेशों पर भरोसा करने के बजाय उन्हें डिफ़ॉल्ट रूप से रोक कर रखता है।

यह permissions को कवर करता है। यह सामग्री को कवर नहीं करता है। भेजने वाले session ने pull request description, web page, dependency README, या किसी अजनबी द्वारा लिखी गई issue comment को पढ़ा हो सकता है, और जो कुछ भी उसने पढ़ा है, वह उस टेक्स्ट को आकार दे सकता है जिसे वह आपके दूसरे session में लिखता है। संदेश डेटा है। यह बाहर से session में प्रवेश करने वाले किसी भी अन्य टेक्स्ट के समान संदेह का पात्र है। यह वह अनुशासन है जिसका वर्णन keeping secrets out of your AI agents में किया गया है: यह मान लें कि trust boundary को पार करने वाली कोई भी चीज़ गलत हो सकती है, और इसे कभी भी खुद को अधिकृत न करने दें।

यदि आप इसे कम करना चाहते हैं तो दो नियंत्रण मौजूद हैं। crossSessionInbound को refuse पर सेट करने से इनबाउंड peer संदेश बिना डिलीवर हुए हट जाते हैं, और project या local settings से वह मान हर दूसरे स्रोत पर लागू होता है, क्योंकि यह ladder पर सबसे सख्त है। इस session को भेजने या सूचीबद्ध करने से रोकने के लिए, SendMessage और ListAgents को नाम देने वाले permission deny rules जोड़ें, दोनों को बिना किसी specifier के bare tool names के रूप में लिखा गया है। isolatePeerMachines को true पर सेट करने के लिए इस मशीन से परे किसी भी session तक संदेश पहुँचने से पहले आपकी स्पष्ट स्वीकृति की आवश्यकता होती है, और वह स्वीकृति bypassPermissions mode में भी आवश्यक है।

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

SendMessage को अस्वीकार करने से subagents को संदेश भेजना भी हट जाता है, क्योंकि एक ही tool दोनों का काम करता है। एक अस्वीकार करने वाला session अपने स्वयं के /status में या अन्य sessions की लिस्टिंग में कोई दृश्य परिवर्तन नहीं दिखाता है, इसलिए सेटिंग की पुष्टि स्क्रीन के बजाय session के configuration से करें।

Bridges और shared memory MCP servers

इसी अवधि में कई third-party projects ने कुछ समान कार्य किए हैं: local agent-to-agent bridges जो चल रहे agents के बीच text relay करते हैं, और MCP (model context protocol) servers जो कई agents को पढ़ने और लिखने के लिए एक shared store प्रदान करते हैं। इन्हें competitor के बजाय एक अलग स्वरूप के रूप में देखें, और किसी भी install command को चलाने से पहले project के अपने README से verify करें। Messaging 'push' आधारित है, क्योंकि sender text को receiver की turn में डालता है। Shared store 'pull' आधारित है, क्योंकि इसमें किसी को interrupt नहीं किया जाता और session अगली बार देखने पर note को देख लेता है। धीरे-धीरे बदलने वाली स्थिति (status) के लिए 'pull' बेहतर है, और यह तभी काम करता है जब session वास्तव में उसे देखता है।

यदि आप इस दिशा में आगे बढ़ते हैं, तो feature list के बजाय process के बारे में पूछना अधिक महत्वपूर्ण है। Server किस user के रूप में चलता है, और वह box पर क्या पढ़ सकता है। Running MCP servers on a VPS इस setup को कवर करता है। Sharing agent skills across repos उस सरल स्थिति को कवर करता है जहाँ आप sessions के बीच live state के बजाय instructions share करना चाहते हैं, और यह उन बहुत सारे messages को हटा देता है जो आपको अन्यथा भेजने पड़ते। व्यापक दृष्टिकोण के लिए, running a coding agent on a VPS से शुरुआत करना उचित है।

FAQ

मेरे session में /list-agents क्यों पहचाना नहीं जा रहा है?

Session में cross-session messaging की सुविधा नहीं है। सबसे पहले claude --version की तुलना 2.1.224 से करें, क्योंकि इस फीचर के लिए वही या बाद का वर्ज़न आवश्यक है। फिर platform की जाँच करें, क्योंकि यह macOS और Linux पर चलता है, native Windows पर नहीं, और यह Amazon Bedrock, AWS पर Claude Platform, Google Cloud के Agent Platform, और Microsoft Foundry पर उपलब्ध नहीं है। यदि दोनों ठीक हैं, तो अपने shell में DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, या DISABLE_GROWTHBOOK की जाँच करें, क्योंकि इनमें से प्रत्येक उस feature-flag evaluation को रोकता है जिस पर यह फीचर निर्भर करता है, जिससे यह बंद रहता है।

दूसरे session को भेजा गया मेरा संदेश क्यों नहीं पहुँचा?

यदि /list-agents काम करता है, तो messaging चालू है और किसी विशिष्ट कारण से संदेश रुक गया है। इसका सामान्य कारण permission modes हैं। जो session permission prompts को bypass करता है, वह हर inbound संदेश को आपकी स्वीकृति के लिए रोक कर रखता है, जब तक कि भेजने वाला भी bypass न कर रहा हो, और वह स्वीकृति संवाद dialogExpiry समय-सीमा (डिफ़ॉल्ट रूप से पाँच मिनट) के बाद समाप्त हो जाता है। भेजने वाले session में 'held' सूचना की जाँच करें। इसे ठीक करने के लिए, ~/.claude/settings.json में crossSessionInbound को accept पर सेट करें या इसे --settings के साथ पास करें, क्योंकि project या local settings में मौजूद accept को ढीले मान (looser value) के रूप में अनदेखा कर दिया जाता है।

क्या Docker में चल रहा Claude Code session host पर चल रहे session को संदेश भेज सकता है?

नहीं। Sessions डिस्क पर मौजूद registration files और प्रति-session inbox socket के माध्यम से एक-दूसरे को ढूंढते हैं, और container का अपना filesystem होता है, इसलिए दोनों एक-दूसरे की फाइलें नहीं देख सकते। एक ही container के भीतर दो sessions सामान्य रूप से एक-दूसरे को संदेश भेज सकते हैं। यही नियम बताता है कि root के रूप में चल रहा session और आपके सामान्य user के रूप में चल रहा session एक-दूसरे तक क्यों नहीं पहुँच सकते: socket केवल उस operating system user तक सीमित होता है जो उसका स्वामी है।

क्या किसी अन्य Claude Code session से आया संदेश सुरक्षित है?

टेक्स्ट को untrusted input मानें, क्योंकि भेजने वाले session ने शायद कोई web page, README, या किसी और द्वारा लिखी गई issue comment पढ़ी हो। Claude Code संदेश को अपने आप कार्य करने से पहले ही रोक देता है: यह किसी लंबित permission prompt को approve नहीं कर सकता, यह अनुरोध पर permission settings या CLAUDE.md को नहीं बदल सकता, और टेक्स्ट में मौजूद slash command केवल plain text के रूप में पहुँचती है और कभी run नहीं होती। ये सुरक्षा उपाय permissions को कवर करते हैं, निर्णय (judgement) को नहीं, इसलिए प्राप्त संदेश को receiving session से निष्पादित करने के लिए कहने से पहले उसे पढ़ लें।

क्या cross-session messaging मेरा कोड Anthropic को भेजता है?

एक ही मशीन पर दो sessions के बीच, नहीं। संदेश उस मशीन पर एक प्रति-session socket के माध्यम से यात्रा करता है और कभी भी Anthropic servers से होकर नहीं गुजरता, और केवल Claude द्वारा लिखा गया टेक्स्ट भेजा जाता है, न कि conversation history या फाइलें। आपकी किसी दूसरी मशीन पर मौजूद session या web पर मौजूद session को भेजे गए संदेश Remote Control connection के माध्यम से Anthropic servers से होकर गुजरते हैं, और उस दिशा में Claude केवल प्राप्त संदेश का उत्तर दे सकता है, उसे शुरू नहीं कर सकता। मशीन से कुछ भी बाहर जाने से पहले अपनी स्वीकृति अनिवार्य करने के लिए isolatePeerMachines को true पर सेट करें।