Issue with Google staying signed in?

[R2bEEaton]

Google account login: session revoked server-side immediately (google_gaia_logged_out) after successful pairing

Environment

• openmessage: built from source, main at commit aa5295d (2026-07-13)
• OS: Windows 11, Go 1.26.5
• Account: personal Gmail (not Workspace, not Google Fi)
• Google Messages QR pairing is no longer offered (US), so account/cookie login is the only option

Summary

Google account login pairs successfully every time, then the moment serve connects, Google reports the session as logged out (google_gaia_logged_out) and the pairing is invalidated (session.json is deleted by Unpair). I could not get a session to survive past the first connect, following the documented procedure exactly.

Steps to reproduce

1. In a Firefox private window, sign in at https://accounts.google.com/AccountChooser?continue=https://messages.google.com/web/config and do not navigate away.
2. Copy the /web/config request as cURL (bash).
3. Pipe it into pair --google-stdin, then tap the emoji on the phone. Pairing reports success.
4. Run serve.

Actual result

INF Connected to Google Messages
INF Listen recovered
INF Reconciling recent conversations
INF No cached SMS history found; starting deep startup backfill
ERR Failed to decode incoming RPC message error="failed to decrypt data event: HMAC mismatch" message_id=...
WRN Google account logged out server-side — session invalid
WRN Disconnected from Google Messages
WRN Skip count is non-zero in postConnect, waiting longer skip_count=21
WRN Checking bugle default on connect is taking long

The error="Google Messages supervisor entered blocked (reauth_required: google_gaia_logged_out)" variant also appears on some runs.

What I tried (all failed the same way)

• Firefox private window (no Device Bound Session Credentials), kept open and signed in through the serve step.
• The exact AccountChooser?continue=.../web/config URL, no navigating away.
• Confirmed the cookie set included SID, HSID, SSID, OSID, APISID, SAPISID, and __Secure-1PSIDTS.
• Full clean slate: stopped all processes, moved the data dir aside so a fresh messages.db and session.json were created (the HMAC mismatch message IDs changed afterward, confirming the reset).
• Unlinked all existing paired devices in Google Messages and checked account security activity for a sign-in challenge.
• Personal Gmail, so no Workspace session-binding policy, and not Google Fi.
• Edge and Chrome captures behave the same but fail even faster, which is consistent with DBSC binding the cookies to the browser. Firefox removes that variable and the session still gets revoked, which points to Google revoking exported web sessions at the account level.

Questions

• Has anyone gotten a personal Gmail account login to persist recently, given Google's DBSC / session-binding rollout? If so, what browser and steps?
• Are the failed to decrypt data event: HMAC mismatch events relevant to the logout, or just leftover queued events that are safe to ignore?

Willing to help

Can provide full debug logs (OPENMESSAGES_LOG_LEVEL=debug) if useful.

[MaxGhenis]

Adding a distinct failure signature + a Chrome-cookie finding from a live macOS install (v2-primary, main post-#144), in case it helps separate two failure modes under this issue.

This signature differs from the OP's immediate google_gaia_logged_out: pairing succeeds and the session connects and holds for ~3–4 minutes, then flips to auth_expired: true / needs_repair: true with last_error: "Google Messages session cookie expired; refreshing and reconnecting…" and loops there indefinitely. So it's a holds-then-cookie-expiry, not an immediate server-side revoke. phone_responding: true throughout — the device link stays alive.

Chrome cookie state on macOS (the source the in-process self-heal reads):

• Core .google.com auth cookies (SID/HSID/SSID/APISID/SAPISID/__Secure-1PSID/__Secure-3PSID) all present and valid through 2027.
• Zero messages.google.com cookies — this Chrome profile has never opened Messages-for-web.

Hypothesis (NOT code-verified — flagging as a lead, not a fact): the #74 in-process cookie self-heal can't renew the session because there's no messages.google.com cookie source in Chrome to refresh from, so it spins on "refreshing" forever. A clean re-pair (removing session.json from both data dirs first, per the runbook) reconnects but only buys the same ~4 minutes before re-expiry. Consistent with #75's thesis that the Google web session is architecturally fragile — recording it as one more concrete data point, and as a possible detection signal: 0 messages.google.com cookies → self-heal is structurally unable to recover → escalate to re-pair/companion instead of looping silently (relevant to #81).

Unverified idea worth testing before betting on it: open messages.google.com/web in the same Chrome profile and pair there, so Chrome then holds live, refreshable Messages cookies the self-heal path can use. Would want to read internal/googlecookies + internal/client refresh logic first to confirm it refreshes against Messages cookies at all.

Repro (macOS, buys ~4 min): quit app → rm session.json from both ~/Library/Application Support/OpenMessage/ and ~/.local/share/openmessage/ → pair via the cookie method (pair --google-file) → tap emoji on phone → relaunch → GET /api/status shows google.connected=true for a few minutes, then the expiry loop. Verifying "fixed" requires watching ≥5 min — it looked stable at 160s twice here and was not.

Refs: #75 (durable fix — Android companion), #81 (surface the self-heal/reconnecting state).

[MaxGhenis]

Follow-up to my comment above: I traced the holds-then-expires signature through the code. The hypothesis was half right, and the wrong half changes what a fix looks like. Code refs: this repo at b8e40f4, libgm fork MaxGhenis/gmessages at 0e43542.

(a) Root cause

The "auth token isn't durably refreshing" half is refuted — the token machinery is fine. The tachyon token defaults to a 24h TTL (libgm/client.go:378-386), refreshes only within 1h of expiry (client.go:104, :418), and authenticates with the token itself plus an ECDSA signature over the session's RefreshKey (client.go:417) — not cookies. The post-#73 fork retries network errors during refresh (libgm/longpoll.go:335). Nothing client-side expires on a minutes scale (the ditto ping's 1→64 min backoff is activity, not credentials).

