Bug: Windows — API calls fail with insufficient scopes despite valid refresh token

[paul-cimento]

Environment

• gws version: latest from npm (npm install -g @googleworkspace/cli)
• OS: Windows 11
• Shell: PowerShell 5.1
• Keyring backend: keyring (default)
• Google Workspace account: yes (Workspace domain)
• OAuth app status: External, testing mode

Steps to Reproduce

1. Run gws auth setup — completes successfully
2. Run gws auth login -s calendar — completes successfully, reports https://www.googleapis.com/auth/calendar in saved scopes
3. Run gws calendar +agenda

Expected

Calendar agenda is returned.

Actual

{
  "error": {
    "code": 403,
    "message": "Request had insufficient authentication scopes.",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "ACCESS_TOKEN_SCOPE_INSUFFICIENT",
        "metadata": {
          "service": "calendar-json.googleapis.com",
          "method": "calendar.v3.CalendarList.List"
        }
      }
    ]
  }
}

Diagnosis

The refresh token is valid and has the correct scopes. Manually exchanging it via https://oauth2.googleapis.com/token confirms the token includes https://www.googleapis.com/auth/calendar:

# Exchange refresh token manually
$body = @{
    client_id     = "<REDACTED>"
    client_secret = "<REDACTED>"
    refresh_token = "<REDACTED>"
    grant_type    = "refresh_token"
}
$response = Invoke-RestMethod -Method Post -Uri "https://oauth2.googleapis.com/token" -Body $body
$response.scope
# Output includes: https://www.googleapis.com/auth/calendar openid https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/userinfo.email

Setting the access token directly via env var works:

$env:GOOGLE_WORKSPACE_CLI_TOKEN = $response.access_token
gws calendar +agenda
# Returns calendar data successfully

This confirms gws is not correctly using the stored refresh token to obtain access tokens. The issue persists even after:

• Deleting credentials.enc
• Setting GOOGLE_WORKSPACE_CLI_CREDENTIALS_FILE to a valid plaintext JSON credentials file (created from gws auth export --unmasked)
• Setting GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file

In all cases, the API call still fails with "insufficient scopes", even though the underlying refresh token has the correct scopes.

The same behavior occurs across all Workspace APIs tested (Calendar, Drive, Gmail), not just Calendar.

Possibly Related

• Auth broken after update #389 — Auth broken after update (Windows keyring issues mentioned by multiple users)
• macOS: credentials.enc decrypt always fails (AES-256-GCM + OS Keyring) #381, credentials.enc decryption fails immediately after auth login on macOS #378, AES-256-GCM credential decryption fails on macOS (Keyring + .encryption_key) #368 — macOS credential decryption failures
• The comment by @olvgrolle in Auth broken after update #389 about missing platform-specific keyring features in Cargo.toml (windows-native feature) may be the root cause

Workaround

Manually refresh the access token and set GOOGLE_WORKSPACE_CLI_TOKEN:

$body = @{
    client_id     = "<from gws auth export>"
    client_secret = "<from gws auth export>"
    refresh_token = "<from gws auth export>"
    grant_type    = "refresh_token"
}
$response = Invoke-RestMethod -Method Post -Uri "https://oauth2.googleapis.com/token" -Body $body
$env:GOOGLE_WORKSPACE_CLI_TOKEN = $response.access_token
# All gws commands now work for ~1 hour until the access token expires

[kz-zl]

Reproducing on macOS as well — not just a Windows issue.

Environment:

• gws 0.22.0 (upgraded from 0.18.1)
• macOS (Darwin 25.3.0)
• zsh
• Keyring backend: keyring (macOS Keychain)

Reproduction:

1. gws auth login --scopes https://www.googleapis.com/auth/drive,... — reports success with all scopes
2. gws drive files list --params '{"pageSize": 2, "fields": "files(id,name)"}' — returns 403 insufficientPermissions
3. Manually exchanging the refresh token from gws auth export --unmasked confirms the token has the drive scope
4. Setting GOOGLE_WORKSPACE_CLI_TOKEN with the access token from the manual exchange makes Drive calls work

The bug appeared after upgrading from v0.18.1 to v0.22.0. Drive worked fine on 0.18.1 earlier in the same session. Same workaround as OP — manually refresh and set GOOGLE_WORKSPACE_CLI_TOKEN.

Interestingly, gws gmail +triage and gws meet conferenceRecords list work fine from the encrypted credentials — the issue seems specific to certain API services (Drive in my case), suggesting gws may be sending a stale or partial access token for some calls.

[Aurelian-Shuttleworth]

Reproducing on macOS as well (Darwin, zsh, gws installed via Nix flake).

Same symptoms: gws calendar +agenda returns 403 on calendarList.list despite gws auth login -s calendar completing successfully with the full calendar scope. Raw API calls via gws calendar events list --params '{"calendarId": "primary", ...}' work fine.

Looking at the source, the +agenda helper in calendar.rs hardcodes calendar.readonly as its requested scope (line 215) rather than using the broader calendar scope that was granted during auth. This scope mismatch may be causing get_token() in auth.rs to issue an access token with only calendar.readonly, which is insufficient for the calendarList.list call the helper makes internally.

Workaround: using raw Discovery-based commands instead of the +agenda helper.