Google Sign-In accounts have no way to authenticate via auth login

[KushH305]

Problem

auth login only accepts email + password, which it POSTs to the login
endpoint. Accounts created via Google Sign-In have no password on the
backend, so there's no credential pair to enter.

Trying "forgot password" to force-provision one doesn't work either —
the backend explicitly rejects it:

Your account was created with Google, simply login with Google!
(noreply@liftoffrank.com)

So Google-only accounts currently have no working path to auth login,
auth refresh, or auth status.

Environment

• OS: Windows
• liftoff-export downloaded from zip file
• Liftoff account: created via Google Sign-In, no password ever set

What I've already ruled out

• Password reset — bounced by the backend (see above)
• Checked auth login --help for a hidden token/flag option — none exists
• No web login exists for Liftoff, so there's no easy DevTools token grab

Ask

Would it be possible to support one of:

• A --token flag or LIFTOFF_TOKEN env var to inject an existing bearer
  token directly (useful for any auth method, not just Google)
• An OAuth/browser-callback flow for auth login when the account uses
  Google Sign-In

Happy to test against my own Google-only account if that's useful for
verifying a fix.

[DTTerastar]

Shipped LIFTOFF_REFRESH_TOKEN in #56, out now in v1.3.1. Set it and the CLI skips auth login entirely — no password needed, no token file touched. On Windows there's now a standalone .exe attached to every release (and to every PR, via a download link in the PR comments).

Being straight with you, though: this only helps if you already have a refresh token, and a Google-only account has no easy way to get one — no web login, so it currently means capturing the token off the phone app with something like mitmproxy/Proxyman. So v1.3.1 isn't a real fix for your case yet.

The actual fix is a Google sign-in path in auth login. There's a concrete lead: our user.signIn call hardcodes "provider": "gymbros", which strongly implies the backend also accepts "provider": "google" with some credential (likely a Google ID token). I can't see the exact request shape — my own account is email/password.

You offered to test, which is appreciated — could I ask one step further? If you can capture the Google sign-in request from the Liftoff app with mitmproxy/Proxyman (the POST to .../user.signIn when you log in with Google) and paste the request body here with anything sensitive redacted, that payload is the one missing piece. With it I can build the real flow.

Keeping this open until then.

[Terastar-Paperclip]

Triage: kind:enhancement (no auth surface currently promises Google Sign-In support, so this is new capability, not a contract regression) + area:auth, priority:medium (real workaround path exists via LIFTOFF_REFRESH_TOKEN, well-scoped fix), triage:needs-info (waiting on the Google sign-in request capture per the maintainer's ask above). Thanks for the detailed report and for offering to help verify — that's exactly what unblocks this one.