gog auth list under-reports scopes when stored token has subset of currently-granted scopes

[rancur]

Summary

gog auth list reports the scope set stored at token-add time in the keyring entry, but a stored token will often successfully execute API calls against scopes it does not list. This caused a 30+ minute false-alarm investigation in one of our agent runs: auth list reported an account as calendar-only, yet gmail send on that same account succeeded.

Reproduction (locally observed)

$ gog --version
v0.12.0 (c18c58c 2026-03-09T05:53:14Z)

$ gog auth list
barry@willcurran.com    default    calendar           2026-02-26T18:45:40Z    oauth
flash@willcurran.com    default    calendar,gmail     2026-04-15T22:01:53Z    oauth

$ gog auth list --json
{
  "accounts": [
    {
      "email": "barry@willcurran.com",
      "services": ["calendar"],
      "scopes": [
        "email",
        "https://www.googleapis.com/auth/calendar",
        "https://www.googleapis.com/auth/userinfo.email",
        "openid"
      ],
      ...
    }
  ]
}

$ gog gmail --account barry@willcurran.com search "newer_than:1d" --results-only
ID                DATE              FROM             SUBJECT  LABELS  THREAD
19e6a781e1d2bfff  2026-05-27 10:25  barry@curran.co  Re: ...  SENT    [2 msgs]

$ gog --verbose gmail --account barry@willcurran.com search "newer_than:1d" --results-only 2>&1 | head -3
time=... level=DEBUG msg=\"creating client options with custom scopes\" serviceLabel=gmail email=barry@willcurran.com
time=... level=DEBUG msg=\"client options with custom scopes created successfully\" serviceLabel=gmail email=barry@willcurran.com

The keyring file's stored scope set does not include gmail, yet gmail send / gmail search both succeed against this account. (We confirmed actual send via msg-id 19e6a77240c18d79 — message landed in Sent.)

Root cause (hypothesis)

Google's OAuth server honors incremental authorization — if the user has previously consented to a wider scope set under the SAME OAuth client (across any account), Google will issue access tokens with the requested scopes off the refresh token even when that specific refresh token's original consent only covered a subset. gog's request-time path \"creating client options with custom scopes\" is asking for gmail scope and Google grants it; meanwhile the keyring entry's stored scope set is stale because it was never re-issued to reflect the broader consent.

Why this matters

Operators (and agents) trust gog auth list as the source of truth for "can this account do X?" When the displayed scope set is a strict subset of what actually works, they either:
(a) waste time re-authing accounts that don't need it, or
(b) raise false-alarm "auth blocker" notifications when there is no actual blocker.

Both happened in our system.

Suggested fix (one of)

1. Detect + persist scope upgrades. When gog successfully obtains an access token off a refresh token with a scope set that exceeds the stored consent set, write the new scope union back to the keyring entry so subsequent auth list calls reflect reality.
2. gog auth refresh <email> command. Trigger a refresh+token-exchange that updates the stored scope metadata without a full browser re-consent flow.
3. auth list warning glyph. When a stored token's scope set has been observed to be insufficient for a recent successful call, mark the row with a * and explain in auth list --help.

Option 1 is the most user-friendly (auto-heals). Option 2 is the smallest change. Option 3 is the cheapest but does not auto-heal.

Workaround

gog auth add <email> --services gmail,calendar --force-consent re-authorizes through the browser flow with the explicit superset, which refreshes the keyring entry's stored scope list. (Verified locally that this is the path that updates the metadata; running it for this account is a separate Will-side step requiring interactive browser action.)

Environment

• Version: v0.12.0 (c18c58c)
• Backend: file keyring (passwords managed in 1Password via gog-safe wrapper)
• macOS 25.2.0 (Darwin), arm64
• Latest release is v0.19.0; release notes since v0.12.0 do not appear to address this specifically ("auth list" changes since v0.12.0 are about graceful unreadable-entry handling and per-client filtering, not scope-upgrade reconciliation).

Happy to test a fix locally; the affected account is barry@willcurran.com (Workspace) on this machine.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed May 27, 2026, 1:45 PM ET / 17:45 UTC.

Summary
Keep open: current main still reports auth list scopes from stored token metadata, while the runtime OAuth path can request service-specific scopes and only persists refresh/access/identity metadata back to the keyring.

Reproducibility: yes. source inspection gives a high-confidence path: store a token with narrower Services/Scopes, successfully refresh/request a broader service scope at runtime, then auth list will still print the stored narrower metadata. I did not run a live Google OAuth account in this read-only review.

