Paano Mag-message ang Dalawang Claude Code Session

Ano ang ibig sabihin ng pagpapalitan ng mensahe ng mga Claude Code session

Maaaring magpadalhan ng mensahe ang dalawang Claude Code session kapag tumatakbo ang mga ito sa iisang machine at sa ilalim ng iisang operating system user. Ang mensahe ay isang piraso ng plain text na isinulat ng isang Claude para sa isa pa. Wala itong conversation history o mga file. Hinahanap ni Claude ang kabilang session gamit ang ListAgents tool at ipinapadala ang text gamit ang SendMessage, kaya hindi mo kailangang tawagin nang manu-mano ang alinman sa mga tool na ito. Sinasabi mo kung ano ang kailangang malaman ng kabilang session, at si Claude ang mismong sumusulat ng mensahe.

Ang feature na ito ay tinatawag na cross-session messaging. Simula August 2026, kailangan nito ang Claude Code v2.1.224 o mas bago, at tumatakbo ito sa macOS at Linux, kabilang 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 ang messaging at wala nang kailangang i-enable. Ang behavior na inilalarawan sa ibaba ay batay sa Anthropic documentation para sa cross-session messaging.

Sa VPS ito higit na kapaki-pakinabang, dahil dito sapat na matagal na tumatakbo ang mga session para maging mahalaga ang pagpapadalhan ng mensahe. Sa laptop, isinasara mo ang lid. Sa server na gumagamit ng tmux, ang session na sinimulan mo noong Monday ay tumatakbo pa rin sa Thursday at hawak pa rin ang context ng isang repository. Kapag mayroon ka nang dalawang ganoong session, hindi na teoretikal ang paraan ng pakikipag-usap ng mga ito. 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 ipinagpapalagay ng gabay na ito.

Kailan sulit ang ikalawang session

Magsimula sa gastos. Hiwalay na Claude instance ang bawat session at may sarili itong context window, kaya humigit-kumulang dalawang beses ang gastos ng dalawang session kumpara sa isang session sa parehong panahon. Kasama sa usage ang bawat naipadalang mensahe, tulad ng prompt na ikaw mismo ang nag-type. Hindi libre ang coordination, at mas bumabagal at nagiging mas magastos ang gawaing tunay na isang sunod-sunod na proseso kapag hinati ito sa magkahiwalay na session.

Magiging sulit ang ikalawang session sa mga sitwasyong may ganitong katangian. 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.

• May nakikitang breaking change ang isang session habang binubuo naman ng isa pa ang code na naapektuhan nito. Ibinubuod ni Claude ang pagbabago at ipinapadala ito, sa halip na ikaw ang muling mag-type nito sa kabilang terminal.
• Gumagawa ang dalawang session sa iisang repository gamit ang magkahiwalay na git worktree, at kailangang malaman ng isa kung ano ang na-merge.
• Nagbabalik ng resulta ang isang mahabang migration o test run 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 mag-e-edit ang dalawang session ng parehong file, gumamit ng isang session. Kung gusto mo ng coordinated group na ini-spawn at sinusubaybayan ni Claude sa loob ng iisang task, iyon ay agent teams, isang hiwalay at hindi pa ganap na feature. Kung gusto mo lamang ng parehong conversation sa ibang terminal, i-resume ang session. Ang cross-session messaging ay para sa magkahiwalay na session na ikaw mismo ang nagsisimula at kumokontrol.

Tiyaking available ang feature bago ito gawing bahagi ng plano

Una, tingnan ang version:

claude --version

Ihambing ang number sa 2.1.224. Pagkatapos, habang nasa isang session, i-type ang /list-agents, na tumatanggap din ng /peers. Ipi-print nito ang bawat agent na maaabot ng session na ito, kasama ang pangalan kung saan ito tumutugon. Kung hindi talaga nakikilala ang command, walang cross-session messaging ang session na ito, at walang settings file ang makakapag-enable 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 panganib para sa mga VPS user. Nakadepende ang cross-session messaging sa feature-flag evaluation, at pinapatay ng ilang privacy variable ang evaluation na ito, kaya nananatiling naka-off ang feature bilang default. 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 walang /list-agents. Maaari ring manggaling ang parehong values sa env map ng 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 variable na may lumabas 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 rito ng empty string.

Pangalanan ang mga session mo, kung hindi ay hindi matutugunan ni Claude ang mga ito

