Google Workspace Extension Authentication Failure in Headless/Cron Environments

[kurokirasama]

The Google Workspace extension fails to authenticate or refresh tokens when running in non-interactive environments (such as cron jobs). This results in the error: "Error: No browser available for authentication."

• Automated tasks (e.g., cron jobs) fail with: Error: No browser available for authentication. Please run: node dist/headless-login.js
• The same commands work correctly when run from an interactive terminal session.

The extension's AuthManager prefers system keyring storage (via node-keytar). In a cron job, the Secret Service (e.g., Gnome Keyring) is typically inaccessible because the session is not initialized (missing DISPLAY and DBUS_SESSION_BUS_ADDRESS).

When loadCachedCredentials() fails to access the keyring, it attempts an interactive OAuth2 flow. The wT() utility function checks for DISPLAY on Linux and, finding none, returns false, triggering a hard crash.

While investigating the source code, I found a hidden environment variable that forces the extension to use encrypted file storage instead of the keyring:

GEMINI_CLI_WORKSPACE_FORCE_FILE_STORAGE=true

When this is set inside the crontab for example, the extension uses WZ.create to store tokens in gemini-cli-workspace-token.json within the extension directory, which works perfectly in headless environments.

Some suggestions, but take them with a grain of salt since I don't know the real scope of these changes:

1. Automatic Fallback: Modify AuthManager to automatically fall back to encrypted file storage if the system keyring is inaccessible, rather than crashing.
2. Formalize Environment Variable: Document GEMINI_CLI_WORKSPACE_FORCE_FILE_STORAGE as a supported configuration for server-side or automated usage.
3. Headless Authentication: Provide a CLI-based method to complete authentication when a browser is not available (e.g., copy-pasting an auth code).