OpenClaw Gog OAuth Setup: Every Error and Fix

The error message reads: aes.KeyUnwrap(): integrity check failed. Your Google OAuth tokens are corrupted. See our Gmail Pub/Sub guide. Your OpenClaw agent can’t read email, can’t check calendar, can’t pull contacts, can’t do anything that touches Google Workspace. The agent is alive but functionally deaf.

Here’s how to fix it — and every other Gog OAuth error we’ve encountered across production deployments.

Gog (steipete/gogcli) is an MIT-0 licensed CLI tool that gives OpenClaw access to Google Workspace. It covers 6 services: Gmail, Calendar, Drive, Contacts, Sheets, and Docs.

Without Gog, your OpenClaw agent has no way to:

• Read your inbox — email triage, urgent alerts, draft replies
• Check your calendar — morning briefings, meeting reminders, conflict detection
• Access Drive — file lookups, document summaries
• Pull contacts — sender context, relationship history
• Read Sheets/Docs — data extraction, report generation

Gog handles OAuth token storage, refresh, and multi-service authentication through a local keyring. When Gog works, it’s invisible. When it breaks, everything downstream breaks with it.

Before we get to the errors, here’s the full setup flow. Understanding it makes the error messages make sense.

1. 1 Create a Google Cloud Project. In Google Cloud Console, create a new project and enable 6 APIs: Gmail, Calendar, Drive, People (Contacts), Sheets, and Docs.
2. 2 Configure the OAuth Consent Screen. Go to APIs & Services > OAuth consent screen. Select “External” user type. Fill in the app name and support email. Add the 6 scopes matching the APIs above. This is where Error #2 lives.
3. 3 Create OAuth Client Credentials. Go to APIs & Services > Credentials > Create Credentials > OAuth 2.0 Client ID. Select “Desktop app.” Download the JSON file.
4. 4 Register Credentials with Gog.
   $ gog auth credentials /path/to/client_secret.json

   ✓ Credentials registered
5. 5 Authenticate Your Google Account. On a headless server, Gog prints a URL. You open it on your local machine, authorize, and paste the redirect URL back.
   $ gog auth add yourname@gmail.com –services gmail,calendar,drive,contacts,sheets,docs

   Open this URL in your browser: https://accounts.google.com/o/oauth2/…

   Paste redirect URL: _
6. 6 Set the GOG_ACCOUNT environment variable. Add GOG_ACCOUNT=yourname@gmail.com to /etc/environment for persistence. Without it, you need --account on every single command.

Root cause: Gog stores OAuth tokens in an encrypted keyring. The keyring is locked with a password. If the password in your environment doesn’t match the password that encrypted the keyring, every attempt to decrypt the tokens fails with this AES error.

This happens when:

• You reinstalled Gog but the old keyring file is still on disk
• You changed GOG_KEYRING_PASSWORD without re-authenticating
• A previous setup used a different password and left stale keyring data
• The environment variable wasn’t loaded (new SSH session, systemd service without EnvironmentFile)

The Fix

1. 1 Stop any running gog processes:
   $ pkill -f “gog”
2. 2 Remove the corrupted keyring:
   $ rm -rf ~/.local/share/keyrings/gogcli*

   $ rm -rf ~/.config/gogcli/keyring*
3. 3 Set (or reset) the keyring password:
   $ export GOG_KEYRING_PASSWORD=“your-secure-password-here”
4. 4 Make it persistent: Add the variable to /etc/environment and reload:
   # Add to /etc/environment

   GOG_KEYRING_PASSWORD=your-secure-password-here

    

   $ source /etc/environment
5. 5 Re-authenticate all 6 services:
   $ gog auth credentials /path/to/client_secret.json

   ✓ Credentials registered

   $ gog auth add yourname@gmail.com –services gmail,calendar,drive,contacts,sheets,docs

   ✓ All 6 services authenticated
6. 6 Verify:
   $ gog auth status

   ✓ gmail — valid (expires 2026-04-25)

   ✓ calendar — valid (expires 2026-04-25)

   ✓ drive — valid (expires 2026-04-25)

   ✓ contacts — valid (expires 2026-04-25)

   ✓ sheets — valid (expires 2026-04-25)

   ✓ docs — valid (expires 2026-04-25)

