Credentials file is silently deleted when decryption fails — user is logged out with no error explaining why

[grahamtyler-gw]

Summary

When gws cannot decrypt credentials.enc, it deletes the file rather than reporting the problem. The error surfaced to the user is unrelated to authentication, so there is no indication that the saved login was just destroyed. The only recovery is gws auth login.

I hit this with real credentials, then reproduced it deliberately in an isolated config directory.

Environment

• gws 0.22.5
• macOS 26.5.2 (Darwin 25.5.0), Apple Silicon (arm64)
• zsh, Node.js v26.5.0
• Keyring backend: keyring (macOS Keychain), storage: encrypted

Reproduction

export D=/tmp/gws-repro
mkdir -p $D

# minimal client config (values can be fake)
cat > $D/client_secret.json <<'EOF'
{"installed":{"client_id":"000000000000-fake.apps.googleusercontent.com",
"project_id":"fake-project-123","auth_uri":"https://accounts.google.com/o/oauth2/auth",
"token_uri":"https://oauth2.googleapis.com/token","client_secret":"FAKE"}}
EOF

# stand in for a credentials file that cannot be decrypted
echo "UNDECRYPTABLE" > $D/credentials.enc

ls $D          # -> client_secret.json  credentials.enc
GOOGLE_WORKSPACE_CLI_CONFIG_DIR=$D gws drive files list --params '{"pageSize":1}'
ls $D          # -> client_secret.json  (credentials.enc is gone)

credentials.enc is deleted. Nothing in the command output mentions credentials, decryption, or logout.

I ran this both with the Keychain reachable and in a stripped environment where it was not. The file is deleted in both cases, so the trigger is decryption failure generally, not Keychain availability specifically.

How this happened with real credentials

I had a working, fully authenticated setup. I then switched install methods — from npx @googleworkspace/cli to npm install -g @googleworkspace/cli — and ran a command.

macOS Keychain access control is per-binary-path, so the newly installed binary at a different path could not retrieve the encryption key that the previous one stored. Decryption failed, and credentials.enc plus token_cache.json were removed. gws auth status then reported auth_method: none, as though I had never signed in.

If that is the mechanism, any change to how gws is installed can silently destroy a user's saved login, which is a surprising outcome for what looks like a routine upgrade.

Expected behavior

Decryption failure should not delete user data. Preferably:

1. Report the actual cause, e.g. Failed to decrypt credentials (encryption key not available from keyring). Run 'gws auth login' to re-authenticate.
2. Leave credentials.enc in place, or move it aside (credentials.enc.bak) rather than removing it.
3. If deletion is intentional, say so explicitly in the output so the user knows they have been logged out.

The current behavior is hard to diagnose because the visible error points somewhere else entirely — in my case at the GCP project, which was not the problem.

Related

• macOS: Credential decryption always fails - OS Keyring not storing encryption key #360 (closed) covers decryption failing on macOS, but not the silent deletion of the credentials file.
• gws auth login can silently leave a stale/split token cache, causing 403 insufficient authentication scopes after re-auth #876 covers a stale/split token cache after re-auth, which is a different failure mode.