Tinutugunan ni Claude ang isang mensahe 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 isang session. Kapag walang itinakda, bumubuo ang Claude Code ng pangalan mula sa pangalan ng folder ng working directory, gaya ng myapp-3f. Ayos ito para sa isang session, pero nakalilito kapag apat na session na ang tumatakbo. Maaari ring magkapareho ang pangalan ng dalawang session. Ipinapakita ng output ng /list-agents ang working directory ng bawat local session. Dahil dito, nakikilala ang mga session na magkapareho ang pangalan. Nagdaragdag din ang sariling listing ni Claude ng maikling identifier sa address kapag may magkakaparehong pangalan. Mas madali ang ikaw mismo ang magpangalan sa mga session kaysa magbasa ng mga identifier.

Isang two-session na tmux layout na maaari mong ulitin

Ito ay isang builder session at isang reviewer session sa iisang repository. Gumagamit ang reviewer ng hiwalay na git worktree, kaya hindi kailanman nagsusulat ang dalawang session sa iisang file. Ang git worktree add kasama ng HEAD ay gumagawa ng detached checkout, na angkop para sa session na nagbabasa ngunit hindi nagko-commit. Magkaiba ang gawain ng dalawang session, kaya mainam na bigyan ang reviewer ng sarili nitong output style, na nagbabago sa system prompt ng session at nananatili sa bawat turn, sa halip na unti-unting mawala gaya ng instruction na minsan mo lang na-type.

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

Inililista naman ng Ctrl+b kasama ng w ang mga window ayon sa pangalan upang 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 problema sa susunod na seksyon. Pagkatapos, magpasa ng gawain gamit ang payak na wika:

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

Isinulat 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 naaantala ang tumatakbong command. Kapag nabasa na ito ni Claude, nagiging isang one-line na Message from row ang message na ine-expand ng Ctrl+O. Mas mahusay ang dalawang session kapag maliit ang mga pagbabago ng builder, dahil nagreresulta ang narrow diff sa mas maikling hand-off at sa review na matatapos ng kabilang session sa isang turn. Ito ang kaugaliang ipinapatupad ng lazy senior dev skill.

Sino ang makakakita sa kanino sa iisang VPS

Hindi dumadaan sa mga server ng Anthropic ang delivery sa iisang machine. Nagsusulat ang bawat session ng mga registration file sa disk at nagbi-bind ng sarili nitong inbox socket. Binabasa ni Claude Code ang mga file na ito upang mahanap ang iba mo pang session. Dalawa ang resulta nito, at parehong nagdudulot ng problema sa isang server.

Limitado 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. 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 file. Normal na makakapag-message sa isa’t isa ang dalawang session sa loob ng parehong container. Kung pinananatili mo sa mga container ang mga agent para sa isolation, gaya ng nasa pagpapatakbo ng mga coding agent sa disposable VM, asahang gagana ang messaging sa loob ng container ngunit hindi sa pagitan ng container at host.

Lalabas sa listing ang mga session mo sa ibang machine at sa web habang nakakonekta ang Remote Control, at mamarkahan ang mga ito bilang ganoon. Makakasagot lamang si Claude dito sa mensaheng nagmula sa isa sa mga session na iyon. Hindi nito maaaring simulan ang palitang iyon.

Bakit hindi kailanman dumating ang iyong mensahe

Karaniwan, walang kinalaman dito ang network. Ang receiving session ang nagpasya kung ano ang gagawin sa mensahe, at ang napagpasyahan nito ay huwag itong i-deliver. Bawat dumarating na mensahe ay nagtatapos sa isa sa tatlong resulta: delivered, held (isinantabi nang hindi dini-deliver hanggang ma-approve mo), o refused (itinapon nang hindi dini-deliver).

Kapag walang naaangkop na crossSessionInbound value, nagpapasya ang Claude Code para sa bawat mensahe sa pamamagitan ng paghahambing ng permission mode ng dalawang session. Pinagpapangkat nito sa isang class ang mga session na nagba-bypass ng permission prompt, at sa kabilang class ang lahat ng iba pang session. Ang auto, acceptEdits, at dontAsk ay itinuturing na prompting. Itinuturing na nagba-bypass ang Plan mode sa isang session na may available na bypass permissions. Kung hindi ka sigurado kung saang class kabilang ang isang session, makatutulong munang basahin ang aktuwal na ginagawa ng bawat permission mode, dahil ang auto ang panimulang mode ng karamihan sa mga session ngayon at kabilang ito sa prompting side ng paghahating iyon. Symmetric ang rule:

• Ang receiving session na nagpo-prompt para sa permissions ay dini-deliver ang bawat mensahe. Nagho-hold lamang ito ng mensahe kapag kinikilala ng sending session ang sarili nito bilang nagba-bypass ng prompts.
• Ang receiving session na nagba-bypass ng prompts ay nagho-hold ng bawat mensahe para sa iyong approval. Nagde-deliver lamang ito kapag ang sender ay nagba-bypass din.

