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

Claude Code सत्रांनी एकमेकांना संदेश पाठवणे म्हणजे काय

दोन Claude Code सत्रे एकाच मशीनवर आणि त्याच operating system user अंतर्गत चालत असतील, तर ती एकमेकांना संदेश पाठवू शकतात. संदेश म्हणजे एका Claude ने दुसऱ्या Claude साठी लिहिलेला plain text चा एक भाग. त्यामध्ये conversation history किंवा files नसतात. 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, AWS वरील Claude Platform, Google Cloud's Agent Platform किंवा Microsoft Foundry वर हे उपलब्ध नाही. एखादे सत्र या आवश्यकता पूर्ण करत असेल, तर messaging आधीपासून enabled असते आणि ते enable करण्यासाठी काहीही करावे लागत नाही. खाली वर्णन केलेले वर्तन cross-session messaging साठी Anthropic documentation वर आधारित आहे.

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

दुसरे सत्र वापरणे कधी योग्य ठरते

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

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

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

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

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

प्रथम आवृत्ती तपासा:

claude --version

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

एका बाबतीत VPS वापरकर्त्यांना विशेषतः अडचण येते. 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 चे hardening करताना लोक हे 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 चा value दिसतो तो unset करा. DISABLE_TELEMETRY आणि CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC साठी कोणताही non-empty value हे behaviour सुरू करतो. त्यात 0 ही string देखील समाविष्ट आहे. त्यामुळे DISABLE_TELEMETRY=0 दिसते तसे काम करत नाही. हे बंद करण्यासाठी variable unset करा किंवा त्याला empty string द्या.

तुमच्या sessions ना नावे द्या; अन्यथा Claude त्यांना address करू शकत नाही

Claude message ला नावानुसार session कडे address करते. 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 सोबत short identifier देखील जोडला जातो. स्वतः नावे देणे हे identifiers वाचण्यापेक्षा सोपे आहे.

दोन session असलेली पुन्हा तयार करता येणारी tmux मांडणी

ही एकाच repository वरील builder session आणि reviewer session आहे. reviewer स्वतंत्र git worktree मध्ये काम करतो, त्यामुळे दोन्ही session एकाच फाइलमध्ये कधीही लिहित नाहीत. git worktree add सोबत HEAD वापरल्यास detached checkout मिळतो. commit करण्याऐवजी फक्त वाचणाऱ्या session साठी हेच आवश्यक आहे. दोन्ही session वेगवेगळी कामे करतात. त्यामुळे reviewer साठी स्वतंत्र output style देणे उपयुक्त ठरते. यामुळे त्या session चा system prompt बदलतो आणि तुम्ही एकदा टाइप केलेल्या instruction प्रमाणे तो हळूहळू दुर्लक्षित होत नाही; प्रत्येक turn मध्ये तो लागू राहतो.

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 लिहून ती पाठवतो. message text तुम्ही लिहीत नाही आणि Claude काय पाठवेल हे बदलू शकते. reviewer window मध्ये sender च्या नावासह message conversation मध्ये दिसतो. ती session idle असल्यास Claude त्यावर लगेच नवीन turn सुरू करतो. ती session mid-turn मध्ये असल्यास message tool calls मधील अंतरापर्यंत थांबतो. त्यामुळे चालू command मध्ये व्यत्यय येत नाही. Claude ने message वाचल्यानंतर तो एका ओळीच्या Message from row मध्ये संक्षिप्त होतो आणि Ctrl+O तो विस्तारते. builder ने त्यातील बदल लहान ठेवले तर ही जोडी अधिक चांगली काम करते. अरुंद diff मुळे hand-off लहान राहतो आणि दुसरी session एका turn मध्ये review पूर्ण करू शकते. हाच सवय निर्माण करण्याचा नियम the lazy senior dev skill लागू करण्याचा उद्देश आहे.

एका VPS वर कोणाला कोण दिसू शकते

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

हा 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 Remote Control connected असतानाच listing मध्ये दिसतात. त्यांना त्याप्रमाणे label केलेले असते. येथे Claude फक्त त्या sessions पैकी एखाद्याकडून आलेल्या message ला reply करू शकतो. तो स्वतःहून तो exchange सुरू करू शकत नाही.

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

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

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