Next step
A focused fix can be attempted in the auth token-source and auth-list metadata tests, but it should verify actual granted-scope data rather than assume requested scopes were granted.

Review details

Best possible solution:

Auto-heal stored OAuth metadata by merging observed granted scope unions after successful token refreshes, deriving service labels from that union where possible while preserving parseable auth list output.

Do we have a high-confidence way to reproduce the issue?

Yes, source inspection gives a high-confidence path: store a token with narrower Services/Scopes, successfully refresh/request a broader service scope at runtime, then auth list will still print the stored narrower metadata. I did not run a live Google OAuth account in this read-only review.

Is this the best way to solve the issue?

Yes, auto-healing the stored metadata from observed granted scopes is the narrowest maintainable fix. A new auth refresh command or warning could be useful later, but it would not solve the stale source of truth as directly.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The repair should persist only scopes actually observed from a successful token response or equivalent verification; blindly adding requested scopes after any refresh could over-report capabilities.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 9987f8b2f053.

Label changes

Label changes:

• add P2: This is a normal auth accuracy bug with real operator impact but no evidence of data loss, security bypass, or broken core runtime.
• add impact:auth-provider: The report concerns OAuth scope metadata, refresh-token behavior, and account capability reporting.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal auth accuracy bug with real operator impact but no evidence of data loss, security bypass, or broken core runtime.
• impact:auth-provider: The report concerns OAuth scope metadata, refresh-token behavior, and account capability reporting.

Evidence reviewed

Acceptance criteria:

• go test ./internal/googleapi ./internal/googleauth ./internal/cmd
• go test ./internal/secrets

What I checked:

• auth list reads stored scopes: authListEntry.details returns e.Token.Services and e.Token.Scopes, and JSON output copies those values directly into the services and scopes fields. (internal/cmd/auth_list_helpers.go:172, 9987f8b2f053)
• runtime token refresh does not reconcile scopes: tokenSourceForAccountScopes builds an OAuth config with the command's required scopes, but persistingTokenSource.Token only updates refresh token, access token, expiry, subject, and email before calling SetToken; it does not merge granted scopes or services. (internal/googleapi/client_auth.go:52, 9987f8b2f053)
• stored scope metadata is captured at auth-add time: auth add persists the selected service names and computed scopes when the refresh token is first saved, which matches the report that later broadened grants can leave keyring metadata stale. (internal/cmd/auth_add.go:271, 9987f8b2f053)
• current tests preserve the stale-scope behavior: The refresh-token persistence test explicitly expects Services and Scopes to remain unchanged after a token refresh, so current regression coverage does not cover scope-upgrade reconciliation. (internal/googleapi/client_more_test.go:188, 9987f8b2f053)
• history points to recent auth metadata owners: Recent auth-list and token-refresh metadata work was in commits 5b05a453d278f72daafb2a40b668ef8b355ac913 and 8addfcee8b39041ecc6e71e6a354ca17f188c013; readonly/incremental scope behavior was touched in 25040fe7fe235229e7321ed67694f109fcc75db9. (8addfcee8b39)
• no shipped/current changelog fix found: The current unreleased changelog only updates bundled skill guidance, and v0.19.0 auth entries cover credentials, import, and file-keyring locking rather than scope reconciliation. (CHANGELOG.md:3, 9987f8b2f053)

Likely related people:

• Peter Steinberger: Recent commits changed auth-list client bucketing and token refresh metadata persistence in the exact files that would need the reconciliation fix. (role: recent auth/keyring contributor; confidence: high; commits: 5b05a453d278, 8addfcee8b39, b25a3c029b37; files: internal/cmd/auth_list_helpers.go, internal/googleapi/client_auth.go, internal/googleapi/client_more_test.go)
• salmonumbrella: Auth scope-shaping and incremental/readonly scope behavior history includes their changes, which is relevant to deciding how to merge observed granted scopes safely. (role: adjacent OAuth scope contributor; confidence: medium; commits: 25040fe7fe23, 50dac265e173, 7cf8b918adc5; files: internal/cmd/auth_add.go, internal/googleauth/oauth_flow.go, internal/googleauth/accounts_server.go)
• Zainan Victor Zhou: The --extra-scopes auth surface affects how non-service scopes may need to round-trip when stored metadata is reconciled. (role: adjacent custom-scope contributor; confidence: low; commits: b10c81a98986; files: internal/cmd/auth_add.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.