Claude Code sessions మధ్య messages ఎలా పంపాలి

Claude Code sessions పరస్పరం సందేశాలు పంపుకోవడం అంటే ఏమిటి

ఒకే machineలో, ఒకే operating system user కింద నడుస్తున్నప్పుడు రెండు Claude Code sessions పరస్పరం సందేశాలు పంపుకోగలవు. ఒక Claude మరొకదాని కోసం రాసే plain textలోని ఒక భాగమే message. ఇందులో conversation history లేదా files ఉండవు. Claude మరొక sessionను ListAgents toolతో కనుగొని, textను SendMessageతో పంపుతుంది. అందువల్ల మీరు ఈ రెండు toolsలో దేనినీ చేతితో call చేయాల్సిన అవసరం లేదు. మరొక sessionకు ఏ సమాచారం అవసరమో మీరు చెబితే, Claude ఆ messageను స్వయంగా రాస్తుంది.

ఈ featureను cross-session messaging అంటారు. August 2026 నాటికి దీనికి Claude Code v2.1.224 లేదా తరువాతి version అవసరం. ఇది macOS మరియు Linuxలో, WSL 2లోని Linuxతో సహా, పనిచేస్తుంది. Native Windows support లేదు. Amazon Bedrock, AWSలోని Claude Platform, Google Cloud's Agent Platform లేదా Microsoft Foundryలో ఇది అందుబాటులో లేదు. ఒక session ఈ అవసరాలను తీర్చినప్పుడు messaging ఇప్పటికే enabledగా ఉంటుంది. దీన్ని enable చేయడానికి ఏమీ చేయాల్సిన అవసరం లేదు. క్రింద వివరించిన ప్రవర్తన cross-session messagingకు సంబంధించిన Anthropic documentation ఆధారంగా ఉంది.

VPSలో ఈ feature ఉపయోగకరంగా ఉంటుంది. ఎందుకంటే sessions ఉపయోగకరంగా ఉండేంతకాలం అక్కడ నడుస్తుంటాయి. Laptopలో మీరు lid మూసేస్తారు. కానీ tmux కింద serverలో ప్రారంభించిన session Mondayన ప్రారంభించినప్పటికీ Thursdayనూ నడుస్తూ ఉంటుంది. అది ఒక repositoryకి సంబంధించిన contextను అలాగే ఉంచుతుంది. అలాంటి sessions రెండు ఉన్నప్పుడు, అవి ఎలా మాట్లాడుకుంటాయన్నది కేవలం సిద్ధాంతం కాదు. మీరు ఇంకా దీన్ని setup చేయకపోతే, ఈ guide ఊహించే session plumbingను వివరించే tmux కింద VPSపై Claude Code నడపడంతో ప్రారంభించండి.

టోకెన్ల ఖర్చుకు అనుగుణంగా రెండవ session ఉపయోగకరమైనప్పుడు

ముందుగా ఖర్చును పరిగణించండి. ప్రతి session తన స్వంత context window కలిగిన ప్రత్యేక Claude instance. అందువల్ల ఒకే కాలవ్యవధిలో రెండు sessions ఉపయోగిస్తే, ఒక session తో పోలిస్తే ఖర్చు సుమారుగా రెండింతలు అవుతుంది. మీరు టైప్ చేసిన prompt లాగే పంపిన message కూడా usage లో లెక్కించబడుతుంది. Coordination ఉచితం కాదు. వాస్తవానికి ఒకే క్రమంలో జరిగే దశలను sessions మధ్య విభజిస్తే పని మరింత నెమ్మదిగా, ఖరీదుగా మారుతుంది.

రెండవ session తన ఖర్చును సమర్థించే సందర్భాలకు ఒకే లక్షణం ఉంటుంది. రెండు పనులు ఒకదానికొకటి వేచి ఉండకుండా సమాంతరంగా నడుస్తాయి. వాటిలో ఒకటి పని మధ్యలో మరొకదానికి అవసరమైన సమాచారాన్ని కనుగొంటుంది.

