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 bezorgt de tekst 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 ondersteuning voor Windows 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.

Een VPS is waar dit relevant is, omdat sessies op een VPS lang genoeg actief blijven om het de moeite waard te maken ze aan te sturen. Op een laptop klapt u het deksel 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, is de manier waarop ze communiceren niet langer theoretisch. Als u dit nog niet heeft ingesteld, begin dan met Claude Code draaien op een VPS onder tmux, waarin de sessie-infrastructuur wordt behandeld die deze handleiding als uitgangspunt neemt.

Wanneer een tweede sessie de tokens waard is

Begin bij de kosten. Elke sessie is een afzonderlijke Claude-instantie 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 terugverdient, vertonen hetzelfde patroon. Twee taken lopen tegelijkertijd zonder op elkaar te wachten, en een van de twee leert halverwege iets wat de andere nodig heeft.

• Eén sessie ontdekt een 'breaking change' terwijl de andere voortbouwt op de code die zojuist is verbroken. Claude vat de wijziging samen en verstuurt deze, in plaats van dat u deze opnieuw moet typen in de andere terminal.
• Twee sessies werken in dezelfde repository in afzonderlijke git worktrees, en een van de sessies 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 bouwsessie en een reviewersessie, 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, een afzonderlijke en nog experimentele functie. Wanneer u alleen hetzelfde gesprek in een andere terminal wilt, hervat dan de sessie. Cross-session messaging 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 diverse privacyvariabelen schakelen die evaluatie uit, waardoor de functie in de standaard uitgeschakelde status blijft. DO_NOT_TRACK, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC en DISABLE_GROWTHBOOK veroorzaken dit allemaal. Gebruikers harden 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 retourneert. Voor DISABLE_TELEMETRY en CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC zorgt elke niet-lege waarde ervoor dat het gedrag wordt ingeschakeld, inclusief de string 0; daarom doet DISABLE_TELEMETRY=0 niet wat het lijkt te doen. U schakelt het uit door de variabele te verwijderen 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-uitvoer 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 betreft een builder-sessie en een reviewer-sessie voor hetzelfde repository. De reviewer werkt in een afzonderlijke git worktree, waardoor beide sessies nooit hetzelfde bestand tegelijkertijd bewerken. git worktree add met HEAD zorgt voor een detached checkout; dit is de gewenste methode voor een sessie die leest in plaats van commits uitvoert.

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 toont de vensters op naam, zodat u er een kunt selecteren. 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 volledig opgestart, of is een van de twee problemen uit de volgende sectie van toepassing. Geef daarna instructies in begrijpelijke 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 tekst van het bericht niet zelf, en de inhoud die 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 bericht heeft gelezen, klapt het bericht in tot een Message from-regel van één regel die Ctrl+O uitvouwt. Het tweetal werkt efficiënter wanneer de builder de wijzigingen klein houdt, omdat een beperkt 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 beoogt af te dwingen.

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 zijn eigen inbox-socket, en Claude Code leest die 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 gebruiker op het besturingssysteem. 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. Voer beide sessies uit als dezelfde gebruiker.

Een container heeft zijn 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 in het uitvoeren van coding agents in een wegwerpbare VM, verwacht dan dat berichtenverkeer werkt binnen een container en niet over de containergrens heen.

Uw sessies op andere machines, en op het web, verschijnen alleen in de lijst terwijl Remote Control is verbonden, 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 het besluit was om het niet af te leveren. Elk inkomend bericht eindigt in een van de drie resultaten: 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 toestemmingsmodi van de twee sessies te vergelijken. Het groepeert sessies die toestemmingsvragen omzeilen in één klasse en alle andere sessies in de andere. auto, acceptEdits en dontAsk tellen als vragen om toestemming. De plan-modus telt als omzeiling in een sessie waarvoor omzeilingsrechten beschikbaar zijn. 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 verzender ook 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 verzender 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 losser 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 door 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 zonder dat er werk is verricht.

Schrijf overdrachten waarvoor geen antwoord nodig is. 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 gekregen 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, waardoor de acties die met dat bericht kunnen worden uitgevoerd worden beperkt. Een bericht kan niet namens u reageren op een openstaande toestemmingsvraag, omdat toestemming vanuit een andere sessie niet gelijkstaat aan uw eigen toestemming. Het kan geen toestemmingsinstellingen, CLAUDE.md of andere configuraties wijzigen op verzoek van een andere sessie. Een slash-commando in de tekst, zoals /compact, komt aan als platte tekst en wordt nooit uitgevoerd. Als voor het verwerken van het bericht een toestemming vereist is waarover de ontvangende sessie niet beschikt, krijgt u dezelfde vraag te zien als bij elk ander proces. In de auto-modus beoordeelt een classifier bovendien elk bericht vóór aflevering; een bericht dat door deze 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 onbekende hebben gelezen, en alles wat is 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 het buitenhouden van geheimen bij uw AI-agents: ga ervan uit dat alles wat een vertrouwensgrens heeft overschreden onjuist kan zijn en sta nooit toe dat het zichzelf autoriseert.

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 prevaleert deze waarde boven 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 weigeringsregels voor toestemming toe waarbij SendMessage en ListAgents worden benoemd, beide geschreven als kale toolnamen zonder specificatie. Door isolatePeerMachines in te stellen op true is uw expliciete goedkeuring vereist voordat een bericht een sessie buiten deze machine bereikt, en die goedkeuring is zelfs in bypassPermissions-modus vereist.

{
  "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 weigerende sessie toont geen zichtbare verandering in zijn eigen /status of in de lijsten van andere sessies; bevestig de instelling daarom vanuit de configuratie van de sessie in plaats van vanaf het scherm.

Bridges en MCP-servers met gedeeld geheugen

In dezelfde periode verschenen diverse externe projecten met een vergelijkbare insteek: lokale agent-naar-agent-bridges die tekst doorsturen tussen actieve agents, en MCP-servers (model context protocol) die meerdere agents voorzien van één gedeelde opslagplaats voor lees- en schrijfacties. Beschouw deze als een andere vorm in plaats van als concurrenten, en verifieer elk installatiecommando in 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 opslagplaats is gebaseerd op pull, omdat niemand wordt onderbroken en een sessie de notitie pas ziet wanneer deze de volgende keer kijkt. Pull is rustiger voor statusinformatie 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 repo's behandelt het eenvoudigere scenario waarbij u instructies in plaats van live status wilt delen tussen sessies, wat een groot aantal berichten bespaart die u anders zou moeten versturen. 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; het werkt op macOS en Linux, maar niet op native Windows. Het is tevens 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 de functie nodig heeft, waardoor deze uitgeschakeld blijft.

Waarom is mijn bericht aan de andere sessie nooit aangekomen?

Als /list-agents werkt, is messaging ingeschakeld en heeft iets anders 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 omzeilt. Dit dialoogvenster voor goedkeuring vervalt na de dialogExpiry-deadline, standaard vijf minuten. Controleer de verzendende sessie op de melding dat het bericht wordt vastgehouden. Om dit op te lossen, stelt u crossSessionInbound in op accept in ~/.claude/settings.json, of geeft u het 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 schijf en een inbox-socket per sessie. Een container heeft een eigen bestandssysteem, waardoor de twee de bestanden niet kunnen zien. Twee sessies binnen dezelfde container kunnen normaal met elkaar communiceren. 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 besturingssysteemgebruiker 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 die 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 oordeel; 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 socket per sessie op die machine en nooit via de 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 gegevens de machine verlaten.