Claude Code sessies laten communiceren op een VPS

Wat het betekent als Claude Code-sessies berichten naar elkaar sturen

Twee Claude Code-sessies kunnen berichten naar elkaar sturen wanneer ze op dezelfde machine draaien, onder dezelfde gebruiker van het besturingssysteem. Een bericht is een stuk platte tekst dat de ene Claude voor de andere schrijft. Het bevat geen gespreksgeschiedenis en geen bestanden. Claude vindt de andere sessie met de ListAgents-tool en levert de tekst af met SendMessage, waardoor u geen van beide tools handmatig hoeft aan te roepen. U geeft aan wat de andere sessie moet weten en Claude schrijft het bericht zelf.

Deze functie heet cross-session messaging. Sinds augustus 2026 is hiervoor Claude Code v2.1.224 of hoger vereist en het werkt op macOS en Linux, inclusief Linux binnen WSL 2. Er is geen native Windows-ondersteuning en het is niet beschikbaar op Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform of Microsoft Foundry. Wanneer een sessie aan deze vereisten voldoet, is messaging al ingeschakeld en hoeft er niets geactiveerd te worden. Het onderstaande gedrag is afkomstig uit de Anthropic-documentatie voor cross-session messaging.

Op een VPS is dit relevant, omdat sessies daar lang genoeg blijven draaien om het de moeite waard te maken ze aan te sturen. Op een laptop klapt u het scherm dicht. Op een server onder tmux draait een sessie die u op maandag bent gestart op donderdag nog steeds, waarbij de context van één repository behouden blijft. Zodra u er twee heeft, wordt de manier waarop ze communiceren relevant. Als u dit nog niet heeft ingesteld, begin dan met Claude Code draaien op een VPS onder tmux, waarin de sessie-infrastructuur wordt behandeld waar deze handleiding vanuit gaat.

Wanneer een tweede sessie de tokens waard is

Begin bij de kosten. Elke sessie is een afzonderlijk Claude-exemplaar met een eigen contextvenster, waardoor twee sessies over dezelfde periode ongeveer twee keer zoveel kosten als één sessie. Een afgeleverd bericht telt voor het verbruik precies zoals een prompt die u zelf heeft getypt. Coördinatie is niet gratis, en werk dat in feite één reeks stappen is, wordt trager en duurder wanneer u dit over meerdere sessies verdeelt.

De gevallen waarin een tweede sessie zichzelf terugbetaalt, vertonen hetzelfde patroon. Twee taken worden tegelijkertijd uitgevoerd zonder op elkaar te wachten, en een van de twee verwerft tijdens het proces informatie die de andere nodig heeft.

• De ene sessie vindt een 'breaking change' terwijl de andere voortbouwt op de code die zojuist is gewijzigd. Claude vat de wijziging samen en verstuurt deze, in plaats van dat u deze opnieuw moet typen in de andere terminal.
• Twee sessies werken aan dezelfde repository in afzonderlijke git worktrees, en de een moet weten wat er is doorgevoerd.
• Een langdurige migratie of testrun rapporteert het resultaat terug aan de sessie die u in de gaten houdt.
• Een bouwer-sessie en een reviewer-sessie, waarbij de reviewer leest wat de bouwer heeft geproduceerd en terugstuurt wat er is gevonden.

Wanneer het werk sequentieel is, of wanneer beide sessies dezelfde bestanden zouden bewerken, gebruik dan één sessie. Wanneer u een gecoördineerde groep wilt die Claude zelf start en superviseert binnen één taak, dan gaat het om agent teams; dit is een afzonderlijke en nog experimentele functie. Wanneer u alleen hetzelfde gesprek in een andere terminal wilt, hervat dan de sessie. Berichten uitwisselen tussen sessies is bedoeld voor onafhankelijke sessies die u zelf start en aanstuurt.

Controleer of de functie aanwezig is voordat u deze in uw planning opneemt

