You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
auth login --services: cloud-platform is re-added after being deselected in the scope picker #918
Version: gws 0.22.5 (@googleworkspace/cli via npm), node v20.11.1, Linux 6.8.0
auth login --services <svc> opens the scope picker. Scopes deselected in the picker can still end up in the authorize URL. cloud-platform is preselected and is re-added regardless of the selection.
Repro
gws auth login --services gmail
In the picker, deselect everything except gmail.send. Header reads Select OAuth scopes 1/17 selected.
Enter.
Read the printed authorize URL.
scope= contains:
https://www.googleapis.com/auth/gmail.send
https://www.googleapis.com/auth/cloud-platform <- deselected at step 2
openid
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Expected: no cloud-platform.
--scopes is unaffected and produces exactly what is asked for:
cloud-platform grants read, write and delete across the user's Google Cloud resources. Someone who opens the picker to narrow scopes, sees 1/17 selected, and consents, grants it anyway. The counter reports the intended selection, so nothing on screen shows the grant is wider than chosen. The authorize URL is the only place the real scope list appears, and it is long enough to wrap in a terminal.
gmail.readonly (restricted, full mailbox read) is also preselected via the Recommended (Core Consumer Scopes) entry.
Also
Toggling Recommended (Core Consumer Scopes) off moves the counter from 9/17 to 8/17 but leaves the eight individual scopes checked, cloud-platform among them. Each has to be deselected separately. If the row is meant to act as a group toggle, that is a second bug; if it is just another checkbox, the name reads like a group.
Suggested fix
Build the authorize URL from picker state, or print the resolved scope list for confirmation before opening the browser. The second is useful on its own: right now checking what you are about to grant means parsing a URL by eye.
This issue overlaps #562 and #741, and the fixes (#564, #662, #747) were all auto-closed by a bot without any maintainer review. It is absurd that a security issue that silently grants full cloud-platform access sits unfixed while every PR gets bot-closed. It makes us seriously question the security of the Google Cloud platform.
Activity
james-dfns commentedon Sep 8, 2026
Workaround until this is fixed: skip the picker and pass explicit scopes, which are used verbatim with no cloud-platform injection:
This issue overlaps #562 and #741, and the fixes (#564, #662, #747) were all auto-closed by a bot without any maintainer review. It is absurd that a security issue that silently grants full cloud-platform access sits unfixed while every PR gets bot-closed. It makes us seriously question the security of the Google Cloud platform.
fix(auth): respect user scope picker for cloud-platform (closes googl…