Jinsi ya kuunganisha vipindi vya Claude Code

Maana ya vipindi vya Claude Code kuwasiliana

Vipindi viwili vya Claude Code vinaweza kuwasiliana wakati vinaendeshwa kwenye mashine moja, chini ya mtumiaji mmoja wa mfumo wa uendeshaji. Ujumbe ni kipande kimoja cha matini ya kawaida ambacho Claude mmoja humwandikia mwingine. Ujumbe huu haubebi historia ya mazungumzo wala faili zozote. Claude hutafuta kipindi kingine kwa kutumia zana ya ListAgents na kuwasilisha matini hiyo 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, ikiwemo 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, mawasiliano huwa tayari yameshawezeshwa na hakuna cha kufanya ili kuyaanzisha. Tabia inayoelezwa hapa chini inatokana na nyaraka za Anthropic kwa ajili ya cross-session messaging.

VPS ndipo mahali ambapo jambo hili ni muhimu, kwa sababu VPS ndipo vipindi vinapoishi kwa muda mrefu kiasi cha kustahili kuwasiliana. 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 kama hivyo, 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 kinapostahili gharama ya token

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

Hali ambazo kikao cha pili hulipa gharama yake zina sifa moja inayofanana. Vipande viwili vya kazi vinafanyika kwa wakati mmoja bila kusubiriana, na kimoja kati ya hivyo hujifunza kitu ambacho kingine kinakihitaji katikati ya kazi.

• Kikao kimoja kinagundua mabadiliko yanayovunja mfumo (breaking change) wakati kingine kinajenga juu ya msimbo uliovunjwa. Claude hufanya muhtasari wa mabadiliko hayo na kuutuma, badala ya wewe kuandika upya kwenye terminal nyingine.
• Vikao viwili vinafanya kazi kwenye repository moja katika git worktrees tofauti, na kimoja kinahitaji kujua nini kimeingia (landed).
• Uhamiaji (migration) mrefu au jaribio la kukimbia (test run) huripoti matokeo yake kwenye kikao unachokifuatilia.
• Kikao cha ujenzi (builder) na kikao cha uhakiki (reviewer), ambapo mkaguzi husoma 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 hukianzisha na kukisimamia ndani ya kazi moja, hizo ni timu za wakala (agent teams), kipengele tofauti ambacho bado kiko katika majaribio. Unapotaka tu mazungumzo yaleyale kwenye terminal nyingine, endeleza kikao hicho (resume). Ujumbe wa kuvuka vikao (cross-session messaging) ni kwa ajili ya vikao huru unavyovianzisha na kuviongoza wewe mwenyewe.

Hakikisha kipengele kipo kabla ya kukitegemea

Kwanza, toleo:

claude --version

Linganisha namba hiyo na 2.1.224. Kisha, ndani ya session, chapa /list-agents, ambayo pia inaitikia /peers. Inaorodhesha kila agent inayoweza kufikiwa na session hii, pamoja na jina ambalo kila mmoja anaitikia. Ikiwa amri 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 huathiri 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 kwa 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 ya maandishi 0, kwa hivyo DISABLE_TELEMETRY=0 haifanyi kile inachoonekana kufanya. Unaizima kwa kuondoa kigezo hicho (unset) au kukiweka kuwa kamba tupu.

Patia vikao vyako majina, la sivyo Claude hataweza kuvitambua

Claude huita ujumbe kwenye kikao kwa kutumia jina lake. 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 huleta mkanganyiko kwa vikao vinne, na vikao viwili vinaweza kuishia kuwa na jina moja. Toleo la /list-agents huonyesha saraka ya kazi ya kila kikao cha ndani, jambo linalosaidia kutofautisha vikao vyenye majina yanayofanana, na orodha ya Claude huongeza kitambulisho kifupi kwenye anwani wakati majina yanapogongana. Kujipa majina mwenyewe ni rahisi zaidi kuliko kusoma vitambulisho.

Mpangilio wa tmux wa vipindi viwili unaoweza kuurudia