Controleer eerst de versie:

claude --version

Vergelijk het nummer met 2.1.224. Typ vervolgens, binnen een sessie, /list-agents; dit commando reageert ook op /peers. Het toont elke agent die deze sessie kan bereiken, inclusief de naam waarop elke agent reageert. Als het commando helemaal niet wordt herkend, beschikt deze sessie niet over cross-session messaging en zal geen enkel instellingenbestand daar verandering in brengen. Typ /status en zoek naar een Peer address-regel: deze bevat het inbox-adres van de huidige sessie, voorafgegaan door uds:.

Eén valkuil treft specifiek VPS-gebruikers. Cross-session messaging is afhankelijk van de evaluatie van feature-flags, en verschillende privacyvariabelen schakelen die evaluatie uit, waardoor de functie in de standaard uitgeschakelde staat blijft. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC en DISABLE_GROWTHBOOK doen dit allemaal. Gebruikers beveiligen een nieuwe server door deze variabelen in ~/.bashrc te plakken en vragen zich vervolgens af waarom /list-agents niet bestaat. Dezelfde waarden kunnen afkomstig zijn uit de env-map in een instellingenbestand of uit beheerde instellingen, dus controleer eerst de shell.

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

Maak de variabele ongedaan die een waarde teruggeeft. Voor DISABLE_TELEMETRY en CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC geldt dat elke niet-lege waarde het gedrag inschakelt, inclusief de string 0; daarom doet DISABLE_TELEMETRY=0 niet wat het lijkt te doen. U schakelt het uit door de variabele te verwijderen (unset) of in te stellen op een lege string.

Geef uw sessies een naam, anders kan Claude ze niet adresseren

Claude adresseert een bericht aan een sessie op basis van de naam. Stel de naam in wanneer u de sessie start:

claude --name builder-api

U kunt deze ook instellen met /rename binnen een actieve sessie. Wanneer u niets instelt, leidt Claude Code een naam af van de mapnaam van de werkdirectory, zoals myapp-3f. Dat is prima voor één sessie, maar verwarrend voor vier, en twee sessies kunnen uiteindelijk dezelfde naam krijgen. De /list-agents-output toont de werkdirectory van elke lokale sessie, waarmee sessies met dezelfde naam van elkaar te onderscheiden zijn, en Claude's eigen lijst voegt een korte identificatie toe aan het adres wanneer namen botsen. Ze zelf een naam geven is efficiënter dan het lezen van identificatiecodes.

Een tmux-layout met twee sessies die u kunt reproduceren

Dit is een builder-sessie en een reviewer-sessie voor één repository. De reviewer werkt in een afzonderlijke git worktree, waardoor de twee nooit hetzelfde bestand bewerken. git worktree add met HEAD zorgt voor een detached checkout, wat gewenst is voor een sessie die leest in plaats van commits maakt. Omdat de twee sessies verschillende taken uitvoeren, is het zinvol om de reviewer een eigen outputstijl te geven. Dit wijzigt de systeemprompt van die sessie, waardoor deze gedurende elke beurt behouden blijft in plaats van te vervagen zoals een eenmalig ingevoerde instructie.

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 en vervolgens w sommen de vensters op naam op, zodat u er een kunt kiezen. Voer in het builder-venster /list-agents uit. U hoort reviewer-api te zien met de werkmap ~/src/api-review. Als deze ontbreekt, is de reviewer-sessie nog niet klaar met opstarten, of is een van de twee problemen uit de volgende sectie van toepassing. Draag vervolgens iets over in duidelijke taal:

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

