Je Claude Code-sessies kunnen elkaar nu bereiken

Vorig jaar zomer verloor ik een middag aan iets doms. Ik had twee Claude Code-sessies open in dezelfde map, allebei aan een ander artikel. De ene wisselde van branch om een pull request af te maken. De andere merkte daar niets van, deed netjes zijn werk, committe, en pushte. “Everything up-to-date”, zei git. De fix stond op een tak waar niemand hem zocht.

Dat probleem had een saaie oplossing: een eigen worktree per sessie. Die staat sindsdien in mijn projectregels en het is nooit meer gebeurd. Maar de onderliggende situatie bleef: twee sessies die aan hetzelfde project werken en niets van elkaar weten.

Sinds Claude Code 2.1.224 kunnen ze elkaar bereiken.

Wat het is

Twee tools, allebei zonder installatie of instelling: ListAgents laat zien welke van jouw sessies bereikbaar zijn, SendMessage stuurt er tekst naartoe. In de sessie zelf kijk je met /list-agents, ook te bereiken als /peers.

Wat er reist is één ding: tekst die de ene Claude voor de andere schrijft. Geen gespreksgeschiedenis, geen bestanden, geen context. Wil je een gesprek meenemen naar een ander venster, dan hervat je die sessie; daar is dit niet voor.

Je hoeft de tekst niet zelf te formuleren. “Vertel de sessie die aan de API werkt wat we net veranderd hebben” is genoeg, Claude schrijft het bericht.

Aan de ontvangende kant komt het binnen tussen twee tool-aanroepen door, dus een lopend commando wordt nooit halverwege onderbroken. Staat die sessie stil, dan begint hij er een nieuwe beurt mee. Eenmaal afgeleverd telt het bericht mee voor je verbruik, precies als een prompt die je zelf intikt.

Waar dat bericht langsgaat

Dit is het deel dat ik het belangrijkst vind, en het staat niet vooraan in de aankondiging.

Twee sessies op je eigen laptop praten dus lokaal met elkaar. Dezelfde tool-aanroep naar je werkcomputer legt een heel andere route af. Voor een openbaar project maakt dat weinig uit, voor werk met klantmateriaal is het precies de vraag die je vooraf stelt.

Lokaal werkt het doordat elke sessie zichzelf in bestanden op schijf inschrijft en daar zijn inbox-socket bindt. Twee sessies kunnen elkaar alleen vinden als ze diezelfde bestanden zien. Een container heeft een eigen bestandssysteem, dus iets in een container en iets op de host bereiken elkaar niet. Twee sessies binnen dezelfde container weer wel.

Wie mag hier eigenlijk iets

Een binnenkomend bericht is een nieuw kanaal een sessie in, en dat roept meteen de vraag op wie er via dat kanaal iets voor elkaar kan krijgen.

Het antwoord is streng, en dat was het al voordat deze functie er stond. Een bericht dat via een andere sessie binnenkomt draagt niet jouw autoriteit. De ontvanger weigert doorgegeven permissieverzoeken, en in auto mode worden ze geblokkeerd. Sinds 2.1.222 gaat een bericht ook nog langs de permissie-classifier voordat het überhaupt vertrekt.

Daarnaast beslist de ontvangende sessie zelf wat er met een bericht gebeurt: afleveren, vasthouden tot jij het goedkeurt, of weigeren. Zonder eigen instelling kijkt Claude Code naar de modus van beide sessies. Sessies vallen in twee klassen: de klasse die permissies overslaat, en de rest, waar auto mode, acceptEdits en dontAsk allemaal onder vallen.

• Vraagt de ontvangende sessie normaal om toestemming, dan komt het bericht binnen. Alleen als de afzender zegt dat hij permissies overslaat, wordt het eerst aan jou voorgelegd.
• Slaat de ontvangende sessie permissies over, dan wordt elk bericht aan jou voorgelegd. Behalve als de afzender dat ook doet.

Wordt er iets vastgehouden, dan zie je een dialoog met de afzender en een voorbeeld van de tekst. Reageer je vijf minuten niet, dan sluit die dialoog en verdwijnt het bericht. Dat is de standaard van dialogExpiry, en je kunt hem verzetten.

Helemaal uitzetten kan met een deny-regel op de twee tools; dan verdwijnen SendMessage en ListAgents uit de sessie.

De kanttekening

Het lost mijn probleem niet op. Die verdwenen commit van vorig jaar was geen communicatieprobleem maar een bestandssysteemprobleem. Twee processen in één map, één HEAD. Een bericht met “ik ben net van branch gewisseld” komt aan nadat het al fout is gegaan, en dan is de vraag niet meer of je het weet maar of je het terug kunt draaien. De regel van een eigen worktree per sessie blijft dus staan. Nieuwe functies zijn zelden een reden om oude discipline op te ruimen, ook niet als de documentatie het samenwerken tussen worktrees als voorbeeld noemt.

Een sessie krijgt er een ingang bij. Dat is de bedoeling, en het is goed dichtgezet: geen autoriteit, geen doorgegeven permissieverzoeken, een classifier ervoor. Maar het blijft tekst die jouw sessie in gaat zonder dat jij hem hebt getypt, en die daarna meetelt voor je verbruik. Bij twee sessies overzie je dat. Bij zes, waarvan de helft in auto mode, is die goedkeuringsdialoog na twee dagen weer zo’n venster waar je doorheen klikt. Dat patroon kennen we inmiddels.

