Eine Benachrichtigung sollte nicht nur die App öffnen, sondern dich zur richtigen Session zurückbringen

Wir beschreiben Benachrichtigungen oft als Zustellproblem: Ist der Hinweis angekommen, wie schnell, erscheint er auf dem Sperrbildschirm. Für Remote-AI-Coding ist diese Sicht zu flach.

Wenn eine Benachrichtigung nur die App öffnen kann, schließt sie den Feedback-Loop nicht wirklich. Der Nutzer muss die Szene immer noch selbst rekonstruieren: Welche Maschine war das, welche Session, hat Claude gerade eine Freigabe angefordert oder eine Fertigstellung gemeldet, und gehörte das zur aktuellen Aufgabe oder zu einer anderen Session, die schon länger im Hintergrund lief?

Das ist weder ein Textproblem noch ein Animationsproblem. Es ist ein vollständiges State-Synchronisationsproblem.

Warum das bei AI Coding schlimmer ist

In vielen normalen Apps verweist eine Benachrichtigung sauber auf genau ein Objekt: eine E-Mail, eine Nachricht, einen Kalendereintrag. Nach dem Tippen ist das Ziel offensichtlich.

Remote-AI-Coding funktioniert nicht so.

Es können gleichzeitig drei Sessions laufen:

• eine refaktoriert ein Modul
• eine wartet auf Testergebnisse
• eine andere steht bei einer Freigabeanfrage still

In dieser Situation bedeutet "Claude braucht dich" praktisch nichts. Entscheidend ist:

• welcher Server die Benachrichtigung ausgelöst hat
• welche Session sie ausgelöst hat
• in welchem Zustand diese Session gerade ist
• ob der Nutzer diese Session bereits ansieht

Fehlt einer dieser Punkte, degradiert die Benachrichtigung zu einer vagen Unterbrechung. Sie kann den Fokus brechen, aber nicht helfen, die nächste Entscheidung zu treffen.

Benachrichtigungen scheitern nicht nur dann, wenn sie verloren gehen

Viele Systeme verstehen Benachrichtigungs-Zuverlässigkeit als "Nachrichten nicht verlieren". In Multi-Session-Workflows gibt es einen zweiten Ausfall, der genauso schlimm ist: Die Benachrichtigung kommt an, bringt dich aber in den falschen Kontext zurück.

Dieser Fehler ist subtiler als kompletter Verlust und oft gefährlicher.

Der Nutzer glaubt, er sei am richtigen Ort, und arbeitet dann in der falschen Session weiter. Beim Remote-AI-Coding kann das bedeuten:

• Claude im falschen Repository zu antworten
• die falsche Aufgabe zu genehmigen
• den Zustand einer Session für den Zustand einer anderen zu halten

Auf Interaktionsebene sieht das wie ein normaler Navigationsfehler aus. Auf Produktebene zerstört es das Vertrauen in den gesamten Remote-Workflow.

Damit Benachrichtigungen nützlich sind, muss der Kontext den ganzen Weg überleben

Eine nützliche Benachrichtigung ist nicht nur ein APNs-Payload. Sie muss die komplette Kette durchlaufen, ohne ihre Identität zu verlieren:

1. wenn das Server-Hook-Event erzeugt wird, muss klar sein, welche tmux_session es ausgelöst hat
2. wenn der Server die Benachrichtigung broadcastet, muss session enthalten sein
3. wenn der Push-Relay dedupliziert, darf er nicht nur nach project deduplizieren, sonst unterdrücken sich verschiedene Sessions gegenseitig
4. wenn die App kalt startet, muss sie die Server-Identität aus dem Push wieder auf den lokal gespeicherten Server abbilden
5. wenn die Navigation am Ende erfolgt, muss sie in den richtigen Server zurückkehren und dann die richtige Session auswählen, statt auf einer Standardsicht zu landen

Sobald ein Schritt auf "best guess" zurückfällt, wird das Endverhalten instabil.

Darum wirken die Benachrichtigungs-Änderungen in 1.6.6 über iOS, Mac, Server und Push-Relay verstreut. Tatsächlich beheben sie dasselbe Problem: eine Benachrichtigung von einer generischen Erinnerung in einen ausführbaren Kontexteinstieg zu verwandeln.