Claude schrijft de samenvatting en verstuurt deze. U schrijft de berichttekst niet zelf en wat Claude verstuurt varieert. In het reviewer-venster verschijnt het bericht in het gesprek met de naam van de afzender. Als die sessie inactief is, start Claude direct een nieuwe beurt. Als de sessie midden in een beurt zit, wacht het bericht tot tussen de tool-aanroepen, zodat een lopend commando nooit wordt onderbroken. Zodra Claude het heeft gelezen, klapt het bericht in tot een Message from-rij van één regel die Ctrl+O uitvouwt. Het duo werkt beter wanneer de builder de wijzigingen klein houdt, omdat een beperkte diff zorgt voor een kortere overdracht en een review die de andere sessie in één beurt kan voltooien; dit is de gewoonte die de vaardigheid van de luie senior ontwikkelaar moet afdwingen.

Wie kan wie zien op één VPS

Aflevering op dezelfde machine verloopt nooit via de servers van Anthropic. Elke sessie schrijft registratiebestanden naar de schijf en bindt een eigen inbox-socket; Claude Code leest deze bestanden om uw andere sessies te vinden. Dit heeft twee gevolgen die beide van invloed zijn op een server.

De socket is beperkt tot uw besturingssysteemgebruiker. Een sessie die u bent gestart als root en een sessie die u bent gestart als deploy kunnen elkaar niet zien, zelfs niet naast elkaar in dezelfde tmux-server, omdat de sessies van de ene gebruiker de socket van de andere niet kunnen bereiken. Start beide sessies als dezelfde gebruiker.

Een container heeft een eigen bestandssysteem. Een sessie binnen Docker en een sessie op de host kunnen elkaar niet bereiken, omdat ze niet dezelfde registratiebestanden lezen. Twee sessies binnen dezelfde container kunnen normaal met elkaar communiceren. Als u agents in containers houdt voor isolatie, zoals beschreven in coding agents draaien in een wegwerpbare VM, houd er dan rekening mee dat berichtenverkeer alleen binnen een container werkt en niet over de containergrens heen.

Uw sessies op andere machines en op het web verschijnen alleen in de lijst zolang Remote Control verbonden is, en ze worden als zodanig gelabeld. Claude kan hier alleen antwoorden op een bericht dat afkomstig is van een van die sessies. Het kan die uitwisseling niet zelf starten.

Waarom uw bericht nooit is aangekomen

De gebruikelijke reden heeft niets met het netwerk te maken. De ontvangende sessie heeft besloten wat er met het bericht moet gebeuren, en de beslissing was om het niet af te leveren. Elk inkomend bericht eindigt in een van de drie uitkomsten: afgeleverd, vastgehouden (opzij gezet zonder aflevering totdat u het goedkeurt), of geweigerd (verwijderd zonder aflevering).

Wanneer er geen crossSessionInbound-waarde van toepassing is, beslist Claude Code per bericht door de permissiemodi van de twee sessies te vergelijken. Het groepeert sessies die toestemmingsvragen omzeilen in één klasse en elke andere sessie in de andere. auto, acceptEdits en dontAsk tellen als vragen om toestemming. De plan-modus telt als omzeiling in een sessie waarvoor omzeilingspermissies beschikbaar zijn. Als u niet zeker weet in welke klasse een sessie valt, is het de moeite waard om eerst wat elke permissiemodus daadwerkelijk doet te lezen, omdat auto de modus is waar de meeste sessies nu mee starten en deze aan de kant van de toestemmingsvragen van die splitsing valt. De regel is vervolgens symmetrisch:

• Een ontvangende sessie die om toestemming vraagt, krijgt elk bericht afgeleverd. Deze houdt er alleen een vast wanneer de verzendende sessie zichzelf identificeert als een sessie die vragen omzeilt.
• Een ontvangende sessie die vragen omzeilt, houdt elk bericht vast voor uw goedkeuring. Deze levert er alleen een af wanneer de afzender ook vragen omzeilt.

