Jenseits von SSH: Warum WebSocket Terminal-Protokolle bei KI-Coding-Agents schlägt

Wenn Entwickler zum ersten Mal von der Steuerung von Claude Code vom Handy hören, ist die natürliche Reaktion: „Warum nicht einfach per SSH auf meinen Mac verbinden?"

Eine berechtigte Frage. SSH ist bewährt, sicher, allgegenwärtig. Jeder Entwickler kennt es. Es gibt exzellente mobile SSH-Clients wie Termius, Blink Shell und Prompt. Warum etwas anderes bauen?

Die Antwort ist nicht, dass SSH schlecht ist. Sondern dass KI-Coding-Agents grundlegend andere Interaktionsmuster haben als interaktive Shell-Sessions – und diese Unterschiede sich zu einer schlechteren Erfahrung summieren, wenn man SSH dafür zweckentfremdet.

Das Interaktionsmodell-Mismatch

SSH wurde 1995 für ein spezifisches Modell entwickelt: Ein Mensch sitzt am Terminal, tippt Befehle, liest Output, tippt weitere Befehle. Die Session ist interaktiv und synchron – du bist die ganze Zeit aktiv dabei.

KI-Coding-Agents kehren dieses Modell um:

Die letzten beiden Zeilen sind das Problem. Wenn Claude Code eine Aufgabe beendet oder deine Freigabe für eine riskante Operation braucht, hat SSH keine Möglichkeit, dir das mitzuteilen. Du musst zuschauen.

Problem 1: Keine Push-Benachrichtigungen

Das ist die größte Lücke. Der wertvollste Workflow mit einem KI-Coding-Agent ist:

1. Aufgabe senden: „Refactore das Payment-Modul für die neue API"
2. Handy weglegen
3. Benachrichtigt werden, wenn Claude fertig ist oder Input braucht
4. Prüfen und weitermachen

SSH kann Schritt 3 nicht. Das SSH-Protokoll hat keinen Mechanismus für Push-Benachrichtigungen an Mobilgeräte. Die TCP-Verbindung existiert nur, solange dein SSH-Client im Vordergrund ist (oder mit Mosh, solange die UDP-Session aktiv ist). Auch dann gibt es keine Brücke zwischen „Daten erschienen im Terminal" und „sende eine Push-Benachrichtigung an dieses Gerät".

Man kann das mit Shell-Skripten über externe Dienste umgehen, aber das ist fragile Infrastruktur, die du selbst bauen und pflegen musst.

WebSocket-Ansatz: Der Server überwacht Claude Codes Output und Hook-Events. Wenn er einen Abschluss oder eine Freigabe-Anfrage erkennt, pusht er ein strukturiertes Event an verbundene Clients. Die iOS-App wandelt diese in native Push-Benachrichtigungen um. Kein Polling, keine externen Dienste.

Problem 2: iOS-Hintergrundverhalten

iOS suspendiert Apps aggressiv, die nicht im Vordergrund sind. Ein SSH-Client im Hintergrund bekommt etwa 30 Sekunden, bevor iOS die Netzwerkverbindungen kappt. Danach:

• SSH: Verbindung bricht ab. Beim Wiedereröffnen bekommst du einen „broken pipe"-Fehler. Du verbindest dich neu, aber du hast die Scroll-Position und jeglichen Output, der während deiner Abwesenheit stattfand, verloren.
• Mosh: Besser – nutzt UDP und kann fortgesetzt werden. Aber du verpasst trotzdem alles, was während der Suspension passiert ist. Und Mosh löst das Benachrichtigungsproblem nicht.

Das ist eine fundamentale iOS-Einschränkung, kein Bug in SSH-Clients. Apple erlaubt aus Akkugründen keine beliebigen Hintergrund-Netzwerkverbindungen.