Total time to fix: 5-10 minutes, assuming you still have your OAuth client secret JSON file. If you don’t have the JSON file, add another 10 minutes to recreate it in Google Cloud Console.

Root cause: Google Cloud projects have 2 OAuth consent screen modes:

• Testing mode — only allows users explicitly listed as “test users” (max 100)
• Production mode — allows any Google account, but requires Google verification for sensitive scopes

New projects default to testing mode. If you didn’t add your Google account email as a test user, Google blocks the authorization.

The Fix

1. 1 Go to APIs & Services > OAuth consent screen in Google Cloud Console
2. 2 Under “Test users,” click “Add Users”
3. 3 Enter your email: yourname@gmail.com
4. 4 Save and retry the gog auth add command

Why this matters: This error looks like a permissions problem on your server, but it’s a Google Cloud Console configuration issue. No amount of debugging on the VPS will fix it — you need to change a setting in the browser.

Root cause: By default, Gog tries to use the system keyring — macOS Keychain on Mac, GNOME Keyring or KDE Wallet on Linux. Headless servers don’t have a desktop environment, so there’s no system keyring service running. Gog can’t find anywhere to store the encrypted tokens.

The Fix

1. 1 Tell Gog to use a file-based keyring:
   $ export GOG_KEYRING_BACKEND=file
2. 2 Set the encryption password:
   $ export GOG_KEYRING_PASSWORD=“your-secure-password-here”
3. 3 Make both persistent across reboots and SSH sessions. Add both variables to /etc/environment and run source /etc/environment
4. 4 Run auth:
   $ gog auth add yourname@gmail.com –services gmail,calendar,drive,contacts,sheets,docs

   ✓ All 6 services authenticated

For Systemd Services

OpenClaw gateway and gog-gmail-watch need these environment variables available to the service. Add an EnvironmentFile directive pointing to /root/.secrets/gog.env containing GOG_KEYRING_BACKEND=file, GOG_KEYRING_PASSWORD, and GOG_ACCOUNT. Lock it down with chmod 600.

Root cause: When you authenticate with --services gmail,calendar,drive,contacts,sheets,docs, Gog requests scopes for all 6 services in a single OAuth flow. If the consent screen doesn’t have all 6 scopes configured, or if the token grant fails partway through, you end up with partial authentication.

Token refresh failures happen when:

• The OAuth client was created with limited scopes
• Google revoked one scope but not others (happens if user removes app access in Google Account settings)
• The token file got corrupted during a partial write (server restart during auth)

The Fix

1. 1 Check which services are authenticated:
   $ gog auth status

   # Look for services listed as “expired” or missing
2. 2 Re-authenticate ALL at once:
   $ gog auth add yourname@gmail.com –services gmail,calendar,drive,contacts,sheets,docs

   ✓ All 6 services authenticated
3. 3 Verify all 6 are present and valid:
   $ gog auth status

   ✓ All 6 services valid
4. 4 Test each service individually:
   $ gog gmail search “is:unread” –max 3

   ✓ 3 results

   $ gog calendar events primary –from today –to tomorrow

   ✓ Events retrieved

   $ gog contacts list –max 3

   ✓ 3 contacts

   $ gog drive files –max 3

   ✓ 3 files

Why this matters: Partial authentication is the sneakiest error because your agent partially works. Morning briefings pull calendar data but fail on email. Email triage works but can’t check contacts for sender context. You’ll spend hours debugging the wrong thing because “it was working yesterday.”

We’ve scripted the entire OAuth setup and error recovery process. Our deployment scripts detect the server environment, choose the right keyring backend, generate secure passwords, clear stale data, and verify every service individually.

The script handles: environment detection (headless vs. desktop), keyring backend selection, secure password generation, stale keyring cleanup, OAuth credential registration, all-6-service authentication, and individual service verification. The 4 errors described in this post are if statements in our script.

For the full deployment process including Pub/Sub email monitoring (which requires working OAuth), nginx configuration, and security hardening, see our complete Google Workspace deployment walkthrough.

Learn about our managed deployment service

Not affiliated with or endorsed by the OpenClaw open-source project.