• ఒక session breaking change ను కనుగొంటుంది. మరొక session ఆ మార్పుతో ప్రభావితమైన code పై పని చేస్తుంది. మీరు దాన్ని మరో terminal లో మళ్లీ టైప్ చేయాల్సిన బదులు, Claude ఆ మార్పును సంక్షిప్తంగా వివరించి పంపుతుంది.
• రెండు sessions వేర్వేరు git worktrees లో ఒకే repository పై పని చేస్తాయి. వాటిలో ఒకదానికి ఏ మార్పులు చేర్చబడ్డాయో తెలుసుకోవాలి.
• దీర్ఘమైన migration లేదా test run తన ఫలితాన్ని మీరు పర్యవేక్షిస్తున్న session కు పంపుతుంది.
• ఒక builder session మరియు ఒక reviewer session ఉంటాయి. reviewer, builder రూపొందించినదాన్ని చదివి, తన పరిశీలనలను తిరిగి పంపుతుంది.

పని క్రమానుసారంగా జరిగితే లేదా రెండు sessions ఒకే files ను సవరించాల్సి ఉంటే, ఒక session ను ఉపయోగించండి. ఒకే task లో Claude స్వయంగా ప్రారంభించి పర్యవేక్షించే coordinated group కావాలంటే, అది agent teams. ఇది వేరు మరియు ఇంకా experimental feature. అదే conversation ను మరో terminal లో మాత్రమే కొనసాగించాలనుకుంటే, session ను resume చేయండి. Cross-session messaging అనేది మీరు స్వయంగా ప్రారంభించి, నియంత్రించే independent sessions కోసం ఉపయోగించాలి.

ఆ ఫీచర్ ఉందో లేదో ముందుగా తనిఖీ చేయండి

ముందుగా version:

claude --version

ఆ సంఖ్యను 2.1.224తో పోల్చండి. తరువాత session లో /list-agents టైప్ చేయండి. ఇది /peers కు కూడా స్పందిస్తుంది. ఈ session చేరుకోగల ప్రతి 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 state లోనే ఉంటుంది. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, మరియు DISABLE_GROWTHBOOK ఇవన్నీ ఇదే చేస్తాయి. కొత్త server ను 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 ను unset చేయండి. DISABLE_TELEMETRY మరియు CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC విషయంలో, ఖాళీ కాని ఏ value అయినా ఈ ప్రవర్తనను on చేస్తుంది. 0 string కూడా ఇందుకు మినహాయింపు కాదు. అందువల్ల DISABLE_TELEMETRY=0 కనిపిస్తున్న విధంగా పనిచేయదు. దీన్ని off చేయడానికి variable ను unset చేయండి లేదా దానికి ఖాళీ string ను set చేయండి.

మీ 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 కు చిన్న identifier ను జోడిస్తుంది. Identifierలను పరిశీలించడంకన్నా sessions కు మీరే పేర్లు ఇవ్వడం సులభం.

పునరుత్పత్తి చేయగల రెండు-session tmux layout

ఇది ఒకే repositoryలోని builder session మరియు reviewer session. Reviewer ప్రత్యేక git worktreeలో పనిచేస్తుంది. అందువల్ల రెండు sessionలు ఒకే fileను ఎప్పుడూ రాయవు. 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 windowలను వాటి పేర్లతో చూపిస్తుంది. అందువల్ల కావాల్సిన windowను ఎంచుకోవచ్చు. builder windowలో /list-agents ను అమలు చేయండి. దాని working directoryగా ~/src/api-review తో reviewer-api కనిపించాలి. అది కనిపించకపోతే 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 ప్రారంభిస్తుంది. అది mid-turnలో ఉంటే, tool calls మధ్య వరకు message వేచి ఉంటుంది. అందువల్ల నడుస్తున్న commandకు అంతరాయం కలగదు. Claude దాన్ని చదివిన తర్వాత, message ఒక వరుసలోని Message from rowగా కుదించబడుతుంది. Ctrl+O దాన్ని విస్తరిస్తుంది. Builder తన మార్పులను చిన్నవిగా ఉంచినప్పుడు ఈ జంట మరింత సమర్థంగా పనిచేస్తుంది. చిన్న diff వల్ల hand-off సంక్షిప్తంగా ఉంటుంది. అలాగే మరో session reviewను ఒకే turnలో పూర్తి చేయగలదు. the lazy senior dev skill అమలు చేయించేది ఈ అలవాటే.

