Inilunsad ng Anthropic ang eksperimentong cross-session messaging para sa Claude Code, na nagpapahintulot sa iba’t ibang session na magpadala ng mensahe nang direkta. Ang tampok na ito ay hindi nagpapadala ng buong konteksto, kundi ang mga resulta ng gawain at mga impormasyon tungkol sa mga dependensya, na ginagamit ang dalawang panloob na tool: ListAgents at SendMessage. Ang bawat lokal na session ay nakarehistro sa disk at nakakabit sa Inbox Socket; ang mga lokal na mensahe ay direktang ipinapadala sa pamamagitan ng socket, habang ang mga mensahe sa ibang machine ay ipinapadala sa pamamagitan ng Anthropic Server. Ang mga mensahe ay nagtatapos ng bagong turn kapag ang session ay walang gawain, at sa loob ng aktibong turn, inaasahan ang pagbabasa habang naghihintay sa pagitan ng mga tool call. Ang tagapagkuha ay nakikilala ang mga cross-session message mula sa user message, at hindi ito maaaring palitan ang pahintulot ng user, at mayroon itong tatlong mode ng inbound control: accept, hold, at refuse. Ang tampok na ito ay sumasama sa mga umiiral na kakayahan tulad ng Resume Session, Agent Teams, at Worktree upang magbigay ng isang coordinate layer sa pagitan ng session para sa Claude Code.May-akda ng artikulo, pinagkukunan: Leifeng.com
Sa mga araw na ito, idinagdag ng Anthropic ang isang bagong eksperimental na kakayahan sa Claude Code: Cross-session messaging, o pagpapadala ng mensahe sa pagitan ng mga session.
Sa simpleng salita, ito ay nagpapahintulot sa iyo na magpadala ng mga mensahe nang direkta sa pagitan ng maraming Claude Code Session na nagpapatakbo nang sabay-sabay.
Halimbawa, nagbuwas ka ng 3 Claude Code Session: isa para sa database, isa para sa backend API, at isa para sa pagsubok. Kahit na maaaring magtrabaho nang sabay-sabay ang 3 na Session, hindi nila alam kung saan na ang bawat isa. Pagkatapos baguhin ng Session sa database ang Schema, kailangan pa rin ng developer na maglipat sa isang iba’t ibang terminal upang sabihin muli ang mga pagbabago sa Session ng backend.
Pagkatapos idagdag ang cross-session messaging, maaari ngayon ng diretso ng Claude ang hakbang na ito. Ang database Session ay maaaring abiso ang back-end Session kung anong mga field ang nagbago, at ang test Session ay maaari ring magpadala ng resulta sa Session na nagmumula ng kaugnay na code kung nakakakita ito ng mga problema sa interface regression. Maaari ng sarili ng Claude na matukoy kailan kailangang abisoan ang ibang Session, o maaari ring tumugon sa hiling ng developer na makipag-ugnayan sa partikular na Session.
Upang maunawaan kung ano ang tumpak na ginagawa nito, sundin ang buong landas ng isang mensahe: ano ang ipinapadala nito, paano ito hinahanap ang target, kailan pumasok ang mensahe sa Claude, at bakit hindi maaaring gawin nang direkta ng tagatanggap.

01
Hindi nagbago ang cross-session messaging ang original na session isolation ng Claude Code.
Kapag nagpapadala ng mensahe ang Session A sa Session B, hindi ito nagpapadala ng sarili nitong Conversation History, mga file na binasa, o buong Context Window. Ayon sa opisyal na patakaran, ang ipinapadala sa pagitan ng mga session ay teksto lamang. Kung kailangan mong i-migrate ang buong usapan at konteksto sa ibang terminal, dapat mong i-Resume ang orihinal na Session, hindi gamitin ang Cross-session messaging.
Nakakatukoy ito sa paraan ng pagtatrabaho ng maraming Claude.
Sa pagkumpleto ng Migration, ang database Session ay binasa ang mga dekada ng mga file at sinubukan ang ilang mga solusyon, at sa huli ay natukoy na kailangang baguhin ang isang partikular na field. Hindi kailangan ng backend Session na malaman ang lahat ng naunang proseso ng pagsusuri; sapat na kumuha lamang ito ng huling pagbabago, at kung paano magiging epekto nito sa kanilang API.
Kaya ang Cross-session messaging ay nagpapadala ng mga resulta ng gawain at impormasyon sa mga pagkakasunod-sunod, hindi ang buong memorya ng trabaho.

