Claude Code सत्रांना एकमेकांना संदेश कसे पाठवायचे

Claude Code सत्रे एकमेकांना संदेश पाठवू शकतात याचा अर्थ

दोन Claude Code सत्रे एकाच मशीनवर आणि त्याच operating system user अंतर्गत चालत असतील, तर ती एकमेकांना संदेश पाठवू शकतात. संदेश म्हणजे एक Claude दुसऱ्या Claude साठी लिहिलेला साधा मजकुराचा भाग. त्यात संभाषणाचा इतिहास किंवा फाइल्स समाविष्ट नसतात. Claude दुसरे सत्र ListAgents tool वापरून शोधतो आणि मजकूर SendMessage वापरून पाठवतो; त्यामुळे तुम्हाला यापैकी कोणतेही tool स्वतः call करावे लागत नाही. दुसऱ्या सत्राला काय माहिती असणे आवश्यक आहे ते तुम्ही सांगता आणि Claude स्वतः संदेश लिहितो.

या सुविधेला cross-session messaging असे म्हणतात. August 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 वर ही सुविधा उपलब्ध नाही. एखादे सत्र या अटी पूर्ण करत असेल, तर messaging आधीपासून enabled असते आणि ते enable करण्यासाठी काहीही करावे लागत नाही. खाली वर्णन केलेले वर्तन cross-session messaging साठी Anthropic documentation वर आधारित आहे.

VPS वर या सुविधेचा उपयोग स्पष्टपणे होतो, कारण सत्रे संबोधित करण्याइतका वेळ VPS वर चालू राहतात. Laptop वर तुम्ही lid बंद करता. tmux अंतर्गत server वर सुरू केलेले सत्र Monday ला सुरू केलेले असले, तरी Thursday ला अजूनही चालू असते आणि एका repository चा context अजूनही त्याच्याकडे असतो. अशी दोन सत्रे असतील, तर ती एकमेकांशी कशी संवाद साधतात हा केवळ सैद्धांतिक प्रश्न राहत नाही. हे अद्याप setup केले नसेल, तर tmux अंतर्गत VPS वर Claude Code चालवणे येथून सुरुवात करा. या guide मध्ये गृहीत धरलेली session plumbing त्यात स्पष्ट केली आहे.

दुसरे session tokens खर्च करण्यास कधी योग्य ठरते

सुरुवात खर्चापासून करा. प्रत्येक session हा स्वतंत्र context window असलेला स्वतंत्र Claude instance असतो. त्यामुळे समान कालावधीत दोन session चालवण्याचा खर्च साधारणपणे एका session च्या दुप्पट असतो. पाठवलेला संदेश तुम्ही स्वतः टाइप केलेल्या prompt प्रमाणेच usage मध्ये मोजला जातो. Coordination विनामूल्य नसते. प्रत्यक्षात एका क्रमाने होणाऱ्या पायऱ्यांचे काम अनेक session मध्ये विभागल्यास ते अधिक धीमे आणि महाग होते.

दुसरा session स्वतःचा खर्च भरून काढतो अशा परिस्थितींमध्ये एक समान रचना असते. कामाचे दोन भाग एकमेकांची वाट न पाहता एकाच वेळी चालतात आणि त्यापैकी एका भागातून कामाच्या मधोमध दुसऱ्या भागाला आवश्यक असलेली माहिती मिळते.

• एक session breaking change शोधतो, तर दुसरा session त्या बदलामुळे तुटलेल्या code वर पुढील काम करत असतो. दुसऱ्या terminal मध्ये तुम्ही ती माहिती पुन्हा टाइप करण्याऐवजी Claude बदलाचा सारांश तयार करून तो पाठवतो.
• दोन session स्वतंत्र git worktree मध्ये त्याच repository वर काम करतात आणि त्यापैकी एका session ला कोणते बदल लागू झाले हे जाणून घ्यायचे असते.
• दीर्घ migration किंवा test run त्याचा निकाल तुम्ही पाहत असलेल्या session कडे पाठवतो.
• एक builder session आणि एक reviewer session असतो. reviewer session builder ने तयार केलेले वाचतो आणि त्याला आढळलेली माहिती परत पाठवतो.

