Jinsi ya kuunganisha vipindi vya Claude Code

Maana ya vipindi vya Claude Code kuwasiliana

Vipindi viwili vya Claude Code vinaweza kutumiana ujumbe vinapokuwa vinafanya kazi kwenye mashine moja, chini ya mtumiaji mmoja wa mfumo wa uendeshaji. Ujumbe ni kipande kimoja cha maandishi ya kawaida ambacho Claude mmoja humwandikia mwingine. Haukubebi historia ya mazungumzo wala faili zozote. Claude hutafuta kipindi kingine kwa kutumia zana ya ListAgents na kuwasilisha maandishi hayo kwa SendMessage, kwa hivyo huna haja ya kutumia zana yoyote kati ya hizo wewe mwenyewe. Unasema kile ambacho kipindi kingine kinahitaji kujua, na Claude huandika ujumbe huo wenyewe.

Kipengele hiki kinaitwa cross-session messaging. Kufikia Agosti 2026, kinahitaji Claude Code v2.1.224 au toleo jipya zaidi, na kinafanya kazi kwenye macOS na Linux, ikijumuisha Linux ndani ya WSL 2. Hakuna usaidizi wa asili wa Windows, na kipengele hiki hakipatikani kwenye Amazon Bedrock, Claude Platform kwenye AWS, Google Cloud's Agent Platform, au Microsoft Foundry. Wakati kipindi kinapokidhi mahitaji hayo, utumaji ujumbe huwa umewashwa tayari na hakuna cha kusanidi. Tabia inayoelezewa hapa chini inatokana na nyaraka za Anthropic kuhusu cross-session messaging.

VPS ndipo mahali ambapo jambo hili ni muhimu, kwa sababu VPS ndipo vipindi vinapoishi kwa muda mrefu kiasi cha kufaa kushughulikiwa. Kwenye kompyuta ya mkononi, unafunga mfuniko. Kwenye seva iliyo chini ya tmux, kipindi ulichokianzisha siku ya Jumatatu bado kinaendelea kufanya kazi siku ya Alhamisi, kikiwa bado kimeshikilia muktadha wa hazina (repository) moja. Mara tu unapokuwa na vipindi viwili vya aina hiyo, jinsi vinavyozungumza huacha kuwa nadharia. Ikiwa bado hujaweka usanidi huo, anza na kuendesha Claude Code kwenye VPS chini ya tmux, ambayo inashughulikia mfumo wa vipindi ambao mwongozo huu unauzingatia.

Wakati kikao cha pili kinastahili gharama ya token

Anza kwa kuangalia gharama. Kila kikao ni mfano (instance) wa Claude unaojitegemea wenye dirisha lake la muktadha (context window), kwa hivyo vikao viwili hugharimu takriban mara mbili ya kile kimoja kwa kipindi hicho hicho. Ujumbe uliotumwa huhesabiwa katika matumizi kama vile prompt uliyoiandika. Uratibu hauji bure, na kazi ambayo kimsingi ni mfululizo mmoja wa hatua huwa polepole na ghali zaidi unapoigawa katika vikao tofauti.

Hali ambazo kikao cha pili hujilipia zenyewe zina sifa moja kuu. Kazi mbili zinafanyika kwa wakati mmoja bila kusubiriana, na mojawapo inajifunza kitu ambacho nyingine inakihitaji katikati ya kazi.

• Kikao kimoja kinagundua mabadiliko yanayovunja mfumo (breaking change) wakati kingine kinajenga juu ya msimbo uliovunjika. Claude hufanya muhtasari wa mabadiliko hayo na kuyatuma, badala ya wewe kuyaandika upya katika terminal nyingine.
• Vikao viwili vinafanya kazi kwenye repository moja katika git worktrees tofauti, na kimoja kinahitaji kujua nini kimeingizwa.
• Uhamiaji (migration) mrefu au jaribio la utendaji (test run) hurudisha matokeo yake kwenye kikao unachokifuatilia.
• Kikao cha ujenzi na kikao cha uhakiki, ambapo mkaguzi anasoma kile kilichozalishwa na mjenzi na kutuma nyuma kile alichokigundua.

