Sechs Releases gegen verlorene Gespräche
z.19 bis z.24: OAuth-Logouts, verschwundene Antworten, Gespräche weg nach dem Abbrechen, hängende „Waiting“-Punkte. Und viele Sessions bremsen nicht mehr.
Vor 1.0 hieß Splitkick JeanZ und war ein Fork von Jean. Hier geht es um JeanZ z.19 bis z.24.
Nach einer Reihe neuer Funktionen hatten diese sechs Releases ein gemeinsames Thema: nichts verlieren. Keinen Login, keine Antwort, keinen Gesprächskontext.
Was kaputt war und was jetzt anders ist
- z.19 – Abmeldungen. Die App hat Claudes OAuth-Token selbst erneuert und dabei laufende Sessions abgemeldet („OAuth session expired“). Jetzt liest sie den Token nur noch. Außerdem gehen Antworten auf Rückfragen der Agenten nicht mehr verloren, und ein Fork öffnet die neue Session.
- z.20 – Pläne und Worktrees. Hast du einen Plan an einen neuen Worktree geschickt, blieb er manchmal hängen, startete vom falschen Basis-Branch, oder der Worktree war plötzlich weg. Jetzt zeigt der Chat, wohin ein Plan gegangen ist. Auch der hängende „Waiting“-Punkt bekam seinen ersten Fix.
- z.21 – der Punkt, diesmal richtig. Die Workspace-Zeile hat ihren Status bisher selbst berechnet. Jetzt übernimmt sie ihn aus den Session-Zeilen.
- z.22 und z.23 – Abbrechen, ohne das Gespräch zu verlieren. Hast du abgebrochen, bevor Claude etwas geschrieben hatte, fing der nächste Turn wieder bei null an. z.22 behob das Symptom, z.23 die Ursache: Die App legt die Claude-Session-ID jetzt selbst fest und speichert sie, bevor Claude startet.
- z.24 – Tempo. Wechselst du die Session, aktualisiert die App nur noch den betroffenen Worktree. Session-Listen liegen im Cache und werden erst neu eingelesen, wenn sich die Datei ändert. Und die Git-Status-Prüfung schreibt die Projektdatei nicht mehr neu. Dazu kommt Pinch-Zoom im Bildbetrachter.
Das Muster
Der erste Fix ist nicht immer der richtige. z.22 sorgte dafür, dass ein Abbruch die Resume-ID nicht mehr verwirft. Ein neues Gespräch bekam seine ID aber erst, wenn Claude antwortete – hast du vorher abgebrochen, war der Kontext trotzdem weg. z.23 machte die Regel deshalb strukturell: Die Session-ID wird festgelegt und gespeichert, bevor der Agent startet, und kein späterer Schritt kann sie mehr verlieren. Seitdem gilt im Repository: Ein Fehler im Session-Zustand gilt erst als behoben, wenn die echten Session-Daten geprüft sind – die gespeicherten Run-Metadaten und die Argumente des laufenden Prozesses, nicht nur ein Unit-Test.