Hiki ni kipindi cha ujenzi (builder) na kipindi cha uhakiki (reviewer) kwenye hazina (repository) moja. Mhakiki anafanya kazi katika git worktree tofauti, kwa hivyo vipindi hivi viwili haviwahi kuandika kwenye faili moja. git worktree add pamoja na HEAD hutoa detached checkout, jambo ambalo ni muhimu kwa kipindi kinachosoma badala ya kufanya commit. Kwa sababu vipindi hivi viwili vinafanya kazi tofauti, inafaa kumpa mhakiki mtindo wa matokeo wake binafsi, ambao hubadilisha system prompt ya kipindi hicho na hivyo kudumu katika kila hatua badala ya kupotea kama maelekezo uliyochapa mara moja.

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 majina 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 yanajitokeza. 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 hatua mpya mara moja. Ikiwa kiko katikati ya hatua, ujumbe husubiri hadi kati ya wito wa zana (tool calls), kwa hivyo amri inayotekelezwa haiingiliwi 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 katika hatua moja, ambayo ndiyo tabia ujuzi wa msanidi mwandamizi mvivu uliopo ili kuitekeleza.

Nani anaweza kuona nani kwenye VPS moja

Uwasilishaji wa ndani ya mashine moja haupiti kwenye seva za Anthropic. Kila session huandika faili za usajili kwenye diski na kufungua socket yake ya inbox, na Claude Code husoma faili hizo ili kupata session zako nyingine. Matokeo mawili yanajitokeza, na yote huathiri seva.

Socket imezuiwa kwa mtumiaji wako wa mfumo wa uendeshaji. Session uliyoianzisha kama root na session uliyoianzisha kama deploy haziwezi kuonana, hata zikiwa kando kando katika tmux server moja, kwa sababu session za mtumiaji mmoja haziwezi kufikia socket ya mtumiaji mwingine. Endesha session zote mbili kama mtumiaji yuleyule.

Container ina mfumo wake wa faili. Session iliyo ndani ya Docker na session iliyo kwenye host haziwezi kufikiana, kwa sababu hazisomi faili zilezile za usajili. Session mbili zilizo ndani ya container moja zinaweza kutumiana ujumbe kama kawaida. Ikiwa unaweka mawakala (agents) kwenye container kwa ajili ya usalama, kama ilivyo katika kuendesha mawakala wa programu kwenye VM ya muda, tarajia ujumbe kufanya kazi ndani ya container na si kuvuka mpaka wa container hiyo.

Session zako kwenye mashine nyingine, na kwenye wavuti, huonekana kwenye orodha tu wakati Remote Control imeunganishwa, na zimewekewa alama kama hizo. Claude hapa anaweza kujibu tu ujumbe uliotoka kwenye moja ya hizo. Haziwezi kuanzisha mawasiliano hayo.

Kwa nini ujumbe wako haukufika

Sababu ya kawaida haina uhusiano wowote na mtandao. Kikao kinachopokea kiliamua nini cha kufanya na ujumbe huo, na uamuzi ulikuwa kutouwasilisha. Kila ujumbe unaofika huishia katika matokeo mojawapo kati ya matatu: kuwasilishwa, kushikiliwa (kuwekwa kando bila kuwasilishwa hadi utakapoidhinisha), au kukataliwa (kufutwa bila kuwasilishwa).

Wakati thamani ya crossSessionInbound haitumiki, Claude Code huamua kwa kila ujumbe kwa kulinganisha hali za ruhusa za vikao hivyo viwili. Hukusanya vikao vinavyoruka maombi ya ruhusa katika daraja moja na kila kikao kingine katika daraja la pili. auto, acceptEdits, na dontAsk huhesabika kama maombi. Hali ya Plan huhesabika kama kuruka maombi katika kikao ambacho kina ruhusa za kuruka maombi. Ikiwa huna uhakika ni daraja gani kikao kinaangukia, kile kila hali ya ruhusa inachofanya hasa inafaa kusomwa kwanza, kwa sababu auto ndipo vikao vingi vinapoanzia sasa na iko upande wa maombi wa mgawanyo huo. Kanuni basi ni linganifu:

• Kikao kinachopokea ambacho huomba ruhusa hupokea kila ujumbe. Hushikilia ujumbe pale tu kikao kinachotuma kinapojitambulisha kama kinachoruka maombi.
• Kikao kinachopokea ambacho huruka maombi hushikilia kila ujumbe kwa ajili ya idhini yako. Huwasilisha ujumbe pale tu mtumaji anapokuwa pia anaruka maombi.