WebSocket-Ansatz: Der Server puffert Terminal-Output unabhängig vom Client-Verbindungsstatus. Wenn die iOS-App in den Vordergrund zurückkehrt, verbindet sie sich automatisch und führt eine mehrstufige Zustandswiederherstellung durch – Refresh bei 0.2s, 0.7s und 1.5s nach Wiederverbindung, um den vollständigen aktuellen Zustand zu erfassen. Kritische Events (Task-Abschluss, Fehler) werden als Push-Benachrichtigungen geliefert, auch wenn die App suspendiert ist.

Problem 3: Session-Zustandsverwaltung

KI-Coding-Agents führen oft mehrere parallele Aufgaben aus. Du könntest haben:

• Session A: Auth-Modul refactoren
• Session B: Tests für die API-Schicht schreiben
• Session C: einen Produktions-Bug fixen

Mit SSH bedeutet das:

1. SSH auf deinen Mac
2. Manuell die richtige tmux-Session attachen: tmux attach -t session-a
3. Status prüfen, detachen: Ctrl+B, D
4. Nächste Session attachen: tmux attach -t session-b
5. Wiederholen

Das funktioniert, ist aber manuell und fehleranfällig auf einer Handy-Tastatur.

WebSocket-Ansatz: Der Server bietet Session-Management als strukturierte Befehle an. Die iOS-App zeigt eine Liste aktiver Sessions mit ihrem aktuellen Status. Tippen zum Wechseln. Neue Sessions mit einem Pfad-Picker erstellen, der das Dateisystem deines Macs durchsucht. Sessions per Wischgeste löschen. Der Server übernimmt die gesamte tmux-Orchestrierung.

Problem 4: Agent-Event-Semantik

SSH transportiert rohe Bytes. Es versteht nicht, was im Terminal passiert. Es kennt den Unterschied nicht zwischen Claude beim Denken, Claude beim Code-Schreiben, Claude beim Warten auf Freigabe oder Claude beim Task-Abschluss.

Claude Code hat ein Hook-System, das Shell-Skripte bei spezifischen Events auslöst: Task-Start, Task-Abschluss, Benachrichtigungs-Events. Über diese Hooks erfährt der Server von Agent-Zustandsänderungen.

SSH-Limitation: Es gibt keinen sauberen Weg, diese Hook-Events durch eine SSH-Session zu leiten. Du bräuchtest einen separaten Kanal (eine weitere SSH-Verbindung, einen Webhook-Service, irgendetwas) neben deiner Terminal-Session.

WebSocket-Ansatz: Der Server empfängt Hook-Events via HTTP POST von Claude Codes Hook-Skripten. Er parst sie, dedupliziert sie (mit einem 3-Sekunden-Fenster zur Vermeidung doppelter Alerts) und pusht sie an die iOS-App über die gleiche WebSocket-Verbindung, die auch Terminal-Daten trägt. Eine Verbindung, mehrere Datentypen.

Problem 5: Authentifizierung und Zugriffskontrolle

SSH-Authentifizierung ist mächtig, aber komplex für mobile Anwendungsfälle:

• Key-Management auf iOS ist umständlich
• Du musst sshd auf deinem Mac konfigurieren
• Port-Forwarding durch NAT erfordert zusätzliche Einrichtung
• SSH dem Internet auszusetzen erfordert sorgfältige Sicherheitskonfiguration

WebSocket-Ansatz: Tactic Remote nutzt API-Key-Authentifizierung über WebSocket. Für LAN-Verbindungen ist der API-Key optional (dein Heimnetzwerk ist die Vertrauensgrenze). Für Cloudflare Tunnel-Verbindungen ist der API-Key erforderlich. Die Mac-App generiert einen 32-Zeichen-Zufallsschlüssel und überträgt ihn per QR-Code – kein Key-File-Management, keine sshd-Konfiguration.

Das ist ein bewusst einfacheres Sicherheitsmodell. Es tauscht SSHs Flexibilität gegen einfache Einrichtung. Wenn du die Sicherheitsgarantien von SSH Public-Key-Authentifizierung brauchst, ist SSH das richtige Tool – aber wahrscheinlich für einen anderen Anwendungsfall.

