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

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

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

इस feature को cross-session messaging कहा जाता है। अगस्त 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 इन आवश्यकताओं को पूरा करता है, तो messaging पहले से ही चालू रहती है और इसे enable करने के लिए कुछ भी करने की आवश्यकता नहीं होती। नीचे वर्णित व्यवहार Anthropic documentation for cross-session messaging से लिया गया है।

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

जब दूसरा session टोकन के लायक हो

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

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

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

जब काम क्रमिक (sequential) हो, या जब दोनों sessions एक ही फाइल को 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 फीचर-फ्लैग मूल्यांकन पर निर्भर करता है, और कई 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 string भी शामिल है, इसलिए DISABLE_TELEMETRY=0 वैसा काम नहीं करता जैसा वह दिखता है। आप variable को unset करके या उसे empty string पर set करके इसे बंद कर सकते हैं।

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

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

claude --name builder-api

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जहाँ हैंड-ऑफ डेडलॉक (deadlock) का कारण बनते हैं

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

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

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

आने वाले संदेश को अविश्वसनीय इनपुट मानें

Claude Code प्राप्त करने वाले Claude को यह बताता है कि संदेश किसी अन्य सत्र से आया है, आपसे नहीं, और यह उस संदेश की क्षमताओं को सीमित कर देता है। कोई संदेश आपकी ओर से लंबित अनुमति प्रॉम्प्ट (permission prompt) का उत्तर नहीं दे सकता, क्योंकि किसी अन्य सत्र की सहमति आपकी सहमति नहीं है। यह किसी अन्य सत्र के अनुरोध पर अनुमति सेटिंग्स, CLAUDE.md, या अन्य कॉन्फ़िगरेशन को नहीं बदल सकता है। टेक्स्ट के भीतर कोई स्लैश कमांड, जैसे कि /compact, सादे टेक्स्ट के रूप में आता है और कभी निष्पादित (execute) नहीं होता है। यदि संदेश पर कार्रवाई करने के लिए ऐसी अनुमति की आवश्यकता है जो प्राप्त करने वाले सत्र के पास नहीं है, तो आपको वही प्रॉम्प्ट दिखाई देगा जो किसी अन्य कार्य के लिए दिखाई देता। ऑटो मोड में, एक क्लासिफायर डिलीवरी से पहले प्रत्येक संदेश की समीक्षा भी करता है, और जिसे वह ब्लॉक करता है, वह संदेश प्राप्तकर्ता तक कभी नहीं पहुँचता है। ये सीमाएँ अनुमेय मोड (permissive modes) में भी बनी रहती हैं, यही कारण है कि एक बायपासिंग सत्र इनबाउंड संदेशों पर भरोसा करने के बजाय उन्हें डिफ़ॉल्ट रूप से होल्ड पर रखता है।

यह अनुमतियों को कवर करता है। यह सामग्री को कवर नहीं करता है। भेजने वाले सत्र ने किसी अजनबी द्वारा लिखा गया पुल रिक्वेस्ट विवरण, वेब पेज, डिपेंडेंसी README, या इश्यू कमेंट पढ़ा हो सकता है, और जो कुछ भी उसने पढ़ा है वह उस टेक्स्ट को आकार दे सकता है जिसे वह आपके दूसरे सत्र में लिखता है। संदेश डेटा है। यह बाहर से सत्र में प्रवेश करने वाले किसी भी अन्य टेक्स्ट के समान संदेह का पात्र है। यह वही अनुशासन है जिसका वर्णन keeping secrets out of your AI agents में किया गया है: यह मान लें कि ट्रस्ट बाउंड्री को पार करने वाली कोई भी चीज़ गलत हो सकती है, और इसे कभी भी खुद को अधिकृत (authorise) न करने दें।

यदि आप इसे कम करना चाहते हैं तो दो नियंत्रण मौजूद हैं। crossSessionInbound को refuse पर सेट करने से इनबाउंड पीयर संदेश बिना डिलीवर हुए ड्रॉप हो जाते हैं, और प्रोजेक्ट या स्थानीय सेटिंग्स से वह मान हर दूसरे स्रोत पर लागू होता है, क्योंकि यह पदानुक्रम में सबसे सख्त है। इस सत्र को भेजने या सूचीबद्ध करने से रोकने के लिए, SendMessage और ListAgents को नाम देने वाले अनुमति अस्वीकार नियम (permission deny rules) जोड़ें, दोनों को बिना किसी स्पेसिफायर के केवल टूल नामों के रूप में लिखें। isolatePeerMachines को true पर सेट करने के लिए इस मशीन से परे किसी भी सत्र तक संदेश पहुँचने से पहले आपकी स्पष्ट स्वीकृति की आवश्यकता होती है, और वह स्वीकृति bypassPermissions मोड में भी आवश्यक है।

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

SendMessage को अस्वीकार करने से सब-एजेंटों को संदेश भेजना भी बंद हो जाता है, क्योंकि एक ही टूल दोनों के लिए काम करता है। एक अस्वीकार करने वाला सत्र अपने स्वयं के /status या अन्य सत्रों की लिस्टिंग में कोई दृश्य परिवर्तन नहीं दिखाता है, इसलिए स्क्रीन के बजाय सत्र के कॉन्फ़िगरेशन से सेटिंग की पुष्टि करें।

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 receiver की turn में text डालता है। Shared store 'pull' है, क्योंकि इसमें किसी को interrupt नहीं किया जाता और session अगली बार देखने पर note को देख लेता है। धीरे-धीरे बदलने वाली status के लिए 'pull' बेहतर है, और यह तभी काम करता है जब session वास्तव में उसे देखता है।

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

FAQ

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

सत्र में क्रॉस-सेशन मैसेजिंग की सुविधा नहीं है। सबसे पहले claude --version की तुलना 2.1.224 से करें, क्योंकि इस फीचर के लिए वही या बाद का वर्ज़न आवश्यक है। फिर प्लेटफॉर्म की जाँच करें, क्योंकि यह macOS और Linux पर चलता है, नेटिव Windows पर नहीं, और यह Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, और Microsoft Foundry पर उपलब्ध नहीं है। यदि दोनों सही हैं, तो अपने शेल में DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, या DISABLE_GROWTHBOOK की जाँच करें, क्योंकि इनमें से प्रत्येक उस फीचर-फ्लैग इवैल्यूएशन को ब्लॉक करता है जिस पर यह फीचर निर्भर करता है, जिससे यह बंद रहता है।

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

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

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

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

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

टेक्स्ट को अनट्रस्टेड इनपुट मानें, क्योंकि भेजने वाले सत्र ने किसी और द्वारा लिखा गया वेब पेज, README, या इश्यू कमेंट पढ़ा हो सकता है। Claude Code संदेश को अपने आप कार्य करने से पहले ही रोक देता है: यह किसी लंबित परमिशन प्रॉम्प्ट को स्वीकृत नहीं कर सकता, यह अनुरोध पर परमिशन सेटिंग्स या CLAUDE.md को नहीं बदल सकता, और टेक्स्ट में मौजूद स्लैश कमांड केवल प्लेन टेक्स्ट के रूप में पहुँचता है और कभी रन नहीं होता। ये सुरक्षा उपाय परमिशन को कवर करते हैं, निर्णय को नहीं, इसलिए प्राप्त करने वाले सत्र को कार्य करने का निर्देश देने से पहले आए हुए संदेश को पढ़ लें।

क्या क्रॉस-सेशन मैसेजिंग मेरा कोड Anthropic को भेजती है?

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