Encryption key always written to file even when OS Keyring is available

[bobsahur-robot]

Summary

gws auth login writes the AES-256-GCM encryption key to both the OS Keyring and ~/.config/gws/.encryption_key (or ~/Library/Application Support/gws/.encryption_key on macOS). However, the read path only checks the file — removing the file causes auth to fail even when the key exists in the Keyring.

The README states:

Credentials are encrypted at rest (AES-256-GCM) with the key stored in your OS keyring (or ~/.config/gws/.encryption_key when GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file).

This implies Keyring is the default and file is the fallback. In practice (v0.18.1 via Homebrew on macOS 26.3 arm64), the file is always the primary read path.

Steps to Reproduce

1. gws auth login — completes successfully, creates .encryption_key file
2. Verify key exists in macOS Keychain (security find-generic-password -s gws)
3. Remove .encryption_key file
4. gws auth status — fails with 401, cannot decrypt credentials

Expected Behavior

When GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND is not set to file, gws should read the encryption key from OS Keyring first, falling back to the file only if Keyring is unavailable.

Why This Matters

Storing the encryption key as a plaintext file alongside the encrypted credentials defeats the purpose of encryption — any file-scanning malware that reads both files can decrypt OAuth tokens offline. Keyring/Keychain storage is significantly more secure since it requires OS-level authorization to access.

Environment

• gws v0.18.1 (Homebrew)
• macOS 26.3 (arm64, Apple Silicon)
• Keychain access confirmed working for other apps

[bobsahur-robot]

Update: looking at the source on main, the resolve_key function correctly tries keyring first → file fallback → generate. This might be fixed in a newer release. We're on v0.18.1 (Homebrew) where keyring read appears to fail silently. Will test with v0.22.0 and close if resolved.

However, the design note says: "The .encryption_key file is never deleted — it always serves as a durable fallback." This means even on latest, the key is always on disk alongside the encrypted credentials, which somewhat undermines the security benefit of keyring storage. A --keyring-only mode (or removing the file after confirming keyring works) would be a nice hardening option.