ఒక VPSలో ఎవరు ఎవరిని చూడగలరు

ఒకే మెషీన్‌లో జరిగే delivery ఎప్పుడూ Anthropic servers ద్వారా సాగదు. ప్రతి session registration files ను disk కు వ్రాసి, తనకంటూ ఒక 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 సాధారణంగా ఒకదానికొకటి messages పంపగలవు. isolation కోసం agents ను containers లో ఉంచితే, తాత్కాలిక VMలో coding agents ను నడపడం లాగా, messaging ఒక container లోపల పనిచేస్తుందని, కానీ container boundary దాటి పనిచేయదని భావించండి.

ఇతర machines పై, అలాగే web పై ఉన్న మీ sessions, Remote Control కనెక్ట్ అయి ఉన్నంతకాలం మాత్రమే listing లో కనిపిస్తాయి. అవి ఆ విధంగానే label చేయబడతాయి. వాటిలో ఒకదాని నుంచి వచ్చిన message కు మాత్రమే ఇక్కడి Claude reply ఇవ్వగలదు. ఆ exchange ను Claude స్వయంగా ప్రారంభించలేదు.

మీ సందేశం ఎందుకు చేరలేదు

సాధారణంగా దీనికి నెట్‌వర్క్‌తో సంబంధం ఉండదు. స్వీకరించే session ఆ సందేశంతో ఏమి చేయాలో నిర్ణయించింది. ఆ నిర్ణయం దాన్ని deliver చేయకూడదనేది. వచ్చే ప్రతి సందేశం మూడు ఫలితాల్లో ఒకదానితో ముగుస్తుంది: delivered, held (మీరు approve చేసే వరకు deliver చేయకుండా పక్కన ఉంచడం), లేదా refused (deliver చేయకుండా తొలగించడం).

ఏ crossSessionInbound value వర్తించనప్పుడు, రెండు sessions permission modes ను పోల్చి Claude Code ప్రతి సందేశానికి నిర్ణయం తీసుకుంటుంది. Permission prompts ను bypass చేసే sessions ను ఒక class గా, మిగిలిన sessions ను మరో class గా సమూహపరుస్తుంది. auto, acceptEdits, మరియు dontAsk prompting గా పరిగణించబడతాయి. Permissions bypass చేయగల అవకాశం ఉన్న session లో Plan mode ను bypassing గా పరిగణిస్తుంది. ఒక session ఏ class లోకి వస్తుందో స్పష్టంగా తెలియకపోతే, ప్రతి permission mode వాస్తవంగా ఏమి చేస్తుందో ముందుగా చదవడం ఉపయోగకరం. ఎందుకంటే ప్రస్తుతం ఎక్కువ sessions auto తో ప్రారంభమవుతాయి, అది ఈ విభజనలో prompting వైపు ఉంటుంది. తరువాతి నియమం symmetric గా ఉంటుంది:

• Permissions కోసం prompt చేసే receiving session ప్రతి సందేశాన్ని deliver చేస్తుంది. Sending session prompts ను bypass చేస్తున్నదని గుర్తిస్తే మాత్రమే దాన్ని hold చేస్తుంది.
• Prompts ను bypass చేసే receiving session ప్రతి సందేశాన్ని మీ approval కోసం hold చేస్తుంది. Sender కూడా bypass చేస్తున్నప్పుడు మాత్రమే దాన్ని deliver చేస్తుంది.