Wakati kazi ni ya mfululizo, au wakati vikao vyote viwili vitahariri faili zilezile, tumia kikao kimoja. Unapotaka kikundi kilichoratibiwa ambacho Claude anakianzisha na kukisimamia ndani ya kazi moja, hiyo ni timu za wakala (agent teams), kipengele tofauti ambacho bado kiko katika majaribio. Unapotaka tu mazungumzo yale yale katika terminal nyingine, endeleza kikao hicho (resume) badala yake. Ujumbe kati ya vikao ni kwa ajili ya vikao huru unavyovianzisha na kuviongoza wewe mwenyewe.

Hakikisha kipengele kipo kabla ya kukitegemea

Kwanza, angalia toleo:

claude --version

Linganisha namba hiyo na 2.1.224. Kisha, ndani ya session, chapa /list-agents, ambayo pia inajibu kwa /peers. Inaorodhesha kila agent inayoweza kufikiwa na session hii, pamoja na jina ambalo kila mmoja anajibu kwalo. Ikiwa amri hiyo haitambuliki kabisa, session hii haina uwezo wa kutuma ujumbe kati ya session (cross-session messaging), na hakuna faili ya mipangilio itakayobadilisha hilo. Chapa /status na utafute mstari wa Peer address: unashikilia anwani ya inbox ya session hii, ikiwa na prefix ya uds:.

Mtego mmoja huwakumba watumiaji wa VPS hasa. Ujumbe kati ya session hutegemea tathmini ya feature-flag, na vigezo kadhaa vya faragha huzima tathmini hiyo, jambo linaloiacha kipengele hicho katika hali yake ya kawaida ya kuzimwa. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, na DISABLE_GROWTHBOOK zote hufanya hivi. Watu huimarisha seva mpya kwa kubandika (paste) vigezo hivyo kwenye ~/.bashrc, kisha wanashangaa kwa nini /list-agents haipo. Thamani zilezile zinaweza kutoka kwenye ramani ya env katika faili ya mipangilio au kutoka kwenye mipangilio inayodhibitiwa, kwa hivyo kagua shell kwanza.

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

Ondoa (unset) kigezo chochote kinachotoa matokeo. Kwa DISABLE_TELEMETRY na CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, thamani yoyote isiyo tupu huwasha tabia hiyo, ikiwemo kamba (string) 0, kwa hivyo DISABLE_TELEMETRY=0 haifanyi kile inachoonekana kufanya. Unaikata kwa kuondoa kigezo hicho au kukiweka kuwa kamba tupu.

Patia vikao vyako majina, la sivyo Claude hawezi kuvitambua

Claude anashughulikia ujumbe kwa kurejelea jina la kikao. Weka jina hilo unapoanzisha kikao:

claude --name builder-api

Unaweza pia kuliweka kwa kutumia /rename ndani ya kikao kinachoendelea. Usipoweka jina lolote, Claude Code huchukua jina kutoka kwenye folda ya saraka ya kazi, kama vile myapp-3f. Hili linafaa kwa kikao kimoja lakini linachanganya ukiwa na vikao vinne, na vikao viwili vinaweza kuishia kuwa na jina moja. Toleo la /list-agents linaonyesha saraka ya kazi ya kila kikao cha ndani, jambo linalosaidia kutofautisha vikao vyenye majina yanayofanana, na orodha ya Claude huongeza kitambulisho kifupi kwenye anwani majina yanapogongana. Kujipa majina mwenyewe ni rahisi zaidi kuliko kusoma vitambulisho.

Mpangilio wa tmux wa vipindi viwili unaoweza kuurudia

