Can you help me setup gog for my agent to read gmail?

[tame lagoon]

I have the secret already

[sharp cloud]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[bright cedar]

Let me verify the right docs path, then I’ll give you the exact next step.

I found the version, good. I’m checking the local docs location so I don’t make up a config path.

If by “secret” you mean the Google OAuth client JSON file, then you’re close.

You generally do not put that into openclaw.json. gog handles the Google auth.

Next steps:

1. Register the OAuth credentials with gog

gog auth credentials /path/to/client_secret.json

2. Add your Google account with Gmail access

gog auth add [e-mail] --services gmail

3. Verify auth worked

gog auth list

4. Test Gmail directly, before involving the agent

gog gmail search 'newer_than:7d' --max 5

Then for OpenClaw:

• If your agent has unrestricted skills, having gog installed is usually enough.
• If you use a skills allowlist, add "gog" to that agent’s skills.

Docs:

• https://docs.openclaw.ai/tools/skills
• https://docs.openclaw.ai/gateway/configuration

Important detail: if you only have the raw client secret string, that is not enough. gog wants the full downloaded OAuth client JSON.

If you want, paste these and I’ll tell you exactly what’s missing:

• openclaw --version
• command -v gog
• gog auth list

[tame lagoon]

'C:\Users\prapunsak\AppData\Local\Microsoft\WinGet\Packages\steipete.gogcli_Microsoft.Winget.Source_8wekyb3d8bbwe\gog.exe' was blocked by your organization's Device Guard policy.
Contact your support person for more info.

[bright cedar]

That error is Windows policy, not a bad secret. Let me check whether there’s an officially documented Windows path for gog, so I don’t send you in the wrong direction.

Yep, that’s not a Google secret problem. Windows is blocking gog.exe itself.

Most likely:

• winget installed gog under your user AppData path
• your org’s Device Guard/AppLocker policy does not allow running it from there

Two important checks:

1. Where is OpenClaw actually running?
   gog only needs to be installed on the machine running the OpenClaw gateway/agent, not on the computer you’re chatting from.

2. If OpenClaw is running on this managed Windows machine, then Device Guard is the blocker. In that case your options are basically:

   • ask IT to allowlist/install gog
   • run OpenClaw on a different machine you control (Mac/Linux/home box/VPS)
   • use a machine without that policy

I also don’t see a documented Windows install path in the bundled gog skill, only Homebrew, so I would not keep fighting the winget/AppData route on a locked-down corporate PC.

Please paste these so I can tell which path makes sense:

openclaw --version
openclaw status

and tell me which machine is hosting OpenClaw.

[tame lagoon]

Do I need to put in any details for
Authorized JavaScript origins
Authorized redirect URIs
?

2026.4.22

@bright cedar
OpenClaw Version 2026.4.22

[bright cedar]

Nice, 2026.4.22 is current, so this is not a version problem.

The blocker is still the same: Windows Device Guard is refusing to run gog.exe.
That means OpenClaw itself is probably fine, but the Gmail helper binary cannot start.

What matters now is where your gateway is running:

• If OpenClaw runs on another machine: install and auth gog there, not on this Windows box.
• If OpenClaw runs on this managed Windows machine: you’ll need one of these:
  1. IT allowlists gog.exe / its install location
  2. move the gateway to a machine you control (Mac/Linux/home box/VPS)
  3. install gog in an org-approved path, if your IT policy allows that

Once gog can actually run, the setup is just:

gog auth credentials /path/to/client_secret.json
gog auth add [e-mail] --services gmail
gog auth list

So the next useful thing is not more OpenClaw config, it’s confirming the host.

Please paste:

openclaw status

and tell me:

Is the OpenClaw gateway running on this same Windows PC, or somewhere else?

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/configuration

[tame lagoon]

| Update | pnpm · up to date · npm latest 2026.4.22 |
| Gateway | local · ws://127.0.0.1:18789 (local loopback) · reachable 91ms · auth token · HQ-PS-N030 (10. |
| | 100.89.188) app 2026.4.22 windows 10.0.26200 |
| Gateway self | HQ-PS-N030 (10.100.89.188) app 2026.4.22 windows 10.0.26200 |
| Gateway service | Scheduled Task installed · registered · running (pid 18676, state Ready, Verified gateway |
| | listener detected on port 18789 even though schtasks did not report a running task.) |
| Node service | Scheduled Task not installed |
| Agents | 4 · no bootstrap files · sessions 36 · default main active 26m ago |
| Memory | enabled (plugin memory-core) · unavailable |
| Plugin compatibility | none |
| Probes | skipped (use --deep) |
| Events | none |
| Tasks | 0 active · 0 queued · 0 running · 20 issues · audit 1 error · 81 warn · 145 tracked |
| Heartbeat | 55m (main), disabled (aemeath), disabled (aemeath-cron), disabled (main-cron) |
| Sessions | 36 active · default gpt-5.4-mini (200k ctx) · 4 stores |