అందువల్ల చాలామంది మొదట రూపొందించే workflow పనిచేయదు. Unattended గా నడపాలని మీరు builder ను --permission-mode bypassPermissions తో ప్రారంభిస్తారు, reviewer ను default settings లోనే వదిలేస్తారు. అప్పుడు builder పంపే ప్రతి సందేశం ఎవరూ చూడని approval dialog లో వేచి ఉంటుంది. ఆ dialog dialogExpiry deadline ముగిసిన తర్వాత మూసివేయబడుతుంది. ఆ deadline యొక్క default విలువ 5m. తరువాత సందేశం drop చేయబడుతుంది. అదే machine లో sending session తన సందేశం hold అయినప్పుడు notification పొందుతుంది. Receiver తరువాత దాన్ని deliver, deny లేదా expire చేసినప్పుడు follow-up notification కూడా వస్తుంది. అందువల్ల socket ను నిందించే ముందు sender screen ను పరిశీలించండి.

ఒక session messages ను unattended గా స్వీకరించాలంటే, crossSessionInbound ను accept కు set చేయండి. మీరు దాన్ని ఎక్కడ set చేస్తారో దాని వర్తింపు నిర్ణయించబడుతుంది. Claude Code ముందుగా managed settings ను, తరువాత --settings flag ను, ఆ తరువాత user settings ను చదువుతుంది. కనుగొన్న మొదటి value ను వర్తింపజేస్తుంది. Project లేదా local settings లోని value, accept < hold < refuse అనే ladder లో అది మరింత strict అయినప్పుడు మాత్రమే వర్తిస్తుంది. .claude/settings.json లోని accept ఏ value కంటే అయినా looser గా ఉంటుంది. అందువల్ల trusted source value ను set చేసినప్పుడు అది ignore చేయబడుతుంది. దాన్ని ~/.claude/settings.json లో ఉంచండి, లేదా ఒక session కోసం pass చేయండి:

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

Headless claude -p worker interactive session మాదిరిగానే inbox socket కు bind అవుతుంది మరియు listing లో కనిపిస్తుంది. అయితే అది approval dialog ను చూపించలేడు. అక్కడ held message, తరువాతి mode లేదా settings మార్పు దాన్ని అనుమతించే వరకు held గానే ఉంటుంది. ఇలాంటి worker messages ను స్వీకరించడానికి పై --settings line ఉపయోగించాలి. Bare mode లో ప్రారంభమైన session ఏ socket కు bind అవదు. అందువల్ల అది messages ను receive చేయలేను, list లో కనిపించదు.

హ్యాండ్ఆఫ్‌లు ఎక్కడ నిలిచిపోతాయి

సందేశాల లూప్‌లను Claude Code మీ కోసం నిర్వహిస్తుంది. Claude Code ఒక sender నుంచి వచ్చే పునరావృత సందేశాలకు rate limit విధిస్తుంది, తక్కువ వ్యవధిలో వచ్చిన ఒకే విధమైన పునరావృత సందేశాలను తొలగిస్తుంది, అలాగే ప్రతి session‌లో చదవడానికి వేచి ఉన్న స్వీకరించిన సందేశాలను 50కి పరిమితం చేస్తుంది. అందువల్ల రెండు session‌లు నిరంతరం ping-pong చేయలేవు. నిల్వలో ఉన్న సందేశాల సంఖ్య 100కి పరిమితం అవుతుంది. ఆ పరిమితి దాటితే పాత సందేశాలు తొలగించబడతాయి.

