Context
PR #42 added backend detection of a stuck Google Messages session (GoogleStatus.NeedsRepair when connected but sends keep failing) and a re-pair banner in the web UI. The native macOS Platforms view (macos/OpenMessage/Sources/OpenMessageApp.swift) still only shows "Open inbox / Sync history" for Google Messages whenever it's "connected" — with no re-pair control.
This was the core of a painful real incident: the session had silently lapsed, the app reported connected=true, and there was no reachable re-pair path in the native UI. Recovery required deleting session.json from ~/Library/Application Support/OpenMessage/ by hand so the app would boot into PairingView.
Ask
In the native Platforms view's Google Messages section:
- When
google.needs_repair is true (from /api/status), show a prominent "Pair again" action that triggers the existing startGooglePairing flow — even though connected is true.
- Consider always offering a low-key "Re-pair" affordance for Google Messages (the web overlay already shows "Pair again" while connected), so a stuck session is never a dead end.
Note for whoever picks this up: the embedded-webview Google sign-in in PairingView gets blocked by Google ("sign-in not allowed in this app") and dead-ends in Google's troubleshooter. The cookie/cURL fallback (Advanced section) is what actually works — make sure that path stays prominent, or automate pulling cookies from the user's signed-in Chrome.
Context
PR #42 added backend detection of a stuck Google Messages session (
GoogleStatus.NeedsRepairwhen connected but sends keep failing) and a re-pair banner in the web UI. The native macOS Platforms view (macos/OpenMessage/Sources/OpenMessageApp.swift) still only shows "Open inbox / Sync history" for Google Messages whenever it's "connected" — with no re-pair control.This was the core of a painful real incident: the session had silently lapsed, the app reported connected=true, and there was no reachable re-pair path in the native UI. Recovery required deleting
session.jsonfrom~/Library/Application Support/OpenMessage/by hand so the app would boot intoPairingView.Ask
In the native Platforms view's Google Messages section:
google.needs_repairis true (from/api/status), show a prominent "Pair again" action that triggers the existingstartGooglePairingflow — even thoughconnectedis true.Note for whoever picks this up: the embedded-webview Google sign-in in
PairingViewgets blocked by Google ("sign-in not allowed in this app") and dead-ends in Google's troubleshooter. The cookie/cURL fallback (Advanced section) is what actually works — make sure that path stays prominent, or automate pulling cookies from the user's signed-in Chrome.