Paano Mag-message ang Claude Code Sessions sa Isa’t Isa

Ano ang ibig sabihin kapag nagme-message ang mga Claude Code session sa isa’t isa

Maaaring mag-message ang dalawang Claude Code session sa isa’t isa kapag tumatakbo ang mga ito sa iisang machine at nasa ilalim ng parehong operating system user. Ang message ay isang piraso ng plain text na isinulat ng isang Claude para sa isa pa. Wala itong conversation history o files. Hinahanap ni Claude ang kabilang session gamit ang ListAgents tool at ipinapadala ang text gamit ang SendMessage, kaya hindi mo kailanman mano-manong tinatawag ang alinman sa mga tool na ito. Sinasabi mo kung ano ang kailangang malaman ng kabilang session, at si Claude ang mismong sumusulat ng message.

Ang feature na ito ay tinatawag na cross-session messaging. Simula Agosto 2026, kailangan nito ang Claude Code v2.1.224 o mas bago, at gumagana ito sa macOS at Linux, kasama ang Linux sa loob ng WSL 2. Wala itong native Windows support, at hindi ito available sa Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, o Microsoft Foundry. Kapag natutugunan ng isang session ang mga requirement na ito, naka-enable na agad ang messaging at wala nang kailangang i-enable. Ang behavior na inilalarawan sa ibaba ay mula sa Anthropic documentation para sa cross-session messaging.

Dito nagiging mahalaga ang VPS, dahil dito tumatagal nang sapat ang mga session para maging kapaki-pakinabang ang pag-address sa mga ito. Sa laptop, isinasara mo ang takip. Sa server na gumagamit ng tmux, ang session na sinimulan mo noong Lunes ay tumatakbo pa rin pagsapit ng Huwebes at hawak pa rin nito ang context ng isang repository. Kapag mayroon ka nang dalawang ganitong session, hindi na teoretikal ang paraan ng pakikipag-ugnayan nila. Kung hindi mo pa ito na-set up, magsimula sa pagpapatakbo ng Claude Code sa VPS gamit ang tmux, na sumasaklaw sa session plumbing na ipinapalagay ng gabay na ito.

Kailan sulit ang paggamit ng ikalawang session

Magsimula sa gastos. Magkahiwalay na Claude instance ang bawat session at may sarili itong context window, kaya humigit-kumulang doble ang gastos ng dalawang session kumpara sa isang session sa parehong panahon. Kasama sa usage ang bawat ipinadalang message, tulad ng prompt na ikaw mismo ang nag-type. Hindi libre ang coordination, at nagiging mas mabagal at mas magastos ang gawaing talagang iisang serye lamang ng mga hakbang kapag hinati ito sa maraming session.

Iisa ang karaniwang katangian ng mga sitwasyong sulit ang ikalawang session. Sabay na tumatakbo ang dalawang bahagi ng trabaho nang hindi naghihintayan, at may natututuhan ang isa na kailangan ng isa pa habang isinasagawa ang task.

• Nakahanap ang isang session ng breaking change habang binubuo naman ng isa ang code na naapektuhan nito. Ibinubuod ni Claude ang pagbabago at ipinapadala ito, kaya hindi mo na kailangang i-type itong muli sa kabilang terminal.
• Gumagawa ang dalawang session sa parehong repository gamit ang magkahiwalay na git worktree, at kailangang malaman ng isa kung ano ang na-merge.
• Nag-uulat ang isang mahaba-habang migration o test run ng resulta nito pabalik sa session na mino-monitor mo.
• May builder session at reviewer session, kung saan binabasa ng reviewer ang ginawa ng builder at ipinapadala ang mga natuklasan nito.

Kapag sequential ang trabaho, o kapag parehong session ang mag-e-edit ng parehong files, gumamit ng isang session. Kung gusto mo ng coordinated group na si Claude ang nag-spawn at nagso-supervise sa loob ng iisang task, iyon ay agent teams—hiwalay at experimental pa ring feature. Kung gusto mo lamang ng parehong conversation sa ibang terminal, i-resume na lang ang session. Para ang cross-session messaging sa magkahiwalay na session na ikaw mismo ang nagsisimula at gumagabay.