Kwa hivyo, mtiririko wa kazi wa kwanza ambao watu wengi huunda ndio hasa ambao haufanyi kazi. Unaanza mjenzi na --permission-mode bypassPermissions kwa sababu unataka uendeshe bila kusimamiwa, unaacha mkaguzi kwenye mipangilio ya kawaida, na kila ujumbe unaotumwa na mjenzi husubiri kwenye kisanduku cha idhini ambacho hakuna anayekitazama. Kisanduku hicho hufungwa baada ya muda wa mwisho wa dialogExpiry, ambao kwa kawaida ni 5m, na ujumbe hufutwa. Kwenye mashine hiyo hiyo, kikao kinachotuma hupata taarifa wakati ujumbe wake unaposhikiliwa, na taarifa ya ufuatiliaji wakati mpokeaji atakapouwasilisha, kuukataa, au kuufuta baadaye, 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. accept katika .claude/settings.json ni legelege kuliko kitu chochote, 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 hufunga socket ya kikasha kama kikao cha mwingiliano na huonekana kwenye orodha, lakini hakiwezi kuonyesha kisanduku 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 (deadlock)

Mizunguko ya ujumbe hushughulikiwa kwa ajili yako. Claude Code huweka kikomo cha kasi (rate-limit) kwa ujumbe unaorudiwa kwa kila mtumaji, huondoa ujumbe unaofanana kabisa unaoingia ndani ya muda mfupi, na huweka ukomo wa ujumbe 50 unaosubiri kusomwa kwa kila session, hivyo session mbili haziwezi kuendelea kutumiana ujumbe (ping-pong) milele. Ujumbe ulioshikiliwa una ukomo wa 100, na ujumbe wa zamani zaidi huondolewa baada ya hapo.

Kushindwa kunakotokea ni kwa utulivu zaidi, na ni suala la makabidhiano badala ya mzunguko. Session A humuuliza session B swali ambalo inahitaji majibu kabla ya kuendelea, kisha inakuwa idle. B hushikilia ujumbe huo, au B yuko katikati ya kazi ndefu, au B anajibu swali ambalo A hakuuliza kweli. A anasubiri. Unarudi baada ya saa moja na kukuta session mbili zikiwa idle na hakuna kazi iliyofanyika.

Andika makabidhiano yasiyohitaji jibu. Ujumbe mzuri hubeba ukweli au uamuzi: nini kimebadilika, na matokeo yalikuwa nini. Ujumbe mbaya humuuliza session mwingine ruhusa, au jibu ambalo mtumaji amekwama nalo. Claude tayari ameelekezwa kamwe asiulize session mwingine kwa ajili ya kitendo ambacho mipangilio yake ya ruhusa ingekizuia, na badala yake aelekeze kazi hiyo kwako. Panua kanuni hiyo wewe mwenyewe. Ikiwa session haiwezi kupiga hatua bila jibu, wewe ndiye unayepaswa kulijibu. Nidhamu ya muktadha (context) inasaidia hapa pia, kwa sababu session iliyopoteza uzi huandika ujumbe usioeleweka; kusimamia muktadha katika Claude Code inashughulikia upande huo.

Chukulia ujumbe unaoingia kama data isiyoaminika

Claude Code humjulisha Claude anayepokea kuwa ujumbe huo umetoka kwenye session nyingine na si kutoka kwako, na huwekea mipaka kile ujumbe huo unachoweza kufanya. Utekelezaji huo upo kwenye programu inayozunguka model badala ya utayari wa model kufuata maagizo, ambayo ndiyo tofauti ya kiutendaji inayotolewa na agent harness. Ujumbe hauwezi kujibu ombi la ruhusa linalosubiri 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 matini, kama vile /compact, hufika kama matini 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 inayopita (bypassing session) hushikilia ujumbe unaoingia kwa chaguo-msingi badala ya kuuamini.