काम sequential असेल किंवा दोन्ही session ने त्याच files मध्ये बदल करायचे असतील, तर एकच session वापरा. एका task च्या आत Claude ने सुरू करून देखरेख केलेला coordinated group हवा असेल, तर ते agent teams आहे. हे स्वतंत्र आणि अद्याप experimental feature आहे. तुम्हाला फक्त तेच conversation दुसऱ्या terminal मध्ये हवे असेल, तर session resume करा. Cross-session messaging हे तुम्ही स्वतः सुरू करून नियंत्रित करता अशा independent session साठी आहे.

हे वैशिष्ट्य वापरण्याचे नियोजन करण्यापूर्वी ते उपलब्ध आहे का ते तपासा

प्रथम version तपासा:

claude --version

हा क्रमांक 2.1.224 शी तुलना करा. त्यानंतर session मध्ये /list-agents टाइप करा. हे /peers ला देखील प्रतिसाद देते. हा command या session ला पोहोचता येणारे सर्व agents आणि प्रत्येक agent ज्या नावाला प्रतिसाद देतो ते नाव दाखवतो. हा command मुळीच ओळखला जात नसेल, तर या session मध्ये cross-session messaging उपलब्ध नाही. कोणतीही settings file बदलून ते सुरू करता येणार नाही. /status टाइप करा आणि Peer address row शोधा. त्यात या session चा स्वतःचा inbox address असतो. त्याच्या सुरुवातीला uds: असते.

एका बाबतीत VPS users विशेषतः अडचणीत येतात. Cross-session messaging हे feature-flag evaluation वर अवलंबून असते. काही privacy variables हे evaluation बंद करतात. त्यामुळे feature ची default स्थिती off राहते. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC आणि DISABLE_GROWTHBOOK हे सर्व असेच करतात. नवीन server harden करताना लोक हे variables ~/.bashrc मध्ये paste करतात. त्यानंतर /list-agents उपलब्ध का नाही, याबद्दल त्यांना आश्चर्य वाटते. हीच values settings file मधील env map मधून किंवा managed settings मधूनही येऊ शकतात. त्यामुळे प्रथम shell तपासा.

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

यापैकी ज्या variable चे मूल्य छापले जाते ते unset करा. DISABLE_TELEMETRY आणि CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC साठी कोणतेही non-empty value हे behaviour सुरू करते. यात 0 string देखील समाविष्ट आहे. त्यामुळे DISABLE_TELEMETRY=0 दिसते तसे काम करत नाही. हे बंद करण्यासाठी variable unset करा किंवा त्याला empty string द्या.

तुमच्या sessions ना नावे द्या; अन्यथा Claude त्यांना संबोधित करू शकत नाही

Claude session च्या नावाने message ला त्या session कडे पाठवतो. Session सुरू करताना नाव सेट करा:

claude --name builder-api

चालू session मध्ये /rename वापरूनही नाव सेट करता येते. काहीही सेट केले नाही, तर Claude Code working directory च्या folder name वरून नाव तयार करतो, उदाहरणार्थ myapp-3f. एका session साठी हे योग्य आहे; पण चार sessions असतील तर गोंधळ होऊ शकतो. दोन sessions ना एकच नाव मिळू शकते. /list-agents output प्रत्येक local session ची working directory दाखवते. त्यामुळे एकाच नावाच्या sessions मधील फरक ओळखता येतो. नावे जुळल्यास Claude ची स्वतःची listing address मध्ये एक छोटा identifier जोडते. Identifiers वाचण्यापेक्षा sessions ना स्वतः नावे देणे अधिक सोपे आहे.

पुनरुत्पादित करता येणारी दोन-session tmux रचना