Tiyaking available ang feature bago ito gawing bahagi ng iyong plano

Una, tingnan ang version:

claude --version

Ihambing ang number sa 2.1.224. Pagkatapos, sa loob ng isang session, i-type ang /list-agents, na tumatanggap din ng /peers. Ipi-print nito ang lahat ng agent na maaabot ng session na ito, kasama ang pangalan na ginagamit ng bawat isa bilang tugon. Kung hindi talaga kinikilala ang command, walang cross-session messaging ang session na ito, at walang settings file na makapagbabago nito. I-type ang /status at hanapin ang row na Peer address: naglalaman ito ng sariling inbox address ng session na ito, na may prefix na uds:.

May isang partikular na trap para sa mga VPS user. Nakadepende ang cross-session messaging sa feature-flag evaluation. May ilang privacy variable na nag-o-off sa evaluation na ito, kaya nananatiling off ang feature sa default nitong state. Ginagawa ito ng DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, at DISABLE_GROWTHBOOK. Karaniwang pinapatatag ng mga tao ang bagong server sa pamamagitan ng pag-paste ng mga ito sa ~/.bashrc, at pagkatapos ay nagtataka kung bakit wala ang /list-agents. Maaari ring manggaling ang parehong value sa env map sa isang settings file o sa managed settings, kaya suriin muna ang shell.

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

I-unset ang alinmang variable na may naka-print na value. Para sa DISABLE_TELEMETRY at CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, ino-on ng anumang non-empty value ang behavior, kabilang ang string na 0, kaya hindi ginagawa ng DISABLE_TELEMETRY=0 ang mukhang ginagawa nito. I-o-off ito sa pamamagitan ng pag-unset ng variable o pagtatakda nito sa empty string.

Bigyan ng pangalan ang mga session; kung hindi, hindi matutukoy ng Claude ang mga ito

Ina-address ng Claude ang isang message sa isang session gamit ang pangalan nito. Itakda ang pangalan kapag sinimulan mo ang session:

claude --name builder-api

Maaari mo rin itong itakda gamit ang /rename habang tumatakbo ang session. Kapag wala kang itinakdang pangalan, bumubuo ang Claude Code ng pangalan mula sa folder name ng working directory, gaya ng myapp-3f. Ayos ito para sa isang session, pero nakalilito kapag apat na ang session, at maaaring magkapareho ang pangalan ng dalawang session. Ipinapakita ng output ng /list-agents ang working directory ng bawat local session, kaya nakikilala ang mga session na magkapareho ang pangalan. Nagdaragdag din ang sariling listing ng Claude ng maikling identifier sa address kapag may nagkakaparehong pangalan. Mas praktikal na ikaw mismo ang magbigay ng pangalan kaysa magbasa ng mga identifier.

Isang two-session na tmux layout na maaari mong ulitin

Ito ay isang builder session at reviewer session sa iisang repository. Gumagana ang reviewer sa hiwalay na git worktree, kaya hindi kailanman sumusulat ang dalawang session sa iisang file. Ang git worktree add kasama ng HEAD ay nagbibigay ng detached checkout, na angkop para sa session na nagbabasa sa halip na nagco-commit.

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

Pagkatapos, inililista ng Ctrl+b at w ang mga window ayon sa pangalan para makapili ka ng isa. Sa builder window, patakbuhin ang /list-agents. Dapat mong makita ang reviewer-api kasama ang working directory nito na ~/src/api-review. Kung wala ito, hindi pa tapos magsimula ang reviewer session, o naaangkop ang isa sa dalawang problemang nasa susunod na seksyon. Pagkatapos, magpasa ng gawain sa simpleng pananalita:

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