De twee routes zien er identiek uit. Lokaal blijft het bericht op je machine, naar een andere machine gaat het langs Anthropic. In beide gevallen doet Claude hetzelfde: één aanroep, één bevestiging. Het verschil zit niet in wat je ziet. Als je met iets werkt dat je niet zomaar de deur uit doet, is dat een gewoonte die je bewust moet aanleren, want de interface helpt je er niet aan herinneren.

Wat ik zelf doe: aan laten staan tussen sessies op deze laptop, want daar zit de winst en daar blijft het lokaal. Naar mijn andere machine zet ik het achter goedkeuring. En de worktrees blijven.

Veelgestelde vragen

Moet ik iets installeren of aanzetten?

Nee. Vanaf versie 2.1.224 staat het aan zodra een sessie aan de voorwaarden voldoet. Werkt /list-agents niet, dan heeft die sessie de functie niet.

Let op de val die mij een uur kostte. Ik draaide acht sessies, allemaal op 2.1.222, terwijl claude --version in mijn terminal netjes 2.1.226 meldde. Mijn eerste gedachte was dat een draaiende sessie zijn startversie vasthoudt en dat herstarten dus zou helpen. Dat klopt, maar het was hier niet de oorzaak.

De desktop-app draagt zijn eigen vastgezette Claude Code, los van wat er op je PATH staat:

ls ~/Library/Application\ Support/Claude/claude-code/
# 2.1.222

Eén versie, en dat is de versie die elk venster start. Herstarten levert dus opnieuw 2.1.222 op. Wat er moet gebeuren is de app zelf bijwerken, niet de sessie.

Per sessie kun je het nakijken in het registratiebestand:

grep -h '"version"' ~/.claude/sessions/*.json

Staat daar iets onder 2.1.224, dan weet je waar je moet zijn.

Waar staan die sessies dan?

In ~/.claude/sessions/, één JSON-bestand per sessie, met het procesnummer, de werkmap, de versie, een afgeleide naam en een peerProtocol-nummer. Daar bindt elke sessie ook zijn inbox-socket. Dat is meteen de verklaring waarom twee sessies elkaar alleen vinden als ze diezelfde bestanden zien, en waarom een container erbuiten valt.

Het bestand verschijnt bij het starten en verdwijnt weer als de sessie stopt, dus die map is een betrouwbaar beeld van wat er nu draait en niet van wat er ooit heeft gedraaid. Handig los van deze functie: het is de snelste manier om te zien hoeveel sessies je open hebt staan en in welke mappen. Er is ook een commando voor:

claude agents --json

Waarom ziet ListAgents niemand terwijl mijn sessies wel draaien?

Omdat ingeschreven staan iets anders is dan bereikbaar zijn, en dat kostte me de meeste tijd. claude agents --json toont elke draaiende sessie, ook de sessies die deze functie helemaal niet hebben. ListAgents toont alleen wie er een inbox openheeft staan.

Het verschil is één veld. Een sessie die luistert draagt in zijn registratiebestand een messagingSocketPath, en daar hangt een echte socket aan:

grep -l messagingSocketPath ~/.claude/sessions/*.json
ls /tmp/cc-socks/

Geen messagingSocketPath, geen inbox. Bij mij gold dat voor alle negen sessies op 2.1.222, en dat is de zuiverste test die er is: geen versiegedoe, gewoon kijken of het veld er staat. Een sessie bindt die socket bovendien pas als hij helemaal is opgestart. Ik had er een die bleef hangen in zijn startup-hooks, en die stond wel keurig ingeschreven maar luisterde nergens naar.

Werkt dit op Windows?

Niet op native Windows. Wel op macOS en Linux, en op Linux binnen WSL 2. Ook niet beschikbaar op Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform en Microsoft Foundry.

Kan een andere sessie mijn code aanpassen via een bericht?

Nee. Er reist alleen tekst, en die tekst draagt jouw autoriteit niet. Een doorgegeven permissieverzoek wordt geweigerd, en in auto mode geblokkeerd. Wat de ontvangende Claude ermee doet, valt onder de permissies van díe sessie.

Gaat mijn bericht langs Anthropic?

Tussen twee sessies op dezelfde machine niet; dat loopt over een lokale socket. Naar een andere machine of naar een web-sessie wel, via de Remote Control-verbinding.

Wat als de ontvangende sessie midden in een taak zit?

Dan wordt er niets onderbroken. Het bericht komt tussen twee tool-aanroepen door binnen. Staat de sessie stil, dan start hij er een nieuwe beurt mee.

Bronnen

• Claude Code Docs, Message your other Claude Code sessions
• Claude Code CHANGELOG, versies 2.1.166, 2.1.222, 2.1.224 en 2.1.225

Gecontroleerd op 10 augustus 2026 tegen de documentatie en de changelog. Wat hierboven over de route naar een andere machine staat, komt uit de documentatie en niet uit eigen waarneming: al mijn draaiende sessies stonden op dat moment nog op 2.1.222, dus onder de eis van 2.1.224, en geen ervan kon de andere bereiken. De observatie over het registratiebestand komt wel uit eigen waarneming, want dat is precies hoe ik erachter kwam.