Ang kahusayan nito ay ang lokal na impormasyon na nagmumula sa iba’t ibang gawain ay hindi lalabas nang patuloy sa iba pang Session. Ang mga detalye kaugnay sa database ay maaaring manatili sa Session ng database, ang proseso ng pagsubok ay maaaring manatili sa Session ng pagsubok, at ang impormasyon ay tanging lalabas sa hangganan ng Session kapag ang isang pagbabago ay nagsisimulang makaapekto sa iba pang gawain.
Ito ay iba sa ideya ng “lahat ng Agent ay nagbabahagi ng isang malaking Context”. Ang Cross-session messaging ay pumipili na panatilihin ang mga Session na hiwalay, at mag-synchronize nang eksplisito ang kinakailangang estado kapag may dependensya sa gawain.
Kasalungat ng isang malinaw na mensahe, ang susunod na tanong ay: Paano makikita ng Session A ang Session B?
02 Kailangan muna makahanap ng isa pang Session
Idinagdag ni Claude Code ang sarili nitong komunikasyong entry point sa mga session na may suporta sa cross-session messaging.
Ang bawat lokal na Session ay magrerehistro ng kaugnay na impormasyon sa disk, samantalang binibigyan ng isang Inbox Socket. Ang Claude ay maaaring maghanap ng mga kasalukuyang konektadong Session gamit ang ListAgents, at pagkatapos ay magpadala ng mensahe sa tinukoy na target gamit ang SendMessage.
Hindi kailangan ng user na mag-operate sa mga panloob na kasangkapan, kailangan lang ipaalam sa Claude kung aling Session ang gustong i-contact, o hayaan itong mag-notify nang aktibo sa kabilang panig kapag may dependensya sa gawain.

Ang pangalan ng session ay kaya'y nagsisimula na na makilahok sa pagtukoy. Maaaring hanapin ni Claude ang target batay sa pangalan; kung may magkakaparehong pangalan, idaragdag ng sistema ang maikling identifier para sa pagkakaiba, habang ipinapakita ang Working Directory upang tulungan ang pagkakasuri kong anong proyekto o directory ang pinagtratrabahuhan ng bawat session.
Matapos makahanap ng target, direktang ipinapadala ang lokal na mensahe sa pamamagitan ng Socket ng kaugnay na Session, hindi na kailangang lumipas sa Anthropic Server. Ang ibang machine o Session sa Claude Code Web ang gagamit ng Anthropic Server at mga koneksyon na kaugnay ng Remote Control.

Ang mekanismo ng pagkakakilanlang ito ang nagtatakda sa hangganan ng lokal na komunikasyon.
Kailangan ng Claude Code na basahin ang rehistrasyong impormasyon na isinulat ng ibang Session sa disk, kaya kahit magkasama ang pisikal na pagpapatakbo ng dalawang Claude sa iisang computer, kung ang file system ay magkakahiwalay, maaaring hindi sila makahanap ng isa’t isa. Karaniwang kaso ay ang Host at hiwalay na Container; kung ang dalawang Session ay nagpapatakbo sa iisang Container, maaaring magkakomunikasyon nang maayos.
Ang Inbox Socket ay pinapalaki rin ng mga pahintulot ng user ng operating system, kaya hindi makakapag-access nang direkta ang iba pang OS User sa shared server sa iyong Session.
Kaya ang tinatawag na “local communication” dito ay talagang nakadepende kung nakikita ba ang rehistrasyon, kung accessible ba ang Socket, at kung pinapayagan ba ng operating system ang pag-access.
Nakakatagpuan na ng mensahe ang target at naipadala sa Inbox, ngayon naman ang pagkakataon ng Runtime ng Claude Code na magdesisyon: kailan ipapasa ang mensahe sa model.

