How to Use OpenClaw Gmail PubSub for Inbox Triggers

Gmail PubSub is the grown-up version of “check my inbox every few minutes.” Instead of polling Gmail from a cron loop, Gmail publishes inbox changes to Google PubSub, and OpenClaw receives those changes through its webhook and hook system. The official docs place Gmail PubSub under Scheduled Tasks because it is one of the ways external events can trigger agent work.

Use the wizard first

The recommended path is the OpenClaw setup command. It writes hooks.gmail config, enables the Gmail preset, and uses Tailscale Funnel for the push endpoint. That matters because Gmail push needs a public HTTPS endpoint; a private laptop URL will not work unless it is exposed safely.

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

Replace the example account with the mailbox you actually want to watch. After setup, the important documented behavior is automatic gateway startup: when hooks.enabled=true and hooks.gmail.account is set, the Gateway starts gog gmail watch serve on boot and auto-renews the watch. If you need to opt out temporarily, set OPENCLAW_SKIP_GMAIL_WATCHER=1.

Know the prerequisites before debugging

• gcloud CLI must be available for Google Cloud setup.
• gog / gogcli must be available for Gmail watch handling.
• OpenClaw hooks must be enabled.
• Tailscale is used for the public HTTPS endpoint in the documented wizard path.

Most Gmail PubSub failures are not model problems. They are endpoint, Google Cloud, or hook configuration problems. If messages are not arriving, check the push route and Google PubSub setup before changing prompts.

Manual setup shape

The manual docs are useful because they show what the wizard is really doing. You select the GCP project, enable Gmail and PubSub APIs, create the topic, grant Gmail push access, and start a watch for the account and label.

gcloud services enable gmail.googleapis.com pubsub.googleapis.com
gcloud pubsub topics create gog-gmail-watch
gcloud pubsub topics add-iam-policy-binding gog-gmail-watch \
  --member=serviceAccount:gmail-api-push@system.gserviceaccount.com \
  --role=roles/pubsub.publisher

gog gmail watch start \
  --account openclaw@gmail.com \
  --label INBOX \
  --topic projects/<project-id>/topics/gog-gmail-watch

Model override for inbox work

Gmail-triggered work does not always need your strongest model. The docs show a hooks.gmail model override with thinking: "off". Use that idea carefully: cheap triage is fine for classification and summaries, but approval-heavy or customer-facing replies should keep a safer model and human review in the loop.

{
  hooks: {
    gmail: {
      model: "openrouter/meta-llama/llama-3.3-70b-instruct:free",
      thinking: "off",
    },
  },
}

If you are turning Gmail-triggered automation into real operations instead of a demo, The OpenClaw Playbook is the shortcut I wish every operator had: identity files, memory rules, safety boundaries, channel discipline, and production habits in one field-tested guide.

Endpoint privacy

The public HTTPS endpoint is the part to treat carefully. Tailscale Funnel is convenient, but it is still exposing a webhook receiver for Gmail push traffic. Keep the hook route narrow, keep the OpenClaw hook config explicit, and avoid reusing that endpoint for unrelated experiments. If someone changes Tailscale mode or the public URL, run the Gmail setup again instead of patching scattered pieces by hand.

Operational test

Send one predictable email to the watched account, then verify that the event reaches the gateway before judging the agent’s answer. A broken watcher, disabled hook, or expired Google authorization will look like an agent silence from the outside. Split transport from reasoning first; only tune prompts after the Gmail change event is visible.

Runbook detail

For How to Use OpenClaw Gmail PubSub for Inbox Triggers, the important operator move is to record the exact documented surface you used and the condition that proves it worked. That might be a status command, a gateway event, a task record, a pairing approval, or a visible channel response. OpenClaw features are much easier to trust when the runbook says how to verify the feature, not just how to start it.