हे एकाच repository वर चालणारे builder session आणि reviewer session आहेत. Reviewer स्वतंत्र git worktree मध्ये काम करतो, त्यामुळे दोन्ही session एकाच फाइलमध्ये कधीही लिहित नाहीत. git worktree add आणि HEAD वापरल्याने detached checkout मिळतो. Commit करण्याऐवजी फाइल्स वाचणाऱ्या session साठी हेच योग्य आहे.

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 वापरल्यास windows ची नावे दिसतात आणि तुम्ही योग्य window निवडू शकता. Builder window मध्ये /list-agents चालवा. त्यात reviewer-api आणि त्याची working directory ~/src/api-review दिसली पाहिजे. ती दिसत नसेल, तर reviewer session सुरू होणे अद्याप पूर्ण झालेले नाही किंवा पुढील section मधील दोनपैकी एखादी समस्या लागू आहे. त्यानंतर साध्या भाषेत काहीतरी सोपवा:

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

Claude summary लिहून ती पाठवतो. तुम्ही संदेशाचा मजकूर लिहायचा नसतो आणि Claude काय पाठवेल ते बदलू शकते. Reviewer window मध्ये संदेश पाठवणाऱ्याच्या नावासह conversation मध्ये दिसतो. तो session idle असल्यास Claude त्यावर लगेच नवीन turn सुरू करतो. तो mid-turn मध्ये असल्यास संदेश tool calls मधील पुढील संधीपर्यंत थांबतो; त्यामुळे सुरू असलेली command मध्येच थांबत नाही. Claude ने संदेश वाचल्यानंतर तो एका ओळीच्या Message from row मध्ये संक्षिप्त होतो आणि Ctrl+O तो विस्तारतो. Builder ने त्यातील बदल लहान ठेवले तर ही जोडी अधिक चांगली काम करते, कारण अरुंद diff मुळे hand-off लहान होतो आणि दुसरे session एका turn मध्ये review पूर्ण करू शकते. हाच सवय आळशी senior dev कौशल्य रुजवण्यासाठी आहे.

एका VPS वर कोण कोणाला पाहू शकते

एकाच मशीनवरील संदेशवहन Anthropic सर्व्हरमार्फत होत नाही. प्रत्येक session डिस्कवर registration files लिहिते आणि स्वतःचा inbox socket bind करते. इतर sessions शोधण्यासाठी Claude Code त्या files वाचते. याचे दोन परिणाम होतात आणि server वर दोन्ही महत्त्वाचे ठरतात.

हा socket तुमच्या operating system user पर्यंत मर्यादित असतो. root म्हणून सुरू केलेली session आणि deploy म्हणून सुरू केलेली session एकमेकांना पाहू शकत नाहीत. त्या एकाच tmux server मध्ये शेजारी चालू असल्या तरी हेच लागू होते, कारण एका user च्या sessions ना दुसऱ्या user च्या socket पर्यंत पोहोचता येत नाही. दोन्ही sessions एकाच user म्हणून चालवा.

Container ची स्वतःची filesystem असते. Docker मधील session आणि host वरील session एकमेकांपर्यंत पोहोचू शकत नाहीत, कारण त्या समान registration files वाचत नाहीत. एकाच container मधील दोन sessions नेहमीप्रमाणे एकमेकांना संदेश पाठवू शकतात. तुम्ही isolation साठी agents containers मध्ये ठेवत असाल, जसे disposable VM मध्ये coding agents चालवताना, तर messaging container च्या आत कार्य करेल; परंतु container boundary ओलांडून कार्य करणार नाही.

इतर machines वरील आणि web वरील तुमच्या sessions listing मध्ये केवळ Remote Control connected असतानाच दिसतात आणि त्यांना त्याप्रमाणे label केलेले असते. येथे Claude फक्त त्या sessions पैकी एखाद्याकडून आलेल्या message ला उत्तर देऊ शकते. ती स्वतःहून असा exchange सुरू करू शकत नाही.

तुमचा संदेश का पोहोचला नाही

याचे नेहमीचे कारण नेटवर्कशी संबंधित नसते. प्राप्त करणाऱ्या session ने संदेशाचे काय करायचे ते ठरवले आणि तो वितरित न करण्याचा निर्णय घेतला. प्राप्त होणारा प्रत्येक संदेश तीनपैकी एका परिणामाकडे जातो: वितरित, राखून ठेवलेला (तुम्ही मंजुरी देईपर्यंत वितरित न करता बाजूला ठेवलेला), किंवा नाकारलेला (वितरण न करता टाकून दिलेला).