నిజంగా సంభవించే వైఫల్యం మరింత నిశ్శబ్దంగా ఉంటుంది. అది loop కాదు, hand-off సమస్య. Session A కొనసాగడానికి ముందుగా session B సమాధానం ఇవ్వాల్సిన ప్రశ్న అడిగి idleగా ఉంటుంది. B ఆ సందేశాన్ని అలాగే ఉంచవచ్చు, లేదా సుదీర్ఘమైన పనిపై మధ్యలో ఉండవచ్చు, లేదా A నిజంగా అడగని ప్రశ్నకు సమాధానం ఇవ్వవచ్చు. A వేచి ఉంటుంది. మీరు ఒక గంట తర్వాత తిరిగి వచ్చేసరికి రెండు idle session‌లు ఉంటాయి, కానీ పని పూర్తికాలేదు.

సమాధానం అవసరం లేని hand-off‌లను రాయండి. మంచి సందేశం ఒక వాస్తవాన్ని లేదా నిర్ణయాన్ని అందిస్తుంది: ఏమి మారింది, ఫలితం ఏమిటి. చెడు సందేశం ఇతర session నుంచి అనుమతి లేదా sender ముందుకు సాగకుండా అడ్డుకుపోయిన ప్రశ్నకు సమాధానం కోరుతుంది. తన permission settings అనుమతించని చర్యను మరొక session‌ను అడగకూడదని Claude‌కు ఇప్పటికే సూచించబడింది. అలాంటి పనిని తిరిగి మీకు పంపాలి. ఈ నియమాన్ని మీరే కూడా విస్తరించండి. సమాధానం లేకుండా session ముందుకు సాగలేకపోతే, దానికి సమాధానం ఇవ్వాల్సింది మీరే. Context discipline కూడా ఇక్కడ సహాయపడుతుంది. సందర్భాన్ని కోల్పోయిన session అస్పష్టమైన సందేశాలను రాస్తుంది; Claude Codeలో context నిర్వహణ ఆ అంశాన్ని వివరిస్తుంది.

వచ్చే సందేశాన్ని నమ్మకంలేని ఇన్‌పుట్‌గా పరిగణించండి

Claude Code, ఈ సందేశం మీ నుంచి కాకుండా మరొక session నుంచి వచ్చిందని స్వీకరించే Claude కు తెలియజేస్తుంది. ఆ సందేశం చేయగల పనులపై కూడా పరిమితులు విధిస్తుంది. ఈ అమలు, model సమ్మతించాలనే దాని సిద్ధతలో కాకుండా, model చుట్టూ ఉన్న program లో జరుగుతుంది. ఇదే agent harness అందించే ప్రాయోగిక తేడా. పెండింగ్‌లో ఉన్న permission prompt కు మీ తరఫున సందేశం సమాధానం ఇవ్వలేదు, ఎందుకంటే మరొక session నుంచి వచ్చిన సమ్మతి మీ సమ్మతి కాదు. మరొక session అడిగిందనే కారణంతో అది permission settings, CLAUDE.md లేదా ఇతర configuration ను మార్చలేదు. /compact వంటి slash command సందేశంలోని text లో ఉంటే, అది plain text గా వస్తుంది. అది ఎప్పటికీ execute కాదు. ఆ సందేశంపై చర్య తీసుకోవడానికి స్వీకరించే session కు లేని permission అవసరమైతే, ఇతర పనులకు కనిపించే అదే prompt మీకు కనిపిస్తుంది. auto mode లో ప్రతి సందేశాన్ని delivery కి ముందు classifier కూడా పరిశీలిస్తుంది. classifier నిరోధించిన సందేశం recipient కు ఎప్పటికీ చేరదు. ఈ పరిమితులు permissive modes లో కూడా కొనసాగుతాయి. అందుకే bypassing session inbound messages ను default గా నిలిపి ఉంచుతుంది, వాటిని నమ్మదు.

