Native OS keychain integration for encryption key storage (macOS Keychain / Windows Credential Manager)

[lgameplayer]

Related to: #153 (which addresses Windows ACL hardening on the file fallback — this request proposes eliminating the file fallback entirely)

Problem

Currently, the AES encryption key used to protect credentials.enc is stored as a flat file at ~/.config/gws/.encryption_key. Even with 0o600 permissions on Unix, this means:

• The encryption key and encrypted token are co-located — an attacker with local filesystem access obtains both simultaneously, rendering the at-rest encryption ineffective
• The key persists on disk indefinitely with no session scoping
• Enterprise security reviews flag this as a gap for company-wide deployments

Proposed Solution

Use OS-native secure storage as the primary mechanism for the encryption key, with the file path as a last-resort fallback only:

• macOS — macOS Keychain via keytar (already present in the monorepo via @google/gemini-cli-core)
• Windows — Windows Credential Manager (already the intended primary keyring path per [Security] Windows: encryption key written to plaintext file with no access controls #153)
• Linux — Secret Service API via keytar (libsecret), with file fallback for headless environments

This would mean the encryption key is stored in the OS's protected credential store, is only accessible to the authenticated user, and is session-scoped on platforms that support it
— the key never touches the filesystem.

Implementation Notes

keytar is already available in the broader googleworkspace/cli monorepo (pulled in by @google/gemini-cli-core@0.34.0). The gws package could either:

1. Add keytar as a direct dependency
2. Use the existing Node.js keychain APIs via a thin wrapper

The storage key name could follow the pattern: service: "gws", account: "<user-email>".

Enterprise Context

This has been raised as a blocking security requirement for company-wide enterprise deployment of gws. The current co-location of the encryption key and encrypted credentials is
flagged in security architecture reviews as providing no meaningful protection against local threat actors. Native keychain integration is the standard pattern for CLI tools
handling OAuth tokens at enterprise scale (see: gh, gcloud, docker).

Acceptance Criteria

• On macOS, encryption key stored in Keychain, not ~/.config/gws/.encryption_key
• On Windows, encryption key stored in Credential Manager
• File fallback retained for CI/headless environments with a clear warning
• Existing credentials migrate gracefully on first use after upgrade