Setting up the gog skill on a VPS hosted OpenClaw
Five pitfalls I hit setting up gog on a headless Hostinger VPS so you don't have to.
February 24, 2026
I spent an afternoon setting up gog (a CLI tool for interacting with Google Workspace) on my OpenClaw instance running on a Hostinger VPS. It took about 40 minutes. It should have taken five.
Here is what I learned so you do not have to learn it the hard way.
What is gog?
gog is a command line tool that lets you interact with Google Workspace services. Think of it as curl for Google APIs. You can search Gmail, send emails, check your calendar, browse Drive, and read spreadsheets all from the terminal.
If you are running an AI assistant on OpenClaw, gog is how you give it access to your Google life. Install it with Homebrew:
brew install steipete/tap/gogcli
The setup is straightforward in theory: register your Google OAuth credentials, authorize your account, and you are done. In practice, on a headless VPS, every step has a trap door.
Pitfall 1: Web vs. Desktop OAuth clients
This is the big one. When you create an OAuth client in the Google Cloud Console, you are given a choice: Web application or Desktop app.
Your instinct might be to pick "Web application." Do not do that.
gog starts a local HTTP server on a random port to receive the OAuth callback. Web application clients require the redirect URI to match exactly what is registered in the console. Since gog picks a different port every time (38683 one run, 46385 the next, 33797 after that) you will get redirect_uri_mismatch errors in an endless loop.
Desktop app clients do not enforce redirect URI matching. Pick Desktop. Save yourself twenty minutes of adding port after port to your Google Cloud settings and wondering why it still does not work.
Pitfall 2: The headless VPS problem
gog's default auth flow tries to open a browser. On a headless VPS, there is no browser. The command will print a URL and then sit there waiting for a callback that will never arrive because the callback goes to 127.0.0.1 on the server, not your laptop.
The solution is the --remote flag, which splits auth into two steps:
# Step 1: Generate the auth URL (on the VPS)
gog auth add you@gmail.com --services gmail,calendar,drive,contacts,sheets,docs --remote --step 1
# Step 2: After authorizing in your browser, paste back the redirect URL
gog auth add you@gmail.com --services gmail,calendar,drive,contacts,sheets,docs --remote --step 2 --auth-url "<the-url-from-your-browser>"
In step 1, gog prints an authorization URL. You open that in a browser on your local machine. Google asks you to sign in and approve permissions. After you approve, your browser redirects to something like http://127.0.0.1:38683/oauth2/callback?code=4/0Afr...&state=....
The page will not load and that is fine. Copy the entire URL from your address bar and feed it back to step 2.
Pitfall 3: Testing mode vs. published apps
If your Google Cloud project OAuth consent screen is in "Testing" mode, only email addresses explicitly listed as test users can authorize. If you are setting this up for a fresh Gmail account, you will hit "Access blocked: has not completed the Google verification process."
You have two options:
- Add your email as a test user in the OAuth consent screen settings.
- Publish the app (which removes the test user restriction).
I just published it. For a personal CLI tool that only you will use, there is no real downside.
Pitfall 4: The keyring password
This one blindsided me at the finish line. After successfully completing the OAuth dance, gog tried to store the token and failed:
store token: no TTY available for keyring file backend password prompt; set GOG_KEYRING_PASSWORD
On a headless server there is no terminal to prompt for a keyring password. The fix is to set the GOG_KEYRING_PASSWORD environment variable:
export GOG_KEYRING_PASSWORD="your-password-here"
You will want this in your shell profile or OpenClaw environment config so it persists across sessions.
Pitfall 5: Set GOG_ACCOUNT
Every gog command needs to know which account to use. Rather than passing --account you@gmail.com every time, set it once:
export GOG_ACCOUNT="you@gmail.com"
Without this, you will get auth errors that look like credential problems but are really just the tool not knowing which account you mean.
tldr
Once all of this is in place, gog is pretty seamless. Openclaw now has untethered access to my (dummy) Google account, and everything works as you would intend it to.