EmailOctober 5, 20266 min read

Should You Connect OpenClaw to Gmail?

OpenClaw can watch Gmail through Pub/Sub, but it means your Google account, a public endpoint and untrusted mail in the agent loop. Here's when to do it and the safer default.

By Toan Nhu

Mermail explainer: should OpenClaw use your Gmail?

OpenClaw can watch a Gmail inbox and wake your agent the moment a message lands. It works, and the official setup is well documented. But the thing you are wiring up is your own Google account, a Cloud project, a public push endpoint and an agent that reads whatever strangers send you. For most OpenClaw builders, the better default is to give the agent its own inbox and keep Gmail for the human.

TL;DR — Connecting OpenClaw to Gmail means authorizing gog on your Google account, creating a Pub/Sub topic, exposing a push endpoint, and piping every new message into your Gateway. OpenClaw's own docs tell you to route that mail to a locked-down reader agent because it is untrusted. If the agent needs email to do its job (sign-ups, verification codes, vendor threads, replies), give it a dedicated Mermail inbox over MCP instead: openclaw skills install @mermail/mermail, then point OpenClaw at https://console.mermail.app/mcp. Free plan: 1 inbox, 1,000 emails/month.

What "connect OpenClaw to Gmail" actually sets up

People searching openclaw gmail or openclaw email usually want one thing: the agent should notice new mail and act on it. OpenClaw's supported path is Gmail Pub/Sub through gog (gogcli). The Gmail Pub/Sub guide describes the chain as Gmail watch, then a Pub/Sub push, then the gog gmail watch serve watcher, then an OpenClaw Gateway hook.

The one-time wizard does a lot on your behalf:

bash

openclaw webhooks gmail setup --account you@example.com

It needs the Gmail account already authorized in gog, which means an OAuth grant on that Google account
It authenticates gcloud, enables the Gmail and Pub/Sub APIs, and creates a topic and push subscription in a Google Cloud project
It starts a Gmail watch on a label (INBOX by default) that the watcher renews on a loop, every 12 hours by default
It needs an HTTPS endpoint Pub/Sub can reach; the supported route is Tailscale Funnel, or your own endpoint with --tailscale off --push-endpoint
It writes hooks.gmail into your config, turns hooks on, and the Gateway auto-starts the watcher on every boot
By default it forwards body snippets of each email (up to 20,000 bytes) into the hook payload

Full flag reference: openclaw webhooks CLI docs. None of this is wrong. It is just a lot of surface area attached to an account that also holds your personal or work mail.

OpenClaw's own docs treat Gmail as untrusted input

The clearest signal comes from OpenClaw itself. Before you run the wizard, the docs ask you to define a restricted mail_reader agent and a hook mapping that keeps Gmail traffic away from your main agent. The example config gives that reader a per-session sandbox, no access to the host workspace, a minimal tool profile, and denies filesystem, runtime, web, browser, cron and gateway tools. Its prompt template literally says to summarize the email as untrusted data and not follow links or instructions inside it.

That is the right instinct. An inbox is the easiest place on the internet for a stranger to put text in front of your agent. If the agent that reads your Gmail is also the agent that can run commands, browse or send, one crafted email is a prompt injection with your Google identity behind it.

What still breaks when the agent shares your Gmail

Even with the reader agent locked down, sharing a human mailbox causes problems that config cannot fix:

Blast radius: a noisy loop, a bad send or a compromised token touches the same Google account that holds your real mail, calendar and Drive
Identity: the agent has no address of its own, so verification codes, vendor replies and newsletters it signed up for all land in your human inbox
Scope: the gog OAuth grant covers the account, not just the threads the agent should see
Audit: when the mailbox is shared, you cannot cleanly answer what the agent read, labeled or sent this week
Exposure: you are running a public push endpoint and two separate tokens (hooks.gmail.pushToken and hooks.token) that you now have to protect and rotate
Lifecycle: adding a second or tenth agent means more Google accounts or more agents reading the same inbox