De eerste workflow die de meeste mensen bouwen, is dus precies degene die niet werkt. U start een builder met --permission-mode bypassPermissions omdat u wilt dat deze onbeheerd draait, u laat de reviewer op de standaardinstellingen staan, en elk bericht dat de builder verstuurt, wacht in een goedkeuringsdialoogvenster dat niemand bekijkt. Dat dialoogvenster sluit na de dialogExpiry-deadline, die standaard op 5m staat, en het bericht wordt verwijderd. Op dezelfde machine krijgt de verzendende sessie een melding wanneer het bericht wordt vastgehouden, en een vervolgbericht wanneer de ontvanger het later aflevert, weigert of laat verlopen. Lees dus het scherm van de afzender voordat u de socket de schuld geeft.

Om een sessie berichten onbeheerd te laten verwerken, stelt u crossSessionInbound in op accept. Waar u dit instelt, bepaalt of het van toepassing is. Claude Code leest eerst de beheerde instellingen, dan de --settings-vlag, dan de gebruikersinstellingen, en past de eerste waarde toe die het vindt. Een waarde in project- of lokale instellingen is alleen van toepassing wanneer deze strikter is, op de ladder accept < hold < refuse. Een accept in .claude/settings.json is soepeler dan al het andere, dus deze wordt genegeerd wanneer een vertrouwde bron een waarde heeft ingesteld. Plaats het in ~/.claude/settings.json, of geef het mee voor één sessie:

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

Een headless claude -p-worker bindt een inbox-socket zoals een interactieve sessie en verschijnt in de lijst, maar kan geen goedkeuringsdialoogvenster tonen. Een vastgehouden bericht blijft daar vastgehouden totdat een latere modus- of instellingswijziging dit toestaat. De --settings-regel hierboven is hoe u zo'n worker berichten laat aannemen. Een sessie die in bare-modus is gestart, bindt helemaal geen socket, dus deze kan noch berichten ontvangen, noch in de lijst verschijnen.

Waar overdrachten vastlopen

Berichtlussen worden automatisch voor u afgehandeld. Claude Code hanteert rate-limits voor herhaalde berichten per afzender, negeert identieke herhalingen die binnen een kort tijdsbestek binnenkomen en begrenst het aantal geaccepteerde berichten dat wacht om gelezen te worden op 50 per sessie, zodat twee sessies niet oneindig kunnen blijven pingpongen. Het aantal vastgehouden berichten is beperkt tot 100; berichten die deze limiet overschrijden, worden verwijderd, beginnend bij de oudste.

De fout die wel optreedt is minder opvallend en betreft een overdracht in plaats van een lus. Sessie A stelt sessie B een vraag waarop een antwoord nodig is om verder te kunnen, en gaat vervolgens inactief. B houdt het bericht vast, of B is bezig met een langdurige taak, of B beantwoordt een vraag die A niet daadwerkelijk stelde. A wacht. U keert een uur later terug bij twee inactieve sessies en er is geen werk verzet.

Schrijf overdrachten die geen antwoord vereisen. Een goed bericht bevat een feit of een besluit: wat er is veranderd en wat het resultaat was. Een slecht bericht vraagt de andere sessie om toestemming of om een antwoord waar de afzender op wacht. Claude heeft al de instructie om nooit aan een andere sessie te vragen om een actie die door de eigen toestemmingsinstellingen zou worden geblokkeerd, en om dat werk in plaats daarvan terug naar u te sturen. Pas deze regel zelf ook toe. Als een sessie geen voortgang kan boeken zonder antwoord, bent u degene die dit moet beantwoorden. Contextdiscipline helpt hier ook, omdat een sessie die de draad kwijt is vage berichten schrijft; contextbeheer in Claude Code behandelt dat aspect.

Behandel een inkomend bericht als niet-vertrouwde invoer