कोणतेही crossSessionInbound मूल्य लागू नसताना, Claude Code दोन sessions च्या permission modes ची तुलना करून प्रत्येक संदेशासाठी निर्णय घेतो. Permission prompts वगळणाऱ्या sessions ना तो एका वर्गात गटबद्ध करतो आणि इतर सर्व sessions ना दुसऱ्या वर्गात ठेवतो. auto, acceptEdits आणि dontAsk यांना prompting असे मानले जाते. ज्या session मध्ये bypass permissions उपलब्ध आहेत, त्या session मधील Plan mode ला bypassing असे मानले जाते. त्यानंतरचा नियम सममितीय असतो:

• Permissions साठी prompt करणाऱ्या receiving session ला प्रत्येक संदेश वितरित केला जातो. Sending session स्वतःची ओळख prompts bypass करणारे म्हणून देते, तेव्हाच तो संदेश राखून ठेवला जातो.
• Prompts bypass करणारी receiving session प्रत्येक संदेश तुमच्या मंजुरीसाठी राखून ठेवते. Sender देखील bypassing असेल, तेव्हाच संदेश वितरित केला जातो.

म्हणून बहुतेक लोक तयार करत असलेला पहिला workflow नेमका काम करत नाही. Unattended चालवण्यासाठी तुम्ही builder ला --permission-mode bypassPermissions सह सुरू करता, reviewer साठी default settings ठेवता आणि builder ने पाठवलेला प्रत्येक संदेश कोणीही पाहत नसलेल्या approval dialog मध्ये मंजुरीची वाट पाहत राहतो. dialogExpiry deadline संपल्यानंतर हा dialog बंद होतो. ही deadline default ने 5m असते आणि संदेश टाकून दिला जातो. त्याच machine वर sending session ला त्याचा संदेश राखून ठेवल्याची सूचना मिळते. Receiver नंतर तो वितरित, नाकारतो किंवा expire करतो तेव्हा follow-up सूचना मिळते. त्यामुळे socket ला दोष देण्यापूर्वी sender ची screen तपासा.

Session ने unattended पद्धतीने संदेश स्वीकारावेत यासाठी crossSessionInbound ला accept वर सेट करा. ते कुठे सेट करता यावर त्याचा लागू होण्याचा आवाका ठरतो. Claude Code प्रथम managed settings, त्यानंतर --settings flag आणि मग user settings वाचतो. त्याला सापडणारे पहिले मूल्य लागू केले जाते. Project किंवा local settings मधील मूल्य तेव्हाच लागू होते, जेव्हा ते accept < hold < refuse या क्रमवारीनुसार अधिक कडक असते. .claude/settings.json मधील accept कोणत्याही मूल्यापेक्षा कमी कडक असते. त्यामुळे trusted source ने मूल्य सेट केले असल्यास ते दुर्लक्षित केले जाते. ते ~/.claude/settings.json मध्ये ठेवा किंवा एका session साठी pass करा:

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

Headless claude -p worker interactive session प्रमाणे inbox socket bind करतो आणि listing मध्ये दिसतो. मात्र तो approval dialog दाखवू शकत नाही. त्यामुळे तेथील राखून ठेवलेला संदेश नंतरचा mode किंवा settings मधील बदल त्याला स्वीकारण्याची परवानगी देईपर्यंत तसाच राहतो. अशा worker ला संदेश स्वीकारण्याची परवानगी देण्यासाठी वरील --settings line वापरा. Bare mode मध्ये सुरू केलेली session कोणताही socket bind करत नाही. त्यामुळे ती संदेश receive करू शकत नाही आणि list मध्येही दिसत नाही.

हस्तांतरण कुठे ठप्प होते