Isinusulat at ipinapadala ni Claude ang summary. Hindi mo kailangang isulat ang text ng message, at nag-iiba ang ipinapadala ni Claude. Sa reviewer window, lumilitaw ang message sa conversation kasama ang pangalan ng sender. Kung idle ang session, agad na nagsisimula si Claude ng bagong turn dito. Kung nasa kalagitnaan ito ng turn, naghihintay ang message hanggang sa pagitan ng mga tool call, kaya hindi nai-interrupt ang tumatakbong command. Kapag nabasa na ito ni Claude, nagiging isang linyang Message from row ang message na pinalalawak ng Ctrl+O. Mas mahusay na gumagana ang setup kapag maliit lamang ang mga pagbabago ng builder, dahil ang mas makitid na diff ay nagreresulta sa mas maikling hand-off at review na kayang tapusin ng kabilang session sa isang turn. Ito ang habit na ipinapatupad ng skill ng tamad na senior dev.

Sino ang makakakita sa kanino sa isang VPS

Hindi dumadaan sa mga server ng Anthropic ang delivery sa iisang machine. Nagsusulat ang bawat session ng mga registration file sa disk at nagba-bind ng sarili nitong inbox socket. Binabasa ng Claude Code ang mga file na ito upang mahanap ang iba mong session. Dalawang epekto ang mahalaga rito, at parehong nagdudulot ng problema sa isang server.

Naka-restrict ang socket sa iyong operating system user. Hindi makikita ng session na sinimulan mo bilang root ang session na sinimulan mo bilang deploy, kahit magkatabi ang mga ito sa iisang tmux server, dahil hindi maaabot ng mga session ng isang user ang socket ng ibang user. Patakbuhin ang parehong session bilang iisang user.

May sarili nitong filesystem ang isang container. Hindi maaabot ng session sa loob ng Docker ang session sa host, dahil hindi nila binabasa ang parehong registration files. Normal na makakapagpalitan ng message ang dalawang session sa loob ng parehong container. Kung gumagamit ka ng mga container para sa isolation ng agents, gaya ng nasa pagpapatakbo ng coding agents sa disposable VM, asahan mong gagana ang messaging sa loob ng isang container ngunit hindi sa pagitan ng mga container boundary.

Lalabas lamang sa listing ang iyong mga session sa ibang machine at sa web habang konektado ang Remote Control, at lalagyan ang mga ito ng kaukulang label. Makakasagot lamang ang Claude dito sa mensaheng nagmula sa isa sa mga session na iyon. Hindi nito masisimulan ang exchange na iyon.

Bakit hindi dumating ang mensahe mo

Karaniwang walang kinalaman dito ang network. Nagpasya ang receiving session kung ano ang gagawin sa mensahe, at ang naging pasya ay huwag itong i-deliver. Ang bawat dumarating na mensahe ay nagtatapos sa isa sa tatlong resulta: delivered, held (isinantabi nang hindi dini-deliver hanggang ma-approve mo), o refused (ibinagsak nang hindi dini-deliver).

Kapag walang naaangkop na crossSessionInbound value, nagpapasya ang Claude Code para sa bawat mensahe sa pamamagitan ng paghahambing sa permission modes ng dalawang session. Pinagsasama nito sa isang class ang mga session na nagba-bypass ng permission prompt, at inilalagay sa kabilang class ang lahat ng iba pang session. Itinuturing na prompting ang auto, acceptEdits, at dontAsk. Itinuturing ang Plan mode na nagba-bypass sa isang session na may available na bypass permissions. Symmetric ang rule:

• Ang receiving session na nagpa-prompt para sa permissions ay nagde-deliver ng bawat mensahe. Nagho-hold lamang ito ng mensahe kapag tinukoy ng sending session na nagba-bypass ito ng prompts.
• Ang receiving session na nagba-bypass ng prompts ay nagho-hold ng bawat mensahe para sa approval mo. Nagde-deliver lamang ito kapag nagba-bypass din ang sender.