Wann SSH besser ist

SSH gewinnt, wenn:

• Du viele Server verwaltest – SSH ist das Standardprotokoll für Server-Zugriff. Ein Client, viele Hosts.
• Du Dateiübertragung brauchst – SFTP/SCP sind in SSH eingebaut. Tactic Remote macht keine Dateiübertragung.
• Du Nicht-Claude-Tools nutzt – SSH ist agent-agnostisch. Es funktioniert mit jeder Terminal-Anwendung.
• Du Port-Forwarding brauchst – SSH-Tunnel sind kampferprobt für Service-Proxying.
• Deine Compliance-Anforderungen SSH vorschreiben – manche Organisationen verlangen SSH für Audit und Zugriffskontrolle.

Die Architektur in der Praxis

So sieht die WebSocket-Architektur für Tactic Remote aus:

iPhone App                    Mac Server                    Claude Code
    │                             │                              │
    │  WebSocket (ws:// or wss://)│                              │
    │◄───────────────────────────►│  tmux send-keys              │
    │  • Terminal I/O             │─────────────────────────────►│
    │  • Session commands         │  tmux capture-pane           │
    │  • Event stream             │◄─────────────────────────────│
    │                             │                              │
    │  Push notification          │  HTTP POST /hook             │
    │◄────────────────────────────│◄─────────────────────────────│
    │  (via WebSocket event)      │  (Claude Code hook scripts)  │
    │                             │                              │

Der Server sitzt zwischen Handy und Claude Code und fügt hinzu:

• Event-Semantik (rohe Terminal-Bytes werden zu strukturierten Events)
• Session-Management (ein Server, viele tmux-Sessions)
• Wiederverbindungs-Resilienz (gepufferter Zustand, automatische Wiederherstellung)
• Benachrichtigungs-Routing (Hook-Events werden zu Push-Benachrichtigungen)

SSH würde dir die rohe Terminal-Verbindung geben (die oberen Pfeile), aber nichts von der Intelligenz dazwischen.

Was ist mit Mosh?

Mosh (Mobile Shell) ist der häufigste Vorschlag zur Verbesserung von SSH auf Mobilgeräten. Es nutzt UDP statt TCP, was hilft bei:

• Netzwerk-Roaming (Wechsel zwischen WiFi und Mobilfunk)
• Verbindungspersistenz (der Server behält den Zustand, auch wenn der Client sich trennt)
• Local Echo (sofortiges Tastatur-Feedback unabhängig von der Latenz)

Mosh verbessert die mobile SSH-Erfahrung tatsächlich. Aber es löst die fundamentalen Probleme nicht:

• Keine Push-Benachrichtigungen
• Kein Agent-Event-Bewusstsein
• Kein strukturiertes Session-Management
• Immer noch der iOS-Hintergrund-Suspension unterworfen (auch wenn die Wiederherstellung schneller ist)

Wenn du SSH-basierte Tools bevorzugst, ist Blink Shell mit Mosh die beste iOS-Option. Es ist ein gutes Tool für ein anderes Problem.

Fazit

Die Frage ist nicht „SSH oder WebSocket?" als abstrakter Protokollvergleich. Sondern „Welches Interaktionsmodell braucht dein Workflow?"

Wenn du Server verwaltest und interaktive Befehle ausführst, ist SSH das richtige Protokoll mit jahrzehntelanger bewährter Zuverlässigkeit.

Wenn du einen KI-Agent steuerst, der autonom läuft, punktuell deine Aufmerksamkeit braucht und von Push-Benachrichtigungen und strukturierter Event-Verarbeitung profitiert, löst eine zweckgebaute WebSocket-Architektur Probleme, die SSH nicht kann – nicht weil SSH fehlerhaft ist, sondern weil es für eine andere Ära der Mensch-Computer-Interaktion entwickelt wurde.