Summary
When the same Google account is authorized under multiple gog clients, gog auth list only displays one row for that email instead of one row per client.
This makes it look like only one token exists, even though client-specific API calls still work.
Environment
gog version: v0.15.0- OS: Linux x86_64
- Keyring backend: file
Setup
Same account authorized under several clients with different scopes:
ro — Gmail/Drive readonlyrw — Calendar/Tasksinbox — Gmail modifycompose — Gmail compose
Observed behavior
Running:
returns only one account row for the email, typically the most recently-added client.
Passing --client does not appear to change the output:
gog auth list --client ro --json
gog auth list --client rw --json
gog auth list --client inbox --json
still reports only the same single row.
However, direct API calls using each client work correctly, for example:
gog gmail search 'in:inbox' --client ro
gog drive search 'trashed=false' --client ro
gog gmail search 'in:inbox' --client inbox
gog calendar list --client rw
So the tokens appear to be stored and usable; only auth list output is collapsed.
Expected behavior
gog auth list should show one row per (email, client) token, for example:
user@example.com compose gmail
user@example.com inbox gmail
user@example.com ro drive,gmail
user@example.com rw calendar,tasks
Likely cause
It looks like buildAuthListEntries() de-duplicates by normalized email only, so multiple tokens for the same email under different clients collapse into a single row.
I tested a local patch that changes the auth-list de-dupe key from email-only to (email, client), and that made all client rows display correctly.
Suggested fix
Use both normalized email and client name when de-duplicating auth list entries.
A regression test could authorize or mock multiple tokens for the same email under different clients and assert that gog auth list --json returns one row per client.
Summary
When the same Google account is authorized under multiple
gogclients,gog auth listonly displays one row for that email instead of one row per client.This makes it look like only one token exists, even though client-specific API calls still work.
Environment
gogversion:v0.15.0Setup
Same account authorized under several clients with different scopes:
ro— Gmail/Drive readonlyrw— Calendar/Tasksinbox— Gmail modifycompose— Gmail composeObserved behavior
Running:
returns only one account row for the email, typically the most recently-added client.
Passing
--clientdoes not appear to change the output:still reports only the same single row.
However, direct API calls using each client work correctly, for example:
So the tokens appear to be stored and usable; only
auth listoutput is collapsed.Expected behavior
gog auth listshould show one row per(email, client)token, for example:Likely cause
It looks like
buildAuthListEntries()de-duplicates by normalized email only, so multiple tokens for the same email under different clients collapse into a single row.I tested a local patch that changes the auth-list de-dupe key from email-only to
(email, client), and that made all client rows display correctly.Suggested fix
Use both normalized email and client name when de-duplicating auth list entries.
A regression test could authorize or mock multiple tokens for the same email under different clients and assert that
gog auth list --jsonreturns one row per client.