Hiki ni kipindi cha ujenzi na kipindi cha uhakiki kwenye hazina moja. Mhakiki hufanya kazi katika git worktree tofauti, kwa hivyo vipindi hivi viwili haviandiki kwenye faili moja. git worktree add pamoja na HEAD hutoa detached checkout, ambayo ndiyo unayohitaji kwa kipindi kinachosoma badala ya kufanya 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

Ctrl+b kisha w huorodhesha madirisha kwa jina ili uweze kuchagua moja. Katika dirisha la ujenzi, endesha /list-agents. Unapaswa kuona reviewer-api ikiwa na saraka yake ya kazi ~/src/api-review. Ikiwa haipo, kipindi cha uhakiki hakijamaliza kuanza, au moja ya matatizo mawili katika sehemu inayofuata yanahusika. Kisha kabidhi kitu kwa lugha rahisi:

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

Claude huandika muhtasari na kuutuma. Huandiki maandishi ya ujumbe, na kile Claude anachotuma hutofautiana. Katika dirisha la uhakiki, ujumbe huonekana kwenye mazungumzo na jina la mtumaji. Ikiwa kipindi hicho hakina kazi, Claude huanza zamu mpya mara moja. Ikiwa kiko katikati ya zamu, ujumbe husubiri hadi kati ya wito wa zana, kwa hivyo amri inayotiririka haikatizwi kamwe. Mara tu Claude anapousoma, ujumbe hukunjwa na kuwa mstari mmoja wa Message from ambao Ctrl+O huupanua. Jozi hii hufanya kazi vizuri zaidi wakati mjenzi anapoweka mabadiliko yake madogo, kwa sababu diff nyembamba hufanya makabidhiano mafupi na uhakiki ambao kipindi kingine kinaweza kumaliza kwa zamu moja, ambayo ndiyo tabia ambayo ujuzi wa msanidi mwandamizi mvivu upo ili kuitekeleza.

Nani anaweza kuona nani kwenye VPS moja

Uwasilishaji kwenye mashine moja haupiti kamwe kwenye seva za Anthropic. Kila kipindi (session) huandika faili za usajili kwenye diski na kufungua socket yake ya kikasha (inbox socket), na Claude Code husoma faili hizo ili kupata vipindi vyako vingine. Matokeo mawili hujitokeza, na yote huathiri seva.

Socket imezuiliwa kwa mtumiaji wako wa mfumo wa uendeshaji. Kipindi ulichokianzisha kama root na kipindi ulichokianzisha kama deploy haviwezi kuonana, hata vikiwa kando kando katika seva moja ya tmux, kwa sababu vipindi vya mtumiaji mmoja haviwezi kufikia socket ya mtumiaji mwingine. Endesha vipindi vyote kama mtumiaji yuleyule.

Container ina mfumo wake wa faili. Kipindi kilicho ndani ya Docker na kipindi kilicho kwenye host haviwezi kufikiana, kwa sababu havisomi faili zilezile za usajili. Vipindi viwili vilivyo ndani ya container moja vinaweza kutumiana ujumbe kama kawaida. Ikiwa unaweka mawakala (agents) kwenye container kwa ajili ya kutengwa, kama ilivyo katika kuendesha mawakala wa programu kwenye VM inayoweza kufutwa, tarajia utumaji ujumbe ufanye kazi ndani ya container na si kuvuka mpaka wa container.

Vipindi vyako kwenye mashine nyingine, na kwenye wavuti, huonekana kwenye orodha tu wakati Remote Control imeunganishwa, na huwekewa alama kama hivyo. Claude hapa anaweza kujibu tu ujumbe uliotoka kwenye mojawapo ya vipindi hivyo. Hawawezi kuanzisha mawasiliano hayo.

Kwa nini ujumbe wako haukufika

