Fix: WS-Chat/Events-Feed brach durch Origin-Header-Mismatch ab (Caddyfile)

Root Cause im echten Hermes-Sourcecode (hermes_cli/web_server.py,
_ws_host_origin_reason) verifiziert, nicht geraten: WebSocket-Upgrades
(/api/ws, /api/pub, /api/events) haben einen zweiten Guard neben dem
Host-Header, der zusaetzlich den Origin-Header gegen den Bind (127.0.0.1)
prueft. Browser schickt die echte Server-Adresse als Origin -> origin_mismatch
-> WS wird mit 4403 (Browser: 1006) geschlossen, komplett ohne Logging
(anders als /api/console + /api/pty). Fix: Origin-Header in Caddy entfernen,
dann ueberspringt Hermes den Check ganz.

Caddyfile

@@ -23,8 +23,25 @@
 	# vom Browser durch (die Server-IP/Domain), das lehnt Hermes mit
 	# "Invalid Host header" ab. Deshalb hier den Host-Header explizit auf
 	# das ueberschreiben, worauf das Dashboard tatsaechlich lauscht.
+	#
+	# GLEICHES Problem existiert fuer WebSocket-Upgrades (Chat/Events-Feed,
+	# /api/ws + /api/pub + /api/events), nur eine Ebene tiefer und OHNE
+	# jede Fehlermeldung: Hermes' WS-Handshake-Guard (hermes_cli/web_server.py,
+	# _ws_host_origin_reason) prueft zusaetzlich zum Host-Header auch den
+	# Origin-Header gegen den Bind (127.0.0.1). Der Origin-Header vom Browser
+	# traegt aber immer die echte aufgerufene Adresse (Deine Server-IP/Domain),
+	# nicht 127.0.0.1 -- das ergibt "origin_mismatch" und Hermes schliesst die
+	# WS-Verbindung sofort mit Code 4403 (Browser zeigt oft 1006). Anders als
+	# beim Host-Header-Fehler auf der normalen HTTP-Seite loggt Hermes diese
+	# Ablehnung fuer /api/ws, /api/pub und /api/events NICHT (nur /api/console
+	# und /api/pty tun das) -- daher blieb der Chat-Fehler in den Logs
+	# unsichtbar, obwohl der Ablauf identisch zum Host-Header-Bug war. Fix:
+	# Origin-Header komplett entfernen, bevor die Anfrage ans Dashboard geht --
+	# fehlt der Origin-Header, ueberspringt Hermes den Origin-Check ganz
+	# (siehe _ws_host_origin_reason: "if not origin: return None").
 	reverse_proxy 127.0.0.1:9119 {
 		header_up Host 127.0.0.1:9119
+		header_up -Origin
 	}
 }
 

README.md

@@ -297,6 +297,41 @@ neu starten (bei s6-Auto-Restart selten noetig):
 docker-compose restart hermes-agent
 ```
 
+**Chat im Dashboard bricht dauerhaft mit "Chat connection interrupted (code
+1006). Reconnecting..." + "events feed disconnected — tool calls may not
+appear" ab, obwohl die Seite selbst (Login, Session-History) normal laedt
+und `docker logs hermes-agent` waehrend des Reconnects RUHIG bleibt (kein
+Guard-Token, kein Fehler, gar nichts):**
+
+Root Cause im echten Hermes-Sourcecode gefunden (`hermes_cli/web_server.py`,
+Funktion `_ws_host_origin_reason`), nicht geraten: der Host-Header-Fix von
+weiter oben loest nur die **HTTP**-Seite. WebSocket-Upgrades
+(`/api/ws`, `/api/pub`, `/api/events` — genau die Endpunkte hinter Chat +
+Events-Feed) haben einen ZWEITEN, unabhaengigen Guard, der zusaetzlich den
+`Origin`-Header prueft. Der Browser schickt als Origin immer die echte
+aufgerufene Adresse (Server-IP/Domain), Hermes ist aber auf `127.0.0.1`
+gebunden und lehnt jeden Origin ab, der nicht `127.0.0.1`/`localhost`/`::1`
+ist -> `origin_mismatch` -> WS wird sofort mit Code 4403 geschlossen
+(Browser zeigt das oft generisch als 1006).
+
+Der Grund warum die Log-Suche vorher ins Leere lief: anders als
+`/api/console` und `/api/pty` loggen `/api/ws`, `/api/pub` und `/api/events`
+diese Ablehnung **nicht** — sie schliessen still. Gleicher Bug-Mechanismus
+wie der Host-Header-Fehler, nur eine Ebene tiefer und ohne jede
+Fehlermeldung.
+
+**Fix (bereits im `Caddyfile`):** Origin-Header komplett entfernen statt ihn
+umzuschreiben — fehlt der Header, ueberspringt Hermes den Origin-Check
+komplett:
+```
+reverse_proxy 127.0.0.1:9119 {
+	header_up Host 127.0.0.1:9119
+	header_up -Origin
+}
+```
+Nach `git pull`: `docker-compose up -d --build caddy` (Config-Reload reicht,
+kein Neubuild von hermes-agent noetig).
+
 ## Verzeichnisse (nicht committet, siehe .gitignore)
 
 - `hermes-agent-src/` — geklonter Hermes-Agent-Sourcecode (Docker-Build-Context)