Kaya ang unang workflow na karaniwang binubuo ng mga tao ay ang eksaktong workflow na hindi gumagana. Nagse-set up ka ng builder gamit ang --permission-mode bypassPermissions dahil gusto mo itong tumakbo nang unattended, iniiwan mo ang reviewer sa default settings, at naghihintay sa approval dialog ang bawat mensaheng ipinapadala ng builder na walang tumitingin dito. Nagsasara ang dialog na iyon pagkalipas ng dialogExpiry deadline, na naka-default sa 5m, at ibinabagsak ang mensahe. Sa iisang machine, nakatatanggap ng notice ang sending session kapag naka-hold ang mensahe nito, at nakatatanggap ito ng follow-up kapag kalaunan ay dine-deliver, dini-deny, o nag-expire ang mensahe ng receiver, kaya basahin ang screen ng sender bago mo sisihin ang socket.

Para mag-take ng mga mensahe nang unattended ang isang session, itakda ang crossSessionInbound sa accept. Kung saan mo ito itatakda ang magpapasya kung saan ito ilalapat. Binabasa muna ng Claude Code ang managed settings, pagkatapos ang --settings flag, at pagkatapos ang user settings; inilalapat nito ang unang value na makita. Ang value sa project o local settings ay inilalapat lamang kapag mas mahigpit ito, ayon sa ladder na accept < hold < refuse. Ang accept sa .claude/settings.json ay mas maluwag kaysa sa lahat, kaya binabalewala ito kapag may value na itinakda ang isang trusted source. Ilagay ito sa ~/.claude/settings.json, o ipasa ito para sa isang session:

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

Ang headless na claude -p worker ay nagbi-bind sa inbox socket gaya ng interactive session at lumilitaw sa listing, pero hindi ito makapagpapakita ng approval dialog. Mananatiling held ang mensahe roon hanggang sa payagan ito ng pagbabago sa mode o settings. Ang --settings line sa itaas ang paraan para payagan ang naturang worker na mag-take ng mga mensahe. Ang session na sinimulan sa bare mode ay hindi nagbi-bind sa anumang socket, kaya hindi ito makatatanggap ng mga mensahe o lilitaw sa listahan.

Saan nagkaka-deadlock ang hand-off

Awtomatikong hinahawakan ang mga message loop. Nililimitahan ng Claude Code ang paulit-ulit na message mula sa bawat sender, itinatapon ang magkakaparehong repeat na dumarating sa loob ng maikling pagitan, at nililimitahan sa 50 bawat session ang mga tinatanggap na message na naghihintay basahin. Dahil dito, hindi maaaring mag-ping-pong nang walang hanggan ang dalawang session. Nililimitahan sa 100 ang mga naka-hold na message, at itinatapon ang pinakaluma kapag lumampas dito.

Mas tahimik ang aktuwal na failure, at hand-off ito sa halip na loop. Nagtatanong ang Session A sa Session B ng sagot na kailangan nito bago magpatuloy, saka nagiging idle. Maaaring hawak pa ni B ang message, kasalukuyang may mahabang turn si B, o sumagot si B sa tanong na hindi naman talaga itinanong ni A. Naghihintay si A. Pagbalik mo makalipas ang isang oras, dalawang idle session ang makikita mo at walang natapos na trabaho.

Sumulat ng mga hand-off na hindi nangangailangan ng reply. Ang magandang message ay naglalaman ng fact o decision: ano ang nagbago at ano ang naging resulta. Ang masamang message ay humihingi sa kabilang session ng permission o ng sagot na kailangan ng sender bago ito makapagpatuloy. Naka-instruct na ang Claude na huwag kailanman humingi sa ibang session ng action na haharangin ng sarili nitong permission settings, at sa halip ay ibalik sa iyo ang gawaing iyon. Palawakin mo rin mismo ang rule na ito. Kung hindi makapagpatuloy ang isang session nang walang sagot, ikaw ang dapat sumagot dito. Nakakatulong din dito ang context discipline, dahil malamang na malabo ang mga message ng session na nawalan ng thread; tinatalakay sa pamamahala ng context sa Claude Code ang bahaging iyon.

Ituring hindi pinagkakatiwalaang input ang papasok na mensahe