Sababu ya kawaida haina uhusiano wowote na mtandao. Kikao cha upokeaji huamua nini kifanyike na ujumbe, na uamuzi ulikuwa kutouwasilisha. Kila ujumbe unaoingia huishia katika mojawapo ya matokeo matatu: kuwasilishwa, kushikiliwa (kuwekwa kando bila kuwasilishwa hadi utakapoidhinisha), au kukataliwa (kufutwa bila kuwasilishwa).

Wakati thamani yoyote ya crossSessionInbound haitumiki, Claude Code huamua kwa kila ujumbe kwa kulinganisha njia za ruhusa za vikao hivyo viwili. Hupanga vikao vinavyoruka maombi ya ruhusa katika daraja moja na kila kikao kingine katika daraja la pili. auto, acceptEdits, na dontAsk huhesabiwa kama maombi. Hali ya Plan huhesabiwa kama kuruka maombi katika kikao ambacho kina ruhusa za kuruka maombi. Kanuni hiyo basi ni linganifu:

• Kikao cha upokeaji kinachoomba ruhusa hupokea kila ujumbe. Hushikilia ujumbe pale tu kikao cha utumaji kinapojitambulisha kama kinachoruka maombi.
• Kikao cha upokeaji kinachoruka maombi hushikilia kila ujumbe kwa ajili ya idhini yako. Huwasilisha ujumbe pale tu mtumaji anapokuwa pia anaruka maombi.

Kwa hivyo, mtiririko wa kwanza wa kazi ambao watu wengi huunda ndio hasa ule ambao haufanyi kazi. Unaanza mjenzi (builder) na --permission-mode bypassPermissions kwa sababu unataka uendeshe bila kusimamiwa, unaacha mkaguzi (reviewer) kwenye mipangilio ya kawaida, na kila ujumbe unaotumwa na mjenzi husubiri kwenye kidirisha cha idhini ambacho hakuna mtu anachokiangalia. Kidirisha hicho hufungwa baada ya muda wa mwisho wa dialogExpiry, ambao kwa kawaida ni 5m, na ujumbe hufutwa. Kwenye mashine hiyo hiyo, kikao cha utumaji hupata taarifa wakati ujumbe wake unaposhikiliwa, na taarifa ya ufuatiliaji wakati mpokeaji baadaye anapouwasilisha, kuukataa, au kuufuta, kwa hivyo soma skrini ya mtumaji kabla ya kulaumu socket.

Ili kufanya kikao kipokee ujumbe bila kusimamiwa, weka crossSessionInbound kuwa accept. Mahali unapoiweka huamua kama inatumika. Claude Code husoma mipangilio iliyosimamiwa kwanza, kisha bendera ya --settings, kisha mipangilio ya mtumiaji, na hutumia thamani ya kwanza inayopata. Thamani katika mipangilio ya mradi au ya ndani inatumika tu wakati ni kali zaidi, kwenye ngazi ya accept < hold < refuse. Thamani ya accept katika .claude/settings.json ni legevu kuliko nyingine yoyote, kwa hivyo hupuuzwa wakati wowote chanzo kinachoaminika kimeweka thamani. Iweke katika ~/.claude/settings.json, au ipitishe kwa kikao kimoja:

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

Mfanyakazi wa claude -p asiye na kichwa (headless) hufunga socket ya kikasha kama kikao cha mwingiliano na huonekana kwenye orodha, lakini hakiwezi kuonyesha kidirisha cha idhini. Ujumbe ulioshikiliwa hapo hubaki umeshikiliwa hadi hali ya baadaye au mabadiliko ya mipangilio yauruhusu. Mstari wa --settings hapo juu ndio njia unayotumia kuruhusu mfanyakazi kama huyo kupokea ujumbe. Kikao kilichoanzishwa katika hali ya bare hakifungi socket yoyote, kwa hivyo hakiwezi kupokea ujumbe wala kuonekana kwenye orodha.

Mahali ambapo makabidhiano hukwama

