fix: prevent gmail.metadata scope from blocking query parameters

[priorwave]

Summary

• Filter gmail.metadata from login scopes when broader Gmail scopes (gmail.modify, gmail.readonly, mail.google.com) are present. Google enforces gmail.metadata restrictions (e.g. blocking the q parameter) even when broader scopes are also in the token.
• Select only the broadest scope per method instead of passing all Discovery Document scopes to yup_oauth2. Method scopes are alternatives, not cumulative.
• Remove superset fallback in token cache to prevent stale all-scopes tokens from being served when a narrower scope is requested.
• Apply the same fix to the MCP server code path (src/mcp_server.rs), which had the identical bug of passing all method scopes.

Problem

Running gws gmail users messages list --params '{"userId": "me", "q": "is:unread"}' returned 403: Metadata scope does not support 'q' parameter because:

1. The Discovery Document lists method scopes as alternatives, but all were passed to yup_oauth2
2. The login scope picker allowed selecting gmail.metadata alongside broader scopes
3. Google's API enforces gmail.metadata restrictions even when broader scopes are present in the token

Changes

File	Change
src/main.rs	select_scope() picks only the first (broadest) scope per method
src/auth_commands.rs	filter_redundant_restrictive_scopes() strips gmail.metadata when broader Gmail scopes are present at login
src/token_storage.rs	Remove superset cache fallback to prevent stale all-scopes tokens being reused
src/mcp_server.rs	Apply select_scope() to the MCP server code path (same bug as CLI)

Test plan

• cargo clippy -- -D warnings passes
• cargo test — 446 tests pass (6 new)
• Manual: gws gmail users messages list --params '{"userId": "me", "q": "is:unread"}' returns results
• Manual: gws gmail users messages list --params '{"userId": "me", "q": "is:unread in:inbox"}' works
• Manual: gws drive files list --params '{"pageSize": 3}' still works
• Manual: Selecting gmail.metadata in scope picker still works (filtered automatically)
• Manual: MCP server Gmail queries work correctly

Fixes #174

🤖 Generated with Claude Code

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[changeset-bot]

🦋 Changeset detected

Latest commit: 89e5540

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@googleworkspace/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[jpoehnelt]

/gemini review

[jpoehnelt]

Some conflicts to fix.

[jpoehnelt]

More conflicts.

[googleworkspace-bot]

/gemini review

[gemini-code-assist]

Code Review

This pull request provides a comprehensive fix for an issue where the restrictive gmail.metadata scope was blocking API calls with query parameters. The changes are well-structured and address the problem from multiple angles: 1. Selecting only the broadest scope from API discovery documents to avoid including restrictive ones by default. 2. Explicitly filtering out gmail.metadata during the login flow if broader Gmail scopes are present. 3. Making the token cache stricter to prevent the reuse of old tokens that contain restrictive scopes. The implementation is clean, idiomatic, and includes appropriate unit tests for the new logic. I have reviewed the changes and found no issues.

[googleworkspace-bot]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses an issue where the gmail.metadata scope was causing API calls to fail by being overly restrictive. The changes to filter this scope during login and to select only the broadest (first) scope for API calls are well-implemented. The removal of the superset token cache fallback is also a crucial part of this fix. I've found one critical issue in src/main.rs where methods that don't require any scopes would fail, and I've provided a suggestion to fix it.