diff --git a/docs/session-20260828-decisions.md b/docs/session-20260828-decisions.md
index 1241b8b..283e1f4 100644
--- a/docs/session-20260828-decisions.md
+++ b/docs/session-20260828-decisions.md
@@ -94,3 +94,15 @@ Beim ersten Aufruf von `opencode mcp list` kann einzelne Server als `✗ failed`
 ## Schlusswort
 
 Diskussion hat ~1 Stunde gedauert, Ergebnis sind 3 Commits (Handoff + TP35 + dieser Anker), 12 valide Backups, 1 synology-Sync als zusätzliche Sicherung. Ausführung der TP35-Schichten erfolgt in separaten Sessions, pro Projekt einer.
+
+## Auth-Sanierung (Bearer) — Vorab-Notiz für „Cloudflare Tunnels"-Punkt
+
+**Anwender-Direktive 2026-08-28**: es kommt ein eigener Punkt zu Cloudflare Tunnels. Ziel: **alle Tools laufen über Caddy oder CF + Caddy (extern)**. Im selben Zug soll die **Bearer-Authentifizierung einmal sauber gelöst** werden — vermutlich in Form eines zentralen Auth-Proxys / Identity-Provider auf Caddy-Ebene, statt Bearer-Tokens verteilt in `~/.secrets/exports.zsh`.
+
+**Was das für n8n-mcp konkret heißt**: das Accept-Header-Strike-Problem (siehe oben) wird **mit** dem Tunnel-Punkt gelöst, **nicht** heute. Bis dahin: Sidebar-Status ist Wahrheit, `mcp list` zeigt `failed` zu unrecht.
+
+**Was das für TP35 bedeutet**: TP35 Schicht 2 (Credentials-Schichtung) wird durch den Tunnel-Punkt **nicht obsolet**, aber die Endform ist anders — statt `{env:...}` pro MCP-Config kommt ein Caddy-Forward mit zentraler Auth. Schicht 2 wird also **erst** sinnvoll, wenn der Tunnel-Punkt steht.
+
+**TP-Vorschlag (für später, nicht jetzt anlegen)**: ein TP „Cloudflare-Tunnel + Caddy als Tool-Auth-Gateway", Scope: alle MCP-Backends hinter CF-Tunnel, Auth per CF Access oder Caddy-Forward, Bearer-Tokens nur noch intern zwischen Caddy und Backend.
+
+**Nicht-Inhalt** für diese Session: keine Bearer-Migration, keine Caddy-Änderung, kein neuer TP. Nur dokumentiert.