openclaw - 💡(How to fix) Fix Google/Gmail operability recovery is too fragile to serve as a sustainable baseline [1 participants]

Summary

Google/Gmail/Drive operability on a live OpenClaw instance is too fragile to treat as a sustainable baseline. The capability exists and has worked, but recovery repeatedly depends on brittle interactive OAuth/keyring/callback flows that are not operationally closed for a production-like instance.

Why this matters

This is not just a one-off auth hiccup. The current recovery path can consume repeated operator attention and still fail without a clear, deterministic closure signal. In practice, that makes a critical capability non-operable even when the platform and integration nominally support it.

Local evidence

Environment:

• OpenClaw CLI: 2026.4.2 (d74a122)
• gog build: v0.11.0-73-g0ed8997
• Account intended as the only valid account: [email protected]

Observed state:

• gog auth list still shows the account, but real Gmail and Drive calls fail with:
  • oauth2: "invalid_grant" "Token has been expired or revoked."
• We cleaned prior account contamination and reduced state to the intended account only.
• Keyring usability was recovered locally, so the dominant blocker narrowed to OAuth operability, not just keyring decryption.

Exact failing evidence:

Get "https://gmail.googleapis.com/gmail/v1/users/me/messages?...": round trip: oauth2: "invalid_grant" "Token has been expired or revoked."
Get "https://www.googleapis.com/drive/v3/files?...": round trip: oauth2: "invalid_grant" "Token has been expired or revoked."

Fragility in current recovery path

The available auth recovery flows are:

• browser callback capture
• --manual
• --remote --step 1/2

In this instance, recovery attempts exposed brittle failure modes:

1. Local callback flow appears to succeed on Google side, but the running process does not reliably consume/close the callback in-context.
2. Remote/manual flow is better, but still easy to invalidate with manual auth state mismatch if the exchange is not completed in exactly the matching active flow.
3. The operator can end up repeating login/consent steps multiple times without achieving an actually operable baseline.

This means the capability can exist in theory while still failing the operational question: can the owner recover it quickly and reliably under normal pressure?

Problem statement

There seems to be a gap between:

• auth surface existing
• auth surface working in happy-path situations
• auth surface being operationally recoverable and sustainable as a baseline

For a critical capability like Gmail/Drive integration, the third property matters.

Request

Please treat this as an operability / recovery-path issue, not only as an auth bug.

What would help most:

1. A clearly documented, deterministic recovery path for revoked/expired OAuth on headless/server-ish instances.
2. Stronger CLI UX around active auth state, stale state, and remote/manual exchange lifecycle.
3. Better protection against silent/looping reauth attempts that appear close to success but do not produce a usable token.
4. A clearer “capability recovered” closure signal (e.g. optional immediate validation against Gmail + Drive after auth).

Current judgment from the instance

This capability should not be considered operationally recovered until all of the following are true:

• Gmail read real
• Gmail send real
• Drive real
• no fragile prompt/keyring surprises
• one repeatable recovery path exists
• evidence of recovery can be validated immediately

Right now, that bar is not met.