Linux 0.9.1: encrypted credentials become undecryptable on same machine after key-storage change

[mkrueger12]

Summary

On Linux, gws 0.9.1 can end up with unreadable encrypted OAuth credentials even though credentials.enc exists and the CLI previously authenticated successfully.

Current failure:

{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

And gws auth status reports:

• encrypted_credentials_exists: true
• encryption_valid: false
• encryption_error: "Could not decrypt. May have been created on a different machine."
• plain_credentials_exists: false

This looks like the same bug family as #27, but on Linux with 0.9.1 after the recent key-storage changes.

Environment

• OS: Debian GNU/Linux 13 (headless-ish environment)
• gws: 0.9.1
• DBUS_SESSION_BUS_ADDRESS is present
• libsecret-1-0 is installed
• no visible gnome-keyring-daemon process
• ~/.config/gws/credentials.enc exists
• ~/.config/gws/.encryption_key does not exist

Evidence

gws auth status:

{
  "auth_method": "oauth2",
  "client_config": "/home/max/.config/gws/client_secret.json",
  "client_config_exists": true,
  "encrypted_credentials": "/home/max/.config/gws/credentials.enc",
  "encrypted_credentials_exists": true,
  "encryption_error": "Could not decrypt. May have been created on a different machine.",
  "encryption_valid": false,
  "plain_credentials": "/home/max/.config/gws/credentials.json",
  "plain_credentials_exists": false,
  "storage": "encrypted"
}

And an API call fails with:

{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

Why this looks like a regression

Issue #27 was fixed by #28 (fix(auth): stabilize encrypted credential key fallback).

But 0.9.1 includes:

• 5872dbe: Stop persisting encryption key to .encryption_key file when OS keyring is available. Existing file-based keys are migrated into the keyring and the file is removed on next CLI invocation.

On this Linux machine, there is no .encryption_key fallback file anymore, and the stored encrypted credentials are no longer decryptable. That suggests the CLI believed the OS keyring was stable/available at write time, but a later process could not retrieve the same key reliably.

Suspected cause

The Linux keyring availability check may be too optimistic in some environments:

• write path succeeds via an OS-keyring code path,
• fallback .encryption_key is removed / never written,
• subsequent process cannot retrieve the same key,
• credentials.enc becomes effectively unreadable.

This may be specific to headless Linux / DBus / Secret Service combinations where keyring access is partially available but not stable across invocations.

Expected

If the OS keyring is not reliably available on Linux, gws should preserve a stable fallback instead of leaving credentials.enc unreadable.

Actual

credentials.enc exists but cannot be decrypted on the same machine, causing all authenticated commands to fail.

Request

Could you confirm whether 5872dbe introduced a Linux regression here, and whether Linux should retain .encryption_key fallback unless keyring retrieval is proven stable across fresh processes?

[GiGurra]

same happens on macos. tried re-authing, says it's successful, but in the end doesn't work. I get the exact same error for all commands that you have

[tvvignesh]

I get the same error when running gws auth export --unmasked > gws_credentials.json on a mac - i had initially tried it on a linux headless server

[fivejjs]

 gws drive files list --params '{"pageSize": 10}'                                                                                                                    ─╯
{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

[moltlau3]

We hit what looks like the same regression on another Linux host, and I can add one extra signal that may help narrow it down.

Additional repro evidence

Environment:

• Linux (node user on a Docker/hosted runtime)
• @googleworkspace/cli 0.9.1
• browser-assisted gws auth login
• usage from both normal shell and OpenClaw agent exec context

Observed sequence:

1. Before re-auth, the host was in a degraded but partially working state:
   • some Gmail/Calendar commands still worked
   • warnings included:
     • failed to decrypt token cache (.../token_cache.json)
2. We then ran:
   • gws auth logout
   • browser-assisted gws auth login
3. Login reported success and wrote encrypted credentials
4. After that, both the user shell and agent runtime failed with:

{
  "error": {
    "code": 401,
    "message": "Authentication failed: Failed to decrypt credentials: Decryption failed. Credentials may have been created on a different machine. Run `gws auth logout` and `gws auth login` to re-authenticate.",
    "reason": "authError"
  }
}

So on this host, 0.9.1 turned a noisy/partial auth state into a clean hard failure after re-auth.

Most important clue

Downgrading back to 0.9.0 restored working behavior on the same host.

The user also noticed that after moving to 0.9.1, .encryption_key was no longer present.

That lines up with the changelog item about stopping persistence of .encryption_key when OS keyring is available.

Why this looks specifically like the root cause

On this host/runtime:

• gws auth login succeeds
• encrypted creds are written
• subsequent normal invocations cannot decrypt them
• 0.9.0 works again immediately after downgrade

That strongly suggests 0.9.1's key-storage behavior is assuming a usable/stable keyring path when this environment does not actually provide one reliably across later processes.

Practical interpretation

This does not look OpenClaw-specific. The same failure reproduced directly in the user's normal shell:

gws calendar events list

with the same Failed to decrypt credentials authError.

If useful, I think the strongest version of the bug statement is:

0.9.1 key-storage behavior appears incompatible with some Linux/headless-ish runtimes because .encryption_key fallback disappears, auth login still reports success, and later fresh processes cannot decrypt the saved credentials. Downgrading to 0.9.0 restores functionality on the same machine.

[jpoehnelt]

Fixed by #359 — the .encryption_key file is now always preserved as a durable fallback, and GOOGLE_WORKSPACE_CLI_KEYRING_BACKEND=file can be set to bypass the OS keyring entirely (for Docker/CI/headless). See #359