Kaya ang unang workflow na karaniwang ginagawa ng mga tao ay eksaktong workflow na hindi gumagana. Nagsisimula ka ng builder gamit ang --permission-mode bypassPermissions dahil gusto mong tumakbo ito nang walang supervision, iniiwan mong naka-default ang reviewer, at naghihintay ang bawat mensaheng ipinapadala ng builder sa isang approval dialog na walang tumitingin. Nagsasara ang dialog na iyon pagkalipas ng dialogExpiry deadline, na ang default ay 5m, at itinatapon 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, dine-deny, o nag-expire ito ng receiver. Kaya basahin muna ang screen ng sender bago sisihin ang socket.

Para gawing unattended ang pagtanggap ng mga mensahe ng isang session, itakda ang crossSessionInbound sa accept. Nakadepende sa lugar ng pag-set kung saan ito ilalapat. Binabasa muna ng Claude Code ang managed settings, kasunod ang --settings flag, at pagkatapos ang user settings. Inilalapat nito ang unang value na makita. Nalalapat lamang ang value sa project o local settings kapag mas mahigpit ito, ayon sa ladder na accept < hold < refuse. Ang accept sa .claude/settings.json ay mas maluwag kaysa sa anuman, kaya hindi ito pinapansin kapag may value nang itinakda ang trusted source. Ilagay ito sa ~/.claude/settings.json, o ipasa ito para sa isang session:

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

Ang headless claude -p worker ay nagbi-bind sa inbox socket tulad ng interactive session at lumilitaw sa listing, ngunit 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 ginagamit upang payagan ang naturang worker na tumanggap 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.

Kung saan nagkaka-deadlock ang mga hand-off

Awtomatikong hinahawakan ang mga message loop. Nililimitahan ng Claude Code ang rate ng mga paulit-ulit na message mula sa bawat sender, inaalis ang magkakaparehong repeat na dumarating sa loob ng maikling panahon, at nililimitahan sa 50 bawat session ang mga tinatanggap na message na naghihintay basahin. Dahil dito, hindi maaaring mag-ping-pong nang walang katapusan ang dalawang session. Nililimitahan sa 100 ang mga naka-hold na message, at inaalis ang mga pinakamatanda 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, pagkatapos ay nagiging idle. Maaaring i-hold ni B ang message, maaaring nasa kalagitnaan si B ng mahabang turn, o maaaring 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 hindi magandang message ay humihingi sa kabilang session ng permission o ng sagot na kailangan ng sender bago makapagpatuloy. Nakasaad na sa mga instruction ng Claude na huwag kailanman humingi sa ibang session ng action na maba-block ng sarili nitong permission settings, at sa halip ay ibalik sa iyo ang gawaing iyon. Palawakin mo 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 malabo ang mga message na isinusulat ng session kapag nawawala ang thread; tinatalakay ng pamamahala ng context sa Claude Code ang bahaging iyon.

Ituring hindi mapagkakatiwalaang 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 mensaheng iyon. Ang pagpapatupad na ito ay nasa program na nakabalot sa model, hindi sa kahandaang sumunod ng model. Ito ang praktikal na pagkakaiba na ginagawa ng agent harness. 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 na nasa loob ng text, gaya ng /compact, ay dumarating bilang plain text at hindi kailanman ine-execute. Kung kailangan ng permission upang kumilos batay sa mensahe at wala nito ang tumatanggap na session, makikita mo ang parehong prompt na makikita mo para sa anumang ibang gawain. Sa auto mode, sinusuri rin ng 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 bilang default ang mga papasok na mensahe sa isang bypassing session sa halip na pagkatiwalaan ang mga ito.

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 hindi mo kilalang tao. Maaaring maimpluwensiyahan ng anumang nabasa nito ang text na isinusulat nito para sa iba mong session. Data ang mensahe. Dapat itong tratuhin nang may parehong pag-iingat gaya ng anumang text na pumasok sa isang session mula sa labas. Ito ang disiplinang inilalarawan sa paglalayo ng mga secret sa iyong AI agents: ipagpalagay na maaaring mali ang anumang tumawid sa trust boundary, at huwag itong hayaang mag-authorize 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 ihinahatid ang mga ito. Kapag itinakda ito sa project o local settings, nangingibabaw ang value na ito sa lahat ng iba pang source dahil ito ang pinakamahigpit sa hierarchy. Upang pigilan ang session na ito sa pagpapadala o paglista, magdagdag ng permission deny rules na tumutukoy sa SendMessage at ListAgents. Isulat ang dalawang ito bilang bare tool names na walang specifier. Kapag itinakda ang isolatePeerMachines sa true, kailangan ang hayagang pag-apruba mo bago makarating ang anumang mensahe sa session sa labas ng machine na ito. Kailangan ang pag-apruba kahit nasa bypassPermissions mode.

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