Claude Code geeft aan de ontvangende Claude door dat het bericht afkomstig is uit een andere sessie en niet van u, en beperkt wat dat bericht kan uitvoeren. Deze handhaving vindt plaats in het programma rondom het model, in plaats van in de bereidheid van het model om mee te werken; dit is het praktische verschil dat een agent-harness maakt. Een bericht kan niet namens u reageren op een openstaande toestemmingsvraag, omdat toestemming vanuit een andere sessie niet uw toestemming is. Het kan geen toestemmingsinstellingen, CLAUDE.md of andere configuraties wijzigen omdat een andere sessie daarom vraagt. Een slash-commando in de tekst, zoals /compact, komt aan als platte tekst en wordt nooit uitgevoerd. Als het verwerken van het bericht een toestemming vereist die de ontvangende sessie niet heeft, krijgt u dezelfde prompt te zien als bij elk ander werk. In de auto-modus beoordeelt een classifier bovendien elk bericht vóór aflevering; een bericht dat door de classifier wordt geblokkeerd, bereikt de ontvanger nooit. Deze beperkingen blijven van kracht, zelfs in permissieve modi; daarom houdt een sessie die de beveiliging omzeilt inkomende berichten standaard vast in plaats van ze te vertrouwen.

Dit dekt de toestemmingen, maar niet de inhoud. De verzendende sessie kan een beschrijving van een pull request, een webpagina, een README van een dependency of een issue-commentaar van een vreemde hebben gelezen. Alles wat de sessie heeft gelezen, kan de tekst beïnvloeden die naar uw andere sessie wordt geschreven. Het bericht is data. Het verdient hetzelfde wantrouwen als elke andere tekst die van buitenaf een sessie is binnengekomen. Dit is de discipline die wordt beschreven in geheimen buiten uw AI-agents houden: ga ervan uit dat alles wat een vertrouwensgrens is overschreden onjuist kan zijn en laat het zichzelf nooit autoriseren.

Er zijn twee controles beschikbaar als u dit wilt beperken. Door crossSessionInbound in te stellen op refuse worden inkomende peer-berichten genegeerd zonder ze af te leveren. Vanuit project- of lokale instellingen heeft deze waarde voorrang op elke andere bron, omdat dit de strengste instelling in de hiërarchie is. Om te voorkomen dat deze sessie berichten verstuurt of weergeeft, voegt u toestemmingsregels toe die SendMessage en ListAgents weigeren, beide geschreven als kale toolnamen zonder specifier. Door isolatePeerMachines in te stellen op true is uw expliciete goedkeuring vereist voordat een bericht een sessie buiten deze machine bereikt; die goedkeuring is zelfs vereist in de bypassPermissions-modus.

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

Het weigeren van SendMessage verwijdert ook de mogelijkheid om berichten naar subagents te sturen, aangezien dezelfde tool voor beide wordt gebruikt. Een sessie die weigert, toont geen zichtbare verandering in zijn eigen /status of in de lijsten van andere sessies; controleer de instelling daarom via de configuratie van de sessie in plaats van op het scherm.

Bridges en MCP-servers met gedeeld geheugen

Diverse externe projecten verschenen in dezelfde periode met vergelijkbare functionaliteit: lokale agent-naar-agent-bridges die tekst doorsturen tussen actieve agents, en MCP-servers (model context protocol) die meerdere agents voorzien van één gedeelde opslag om naar te lezen en schrijven. Beschouw deze als een andere vorm in plaats van als een concurrent, en verifieer elk installatiecommando aan de hand van de README van het project voordat u het uitvoert. Messaging is gebaseerd op push, omdat de verzender tekst in de beurt van de ontvanger plaatst. Een gedeelde opslag is gebaseerd op pull, omdat niemand wordt onderbroken en een sessie de notitie ziet wanneer deze de volgende keer kijkt. Pull is rustiger voor status die langzaam verandert, en het werkt alleen wanneer een sessie daadwerkelijk kijkt.