संदेशांचे लूप तुमच्यासाठी हाताळले जातात. Claude Code प्रत्येक प्रेषकाकडून वारंवार येणाऱ्या संदेशांवर rate limit लागू करते, अल्प कालावधीत आलेल्या एकसारख्या पुनरावृत्ती संदेशांना टाकून देते आणि प्रत्येक session मध्ये वाचण्याची प्रतीक्षा करणाऱ्या स्वीकारलेल्या संदेशांची संख्या 50 पर्यंत मर्यादित ठेवते. त्यामुळे दोन session अनंतकाळ परस्परांना संदेश पाठवत राहू शकत नाहीत. साठवून ठेवलेल्या संदेशांची मर्यादा 100 आहे. त्यापेक्षा जास्त झाल्यास सर्वात जुने संदेश टाकून दिले जातात.

प्रत्यक्षात घडणारे अपयश अधिक शांतपणे होते. हा लूप नसून हस्तांतरणाची समस्या असते. Session A पुढे सुरू ठेवण्यापूर्वी आवश्यक असलेले उत्तर मिळवण्यासाठी session B ला प्रश्न विचारते आणि नंतर निष्क्रिय होते. B तो संदेश प्रलंबित ठेवते, किंवा B एखाद्या दीर्घ कामाच्या turn मध्ये असते, किंवा A ने प्रत्यक्षात विचारलेला नसलेला प्रश्न B चुकून सोडवते. A प्रतीक्षा करते. तुम्ही एका तासाने परत येता, तेव्हा दोन्ही session निष्क्रिय असतात आणि कोणतेही काम झालेले नसते.

उत्तराची आवश्यकता नसतील अशा पद्धतीने हस्तांतरणाचे संदेश लिहा. चांगल्या संदेशात एखादी वस्तुस्थिती किंवा निर्णय असतो: काय बदलले आणि त्याचा परिणाम काय झाला. वाईट संदेशात दुसऱ्या session कडून परवानगी किंवा प्रेषकाला अडवून ठेवणाऱ्या प्रश्नाचे उत्तर मागितलेले असते. Claude ला आधीच असे निर्देश दिले आहेत की स्वतःच्या permission settings मुळे ज्या कृतीला परवानगी मिळणार नाही, ती कृती करण्यासाठी दुसऱ्या session ला कधीही विचारू नये आणि ते काम त्याऐवजी तुमच्याकडे पाठवावे. हा नियम तुम्ही स्वतःही पुढे लागू करा. एखादे session उत्तराशिवाय पुढे जाऊ शकत नसेल, तर त्याचे उत्तर तुम्हीच द्यावे. Context discipline यामध्येही मदत करते, कारण ज्याचा संदर्भ तुटला आहे असे session अस्पष्ट संदेश लिहिते; Claude Code मध्ये context व्यवस्थापित करणे या बाजूचे स्पष्टीकरण देते.

आवक संदेश अविश्वसनीय इनपुट म्हणून हाताळा

Claude Code प्राप्त करणाऱ्या Claude ला सांगते की हा संदेश तुमच्याकडून नव्हे, तर दुसऱ्या session मधून आला आहे. तसेच हा संदेश काय करू शकतो यावर ती मर्यादा घालते. तुमच्या वतीने प्रलंबित permission prompt ला संदेश उत्तर देऊ शकत नाही, कारण दुसऱ्या session ची संमती ही तुमची संमती नाही. दुसऱ्या session ने सांगितले म्हणून तो permission settings, CLAUDE.md किंवा इतर configuration बदलू शकत नाही. मजकुरातील slash command, जसे /compact, plain text म्हणून येते आणि ती कधीही execute होत नाही. संदेशावर प्रक्रिया करण्यासाठी प्राप्त करणाऱ्या session कडे नसलेली permission आवश्यक असल्यास, इतर कोणत्याही कामासाठी दिसतो तसाच prompt तुम्हाला दिसतो. auto mode मध्ये delivery पूर्वी classifier प्रत्येक संदेशाचे परीक्षण करतो. classifier ने एखादा संदेश block केल्यास तो recipient पर्यंत पोहोचत नाही. या मर्यादा permissive modes मध्येही लागू राहतात. म्हणून bypass करणारे session inbound messages वर default ने hold करतात; त्यांच्यावर आपोआप विश्वास ठेवत नाहीत.