Mizunguko ya ujumbe hushughulikiwa kwa ajili yako. Claude Code huweka kikomo cha kasi (rate-limit) kwa ujumbe unaojirudia kwa kila mtumaji, hufuta ujumbe unaofanana unaoingia ndani ya muda mfupi, na huweka ukomo wa ujumbe 50 unaosubiri kusomwa kwa kila kikao, ili vikao viwili visiweze kuendelea kuping-pong milele. Ujumbe ulioshikiliwa una ukomo wa 100, na ujumbe wa zamani zaidi hufutwa baada ya hapo.

Kushindwa kunakotokea ni kwa utulivu zaidi, na ni suala la makabidhiano badala ya mzunguko. Kikao A humuuliza kikao B swali ambalo linahitaji jibu kabla ya kuendelea, kisha huenda kwenye hali ya kutofanya kazi (idle). B hushikilia ujumbe huo, au B yuko katikati ya kazi ndefu, au B anajibu swali ambalo A hakuuliza kweli. A husubiri. Unarudi saa moja baadaye na kukuta vikao viwili vikiwa havifanyi kazi na hakuna kazi iliyokamilika.

Andika makabidhiano ambayo hayahitaji jibu. Ujumbe mzuri hubeba ukweli au uamuzi: nini kimebadilika, na matokeo yalikuwa nini. Ujumbe mbaya huomba ruhusa kutoka kwa kikao kingine, au huomba jibu ambalo mtumaji amekwama kwalo. Claude tayari ameelekezwa kamwe asiombe kikao kingine kufanya kitendo ambacho mipangilio yake ya ruhusa ingekizuia, na badala yake aelekeze kazi hiyo kwako. Panua kanuni hiyo wewe mwenyewe. Ikiwa kikao hakiwezi kupiga hatua bila jibu, wewe ndiye unayepaswa kulijibu. Nidhamu ya muktadha (context) inasaidia hapa pia, kwa sababu kikao kilichopoteza uzi wa mazungumzo huandika ujumbe usioeleweka; kusimamia muktadha katika Claude Code kunashughulikia upande huo.

Chukulia ujumbe unaoingia kama data isiyoaminika

Claude Code humjulisha Claude anayepokea ujumbe kuwa ujumbe huo umetoka katika session nyingine na si kutoka kwako, na huwekea mipaka kile ujumbe huo unachoweza kufanya. Ujumbe hauwezi kujibu ombi la ruhusa lililosubiriwa kwa niaba yako, kwa sababu idhini kutoka kwa session nyingine si idhini yako. Hauwezi kubadilisha mipangilio ya ruhusa, CLAUDE.md, au usanidi mwingine kwa sababu session nyingine imeomba hivyo. Slash command iliyo ndani ya maandishi, kama vile /compact, hufika kama maandishi ya kawaida na haitekelezwi kamwe. Ikiwa utekelezaji wa ujumbe unahitaji ruhusa ambayo session inayopokea haina, utaona ombi lilelile ambalo ungeona kwa kazi nyingine yoyote. Katika auto mode, classifier pia hupitia kila ujumbe kabla ya kuwasilishwa, na ujumbe unaozuiwa na classifier haumfikii mpokeaji kamwe. Mipaka hii hudumu hata katika permissive modes, ndiyo maana session inayopokea ujumbe kutoka nje huizuia kwa chaguo-msingi badala ya kuiamini.

Hayo yanahusu ruhusa. Hayahusu maudhui. Session inayotuma ujumbe inaweza kuwa imesoma maelezo ya pull request, ukurasa wa wavuti, README ya dependency, au maoni ya issue yaliyoandikwa na mgeni, na chochote ilichosoma kinaweza kuathiri maandishi inayoandikia session yako nyingine. Ujumbe ni data. Unastahili kutiliwa shaka kama maandishi mengine yoyote yaliyoingia kwenye session kutoka nje. Hii ndiyo nidhamu iliyoelezewa katika kuepusha siri zako na AI agents: chukulia chochote kilichovuka mpaka wa uaminifu kinaweza kuwa si sahihi, na usiruhusu kamwe kijipe idhini yenyewe.