If you already connected OpenClaw to your primary Gmail for a demo, stop the watcher (unset hooks.gmail.account or set OPENCLAW_SKIP_GMAIL_WATCHER=1), revoke the gog OAuth grant in your Google account, and move the agent to its own mailbox before you leave it running unattended.

The alternative: give OpenClaw its own inbox

An agent inbox is a mailbox the agent owns: its own address, a receive path, an optional send path, and API or MCP access. There is no Google project, no Pub/Sub topic and no public tunnel. Your personal Gmail never enters the loop.

Mermail publishes an official OpenClaw skill on ClawHub and a hosted MCP server. Four steps:

1. Create a Free workspace at console.mermail.app and generate an API key.

2. Install the Mermail skill so the agent learns the right email workflows:

bash

openclaw skills install @mermail/mermail

3. Register the hosted MCP server with your API key:

bash

openclaw mcp set mermail '{"url":"https://console.mermail.app/mcp","transport":"streamable-http","headers":{"x-api-key":"'$MERMAIL_API_KEY'"}}'

4. Ask the agent to create its mailbox and check mail. Typical tools include create_mailbox, list_emails and get_email. If the agent only needs to receive (sign-up codes, vendor replies), use the receive-first profile https://console.mermail.app/mcp?profile=agent-inbox so send tools are not exposed at all.

Exact OpenClaw config keys can change between releases, so check the current OpenClaw MCP docs if a command errors. Background on the skill: OpenClaw × Mermail.

If you keep Gmail anyway, harden it

Some workflows really do need the agent to see a human inbox, such as summarizing your own mail. If that is you, follow the safe shape OpenClaw documents and go a little further:

Use a dedicated, non-primary Google account rather than the one that holds your work and personal life
Apply the restricted mail_reader agent and mapping before you run the setup wizard, because the wizard does not create them for you
Keep delivery off and the reader's tools minimal; let a separate, human-approved step do any replying
Set hooks.gmail.includeBody: false if subjects and senders are enough for the job
Redact setup output before sharing it, since it can contain your push and hook tokens
Run either the Gateway's auto-started watcher or openclaw webhooks gmail run, never both against the same listener

When Gmail is the right call

Connect Gmail when a human is the mailbox owner and the agent is an assistant reading over their shoulder: triaging your own inbox, drafting replies you send yourself, or summarizing a newsletter label. When the agent is the one signing up, receiving codes, talking to vendors or replying on its own, it needs its own address, and Gmail is the wrong tool.

Mermail fit (live plans)

From mermail.app/pricing:

Free, $0: 1 inbox, 1,000 emails/month, 1 GB storage, Agent Wallet payments; enough to prove the OpenClaw loop
Developer, $19/month: 5 inboxes, 10,000 emails/month, custom domains
Growth, $49/month: 10 inboxes, 20,000 emails/month
Enterprise, custom: dedicated IPs, SSO, custom limits

Next step

Open console.mermail.app, create a Free inbox, run openclaw skills install @mermail/mermail, and let your OpenClaw agent own its address. Your Gmail stays yours.

FAQ

Should you connect OpenClaw to Gmail?

Only when a human owns the mailbox and you follow OpenClaw's restricted reader setup. If the agent needs email to act on its own, give it a dedicated inbox so it does not share your Google identity, tokens or threads.

How does OpenClaw connect to Gmail?

Through Gmail Pub/Sub and gog. Gmail pushes new-mail events to a Pub/Sub topic, Pub/Sub calls the gog watcher on a public HTTPS endpoint, and the watcher forwards the message to an OpenClaw Gateway hook. The openclaw webhooks gmail setup wizard configures this for you.

Do I need Tailscale or a Google Cloud project?

For the Gmail path, yes: Pub/Sub lives in a Google Cloud project, and the supported push endpoint is Tailscale Funnel unless you bring your own HTTPS endpoint. A Mermail inbox needs neither, only an API key and the hosted MCP URL.

Can OpenClaw use Mermail and Gmail at the same time?

Yes. You can keep a restricted Gmail reader for your own mail and give the acting agent a Mermail inbox for sign-ups, verification codes and outbound threads.