Claude Code సెషన్లు ఒకదానికొకటి సందేశాలు ఎలా పంపుతాయి

Claude Code సెషన్లు ఒకదానితో మరొకటి సందేశాలు పంపుకోవడం అంటే ఏమిటి

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

ఈ 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లో కూడా ఇది అందుబాటులో లేదు. ఒక సెషన్ ఈ అవసరాలను తీర్చినప్పుడు messaging ఇప్పటికే enabled అయి ఉంటుంది. దీన్ని enable చేయాల్సిన అవసరం లేదు. కింది ప్రవర్తన cross-session messagingకు సంబంధించిన Anthropic documentation ఆధారంగా ఉంది.

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

రెండవ session కోసం tokens ఖర్చు చేయడం ఎప్పుడు సముచితం

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

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

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

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

ఉపయోగించాలనుకునే feature ఉందో లేదో ముందుగా తనిఖీ చేయండి

ముందుగా 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 స్థితిలోనే ఉంటుంది. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, మరియు DISABLE_GROWTHBOOK ఇవన్నీ ఇదే పని చేస్తాయి. కొత్త server ను భద్రపరచేటప్పుడు వీటిని ~/.bashrc లో paste చేస్తారు. తరువాత /list-agents అందుబాటులో లేకపోవడానికి కారణం ఏమిటని ఆశ్చర్యపడతారు. ఇదే values, settings file లోని env map నుంచి లేదా managed settings నుంచి కూడా రావచ్చు. అందువల్ల ముందుగా shell ను తనిఖీ చేయండి.

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

ఏది output ఇస్తే దాన్ని unset చేయండి. DISABLE_TELEMETRY మరియు CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC కోసం, non-empty value ఏదైనా behaviour ను on చేస్తుంది. 0 string కూడా దీనిలో భాగమే. అందువల్ల DISABLE_TELEMETRY=0, కనిపించే విధంగా పనిచేయదు. Variable ను unset చేయడం ద్వారా లేదా దానికి empty string value ఇవ్వడం ద్వారా దాన్ని off చేయాలి.

మీ 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 ను జోడిస్తుంది. Identifiers చదవడం కంటే మీరే sessions కు పేర్లు పెట్టడం సులభం.

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

ఇది ఒకే repositoryలోని builder session మరియు reviewer session. Reviewer ప్రత్యేక git worktreeలో పనిచేస్తుంది. అందువల్ల రెండూ ఒకే fileను ఎప్పుడూ రాయవు. 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ను పేరుతో జాబితా చేయవచ్చు. అందులో ఒకదాన్ని ఎంచుకోండి. 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 తన changesను చిన్నగా ఉంచితే ఈ జంట మరింత సమర్థంగా పనిచేస్తుంది. చిన్న diff వల్ల hand-off సంక్షిప్తంగా ఉంటుంది. మరో session reviewను ఒకే turnలో పూర్తి చేయగలదు. lazy senior dev skill అమలు చేయించేది ఇదే అలవాటు.

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

అదే మెషీన్‌లో జరిగే డెలివరీ Anthropic సర్వర్ల ద్వారా ఎప్పుడూ వెళ్లదు. ప్రతి 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గా run చేయండి.

ఒక containerకు సొంత filesystem ఉంటుంది. Dockerలోని session, hostపై ఉన్న sessionను చేరుకోలేవు. అవి ఒకే registration filesను చదవవు. ఒకే containerలోని రెండు sessions సాధారణంగా పరస్పరం messageలు పంపుకోగలవు. Isolation కోసం agentsను containersలో ఉంచితే, disposable VMలో coding agentsను run చేయడం మాదిరిగా, containerలో messaging పనిచేస్తుందని, కానీ container boundary దాటి పనిచేయదని అంచనా వేయండి.

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

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

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

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

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

అందువల్ల చాలామంది మొదట రూపొందించే workflow సరిగ్గా పనిచేయనిదే అవుతుంది. unattended గా నడపాలనే ఉద్దేశంతో --permission-mode bypassPermissions ఉపయోగించి builder ను ప్రారంభిస్తారు, reviewer ను default settings లోనే ఉంచుతారు. ఫలితంగా builder పంపే ప్రతి సందేశం ఎవరూ చూడని approval dialog లో వేచి ఉంటుంది. ఆ dialog dialogExpiry deadline తర్వాత మూసుకుపోతుంది. దీని default విలువ 5m. అప్పుడు సందేశం dropped అవుతుంది. అదే machine పై sending session తన సందేశం held అయినప్పుడు notice అందుకుంటుంది. Receiver తరువాత దాన్ని delivered, denied, లేదా expired చేసినప్పుడు follow-up notice కూడా అందుతుంది. కాబట్టి socket ను నిందించే ముందు sender యొక్క screen ను పరిశీలించండి.