Kuna vidhibiti viwili ikiwa unataka kupunguza hali hii. Kuweka crossSessionInbound kuwa refuse hufuta ujumbe wa peer unaoingia bila kuuwasilisha, na kutoka kwa mipangilio ya mradi au ya ndani, thamani hiyo hutumika juu ya vyanzo vingine vyote, kwa sababu ndiyo kali zaidi katika ngazi ya utekelezaji. Ili kuzuia session hii kutuma au kuorodhesha, ongeza sheria za kukataa ruhusa (deny rules) kwa kutaja SendMessage na ListAgents, zote zikiwa zimeandikwa kama majina ya zana (tool names) bila specifier yoyote. Kuweka isolatePeerMachines kuwa true kunahitaji idhini yako ya wazi kabla ya ujumbe wowote kufikia session iliyo nje ya mashine hii, na idhini hiyo inahitajika hata katika bypassPermissions mode.

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

Kukataa SendMessage pia huondoa uwezo wa kutuma ujumbe kwa subagents, kwa kuwa zana hiyo hiyo hutumika kwa yote mawili. Session inayokataa haionyeshi mabadiliko yoyote yanayoonekana katika /status yake au katika orodha za session nyingine, kwa hivyo thibitisha mpangilio huo kutoka kwa usanidi wa session badala ya kuutazama kwenye skrini.

Madaraja na seva za MCP za kumbukumbu iliyoshirikiwa

Miradi kadhaa ya watu wengine ilijitokeza katika kipindi hicho ikifanya kazi zinazofanana: madaraja ya ndani ya wakala-kwa-wakala (agent-to-agent bridges) yanayopitisha maandishi kati ya mawakala wanaoendelea kufanya kazi, na seva za MCP (model context protocol) zinazowapa mawakala kadhaa hifadhi moja iliyoshirikiwa ya kusoma na kuandika. Yachukulie haya kama muundo tofauti badala ya mshindani, na hakikisha kila amri ya usakinishaji inalingana na README ya mradi husika kabla ya kuiendesha. Ujumbe ni wa aina ya "push", kwa sababu mtumaji huweka maandishi kwenye zamu ya mpokeaji. Hifadhi iliyoshirikiwa ni ya aina ya "pull", kwa sababu hakuna anayekatizwa na kipindi (session) huona dokezo wakati kinapoliangalia tena. "Pull" ni tulivu zaidi kwa hali inayobadilika polepole, na hufanya kazi tu wakati kipindi kinapoliangalia kikweli.

Ukifuata njia hiyo, maswali ya kujiuliza yanahusu mchakato badala ya orodha ya vipengele. Seva huendeshwa na mtumiaji yupi, na inaweza kusoma nini kwenye seva hiyo. Kuendesha seva za MCP kwenye VPS kunashughulikia usanidi huo. Kushiriki ujuzi wa wakala kati ya repo kunashughulikia hali rahisi zaidi ambapo unachotaka kushiriki kati ya vipindi ni maelekezo badala ya hali ya sasa (live state), na huondoa ujumbe mwingi ambao ungetuma vinginevyo. Kwa mtazamo mpana zaidi, kuendesha wakala wa usimbaji kwenye VPS ndipo mahali pa kuanzia.

FAQ

Kwa nini /list-agents haitambuliki katika session yangu?

Session haina uwezo wa kutuma ujumbe kati ya session tofauti. Kwanza, kagua claude --version dhidi ya 2.1.224, kwa sababu kipengele hiki kinahitaji toleo hilo au la baadaye. Kisha, kagua mfumo unaotumia, kwa sababu inafanya kazi kwenye macOS na Linux pekee na si kwenye Windows asilia, na haipatikani kwenye Amazon Bedrock, Claude Platform kwenye AWS, Google Cloud's Agent Platform, au Microsoft Foundry. Ikiwa yote ni sawa, kagua shell yako kwa DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, au DISABLE_GROWTHBOOK, kwa sababu kila moja ya hayo huzuia tathmini ya feature-flag ambayo kipengele hiki kinategemea na kuifanya isifanye kazi.