Hayo yanahusu ruhusa. Hayahusu maudhui. Session inayotuma 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 matini inayoandika kwenye session yako nyingine. Ujumbe huo ni data. Unastahili mashaka yaleyale kama matini nyingine yoyote iliyoingia kwenye session kutoka nje. Hii ndiyo nidhamu inayoelezewa katika kuepusha siri kwenye AI agents zako: chukulia kuwa chochote kilichovuka mpaka wa uaminifu kinaweza kuwa si sahihi, na usiruhusu kamwe kijipe idhini yenyewe.

Kuna vidhibiti viwili ikiwa unataka kupunguza haya. Kuweka crossSessionInbound kuwa refuse hufuta ujumbe wa peer unaoingia bila kuuwasilisha, na kutoka kwenye project au local settings, thamani hiyo hutumika juu ya vyanzo vingine vyote, kwa sababu ndiyo kali zaidi katika ngazi hiyo. Ili kuzuia session hii kutuma au kuorodhesha, ongeza sheria za kuzuia ruhusa (permission 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
}

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

Madaraja na seva za MCP za kumbukumbu iliyoshirikiwa

Miradi kadhaa ya watu wengine ilianza wakati mmoja ikifanya mambo yanayofanana: madaraja ya ndani ya wakala-kwa-wakala yanayopitisha maandishi kati ya mawakala wanaoendelea, na seva za MCP (model context protocol) zinazowapa mawakala kadhaa hifadhi moja iliyoshirikiwa ya kusoma na kuandika. Yachukulie kama umbo tofauti badala ya mshindani, na hakiki amri yoyote ya usakinishaji dhidi ya README ya mradi husika kabla ya kuiendesha. Ujumbe ni wa kusukuma (push), kwa sababu mtumaji huweka maandishi kwenye zamu ya mpokeaji. Hifadhi iliyoshirikiwa ni ya kuvuta (pull), kwa sababu hakuna anayekatizwa na kipindi (session) huona dokezo wakati kinapoiangalia tena. Kuvuta ni njia tulivu zaidi kwa hali inayobadilika polepole, na hufanya kazi tu wakati kipindi kinapoangalia.

Ukifuata njia hiyo, maswali ya kujiuliza yanahusu mchakato badala ya orodha ya vipengele. Seva huendeshwa kama mtumiaji yupi, na inaweza kusoma nini kwenye seva hiyo. Kuendesha seva za MCP kwenye VPS inashughulikia usanidi huo. Kushiriki ujuzi wa wakala kwenye repos inashughulikia hali rahisi zaidi ambapo unachotaka kushiriki kati ya vipindi ni maelekezo badala ya hali ya moja kwa moja (live state), na huondoa ujumbe mwingi ambao ungetuma vinginevyo. Kwa picha pana 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 na si kwenye Windows asilia, na haipatikani kwenye Amazon Bedrock, Claude Platform kwenye AWS, Google Cloud's Agent Platform, na 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 kukiacha kikiwa kimezimwa.

Kwa nini ujumbe wangu kwenda kwenye session nyingine haukufika?

Ikiwa /list-agents inafanya kazi, basi mfumo wa ujumbe umewashwa na kuna kitu kingine finyu kimezuia 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 anapita ruhusa hizo, na kisanduku hicho cha idhini hufutwa baada ya muda wa mwisho wa dialogExpiry, ambao ni dakika tano kwa kawaida. Kagua session inayotuma ujumbe kwa ajili ya 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.

Je, session ya Claude Code 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 (filesystem), kwa hivyo hizo mbili haziwezi kuona faili zilezile. Session mbili 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 issue 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 haiwezi kutekelezwa. Kinga hizo hufunika ruhusa na si uamuzi, kwa hivyo soma kile kilichofika kabla ya kuiambia session inayopokea ikifanyie kazi.

Je, 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 kwenda kwenye session iliyo kwenye mashine yako nyingine, au kwenye session iliyo kwenye wavuti, husafiri kupitia seva za Anthropic kupitia muunganisho wa Remote Control, na katika mwelekeo huo Claude anaweza tu kujibu ujumbe uliowasili, hawezi kuanzisha ujumbe. Weka isolatePeerMachines kuwa true ili kuhitaji idhini yako kabla ya kitu chochote kutoka kwenye mashine.