The mortal layer is the cookie session. In Gaia mode every request also carries the Google account cookie jar plus a SAPISIDHASH Authorization header (client.go:56-68, attached at http.go:50), and the long-poll hits the Gaia endpoint whenever cookies exist (longpoll.go:358-359). When Google stops honoring the exported cookies, the next poll open gets 401/403 → ListenFatalError → the generation dies (longpoll.go:378-385). Since the code rules out any client-side cause at the 3–4-minute scale, the expiry is server-side revocation of an exported browser session — inference for the why, but consistent with the OP's DBSC/session-binding evidence; my account just gets a few minutes' grace where the OP's gets none. (Minor wrinkle, mostly moot: libgm ingests rotated cookies from Set-Cookie in memory (client.go:71-80, http.go:59) but persists them only on AuthTokenRefreshed — internal/client/events.go:379-393 — i.e. roughly daily.)

The "self-heal structurally can't run here" half is confirmed exactly, with a twist. The native refresh hard-requires messages.google.com:OSID (internal/googlecookies/googlecookies.go:40-47) and fails with missing required cookies without it (:180-188); the macOS script has the identical set (scripts/refresh-google-session-cookies-macos.py:36-43). With zero messages.google.com cookies in Chrome, every repair attempt fails before touching the network.

The twist: the availability gate lies. canRefreshGoogleCookies (cmd/serve.go:858-863) → NativeSupported() (internal/googlecookies/secret_darwin.go:18-32) checks only that a Chrome cookie DB file exists, not that the required cookies are present. That gate is what classifies the 401 as repairable FailureCredentialsExpired instead of park-and-tell-the-user FailureUpgradeRequired (internal/bridgeadapters/google/google.go:274-285). Full chain: 401 → ListenFatalError → credentials-expired → auth_expired + the "refreshing and reconnecting…" status (google.go:629-648 → internal/app/google_generation.go:112-122; string at internal/app/google_auth.go:5) → supervisor starts credential repair (internal/bridge/supervisor.go:1186-1187) → repair fails on the missing OSID and flags needs_repair (cmd/google_supervisor.go:96-100) → StateBlocked (supervisor.go:963-967).

"Loops there forever" is actually a park with a stale status. Blocked is terminal until an explicit retry (supervisor.go:534-568); the startup connect is one-shot (cmd/serve.go:240-257), and I found no auto-retry driver anywhere — the web UI reconnect is a manual button and the Swift app never calls it. Nothing clears last_error/auth_expired in Blocked, so /api/status reports "refreshing and reconnecting…" indefinitely while nothing is running. Each reconnect press or app relaunch performs exactly one doomed repair and re-parks. (Also why this state doesn't get the account throttled — it isn't actually hammering.)

Windows contrast: NativeSupported() is false there (secret_other.go:13-15), so the OP's install classifies the same failure as FailureUpgradeRequired and parks honestly. The misleading eternal-refresh signature is specific to macOS with Chrome installed but no Messages-web cookies.

(b) Would the messages.google.com/web pairing workaround engage the self-heal?