Item | Value |
+----------------------+-----------------------------------------------------------------------------------------------+
| OS | windows 10.0.26200 (x64) · node 24.14.0 |
| Dashboard | http://127.0.0.1:18789/ |
| Tailscale | off |
| Channel | stable (default)

[bright cedar]

That confirms it, your gateway is running on that same Windows PC (HQ-PS-N030).

So the problem is pretty clear now:

• OpenClaw itself is up
• but gog.exe cannot run on that machine
• and because the agent uses gog as an external binary, Gmail access will not work until Windows policy allows it

So this is not an OpenClaw config/version issue. It’s a Device Guard / AppLocker policy issue on the host running the gateway.

Your realistic options are:

1. Ask IT to allowlist gog.exe

   • ideally wherever they approve software to run from
   • if they can make gog runnable from a normal terminal, OpenClaw can use it

2. Move the OpenClaw gateway to another machine

• Mac, Linux, home PC, VPS, etc.
  • then install/auth gog there instead

3. Use an org-approved install path/package
   • only if your IT team supports that
   • I would not expect the current winget AppData install to work under strict policy

Once gog is runnable, the setup is just:

gog auth credentials /path/to/client_secret.json
gog auth add [e-mail] --services gmail
gog auth list

So the next test I’d do on that Windows box is simply:

where.exe gog
gog auth list

If gog auth list is blocked, that confirms the policy is the blocker.

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/configuration

If you want, I can help you pick the least painful path here, either “talk to IT” or “move the gateway off this machine.”

[tame lagoon]

Do I need to put in any details for
Authorized JavaScript origins
Authorized redirect URIs
?

[bright cedar]

I’m checking one thing quickly, whether gog has a better Windows install path than the winget/AppData one you hit.

Yep, this just reconfirms the same thing: your gateway is running on a managed Windows 10 machine, and Device Guard is the blocker.

So you’re not missing an OpenClaw config setting here. OpenClaw is up, but it cannot use Gmail until Windows allows gog.exe to run.

Best next steps:

1. Ask IT to allowlist or install gog.exe

   • ideally in an approved location like Program Files
   • your current winget install landed in AppData, which is commonly blocked by Device Guard/AppLocker

2. Once it runs, test it directly

   gog auth list
   gog auth credentials C:\path\to\client_secret.json
   gog auth add [e-mail] --services gmail
   

3. If IT won’t allow it, move the OpenClaw gateway to another machine you control, then install/auth gog there.

One useful data point, gog’s Windows install story still looks a bit rough upstream too, there’s even an open issue for it:

• https://github.com/steipete/gogcli/issues/157

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/configuration

If you want, I can help you draft the exact IT request so they know what to allow.

Short version: no, not for the normal gog setup.

For gog, you should create an OAuth client with:

• Application type: Desktop app

If you do that, you generally do not need to fill in:

• Authorized JavaScript origins
• Authorized redirect URIs

And you should not put your OpenClaw URL (127.0.0.1:18789) there.

What gog wants is the downloaded Desktop app client JSON, then:

gog auth credentials /path/to/client_secret.json
gog auth add [e-mail] --services gmail

Only fill Authorized redirect URIs if you are doing an advanced/custom auth flow, like:

• --redirect-host ...
• --redirect-uri ...
• proxy/tunnel/remote callback setup

In that case, the redirect URI must match exactly, for example:

https://your-hostname/oauth2/callback

But for the standard local flow, leave those blank and use a Desktop app client.

If you’re seeing those fields now, you probably chose Web application by mistake. I’d recreate the OAuth client as Desktop app.

Reference:

• https://github.com/steipete/gogcli
• https://docs.openclaw.ai/help/faq

If you want, send a screenshot of the Google OAuth client page and I’ll tell you if you picked the right client type.

[tame lagoon]

I use Web Application. is that wrong?

[bright cedar]

Yes, for the normal gog setup, Web Application is the wrong one.

Use:

• OAuth client type: Desktop app

That’s the one gog expects for the standard local auth flow.

So I’d do this:

1. In Google Cloud, create a new OAuth client
2. Choose Desktop app
3. Download the JSON
4. Run:

gog auth credentials /path/to/client_secret.json