03 Pagkatapos maabot ang impormasyon
Kung ang backend Session ay nagpapalit ng file, at ang test Session ay nagpadala ng mensahe na nag-aalala tungkol sa isang interface regression issue na ito ay natuklasan.
Hindi agad ipaputol ng Claude Code ang nagpapatakbo na Tool.
Kung nasa Idle state ang target Session, maaaring mag-trigger ang mensahe para sa isang bagong Turn; kung nasa Active Turn na si Claude, ang mensahe ay maghihintay at babasahin sa pagitan ng dalawang Tool Call.
Ang dahilan sa pagtrato nito ay may kaugnayan sa paraan ng pagpapatakbo ng Coding Agent. Maaaring nag-aayos ng file, nagpapatakbo ng mga pagsubok, nagpapatakbo ng Migration, o nagpaproseso ng iba pang mga gawain na nagkakahalaga ng oras ang Claude. Kung ang mga panlabas na mensahe ay maaaring magbago ng anumang oras, madaling maging sanhi ito ng pagpapatakbo lamang ng bahagi ng kasangkapan, samantalang ang Agent ay nagsisimula na ring magplano muli batay sa bagong impormasyon.
Kaya ang mensahe ay nakakaapekto sa susunod na desisyon ni Claude, at hindi direktang nagpapalit sa kasalukuyang operasyon.
Ito ay nangangahulugan na ang Cross-session messaging ay na-integrate na sa Agentic Loop ng Claude Code bilang isang asynchronous source ng input. At ang entry point na ito ay hindi lamang para sa iba pang Claude Session.
Ang Claude Code ay magpapakita ng Messaging Socket ng kasalukuyang Session sa Hook at Bash na nagmumula sa Child Process. Pagkatapos matapos ang isang matagal na nagtatagal na background task, maaari itong ipadala nang aktibo ang resulta pabalik sa kasalukuyang Session, nang hindi kailangang i-poll ang Claude kung natapos na ito.

Hindi ito isang reliable message queue. Ang mga duplicate na mensahe ay may rate limiting, at maaaring mawala ang parehong nilalaman sa maikling panahon; ang bawat Session ay nagtatago ng pinakamaraming 50 na mensahe na natanggap ngunit hindi pa binasa ni Claude, habang ang mga mensahe na nasa Hold ay gumagamit ng ibang buffer, na may kapasidad na pinakamaraming 100.
Kaya ito ay mas angkop para sa pagpapadala ng pagbabago sa estado, resulta ng gawain, at mga abiso sa pakikipagtulungan. Ang mga katotohanang dapat panatilihin nang matagal, dapat pa ring i-record sa Git, file, database, o iba pang persistent na sistema.
Pagkatapos makarating ang mensahe sa Runtime, hindi pa ito agad maaaring maging isang aksyon na isasagawa, dahil kailangan pa ng tagatanggap na masuri: gaano karami ang awtoridad ng nilalaman na nadatnan mula sa ibang Claude.
04 Paano ang pagmamana ng mga pahintulot
Nagkakaroon ng malinaw na pagkakaiba ang Claude Code sa User Message at Peer Session Message.
Hindi itinuturing na pinahihintulutan ng user ang nilalaman mula sa ibang Session, kaya hindi ito maaaring mag-approve ng Permission Prompt para sa user, o humiling sa tagatanggap na baguhin ang Permission Settings, CLAUDE.md o iba pang mga konfigurasyon. Kahit na naglalaman ang mensahe ng Claude Code Command, ito ay tatanggapin lamang bilang karaniwang teksto.

Kung ang Session A ay humihingi sa Session B na tanggalin ang isang file, at kailangan ng pahintulot ng user sa Session B para sa operasyong ito, magkakaroon pa rin ng Permission Prompt.
Limitado rin ng Claude Code ang isang iba pang paraan ng pagbubypass ng pahintulot: kung tinanggihan na ng Permission System ang isang operasyon sa kasalukuyang Session, hindi dapat humingi ang Claude ng ibang Session upang gawin ito para sa kanya.
Kung hindi, habang may iba’t ibang pahintulot sa ilang session, ang mga session na may mababang pahintulot ay maaaring paulit-ulit na isauli ang mga gawain na hindi nila kayang gawin sa mga session na may mataas na pahintulot, kaya nababawasan ang orihinal na hangganan ng pahintulot.
Sa labas ng pagsasagawa ng pahintulot, may karagdagang Inbound Control ang mensahe mismo. Ang tagatanggap ay maaaring itakda ang mga mensahe sa pagitan ng Session bilang accept、hold orefuse: ipasa agad sa Claude, panatilihin nang pansamantalang maghintay ng karagdagang pagkumpirma, o agad na tanggalin.