Mechanically, yes. Pairing Messages-for-web in Chrome creates exactly the cookie set the refresher demands (OSID on messages.google.com plus the five .google.com cookies it already finds). The loader snapshots the cookie DB + WAL for freshness (googlecookies.go:236-272), prefers messages.google.com-host values (:49-53), rewrites auth_data.cookies wholesale (:314-342), and on repair success the supervisor starts a fresh generation (supervisor.go:970-971). The structural blocker disappears. Notable: pairing itself succeeded with zero messages.google.com cookies, so OSID is the refresher's requirement, not necessarily Google's.

What the code can't promise is that Google honors Chrome's cookies replayed from libgm. Two risks:

1. If the revocation is session-bound, the refreshed cookies die again in minutes — and with repair now succeeding, today's quiet park becomes a genuine connect → revoke → refresh → reconnect cycle every few minutes. There's no rate limit on the repair path, and that reconnect churn is exactly the pattern that gets accounts throttled.
2. Replaying a live browser session's cookies from a second, non-browser client may destabilize Chrome's own Google session. The OP saw account-level revocation even from a Firefox private window (no device binding), so the server heuristics go beyond DBSC.

Verdict: worth one supervised experiment as a diagnostic, not as guidance. If the session still dies in ~4 minutes with live, refreshable, browser-fresh Messages cookies behind it, that conclusively kills the "we just lacked a refresh source" theory and leaves the attachment point itself as the problem.

(c) Recommendation

1. Ship a small honest-failure patch regardless (pairs with Show "Reconnecting…" in platform pills during an active Google cookie self-heal #81): make repair availability cookie-aware — dry-run the required-cookie check instead of "cookie DB exists" — so a structurally unrepairable expiry parks immediately as re-pair-needed with an accurate last_error, instead of reporting "refreshing and reconnecting…" forever. Cheap, and it gives Show "Reconnecting…" in platform pills during an active Google cookie self-heal #81 its escalation signal (0 messages.google.com cookies → self-heal can't work → surface re-pair/companion).
2. Don't invest in making the web-session lifecycle durable (persisting cookie rotation, relaxing the OSID set, retry tuning). The failing layer is server-side revocation of an exported browser session; there is no client-side fix for that.
3. Commit to Design: move SMS/RCS off the Google web session onto an Android companion (the durable pairing fix) #75 (Android companion) as the durable fix. This signature — device link healthy (phone_responding: true throughout), token machinery healthy, cookie session killed by Google in minutes — is about as clean a confirmation of Design: move SMS/RCS off the Google web session onto an Android companion (the durable pairing fix) #75's "renting a session Google can cancel" thesis as we're going to get.

[kevincojean]

Yep, Google messages link died in one day for me.
Thanks for the project, I hope to use it a lot.

[R2bEEaton]

Thanks for digging into this so thoroughly — makes sense, and matches what I was seeing. Sounds like this really is Google killing exported sessions server-side rather than anything on our end, so agree the Android companion (#75) is the real fix long-term.

In the meantime I made a small patch on my fork that doesn't touch the Gaia/cookie-revocation logic itself, but cleans up the repair flow on Windows:

• Session backup on re-pair — before Google account pairing overwrites session.json, it now stashes the old one aside (session.json.prepair-<timestamp>.bak) and restores it automatically if pairing fails partway through, so a bad re-pair attempt doesn't leave you worse off than before.
• Windows-safe umask — the old code called syscall.Umask, which doesn't actually exist in Go's syscall package on Windows (Unix-only), so serve.go was on shaky ground there; split into umask_windows.go / umask_unix.go so it builds and behaves correctly on both.
• Windows signal handling fix — swapped syscall.SIGINT/SIGTERM for os.Interrupt in the shutdown handler, since those aren't valid signals to listen for on Windows.

Interesting update: since making these changes, I haven't had a single sign-out. I don't think this fixes the actual server-side revocation you root-caused — but my guess is it fixed something adjacent: if serve was crashing or exiting badly on Windows before (from the invalid umask/signal calls), and I was repeatedly re-pairing to recover from that, each of those extra re-pair attempts is exactly the kind of reconnect churn you flagged as a likely trigger for Google's account-level throttling. Now that the process runs cleanly and repair doesn't corrupt the session on failure, I'm no longer stuck in that retry loop — so it's plausible I just stopped tripping the same heuristic, not that the underlying revocation risk went away. Flagging as an unconfirmed data point in case it's useful, not as a fix.

Branch, if you want to take a look: https://github.com/Eaton-Integrations/openmessage/tree/windows-google-cookie-pairing