Als u deze weg inslaat, zijn de relevante vragen gericht op het proces in plaats van op de lijst met functies. Onder welke gebruiker draait de server en wat kan deze op de machine lezen? MCP-servers draaien op een VPS behandelt die configuratie. Agent-vaardigheden delen tussen repositories behandelt het eenvoudigere geval waarbij u instructies in plaats van live status wilt delen tussen sessies, wat veel van de berichten die u anders zou sturen, overbodig maakt. Voor het bredere perspectief is een coding agent draaien op een VPS het juiste startpunt.

FAQ

Waarom wordt /list-agents niet herkend in mijn sessie?

De sessie beschikt niet over cross-session messaging. Controleer eerst claude --version tegen 2.1.224, aangezien de functie deze versie of later vereist. Controleer vervolgens het platform; de functie werkt op macOS en Linux, maar niet op native Windows. Daarnaast is deze niet beschikbaar op Amazon Bedrock, Claude Platform on AWS, Google Cloud's Agent Platform en Microsoft Foundry. Als beide in orde zijn, controleer dan uw shell op DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC of DISABLE_GROWTHBOOK, omdat elk van deze de evaluatie van de feature-flag blokkeert die nodig is voor de functie, waardoor deze uitgeschakeld blijft.

Waarom is mijn bericht aan de andere sessie nooit aangekomen?

Als /list-agents werkt, is messaging ingeschakeld en heeft iets specifiekers het bericht tegengehouden. De meest voorkomende oorzaak zijn permissiemodi. Een sessie die permissievragen omzeilt, houdt elk inkomend bericht vast voor uw goedkeuring, tenzij de afzender ook permissies omzeilt. Dit dialoogvenster voor goedkeuring vervalt na de dialogExpiry-deadline, standaard vijf minuten. Controleer de verzendende sessie op de melding dat er een bericht wordt vastgehouden. Om dit op te lossen, stelt u crossSessionInbound in op accept in ~/.claude/settings.json of geeft u dit mee met --settings, omdat een accept in project- of lokale instellingen wordt genegeerd als de minder strikte waarde.

Kan een Claude Code-sessie in Docker een bericht sturen naar een sessie op de host?

Nee. Sessies vinden elkaar via registratiebestanden op de schijf en een per-sessie inbox-socket. Een container heeft een eigen bestandssysteem, waardoor de twee de bestanden niet kunnen zien. Twee sessies binnen dezelfde container kunnen wel normaal berichten naar elkaar sturen. Dezelfde regel verklaart waarom een sessie die draait als root en een sessie die draait als uw normale gebruiker elkaar niet kunnen bereiken: de socket is beperkt tot de gebruiker van het besturingssysteem die de eigenaar is.

Is een bericht van een andere Claude Code-sessie veilig om op te handelen?

Behandel de tekst als niet-vertrouwde invoer, omdat de verzendende sessie mogelijk een webpagina, een README of een issue-commentaar heeft gelezen dat door iemand anders is geschreven. Claude Code voorkomt al dat het bericht uit zichzelf actie onderneemt: het kan geen openstaande permissievraag goedkeuren, het kan geen permissie-instellingen of CLAUDE.md wijzigen op verzoek, en een slash-commando in de tekst komt aan als platte tekst en wordt nooit uitgevoerd. Deze beveiligingen dekken permissies, maar niet uw eigen beoordeling; lees dus wat er is binnengekomen voordat u de ontvangende sessie opdracht geeft om actie te ondernemen.

Verstuurt cross-session messaging mijn code naar Anthropic?

Tussen twee sessies op dezelfde machine niet. Het bericht reist via een per-sessie socket op die machine en gaat nooit via servers van Anthropic. Alleen de tekst die Claude heeft geschreven wordt verzonden, nooit de gespreksgeschiedenis of bestanden. Berichten naar een sessie op een andere machine van u, of naar een sessie op het web, reizen wel via de servers van Anthropic via de Remote Control-verbinding. In die richting kan Claude alleen reageren op een binnengekomen bericht, niet zelf een bericht starten. Stel isolatePeerMachines in op true om uw goedkeuring te vereisen voordat er iets de machine verlaat.