Kung hindi eksplisitong naka-configure ang user ang mga patakaran, ang Claude Code ay tutugon pa rin sa current na Permission Mode ng sender at receiver. Ang isang Session na nakakapagbubuwis sa karaniwang Permission Prompt ay hindi itinuturing na pareho sa isang karaniwang Session bilang pinagmulan ng mensahe; kapag mataas ang sariling pahintulot ng receiver, maaaring pumasok muna sa Hold ang panlabas na mensahe.

May dalawang pagtataya dito: una, matutukoy kung maaaring pumasok ang mensahe sa Claude, at pangalawa, matutukoy kung may awtorisasyon ang aksyon na handaing gawin ng Claude batay sa mensaheng iyon.
Sa punto na ito, ang buong path ng isang Cross-session message ay natapos na: mula sa pagbuo ng mensahe, paghahanap sa target, pagkumpleto ng pagdudulot, hanggang sa pagbasa ng mensahe ng Runtime, at pagkatapos ay sa pamamagitan ng sariling kontrol ng pahintulot ng tagatanggap.

Layer ng koordinasyon sa pagitan ng 05 sesyon
I-back ang link na ito sa kasalukuyang kakayahan ni Claude Code, mas malinaw ang posisyon ng Cross-session messaging.
Ipinagpapatuloy ang Session upang magpatuloy sa dating Conversation at Context, ang Agent Teams ay ginagamit para lumikha at pamahalaan ang isang grupo ng nagkakasamang Agent, ang Worktree ay nagtataguyod ng paghihiwalay ng mga pagbabago sa code sa iba’t ibang Session, habang ang Remote Control ay naglulutas sa pagpapatuloy ng kontrol sa Session mula sa ibang device.
Ang cross-session messaging ay tumutukoy sa isang iba’t ibang sitwasyon: ang ilang Session na orihinal na nagtatrabaho nang hihiwalay, ay nagkakaroon ng pagkakasalig sa isa’t isa habang nagtatapos ng kanilang mga gawain, at kung paano ipapadala ang mga kinakailangang impormasyon sa isa’t isa.
Kahit na mas maraming Claude Code Session ang binuksan noon upang lutasin ang mga problema sa pagpaparalelo, kailangan pa rin ng mga developer na subaybayan ang progreso ng bawat terminal at paulit-ulit na ipaalam ang estado ng mga gawain sa pagitan ng tao at Session. Ngayon, direkta na ang mga impormasyon tulad ng pagbabago sa interface, mga resulta sa pagsubok, at pagkumpleto ng Migration sa mga naaapektuhang Session.
Hindi pinagsama ng cross-session messaging ang mga maraming Claude bilang isang Agent, kundi idinagdag lamang ang isang layer ng kakayahang komunikasyon sa labas ng dating Context, working directory, at mga hangganan ng pahintulot.
Sa mas malaking larangan ng proyekto, ang disenyo na ito ay nag-aalok ng isang iba pang pagkakataon para sa maraming Agent: ang iba’t ibang Agent ay hindi kailangang magbahagi ng lalong lumalaking Context, kundi maaari pa ring makapag-ugnay sa pamamagitan ng malinaw na mga interface ng komunikasyon. Pagkatapos ng paghihiwalay ng mga gawain, estado, at pahintulot, mas madaling palawakin ang sistema.
habang patuloy na tumataas ang bilang ng mga Agent, ang mga tanong ay magsisilbi mula sa “Gaano karami ang kayang gawin ng isang Agent” patungo sa “Kaya ba ng mga Agent na ito na magpalitan nang tama ang estado, tratuhin ang mga depensiyensiya, at matapos nang maayos ang pagpapasa”.
Ang cross-session messaging, bagaman naglutas lamang ito ng isang bahagi, ay nagsimula nang bigyan ang maraming Session na paraan ng paggawa ni Claude Code ng mas kompletong istrakturang inhinyeriyo. Baka sa hinaharap, ang mekanismo ng cross-session sa loob ng lokal na network na ito ay magiging isang Agent-to-Agent communication protocol na sumasaklaw sa mga machine at ecosystem, at ang maikling usapang ito sa pagitan ng dalawang Claude ay magiging mahalagang hakbang sa pagkakabuo ng isang mataas na awtomatizado software factory.