यामुळे permissions विषयीची बाब स्पष्ट होते. मात्र content बाबत हीच गोष्ट लागू होत नाही. पाठवणाऱ्या session ने pull request description, web page, dependency README किंवा अपरिचित व्यक्तीने लिहिलेली issue comment वाचलेली असू शकते. त्याने वाचलेली कोणतीही माहिती तुमच्या दुसऱ्या session साठी तो लिहीत असलेल्या मजकुरावर परिणाम करू शकते. हा संदेश data आहे. बाहेरून session मध्ये आलेल्या इतर कोणत्याही मजकुराप्रमाणेच त्याच्याकडे संशयाने पाहा. तुमच्या AI agents पासून secrets दूर ठेवणे या शिस्तीचे हेच तत्त्व आहे: trust boundary पार केलेली कोणतीही माहिती चुकीची असू शकते असे गृहीत धरा आणि तिला स्वतःला authorise करू देऊ नका.

हे कमी प्रमाणात हवे असल्यास दोन controls उपलब्ध आहेत. crossSessionInbound ची value refuse वर सेट केल्यास inbound peer messages deliver न करता discard केले जातात. project किंवा local settings मधून ही value सेट केल्यास ती इतर सर्व sources वर लागू होते, कारण ladder मधील ती सर्वात strict value आहे. या session कडून messages पाठवणे किंवा listings दाखवणे थांबवण्यासाठी SendMessage आणि ListAgents यांची नावे देणारे permission deny rules जोडा. दोन्ही bare tool names म्हणून, कोणत्याही specifier शिवाय लिहा. isolatePeerMachines ची value true वर सेट केल्यास या machine च्या बाहेरील session कडे कोणताही संदेश पोहोचण्यापूर्वी तुमची explicit approval आवश्यक होते. ही approval bypassPermissions mode मध्येही आवश्यक असते.

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

SendMessage नाकारणे subagents कडे messaging देखील बंद करते, कारण दोन्हींसाठी एकच tool वापरले जाते. नकार देणाऱ्या session च्या स्वतःच्या /status मध्ये किंवा इतर sessions च्या listings मध्ये कोणताही दृश्यमान बदल दिसत नाही. म्हणून setting पडद्यावरून नव्हे, तर session च्या configuration मधून पडताळा.

Bridges आणि shared memory MCP servers

याच कालावधीत अनेक third-party projects संबंधित पण वेगळ्या प्रकारची कामे करणारे उपलब्ध झाले. त्यात चालू agents मधील मजकूर relay करणारे local agent-to-agent bridges आणि अनेक agents ना एकाच shared store मधून वाचता व लिहिता येईल असे MCP (model context protocol) servers यांचा समावेश आहे. त्यांना competitor म्हणून नव्हे, तर वेगळ्या रचनेचा पर्याय म्हणून तपासा. कोणतीही install command चालवण्यापूर्वी ती संबंधित project च्या स्वतःच्या README मधील सूचनांशी पडताळा.

Messaging हे push स्वरूपाचे असते, कारण sender मजकूर receiver च्या turn मध्ये ठेवतो. Shared store हे pull स्वरूपाचे असते, कारण कोणत्याही session मध्ये व्यत्यय येत नाही आणि session पुढील वेळी ती नोंद पाहते तेव्हा तिला ती दिसते. हळूहळू बदलणाऱ्या status साठी pull अधिक शांत पद्धत आहे. मात्र session ने प्रत्यक्षात ती नोंद पाहिल्यावरच ती पद्धत कार्य करते.

तुम्ही हा मार्ग निवडल्यास, feature list पेक्षा process संदर्भातील प्रश्न अधिक महत्त्वाचे आहेत. Server कोणत्या user म्हणून चालतो? आणि तो box वरील कोणता data वाचू शकतो? VPS वर MCP servers चालवणे मध्ये त्या setup चे वर्णन आहे. repos मध्ये agent skills share करणे हा अधिक सोपा प्रकार स्पष्ट करते. Sessions मध्ये share करायची गोष्ट live state ऐवजी instructions असेल, तर ही पद्धत योग्य आहे. त्यामुळे अन्यथा पाठवाव्या लागणाऱ्या अनेक messages टाळता येतात. व्यापक संदर्भासाठी VPS वर coding agent चालवणे येथून सुरुवात करा.

