diff --git a/docs/tp16.1-warp-mesh-native-ap1.md b/docs/tp16.1-warp-mesh-native-ap1.md
index 05b881a..7bfd950 100644
--- a/docs/tp16.1-warp-mesh-native-ap1.md
+++ b/docs/tp16.1-warp-mesh-native-ap1.md
@@ -79,6 +79,17 @@ MCP ist read-only, s. §11 der Mapping-Doc). Erfolgt der Create → Mesh ist im
 Plan-/Auth-Fehler → **Stopp, Fallback = LXC-auf-pve-WARP-Connector** (alter Plan, ebenfalls dokumentiert).
 Token danach: `GET /accounts/…/warp_connector/{tunnel_id}/token` → das ist das `eyJhIjoi…In0=`-Register-Token.
 
+**⚠️ Token-Permission-Gotcha (2026-07-17, real erlebt):** `POST /warp_connector` schlug mit `code 10000
+"Authentication error"` (HTTP 403) fehl, obwohl der `CF_API_TOKEN` gültig ist und `teamnet/routes` PATCHen kann.
+Ursache: Cloudflare hat beim WARP-Connector→Mesh-Rebranding (2026-04-14) eine **eigene, separate Permission-Group**
+eingeführt — `Cloudflare One Connector: WARP` (Read/Edit) — „Grants write access to Cloudflare Mesh nodes". Das ist
+**nicht** dasselbe wie `Cloudflare Tunnel Write` (nur für cloudflared) oder `Cloudflare One Connectors Write`
+(Sammel-Permission, deckt aber laut Doku nicht zuverlässig Mesh ab). Verifiziert gegen
+`developers.cloudflare.com/fundamentals/api/reference/permissions/` (aktuelle Tabelle, nicht die älteren
+tunnel-spezifischen Doc-Seiten, die noch die alten Namen zeigen). Im Token-Editor unter **Account**-Permissions nach
+**„Cloudflare One Connector: WARP"** suchen (nicht „Tunnel"), **Edit** wählen. Für §4.4 zusätzlich
+**„Cloudflare One Networks"** → Edit (Routes/vnets).
+
 ### 4.1 CF-Prerequisites setzen (⚠️ account-weit, trifft LIVE-Geräte → 1× kurzer WARP-Reconnect einplanen)
 1. **Unique Device IP AN:** `PATCH /accounts/…/devices/settings {use_zt_virtual_ip:true}` (Dashboard: Team & Resources →
    Devices → Management → „Assign a unique IP address to each device").