• Permissions साठी prompting करणाऱ्या प्राप्त सत्राला प्रत्येक संदेश वितरित केला जातो. पाठवणारे सत्र prompts bypass करत असल्याचे स्वतःची ओळख देत असेल, तरच तो संदेश hold केला जातो.
• Prompts bypass करणारे प्राप्त सत्र तुमच्या मंजुरीसाठी प्रत्येक संदेश hold करते. पाठवणारे सत्र देखील bypass करत असेल, तरच तो संदेश वितरित केला जातो.

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

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

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

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

हँड-ऑफ कुठे अडकतात

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

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

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

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

Claude Code प्राप्त करणाऱ्या Claude ला हा संदेश तुमच्याकडून नव्हे, तर दुसऱ्या session मधून आला आहे असे कळवते आणि त्या संदेशाद्वारे काय करता येईल यावर मर्यादा घालते. ही अंमलबजावणी model च्या अनुपालनाच्या इच्छेऐवजी model भोवती असलेल्या program मध्ये असते. हाच agent harness चा व्यावहारिक फरक आहे. प्रलंबित permission prompt ला तुमच्या वतीने संदेश उत्तर देऊ शकत नाही, कारण दुसऱ्या session ची संमती ही तुमची संमती नाही. दुसऱ्या session ने सांगितले म्हणून तो permission settings, CLAUDE.md किंवा इतर configuration बदलू शकत नाही. मजकुरातील /compact सारखा slash command plain text म्हणून येतो आणि कधीही execute होत नाही. संदेशावर कृती करण्यासाठी receiving session कडे नसलेली permission आवश्यक असल्यास, इतर कोणत्याही कामासाठी दिसतो तोच prompt तुम्हाला दिसतो. auto mode मध्ये delivery करण्यापूर्वी classifier प्रत्येक संदेशाचे पुनरावलोकन करतो. classifier ने रोखलेला संदेश recipient पर्यंत पोहोचत नाही. हे निर्बंध permissive modes मध्येही लागू राहतात. त्यामुळे bypassing session inbound messages वर default ने hold ठेवते आणि त्यांच्यावर विश्वास ठेवत नाही.

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

यापैकी कमी संदेश हवे असल्यास दोन controls उपलब्ध आहेत. crossSessionInbound ची value refuse वर सेट केल्यास inbound peer messages deliver न करता drop केले जातात. project किंवा local settings मधून ही value इतर सर्व sources वर लागू होते, कारण ladder मधील ती सर्वात strict value आहे. या session मधून sending किंवा listing थांबवण्यासाठी 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 दरम्यान text relay करणारे local agent-to-agent bridges आणि अनेक agents ना एकाच shared store मधून read आणि write करण्याची सुविधा देणारे MCP (model context protocol) servers. त्यांना competitor म्हणून नव्हे, तर वेगळ्या रचनेचा पर्याय म्हणून तपासा. कोणतीही install command चालवण्यापूर्वी ती संबंधित project च्या स्वतःच्या README शी पडताळा. Messaging हे push पद्धतीचे असते, कारण sender receiver च्या turn मध्ये text ठेवतो. Shared store हे pull पद्धतीचे असते, कारण कोणत्याही session मध्ये व्यत्यय येत नाही आणि session पुढच्या वेळी तपासते तेव्हा तिला ती note दिसते. हळूहळू बदलणाऱ्या status साठी pull पद्धत अधिक शांत असते. मात्र session ने प्रत्यक्षात ते तपासले तरच ती कार्य करते.

हा पर्याय निवडल्यास feature list पेक्षा process विषयी प्रश्न विचारणे अधिक महत्त्वाचे आहे. Server कोणत्या user म्हणून चालतो आणि box वरील कोणता data तो read करू शकतो? VPS वर MCP servers चालवणे मध्ये त्या setup चे वर्णन आहे. repos दरम्यान agent skills share करणे या सोप्या प्रकरणाचे वर्णन करते. Sessions दरम्यान live state ऐवजी instructions share करायच्या असल्यास हा पर्याय योग्य आहे आणि अन्यथा पाठवाव्या लागणाऱ्या अनेक 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 येणारा प्रत्येक message तुमच्या मंजुरीसाठी थांबवतो, जोपर्यंत पाठवणारा session देखील bypass करत नाही. dialogExpiry ची मुदत संपल्यानंतर, जी default ने five minutes आहे, ती approval dialog वगळली जाते. थांबवलेली सूचना पाठवणाऱ्या 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 वर कृती करणे सुरक्षित आहे का?

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

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

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