Inaalis din ng pag-deny sa SendMessage ang messaging sa subagents, dahil iisang tool ang nagsisilbi sa dalawang ito. Walang nakikitang pagbabago sa sariling /status ng session na tumatanggi o sa mga listing ng ibang session. Kaya kumpirmahin ang setting mula sa configuration ng session, hindi mula sa screen.

Bridge at shared memory na MCP servers

Sa parehong panahon, may ilang third-party project na naglabas ng mga tool para sa kaugnay na gamit: mga local agent-to-agent bridge na nagre-relay ng text sa pagitan ng mga agent na tumatakbo, 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 uri ng solusyon, hindi bilang competitor, at i-verify ang anumang install command sa README ng mismong project bago ito patakbuhin. Push ang messaging dahil inilalagay ng sender ang text sa turn ng receiver. Pull naman ang shared store dahil walang nape-perturb na session, at nakikita ng isang session ang note kapag muli nitong sinuri ang store. Mas kalmado ang pull para sa status na mabagal magbago, at gagana lamang ito kapag aktuwal na nagsuri ang isang session.

Kung iyon ang pipiliin mo, ang mga dapat itanong ay tungkol sa proseso, hindi sa listahan ng feature. Bilang sinong user tumatakbo ang server, at ano ang maaari nitong basahin sa box. Saklaw ito ng Pagpapatakbo ng MCP servers sa isang VPS. Saklaw naman ng Pagbabahagi ng agent skills sa iba’t ibang repo ang mas simpleng sitwasyon kung ang nais mong ibahagi sa pagitan ng mga session ay mga instruction, hindi live state; nababawasan din nito ang maraming mensaheng kailangan mo sanang ipadala. Para sa mas malawak na larawan, pagpapatakbo ng coding agent sa isang VPS ang magandang panimulang gabay.

FAQ

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

Walang cross-session messaging ang session. Suriin muna ang claude --version laban sa 2.1.224, dahil kailangan ng feature ang bersiyong iyon o mas bago. Suriin din ang platform, dahil gumagana ito sa macOS at Linux ngunit hindi sa native Windows. Hindi rin 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 hinaharangan ng bawat isa ang feature-flag evaluation na kailangan ng feature at iniiwan itong naka-off.

Bakit hindi dumating ang mensahe ko sa kabilang session?

Kung gumagana ang /list-agents, naka-on ang messaging at may mas tiyak 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. Nawawala ang approval dialog kapag lumampas sa deadline ng dialogExpiry, na limang minuto bilang default. Tingnan 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 kapag mas maluwag ang value nito.

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

Hindi. Hinahanap ng mga session ang isa't isa sa pamamagitan ng registration files sa disk at per-session inbox socket. Sariling filesystem ang ginagamit ng container, kaya hindi nakikita ng dalawang session ang parehong files. Normal na makakapagpadala ng mensahe sa isa't isa ang dalawang session sa loob ng parehong container. Ipinapaliwanag din ng parehong rule kung bakit hindi magkaabot ang session na tumatakbo bilang root at ang session na tumatakbo bilang normal user mo: limitado ang socket sa operating system user na nagmamay-ari nito.

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

Ituring na untrusted input ang text, dahil maaaring nagbasa ang sending session ng web page, README, o issue comment na isinulat ng ibang tao. Pinipigilan na mismo ng Claude Code ang mensahe na kumilos nang mag-isa: hindi nito maaaprubahan 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. Saklaw ng mga proteksiyong ito ang permissions ngunit hindi ang judgement, kaya basahin muna ang natanggap bago mo utusan ang receiving session na kumilos.

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

Hindi, kung nasa iisang machine ang dalawang session. Dumadaan ang mensahe sa per-session socket sa machine na iyon at hindi sa Anthropic servers. Text lang na isinulat ni Claude ang ipinapadala; hindi kasama ang conversation history o files. Ang mga mensahe sa session na nasa iba mo pang machine, o sa session sa web, ay dumadaan sa Anthropic servers sa pamamagitan ng Remote Control connection. Sa direksiyong iyon, makakasagot lamang si Claude sa mensaheng natanggap niya at hindi siya makakapagsimula ng mensahe. Itakda ang isolatePeerMachines sa true upang kailanganin ang approval mo bago may anumang lumabas sa machine.