FAQ

माझ्या session मध्ये /list-agents ओळखले का जात नाही?

या session मध्ये cross-session messaging उपलब्ध नाही. प्रथम claude --version ची 2.1.224 शी तुलना करा, कारण या सुविधेसाठी ही आवृत्ती किंवा त्यानंतरची आवृत्ती आवश्यक आहे. त्यानंतर 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 रोखतो. त्यामुळे ही सुविधा बंद राहते.

दुसऱ्या session ला पाठवलेला माझा message कधीच का पोहोचला नाही?

/list-agents कार्यरत असल्यास messaging सुरू आहे आणि त्या message ला दुसऱ्या कारणामुळे अडथळा आला आहे. याचे सामान्य कारण म्हणजे permission modes. permission prompts bypass करणारा session प्रत्येक inbound message तुमच्या मंजुरीसाठी धरून ठेवतो, जोपर्यंत sender देखील prompts bypass करत नाही. dialogExpiry ची deadline संपल्यानंतर, default स्वरूपात पाच मिनिटांनी, हा approval dialog टाकून दिला जातो. held notice साठी sending session तपासा. हे दुरुस्त करण्यासाठी ~/.claude/settings.json मध्ये crossSessionInbound चे मूल्य accept असे सेट करा किंवा ते --settings सह द्या. कारण project किंवा local settings मधील accept हे अधिक सैल मूल्य असल्यामुळे दुर्लक्षित केले जाते.

Docker मधील Claude Code session host वरील session ला message पाठवू शकतो का?

नाही. Sessions disk वरील registration files आणि प्रत्येक session साठी असलेल्या inbox socket द्वारे एकमेकांना शोधतात. Container चे filesystem स्वतंत्र असल्यामुळे दोन्ही sessions ना समान files दिसत नाहीत. एकाच container मधील दोन sessions एकमेकांना नेहमीप्रमाणे message पाठवू शकतात. root म्हणून चालणारा session आणि तुमचा सामान्य user म्हणून चालणारा session एकमेकांपर्यंत पोहोचू शकत नाहीत, हे देखील याच नियमामुळे स्पष्ट होते. Socket वर तो ज्या operating system user च्या मालकीचा आहे त्याच user साठी प्रवेश मर्यादित असतो.

दुसऱ्या Claude Code session कडून आलेल्या message वर कृती करणे सुरक्षित आहे का?

त्या text कडे अविश्वसनीय input म्हणून पाहा, कारण पाठवणाऱ्या session ने एखादे web page, README किंवा दुसऱ्या व्यक्तीने लिहिलेली issue comment वाचलेली असू शकते. Claude Code स्वतःहून message वर कृती करण्यापासून आधीच थांबवतो. तो pending permission prompt मंजूर करू शकत नाही, विनंतीवर permission settings किंवा CLAUDE.md बदलू शकत नाही, आणि text मधील slash command plain text म्हणून येतो व कधीही चालत नाही. ही संरक्षणे permissions पुरती मर्यादित आहेत; judgement साठी नाहीत. त्यामुळे receiving session ला कृती करण्यास सांगण्यापूर्वी आलेला मजकूर वाचा.

Cross-session messaging माझा code Anthropic कडे पाठवते का?

एकाच machine वरील दोन sessions दरम्यान, नाही. Message त्या machine वरील प्रत्येक session साठी असलेल्या socket द्वारे पाठवला जातो आणि Anthropic servers मधून जात नाही. तसेच फक्त Claude ने लिहिलेला text पाठवला जातो; conversation history किंवा files कधीही पाठवल्या जात नाहीत. तुमच्या दुसऱ्या machine वरील session ला किंवा web वरील session ला पाठवलेले messages मात्र Remote Control connection द्वारे Anthropic servers मधून जातात. या दिशेने Claude फक्त आलेल्या message ला reply करू शकतो; स्वतःहून message सुरू करू शकत नाही. Machine बाहेर काहीही जाण्यापूर्वी तुमची मंजुरी आवश्यक करण्यासाठी isolatePeerMachines चे मूल्य true असे सेट करा.