Sinasabi ng Claude Code sa tumatanggap na Claude na nagmula ang mensahe sa ibang session at hindi sa iyo, at nililimitahan nito kung ano ang maaaring gawin ng mensahe. Hindi masasagot ng isang mensahe ang nakabinbing permission prompt para sa iyo, dahil ang pahintulot mula sa ibang session ay hindi pahintulot mo. Hindi nito mababago ang permission settings, CLAUDE.md, o iba pang configuration dahil hiniling ito ng ibang session. Ang slash command sa loob ng text, gaya ng /compact, ay dumarating bilang plain text at hindi kailanman ine-execute. Kung kailangan ng permission para maisagawa ang hinihiling ng mensahe at wala nito ang tumatanggap na session, makikita mo ang parehong prompt na makikita mo para sa ibang gawain. Sa auto mode, sinusuri rin ng isang classifier ang bawat mensahe bago ito ihatid, at hindi nakararating sa recipient ang mensaheng bina-block nito. Nananatili ang mga limitasyong ito kahit sa permissive modes. Kaya naka-hold by default ang mga papasok na mensahe sa isang bypassing session sa halip na awtomatikong pagkatiwalaan.

Saklaw nito ang permissions. Hindi nito saklaw ang content. Maaaring nagbasa ang nagpapadalang session ng pull request description, web page, dependency README, o issue comment na isinulat ng ibang tao, at maaaring makaapekto sa text na isusulat nito para sa isa mong session ang anumang nabasa nito. Data ang mensahe. Dapat itong ituring na kasing-duda ng anumang text na pumasok sa session mula sa labas. Ito ang disiplinang inilalarawan sa pag-iwas na mailagay ang mga secret sa iyong AI agents: ipagpalagay na maaaring mali ang anumang tumawid sa isang trust boundary, at huwag itong hayaang magbigay ng pahintulot para sa sarili nito.

May dalawang control kung gusto mong mabawasan ito. Kapag itinakda ang crossSessionInbound sa refuse, dini-drop ang mga papasok na peer message nang hindi inihahatid ang mga ito. Mula sa project o local settings, nangingibabaw ang value na ito sa lahat ng iba pang source dahil ito ang pinakamahigpit na setting sa hierarchy. Para pigilan ang session na ito sa pagpapadala o pag-lista, magdagdag ng permission deny rules na tumutukoy sa SendMessage at ListAgents. Pareho dapat itong isulat bilang bare tool names na walang specifier. Kapag itinakda ang isolatePeerMachines sa true, kailangan ang iyong tahasang pag-apruba bago makarating ang anumang mensahe sa session na nasa labas ng machine na ito. Kailangan ang pag-aprubang ito kahit nasa bypassPermissions mode.

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

Ang pag-deny sa SendMessage ay nag-aalis din ng messaging sa subagents dahil iisang tool ang ginagamit para sa dalawang ito. Walang nakikitang pagbabago sa sariling /status ng isang tumatangging session o sa mga listing ng ibang session. Kaya kumpirmahin ang setting mula sa configuration ng session, hindi mula sa screen.

Bridges at shared memory na MCP servers

Maraming third-party project ang inilabas sa parehong panahon na may kaugnay na gamit: mga local agent-to-agent bridge na nagre-relay ng text sa pagitan ng mga tumatakbong agent, at mga MCP (model context protocol) server na nagbibigay sa ilang agent ng iisang shared store para magbasa at magsulat. Ituring ang mga ito bilang ibang anyo, hindi bilang competitor, at i-verify ang anumang install command sa sariling README ng project bago ito patakbuhin. Push ang messaging dahil inilalagay ng sender ang text sa turn ng receiver. Pull ang shared store dahil walang nape-publish na interruption at nakikita ng session ang note kapag muli itong tumingin. Mas angkop ang pull para sa status na mabagal magbago, at gagana lamang ito kapag aktuwal na tumingin ang session.