Session messages ను unattended గా స్వీకరించేలా చేయడానికి crossSessionInbound ను accept కు సెట్ చేయండి. దాన్ని ఎక్కడ సెట్ చేస్తారో దాని వర్తింపు నిర్ణయమవుతుంది. Claude Code ముందుగా managed settings ను చదువుతుంది. తరువాత --settings flag ను చదువుతుంది. ఆ తరువాత user settings ను చదివి, మొదట కనిపించిన విలువను అమలు చేస్తుంది. Project లేదా local settings లోని విలువ accept < hold < refuse అనే ladder లో మరింత strict గా ఉన్నప్పుడు మాత్రమే వర్తిస్తుంది. .claude/settings.json లోని accept ఏ విలువకన్నా looser గా ఉంటుంది. అందువల్ల trusted source ఒక విలువను సెట్ చేసినప్పుడు అది ఎల్లప్పుడూ 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 అయిన సందేశం, తరువాతి mode లేదా settings మార్పు దాన్ని అనుమతించే వరకు held గానే ఉంటుంది. అలాంటి worker messages ను స్వీకరించేందుకు పై --settings line ను ఉపయోగించాలి. Bare mode లో ప్రారంభించిన session ఎలాంటి socket ను bind చేయదు. అందువల్ల అది messages ను receive చేయదు, list లో కూడా కనిపించదు.

Hand-off‌లు ఎప్పుడు నిలిచిపోతాయి

Message loops‌ను మీ కోసం నిర్వహిస్తారు. Claude Code ఒకే sender పంపే పునరావృత messages‌కు rate limit అమలు చేస్తుంది, తక్కువ వ్యవధిలో వచ్చిన ఒకే content గల repeats‌ను తొలగిస్తుంది, అలాగే ప్రతి session‌లో చదవడానికి వేచి ఉన్న accepted messages‌ను 50కి పరిమితం చేస్తుంది. అందువల్ల రెండు sessions ఎప్పటికీ ping-pong చేయలేవు. Held messages పరిమితి 100. ఆ పరిమితి దాటితే అత్యంత పాత messages తొలగించబడతాయి.

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

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

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

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

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

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

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

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

బ్రిడ్జ్‌లు మరియు shared memory MCP servers

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

మీరు ఆ విధానాన్ని ఎంచుకుంటే, అడగాల్సిన ముఖ్యమైన ప్రశ్నలు feature list గురించి కాకుండా process గురించి ఉండాలి. Server ఏ user గా నడుస్తుంది? అది system లో ఏమేమి చదవగలదు? VPS పై MCP servers నడపడం ఆ setup ను వివరిస్తుంది. Sessions మధ్య instructions ను live state కు బదులుగా share చేయాలనుకుంటే, సరళమైన సందర్భాన్ని repos మధ్య agent skills పంచుకోవడం వివరిస్తుంది. మీరు లేకపోతే పంపాల్సి వచ్చే అనేక 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 ను నిరోధించి, దాన్ని off గా ఉంచుతుంది.

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

/list-agents పనిచేస్తే messaging ప్రారంభించబడి ఉంది. కాబట్టి ఆ message ను మరింత నిర్దిష్టమైన ఏదో అంశం ఆపి ఉండవచ్చు. సాధారణ కారణం permission modes. Permission prompts ను bypass చేసే session ప్రతి inbound message ను మీ approval కోసం నిలిపి ఉంచుతుంది, sender కూడా bypass చేయకపోతే ఇది జరుగుతుంది. ఆ approval dialog dialogExpiry deadline తర్వాత తొలగించబడుతుంది; default గా ఇది ఐదు నిమిషాలు. Message పంపిన session లో held notice ఉందా చూడండి. పరిష్కరించడానికి ~/.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 ఉంటుంది కాబట్టి, రెండు sessions ఒకే files ను చూడలేవు. అదే container లోని రెండు sessions సాధారణంగా ఒకదానికొకటి message పంపగలవు. root గా నడుస్తున్న session మరియు మీ సాధారణ user గా నడుస్తున్న session ఒకదానిని మరొకటి చేరుకోలేకపోవడానికి కూడా ఇదే నియమం కారణం. Socket ను దాని owner అయిన operating system user కు మాత్రమే పరిమితం చేస్తారు.

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

ఆ text ను నమ్మదగని input గా పరిగణించండి. పంపిన session web page, README లేదా మరొకరు రాసిన issue comment ను చదివి ఉండవచ్చు. Claude Code message ఆధారంగా స్వయంగా చర్య తీసుకోకుండా ఇప్పటికే కొన్ని రక్షణలను అమలు చేస్తుంది. ఇది pending permission prompt ను approve చేయలేదు. అభ్యర్థన వచ్చినప్పుడు permission settings లేదా CLAUDE.md ను మార్చలేదు. Text లోని slash command plain text గా మాత్రమే వస్తుంది, ఎప్పుడూ run కాదు. ఈ రక్షణలు permissions కు మాత్రమే వర్తిస్తాయి; judgement కు కాదు. అందువల్ల receiving session కు చర్య తీసుకోమని చెప్పే ముందు వచ్చిన text ను చదవండి.

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 చేయండి.