Kwa nini ujumbe wangu kwa session nyingine haukufika?

Ikiwa /list-agents inafanya kazi, basi utumaji ujumbe umewashwa na kuna kitu kingine kidogo kilichozuia ujumbe huo. Sababu ya kawaida ni viwango vya ruhusa (permission modes). Session inayopita (bypass) maombi ya ruhusa hushikilia kila ujumbe unaoingia ili upate idhini yako, isipokuwa mtumaji naye pia apite (bypass), na kisanduku hicho cha idhini hufutwa baada ya muda wa mwisho wa dialogExpiry, ambao ni dakika tano kwa chaguomsingi. Kagua session inayotuma ujumbe ili kuona taarifa ya ujumbe ulioshikiliwa. Ili kurekebisha hili, weka crossSessionInbound kuwa accept katika ~/.claude/settings.json au uipitishe kwa --settings, kwa sababu accept katika mipangilio ya mradi au ya ndani hupuuzwa kwa kuwa ni thamani isiyo na nguvu (looser value).

Je, session ya Claude Code iliyo ndani ya Docker inaweza kutuma ujumbe kwa session iliyo kwenye host?

Hapana. Session hutafutana kupitia faili za usajili kwenye diski na socket ya inbox ya kila session, na container ina mfumo wake wa faili, kwa hivyo hizo mbili haziwezi kuona faili zilezile. Session mbili zilizo ndani ya container moja zinaweza kutumiana ujumbe kama kawaida. Kanuni hiyo hiyo inaeleza kwa nini session inayofanya kazi kama root na session inayofanya kazi kama mtumiaji wako wa kawaida haziwezi kufikiana: socket imezuiliwa kwa mtumiaji wa mfumo wa uendeshaji anayeimiliki.

Je, ujumbe kutoka kwa session nyingine ya Claude Code ni salama kuufanyia kazi?

Chukulia maandishi hayo kama data isiyoaminika, kwa sababu session inayotuma inaweza kuwa imesoma ukurasa wa wavuti, README, au maoni ya suala (issue comment) yaliyoandikwa na mtu mwingine. Claude Code tayari inazuia ujumbe huo usijifanyie kazi wenyewe: haiwezi kuidhinisha ombi la ruhusa linalosubiri, haiwezi kubadilisha mipangilio ya ruhusa au CLAUDE.md kwa ombi, na amri ya slash (slash command) iliyo kwenye maandishi hufika kama maandishi ya kawaida na haitekelezwi kamwe. Kinga hizo hufunika ruhusa na si uamuzi, kwa hivyo soma kile kilichofika kabla hujaambia session inayopokea ikifanyie kazi.

Je, utumaji ujumbe kati ya session tofauti hutuma code yangu kwa Anthropic?

Kati ya session mbili kwenye mashine moja, hapana. Ujumbe husafiri kupitia socket ya kila session kwenye mashine hiyo na haupiti kamwe kwenye seva za Anthropic, na maandishi yaliyoandikwa na Claude pekee ndiyo yanayotumwa, si historia ya mazungumzo au faili. Ujumbe kwa session iliyo kwenye mashine yako nyingine, au kwa session iliyo kwenye wavuti, husafiri kupitia seva za Anthropic kupitia muunganisho wa Remote Control, na katika mwelekeo huo Claude anaweza kujibu tu ujumbe uliowasili, hawezi kuanzisha ujumbe. Weka isolatePeerMachines kuwa true ili kuhitaji idhini yako kabla ya kitu chochote kutoka kwenye mashine hiyo.