diff --git a/docs/handoff-20260901-tp41.md b/docs/handoff-20260901-tp41.md
index 907a7f5..44976b2 100644
--- a/docs/handoff-20260901-tp41.md
+++ b/docs/handoff-20260901-tp41.md
@@ -161,5 +161,6 @@ Sitzungstranskript geraten (Regex-Loch `_PW`). **Rotation erwägen** (Terpene-An
 
 ### Noch offen
 - **d47435-Revoke** (User, Account API Tokens Write). **T3-Client-Verify** (User, WARP neu verbinden).
-- **T5** (GitHub/Google-Callbacks — der eigentliche OTP-Fix, User). **T6/T7/dw-Geli**.
+- **T5** (GitHub/Google-Callbacks — der eigentliche OTP-Fix, User) — **Schritt-für-Schritt:**
+  [`docs/tp41-t5-idp-callback-anleitung.md`](tp41-t5-idp-callback-anleitung.md). **T6/T7/dw-Geli**.
 - 🔴 **`TERPENE_ANDROID_KEYSTORE_PW`-Rotation erwägen** (Transkript-Leak, s.o.).
diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md
index ea0e82b..bcc7c64 100644
--- a/docs/teilprojekte.md
+++ b/docs/teilprojekte.md
@@ -2169,6 +2169,7 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört
 | 4 | **CF-Access-Service-Token** (`CF_API_TOKEN`) | Cloudflare-Zugang, s. TP14.4 | ⏳ **läuft am 2027-01-09 ohnehin ab** — harter Termin, unabhängig vom Projektende | Runbook liegt (`tp14.4-cf-access-token-runbook.md`) | Token neu ausstellen + `~/.secrets` nachziehen; **account-owned**, anderer verify-Endpoint |
 | 5 | **Nautobot-Tokens** (`NAUTOBOT_SUPERUSER_API_TOKEN`, `NAUTOBOT_GITEA_TOKEN`) | Nautobot-Superuser + Gitea-Anbindung | 🔴 in der TP16.3-§2/§3-Session (2026-08-31) durch schwache `sed`-Maskierung **ins Transkript** geraten | Werte in `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored) | neu ausstellen + Stack-YML nachziehen; Superuser-Token wird von den `gc-*`-Skripten gelesen |
 | 6 | **MariaDB `root`** (LXC 302, `10.40.20.23`) | root-DB-Login | 🔴 am 2026-09-01 (TP39) ins Transkript geraten — die `/root/.my.cnf` trug `password <wert>` **ohne `=`**, die Feld-Maskierung ankerte auf `=` und griff nicht | Wert in `/root/.my.cnf` (chmod 600) | `SET PASSWORD` + `.my.cnf` nachziehen; **kein** externer Konsument (Dienste nutzen eigene DB-User) ⇒ billigste Rotation der Liste |
+| 7 | **`TERPENE_ANDROID_KEYSTORE_PW`** | Terpene-Android-TWA-Signing (`android/android.keystore`, alias `terpene`) | 🔴 am 2026-09-01 (TP41) durch **Regex-Suffix-Loch** (`_PW` nicht abgedeckt) ins Transkript geraten | Wert in `~/.secrets/credentials.env` + Keystore-Datei | **Store-/Key-Passwort** via `keytool -storepasswd`/`-keypasswd` ändern + `credentials.env` nachziehen; Konsument = Android-Build/Play-Signing (**Cross-Projekt blaueblüten**) — den **Key selbst NICHT** neu erzeugen |
 
 > ✅ **Der Leak-MECHANISMUS hinter #1 ist seit 2026-08-31 zu — der Wert bleibt trotzdem verbrannt.**
 > Alle sechs Skripte im Repo, die `sshpass -p <PW>` benutzten (`nautobot/gc-transaktion.py` und
@@ -2188,6 +2189,12 @@ Umzug **nebeneinander**, ein zweiter AP am selben Punkt bringt nichts und stört
 > um sie zu sehen. #6 ist zugleich der **billigste** Posten (kein externer Konsument), aber die
 > Panne dahinter ist der teure Teil.
 >
+> 🔴 **#7 ist die vierte Maskierungs-Panne derselben Klasse** (nach `SHELLY_DEVICE_PW` 08-28,
+> Nautobot-Tokens 08-31, MariaDB-root 09-01): diesmal ein **Regex-Suffix-Loch** — das Muster
+> `(TOKEN|PASS|PASSWORD|SECRET|KEY|CLIENT_ID)` deckte den Suffix `_PW` **nicht** ab, also blieb der
+> Wert von `TERPENE_ANDROID_KEYSTORE_PW` beim maskierten Lesen stehen. **Dieselbe Merkregel, erweitert:**
+> die Alternation muss `PW`/`PWD` mit enthalten (`…|PW|PWD|…`), sonst greift die Feld-Ersetzung nicht.
+>
 > ℹ️ **#3 war bis 2026-08-24 TP17.2** und ist jetzt vollständig hier (s. Detailabschnitt unten) —
 > es benutzt denselben Geräte-Durchgang wie #2, **ein Reboot statt zwei**. #4 gehört sachlich zu
 > **TP14.4**, das als TP bestehen bleibt (dort steckt das CF-Access-Profil, nicht nur der Token).
diff --git a/docs/tp41-t5-idp-callback-anleitung.md b/docs/tp41-t5-idp-callback-anleitung.md
new file mode 100644
index 0000000..726c4fc
--- /dev/null
+++ b/docs/tp41-t5-idp-callback-anleitung.md
@@ -0,0 +1,38 @@
+# TP41 T5 — IdP-Callback-URLs reparieren (der Daily-OTP-Fix)
+
+**Problem:** Nach dem Team-Domain-Rename `bf4` → `emsenhuber` kennen die OAuth-Apps bei GitHub/Google
+die neue Callback-URL nicht. Login schlägt mit „redirect_uri is not associated with this application"
+fehl → Cloudflare Access fällt auf **E-Mail-OTP** zurück (das tägliche Nervthema).
+
+**Die EINE URL**, die bei beiden Providern hinterlegt sein muss:
+`https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`
+
+## GitHub  (Client ID `Ov23li2h96hAkGRPJXYV`)
+1. github.com → rechts oben aufs Profilbild → **Settings**.
+2. Linke Spalte ganz unten **Developer settings** → **OAuth Apps**.
+3. Die App mit Client ID `Ov23li2h96hAkGRPJXYV` öffnen.
+4. **Authorization callback URL** = `https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`.
+5. (Optional **Homepage URL** = `https://emsenhuber.cloudflareaccess.com`.)
+6. **Update application** klicken.
+
+## Google  (Client ID `276709275903-b3q55lsj203v4strbhh5mub76cib867e.apps.googleusercontent.com`)
+1. console.cloud.google.com → oben das richtige **Projekt** wählen.
+2. **APIs & Services** → **Credentials**.
+3. Unter **OAuth 2.0 Client IDs** den Client `276709275903-…apps.googleusercontent.com`
+   (Typ *Web application*) öffnen.
+4. **Authorized redirect URIs** → **+ ADD URI** →
+   `https://emsenhuber.cloudflareaccess.com/cdn-cgi/access/callback`.
+5. **Authorized JavaScript origins** → **+ ADD URI** → `https://emsenhuber.cloudflareaccess.com`.
+6. **SAVE**. (Google-Propagation dauert teils ein paar Minuten.)
+
+## Testen
+1. Neues **privates** Browserfenster → eine Access-geschützte Seite öffnen.
+2. Beim CF-Login **GitHub** bzw. **Google** wählen → muss ohne „redirect_uri"-Fehler durchlaufen,
+   **keine** OTP-Mail mehr.
+3. Gegenprobe (optional, kann Claude read-only): CF-Audit
+   `GET /accounts/<acc>/access/logs/access_requests` → `identity_provider` = `github`/`google`
+   statt `onetimepin`.
+
+## Hinweis
+Die Team-Domain heißt `emsenhuber.cloudflareaccess.com` (das alte Org-Label `bf4…` in CF nicht
+anfassen). Session gilt 720 h (30 Tage) — nach dem Fix sollte der Login also lange halten.