Claude Code: Sessions tauschen sich seit v2.1.224 untereinander aus
Mit dem Feature cross-session messaging können Claude Code Sessions seit August direkt miteinander kommunizieren. Über ListAgents findet eine Session andere Sessions und sendet ihnen per SendMessage Textnachrichten.
Veröffentlicht am 16. Okt. • Zuerst erschienen auf reado.watermelon-studio.it
Seit August können Claude-Code-Sessions miteinander kommunizieren. Das Feature heißt cross-session messaging und kam mit v2.1.224: Eine Session findet Ihre anderen Sessions mit ListAgents und sendet einer davon mit SendMessage eine Nachricht. Übertragen wird nur der Text, den Claude für die andere Session schreibt, niemals der Konversationsverlauf oder Dateien.
Ich habe damit rind-ui gebaut, eine Headless-UI-Komponentenbibliothek, mit zwei Sessions, die unterschiedliche Aufgaben haben. Eine ist der PM, die andere ist der Engineer. So ist das gelaufen, einschließlich der Teile, die beim ersten Versuch nicht funktionierten.
Die CLAUDE.md des Repositorys sagt es unmissverständlich: Zwei Sessions arbeiten an diesem Repo, eine schreibt Specs und reviewt, die andere implementiert.
Die PM-Session schreibt jede Komponente als Spec (einen OpenSpec Change: die Anforderungen, die Szenarien, die Aufgaben) und validiert sie, bevor es überhaupt Code gibt. Wenn der Engineer fertig ist, reviewt der PM das Ergebnis.
Die Engineer-Session nimmt eine Spec, implementiert sie und schickt, wenn sie sich für fertig hält, eine Nachricht zurück mit der Bitte um Review. Diese Übergabe listet jede Datei auf, die sie berührt hat, damit das Review genau weiß, worauf es schauen muss.
Keine der beiden Sessions kennt den Kontext der anderen. Jede sieht das Repository und die Nachrichten, die sie erhält. Ich denke, das hilft: Der Reviewer teilt nicht die Annahmen des Implementierers und liest den Code dadurch eher so, wie es die nächste Person tun würde.
Die erste Version erlaubte bis zu drei Review-Runden pro Change. Inzwischen sind es zwei, mit strengeren Regeln. Ich sehe das als das Slot-Machine-Problem im Kleinen: Einem Reviewer, der Probleme finden soll, findet immer noch eines mehr, also muss der Loop gesagt bekommen, wo er aufhört. Heute lauten die Regeln:
Dann wird der Change genehmigt, archiviert und gemergt. Die Severity-Zeile und das Limit der Durchläufe haben aus einem endlosen Loop einen Loop gemacht, der endet.
Das ist der Teil, der mir am besten gefällt, und der Grund, warum ich das hier auf dem Blog von Reado schreibe, der IDE zum Lesen des Codes, den Ihr KI-Agent schreibt.
Die PM-Session schreibt ihre Feststellungen nicht in eine Chat-Nachricht. Sie hinterlässt sie als Reado-Kommentare, verankert an genau den Zeilen, um die es geht, jeweils typisiert (bug, refactor, performance…) und als Task markiert. Es sind Markdown-Dateien im Ordner.reado/ innerhalb des Repositorys, sodass beide Sessions dieselbe Liste lesen, und ich auch.
Der Engineer behebt jeden davon, und der Task wird mit einem Befehl geschlossen, der die Behebung beweist: task done mit einem --verify-Testbefehl. Normalerweise führt der Engineer ihn aus; während der Verifikation führt ihn der PM manchmal selbst aus. Reado zeichnet den Task nur als erledigt auf, wenn dieser Befehl erfolgreich ist; eine Behebung ohne bestandenen Check bleibt sichtbar als unverifiziert, bis sich jemand sie ansieht.
Bislang hat der PM 128 dieser Tasks hinterlassen: 115 Bugs, 5 Refactors, 3 Performance-Probleme und 5 Notizen. Alle 128 sind geschlossen, und jeder einzelne wurde durch einen erfolgreichen verify-Befehl geschlossen.
Das hat einen Nebeneffekt, den ich nicht geplant hatte. Wenn ich den Code in Reado öffne, muss ich nicht rekonstruieren, worüber sich die beiden Sessions gestritten haben. Jeder Fund liegt an der Zeile, um die es geht, mit der Beschreibung, was falsch war, und dem Test, der die Behebung bewiesen hat. Das macht es für die Session, die den Bug beheben muss, einfacher, und für mich ist es einfacher zu sehen, was passiert, wo, und wie es gelöst wird.
Meistens habe ich ihnen bei der Arbeit zugesehen. Die beiden Sessions geben die Arbeit von selbst hin und her: Spec, Implementierung, Review, Behebungen, Verifikation.
Meine Aufgabe ist die, über die ich in meinem letzten Beitrag geschrieben habe: zu entscheiden, was es wert ist, behalten zu werden. Jede Spec endet in einem einzigen Change, und ich reviewe diesen Change, bevor er landet. Nicht um jede Zeile Korrektur zu lesen (die Sessions haben den Diff bereits zweimal geprüft), sondern um zu beurteilen, ob es das ist, was ich wollte, und um die Kommentare zu lesen, die erklären, warum der Code so aussieht, wie er aussieht.
Der Teil, den ich nicht erwartet habe, ist, wie gut sich die PM-Rolle lateral skalieren lässt. Der PM muss nicht bei einem Projekt bleiben: Er kann drei Specs für eines schreiben, zum nächsten Projekt wechseln und dort drei weitere schreiben, dann wieder wechseln. Die Engineer-Sessions haben immer eine Spec liegen, und mehrere Projekte kommen gleichzeitig voran. Die Token-Rechnung steigt entsprechend, aber für die Menge an Arbeit, die erledigt wird, ist das ein Kostenfaktor, den ich für vertretbar halte.
Am besten funktioniert es, wenn das Projekt klare Grenzen hat. rind-ui ist ein gutes Beispiel: eine vollständige Headless-Komponentenbibliothek, plus eine Bibliothek, die das Testen von darauf aufbauenden Komponenten erleichtert. Der Umfang ist definiert, der Agent weiß, was zu tun ist, und es bleiben nicht viele Entscheidungen offen. Wenn doch eine offen bleibt, rät der PM nicht, sondern fragt mich.
Eine Warnung, bevor Sie das nachbauen. Zwei Sessions, die sich gegenseitig reviewen, liefern gute Ergebnisse, aber sie sind teuer: Jede Spec wird geschrieben, implementiert, gerewiewt, behoben und verifiziert, und jeder Schritt liest eine Menge Code. Ich bin dabei schon mehr als einmal ausgerechnet.
Was ich von Anfang an anders machen würde: beiden Sessions, dem PM und dem Engineer, sagen, für die weniger komplexen Teile ein leichteres Modell wie Sonnet zu verwenden und das stärkste Modell für die Schritte aufzusparen, die Urteilsvermögen erfordern, etwa das Schreiben der Spec und des Reviews selbst.
Unterwegs wurden aus den zwei Sessions drei: Eine dritte kam dazu und baute die Dokumentationswebsite. Das Ergebnis können Sie unter rind.watermelon-studio.it sehen, mit Live-Beispielen für jede Komponente, vorerst React.
Die Bibliothek ist bereits auf npm, und sie verändert sich jeden Tag: Neue Komponenten kommen an, wenn ihre Specs den Loop durchlaufen, und viele weitere sind bereits spezifiziert. Wenn es so weitergeht wie bisher, schreibe ich das Follow-up, wenn es mehr zu zeigen gibt.
Wenn Sie die Review-Seite davon selbst ausprobieren möchten, ist die Reado-App kostenlos und MIT-lizenziert: Sie können sie hier herunterladen.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 16 • Originally published at reado.watermelon-studio.it
Since August, Claude Code sessions can talk to each other. The feature is called cross-session messaging and arrived in v2.1.224: a session finds your other sessions with ListAgents and sends one of them a message with SendMessage. What travels is only the text Claude writes for the other session, never the conversation history or files.
I've been using it to build rind-ui, a headless UI component library, with two sessions that have different jobs. One is the PM. The other is the engineer. This is how that went, including the parts that didn't work the first time.
The repository's CLAUDE.md says it plainly: two sessions work on this repo, one writes specs and reviews, one implements.
The PM session writes each component as a spec (an OpenSpec change: the requirements, the scenarios, the tasks) and validates it before any code exists. When the engineer is done, the PM reviews the result.
The engineer session takes one spec, implements it, and when it thinks it's finished, sends a message back asking for review. That hand-off lists every file it touched, so the review knows exactly what to look at.
Neither session has the other's context. Each sees the repository and the messages it receives. I think that helps: the reviewer doesn't share the implementer's assumptions, so it reads the code more like the next person would.
The first version allowed up to three review rounds per change. It's now down to two, with stricter rules. I see it as the slot machine problem in miniature: a reviewer asked to find problems will always find one more, so the loop has to be told where to stop. Today the rules are:
Then the change is approved, archived, and merged. The severity line and the cap on passes are what turned an open-ended loop into one that ends.
This is the part I like most, and the reason I'm writing this on the blog of Reado, the IDE for reading the code your AI agent writes.
The PM session doesn't write its findings into a chat message. It leaves them as Reado comments, anchored to the exact lines they're about, each one typed (bug, refactor, performance…) and marked as a task. They're Markdown files in.reado/ inside the repository, so both sessions read the same list, and so do I.
The engineer fixes each one, and the task is closed with a command that proves the fix: task done with a --verify test command. Usually the engineer runs it; during verification the PM sometimes runs it itself. Reado records the task as done only if that command passes; a fix without a passing check stays visible as unverified until someone looks at it.
So far the PM has left 128 of these tasks: 115 bugs, 5 refactors, 3 performance issues and 5 notes. All 128 are closed, and every one of them was closed by a verify command that passed.
That has a side effect I didn't plan for. When I open the code in Reado, I don't need to reconstruct what the two sessions were arguing about. Each finding sits on the line it's about, with what was wrong, and the test that proved it fixed. It's easier for the session that has to fix the bug, and it's easier for me to see what's happening, where, and how it's being resolved.
Mostly, I watched them work. The two sessions pass the work back and forth on their own: spec, implementation, review, fixes, verification.
My job is the one I wrote about in my last post: deciding what's worth keeping. Each spec ends in a single change, and I review that change before it lands. Not to proofread every line (the sessions already did two passes on the diff), but to judge whether it's what I wanted, and to read the comments that explain why the code looks the way it does.
The part I didn't expect is how well the PM role scales sideways. The PM doesn't have to stay on one project: it can write three specs for one, move to the next project and write three more there, then switch again. The engineer sessions always have a spec waiting, and several projects move forward at once. The token bill goes up with it, but for the amount of work that gets done, it's a cost I find reasonable.
It works best when the project has clear edges. rind-ui is a good example: a complete headless component library, plus a library that makes it easier to test components built on top of it. The scope is defined, the agent knows what to do, and not many decisions are left open. When one is, the PM doesn't guess: it asks me.
One warning before you copy this. Two sessions reviewing each other's work produce good results, but they're expensive: every spec gets written, implemented, reviewed, fixed and verified, and each step reads a lot of code. I've run out of tokens more than once doing this.
What I'd do differently from the start: tell both sessions, the PM and the engineer, to use a lighter model such as Sonnet for the less complex parts, and keep the strongest model for the steps that need judgment, like writing the spec and the review itself.
Along the way the two sessions became three: a third one joined and built the documentation site. You can see the result at rind.watermelon-studio.it, with live examples for every component, React for now.
The library is already on npm, and it changes every day: new components land as their specs go through the loop, and many more are already specced. If it keeps working the way it has, I'll write the follow-up when there's more to show.
If you want to try the review side of this yourself, the Reado app is free and MIT-licensed: download it here.