Kung iyon ang pipiliin mo, ang mahahalagang tanong ay tungkol sa proseso, hindi sa listahan ng feature. Bilang sinong user tumatakbo ang server, at ano ang maaari nitong basahin sa box. Sinasaklaw ng Pagpapatakbo ng MCP servers sa isang VPS ang setup na iyon. Sinasaklaw ng Pagbabahagi ng agent skills sa pagitan ng mga repo ang mas simpleng kaso kung ang nais mong ibahagi sa pagitan ng mga session ay mga instruction sa halip na live state, at inaalis nito ang maraming mensaheng kailangan mo sanang ipadala. Para sa mas malawak na larawan, pagpapatakbo ng coding agent sa isang VPS ang magandang panimulang punto.

FAQ

Bakit hindi nakikilala sa session ko ang /list-agents?

Walang cross-session messaging ang session. Suriin muna ang claude --version laban sa 2.1.224, dahil kailangan ng feature ang bersyong iyon o mas bago. Suriin din ang platform, dahil tumatakbo ito sa macOS at Linux ngunit hindi sa native Windows, at hindi ito available sa Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform, at Microsoft Foundry. Kung maayos ang dalawang ito, tingnan ang shell para sa DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, o DISABLE_GROWTHBOOK, dahil bina-block ng bawat isa ang feature-flag evaluation na kailangan ng feature at iniiwan itong naka-off.

Bakit hindi nakarating ang mensahe ko sa kabilang session?

Kung gumagana ang /list-agents, naka-on ang messaging at may mas partikular na pumigil sa mensaheng iyon. Karaniwang sanhi ang permission modes. Ang session na nagba-bypass ng permission prompts ay nagho-hold ng bawat inbound message para sa approval mo, maliban kung nagba-bypass din ang sender. Awtomatikong dini-discard ang approval dialog pagkalipas ng deadline na dialogExpiry, na limang minuto bilang default. Suriin ang sending session para sa held notice. Para ayusin ito, itakda ang crossSessionInbound sa accept sa ~/.claude/settings.json, o ipasa ito gamit ang --settings, dahil binabalewala ang accept sa project o local settings bilang mas maluwag na value.

Maaari bang magpadala ng mensahe ang isang Claude Code session sa Docker sa session na nasa host?

Hindi. Naghahanap ang mga session sa isa't isa gamit ang registration files sa disk at per-session inbox socket. May sariling filesystem ang container, kaya hindi makikita ng dalawang session ang parehong files. Karaniwang makakapagpadala ng mensahe sa isa't isa ang dalawang session na nasa loob ng parehong container. Ipinapaliwanag din ng parehong panuntunan kung bakit hindi makapag-ugnayan ang session na tumatakbo bilang root at ang session na tumatakbo bilang normal mong user: limitado ang socket sa operating system user na nagmamay-ari nito.

Ligtas bang sundin ang mensahe mula sa ibang Claude Code session?

Ituring na untrusted input ang text, dahil maaaring nakabasa ang sending session ng web page, README, o issue comment na isinulat ng ibang tao. Awtomatikong pinipigilan na ng Claude Code ang mensahe na kumilos nang mag-isa: hindi nito maa-approve ang pending permission prompt, hindi nito mababago ang permission settings o CLAUDE.md kapag hiniling, at ang slash command sa text ay dumarating bilang plain text at hindi kailanman tumatakbo. Sinasaklaw ng mga proteksiyong ito ang permissions ngunit hindi ang judgement, kaya basahin muna ang natanggap bago mo utusang kumilos ang receiving session.

Ipinapadala ba ng cross-session messaging ang code ko sa Anthropic?

Hindi, kung nasa parehong machine ang dalawang session. Dumadaan ang mensahe sa per-session socket sa machine na iyon at hindi sa Anthropic servers. Tanging text na isinulat ni Claude ang ipinapadala, hindi ang conversation history o files. Ang mga mensahe sa session na nasa iba mong machine, o sa session sa web, ay dumadaan sa Anthropic servers sa pamamagitan ng Remote Control connection. Sa ganitong direksiyon, makakasagot lamang si Claude sa mensaheng natanggap niya at hindi siya makakapagsimula ng mensahe. Itakda ang isolatePeerMachines sa true para kailanganin ang approval mo bago may lumabas sa machine.