ఇది permissions గురించి మాత్రమే. Content గురించి కాదు. పంపే session ఒక pull request description, web page, dependency README లేదా అపరిచితుడు రాసిన issue comment ను చదివి ఉండవచ్చు. అది చదివిన ఏదైనా text, మీ మరో session కు రాసే సందేశాన్ని ప్రభావితం చేయవచ్చు. ఆ సందేశం data మాత్రమే. బయట నుంచి session లోకి వచ్చిన ఇతర text లాగే దానిపైనా అనుమానం ఉంచాలి. మీ AI agents లో secrets ను ఉంచకుండా ఉండటం అనే నియమం ఇదే: trust boundary దాటిన ఏదైనా తప్పు కావచ్చని భావించండి. అది తనకు తానే authorise చేసుకునేలా ఎప్పుడూ అనుమతించవద్దు.

ఇలాంటి సందేశాలను తగ్గించాలనుకుంటే రెండు controls ఉన్నాయి. crossSessionInbound ను refuse కు set చేస్తే inbound peer messages delivery లేకుండానే drop అవుతాయి. project లేదా local settings నుంచి ఈ value ప్రతి ఇతర source కంటే ప్రాధాన్యంగా ఉంటుంది, ఎందుకంటే ladder లో ఇదే strictest value. ఈ session sending లేదా listing చేయకుండా ఆపడానికి SendMessage మరియు ListAgents పేర్లతో permission deny rules జోడించండి. రెండింటినీ specifier లేకుండా bare tool names గా రాయాలి. isolatePeerMachines ను true కు set చేస్తే, ఈ machine దాటి ఉన్న session కు ఏదైనా message చేరే ముందు మీ explicit approval అవసరం. bypassPermissions mode లో కూడా ఈ approval తప్పనిసరి.

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

SendMessage ను deny చేయడం వల్ల subagents కు messaging కూడా తొలగిపోతుంది, ఎందుకంటే రెండింటికీ అదే tool ఉపయోగించబడుతుంది. నిరాకరించే session తన స్వంత /status లో లేదా ఇతర sessions listings లో కనిపించే మార్పును చూపదు. అందువల్ల screen ఆధారంగా కాకుండా, session configuration నుంచి setting ను నిర్ధారించండి.

Bridges మరియు shared memory MCP servers

అదే కాలంలో మరికొన్ని third-party projects సంబంధితమైన, కానీ భిన్నమైన విధానంతో వచ్చాయి: నడుస్తున్న agents మధ్య text ను relay చేసే local agent-to-agent bridges, అలాగే అనేక agents ఒకే shared store లో చదవడానికి, వ్రాయడానికి వీలు కల్పించే MCP (model context protocol) servers. వీటిని పోటీదారులుగా కాకుండా భిన్నమైన నిర్మాణంగా అంచనా వేయండి. ఏదైనా install command నడిపే ముందు, దాన్ని project యొక్క స్వంత README తో నిర్ధారించండి. Messaging అనేది push విధానం, ఎందుకంటే sender text ను receiver యొక్క turn లోకి ఉంచుతుంది. Shared store అనేది pull విధానం, ఎందుకంటే ఎవరూ అంతరాయం కలిగించరు. Session తర్వాతిసారి note ను పరిశీలించినప్పుడు దాన్ని చూస్తుంది. నెమ్మదిగా మారే status కోసం pull ప్రశాంతమైన విధానం. అయితే session నిజంగా దాన్ని పరిశీలించినప్పుడే ఇది పనిచేస్తుంది.

మీరు ఈ విధానాన్ని ఎంచుకుంటే, పరిశీలించాల్సిన ప్రశ్నలు feature list గురించి కాకుండా process గురించి ఉండాలి. Server ఏ user గా నడుస్తుంది? అది system లో ఏ data ను చదవగలదు? VPS పై MCP servers నడపడం ఆ setup ను వివరిస్తుంది. Sessions మధ్య share చేయాలనుకుంటున్నది live state కాకుండా instructions అయితే, repos మధ్య agent skills share చేయడం మరింత సరళమైన సందర్భాన్ని వివరిస్తుంది. మీరు లేకపోతే పంపాల్సి వచ్చే అనేక messages ను అది తొలగిస్తుంది. విస్తృత దృశ్యం కోసం VPS పై coding agent నడపడం తో ప్రారంభించండి.

