IMAP Email Trigger

The bundled IMAP plugin watches an existing mailbox and starts a separate, isolated agent session for each allowed incoming message. Official docs: it does not send mail, modify flags, expose a public webhook, or backfill messages already in the box when monitoring starts.

Configure a restricted reader agent before you enable the plugin. Authoritative setup: docs.openclaw.ai/automation/imap. v2026.10.9 fixed IMAP sender checks that accepted a trusted address hidden in nested comments in the From header (Nodemailer 10.1.4).

Why this is not Gmail PubSub

The plugin talks to the Gateway’s trusted email dispatcher. It does not need hooks.enabled, Google Cloud, Tailscale Funnel, or a public HTTP endpoint. agentId, sender policy, and the restricted reader are the boundary. HTTP-hook allowlists are not.

Safe defaults

  1. Create a dedicated reader agent. Do not reuse the agent that has shell on your homedir.
  2. Set hostname, username, and a sender allowlist. Tokens in env, not in the YAML. Credentials.
  3. Require a sandbox backend and an authenticated model, as the official page states.
  4. Upgrade to 10.9 so spoofed From headers with nested comments fail. Mail you used to accept may now be dropped—that is the fix. Confirm the real address, not a comment.

Sending mail is a different tool

IMAP trigger is inbound only. Bundled Himalaya (or similar) skills are a separate outbound/read CLI path. Audit those like any skill: skills audit.

Related