FAQ

నా session లో /list-agents ఎందుకు గుర్తించబడటం లేదు?

ఈ session కు cross-session messaging అందుబాటులో లేదు. ముందుగా claude --version ను 2.1.224 తో పోల్చి చూడండి, ఎందుకంటే ఈ feature కు ఆ version లేదా తరువాతి version అవసరం. తరువాత 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 ఆధారపడే feature-flag evaluation ను అడ్డుకుని, దాన్ని నిలిపివేస్తుంది.

మరో session కు పంపిన నా message ఎందుకు ఎప్పటికీ చేరలేదు?

/list-agents పనిచేస్తే messaging ప్రారంభించబడి ఉంది. ఆ message ను మరింత నిర్దిష్టమైన ఏదో కారణం ఆపి ఉండవచ్చు. సాధారణ కారణం permission modes. Permission prompts ను bypass చేసే session ప్రతి inbound message ను మీ approval కోసం నిలిపి ఉంచుతుంది, sender కూడా bypass చేయకపోతే ఇదే జరుగుతుంది. ఆ approval dialog dialogExpiry deadline తర్వాత తొలగించబడుతుంది. Default గా ఈ గడువు five minutes. నిలిపి ఉంచిన notice కోసం sending session ను పరిశీలించండి. దీన్ని సరిచేయడానికి ~/.claude/settings.json లో crossSessionInbound ను accept గా set చేయండి లేదా --settings తో pass చేయండి. ఎందుకంటే project లేదా local settings లోని accept తక్కువ కఠినమైన value కావడంతో ignore చేయబడుతుంది.

Docker లోని Claude Code session host పై ఉన్న session కు message పంపగలదా?

లేదు. Sessions disk పై ఉన్న registration files మరియు ప్రతి session కు ప్రత్యేకమైన inbox socket ద్వారా ఒకదానిని మరొకటి కనుగొంటాయి. Container కు తన స్వంత filesystem ఉంటుంది. అందువల్ల రెండూ ఒకే files ను చూడలేవు. ఒకే container లోని రెండు sessions సాధారణంగా ఒకదానికొకటి message పంపగలవు. root గా నడుస్తున్న session మరియు మీ సాధారణ user గా నడుస్తున్న session ఒకదానికొకటి చేరుకోలేకపోవడానికి కూడా ఇదే నియమం వర్తిస్తుంది. Socket ను దాని యాజమాన్యంలోని operating system user కు మాత్రమే పరిమితం చేస్తారు.

మరో Claude Code session నుంచి వచ్చిన message పై చర్య తీసుకోవడం సురక్షితమేనా?

ఆ text ను untrusted input గా పరిగణించండి. Sending session ఒక web page, README లేదా మరొకరు రాసిన issue comment ను చదివి ఉండవచ్చు. Claude Code స్వయంగా message పై చర్య తీసుకోకుండా ఇప్పటికే కొన్ని నియంత్రణలను అమలు చేస్తుంది. అది pending permission prompt ను approve చేయలేదు. Request ఆధారంగా permission settings లేదా CLAUDE.md ను మార్చలేదు. Text లోని slash command plain text గా మాత్రమే వస్తుంది, ఎప్పటికీ run కాదు. ఈ రక్షణలు permissions ను మాత్రమే కవర్ చేస్తాయి, judgement ను కాదు. అందువల్ల వచ్చిన text ను చదివిన తరువాతే 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 నుంచి ఏదైనా బయటకు వెళ్లే ముందు మీ approval తప్పనిసరి కావాలంటే isolatePeerMachines ను true గా set చేయండి.