Three stable OpenClaw releases shipped between November 3 and November 8, 2026, and together they change what a one-person business can expect from its automations. v2026.10.10 lets an automation start when a connected service reports an event, instead of waiting for a timer. v2026.11.1 and v2026.11.2 then repair a set of cases in which reminders, schedules, emails and messages could be lost without an obvious error.
Automations can start from MCP events
The v2026.10.10 release notes present event-triggered automations as an alternative to waiting for a timer to check for changes. According to the MCP Events documentation, a remote MCP server filters changes and sends signed webhooks, and OpenClaw stores each event and runs the automation’s existing instructions, tool policy and delivery settings. The documentation states that events do not add a second scheduler and that the connected app view does not have to stay open.
The feature has limits that matter before anyone builds on it. It is opt-in, delivered through the bundled mcp-events plugin, and implements one profile of an experimental specification, the OpenAI webhook profile. Polling and push streams are not part of that profile. It also requires a public HTTPS callback. The documentation instructs operators to route only /plugins/mcp-events/callback/ to the Gateway and not to expose the Control UI, the Gateway WebSocket or other administrative paths. OpenClaw does not open a tunnel on the operator’s behalf.
This is separate from the inbound webhooks OpenClaw already offered, which use bearer authentication. MCP Events uses a signing secret for each subscription, and subscriptions run on finite leases that OpenClaw refreshes without calling a model.
What a received event does and does not promise
The documentation is direct about delivery guarantees. A successful webhook response confirms that OpenClaw stored the event. It does not confirm that the model finished or that output was delivered. MCP Events does not guarantee that every upstream event arrives, events can arrive out of order, and a source that offers no replay cannot resend what was missed. After a run has been handed off, OpenClaw does not automatically repeat it if the outcome is uncertain, because the run may have had side effects.
The documentation gives two recommendations for critical workflows: reconcile against the authoritative source and make write actions idempotent. It also recommends isolated runs for external comments and documents, and states that event content is untrusted data even when the signature is valid. For a solo operator, a sensible first use is a read-only job, such as summarizing a new comment, with results kept in run history. The documentation’s own example uses that design.
Downgrading needs planning. Older versions do not understand the event schedule type, so event jobs must be removed before moving back, and the target version’s database compatibility has to be checked against a copied state database.
Reminders and schedules that disappeared
The v2026.11.2 release notes, published November 8, describe a patch release with no new features, drawn from 113 pull requests and 53 direct commits. Several fixes address automations that stopped working without a clear signal.
Scheduled reminders could disappear if their text mentioned heartbeat polls or wakes (PR #129650), which is relevant to anyone using heartbeats alongside reminders. An automation could delete its own schedule and cancel its active run when its live ownership could not be confirmed, and that is now prevented (PR #167857). Retention cleanup no longer removes the sessions of running jobs in a selected custom store (PR #176745). Blank edit flags no longer leave old failure-alert destinations in place (PR #177681).
Two fixes have follow-up work. Scheduled announcements without an account could use the wrong conversation identity on a channel with a named default account, and the notes state that identities already recorded incorrectly are not repaired (PR #187637). Older scheduled jobs that need a stored inference account are repaired by Doctor, and operators who upgrade manually from source are told to run openclaw doctor --fix before startup.
v2026.11.1, published November 5, handled the scheduler’s startup and cancellation paths. Interrupted long-running jobs no longer prevent the scheduler from starting, and canceled runs stop reply hooks. Provider rate-limit cooldowns now follow the timing the provider specifies, rather than accumulating hours of local backoff.
Mail and messages that never reached the agent
Inbound channels received similar attention. The IMAP email trigger, which starts a separate agent session for each allowed message, could skip eligible mail after a temporary DNS failure during DKIM verification. v2026.11.2 fixes that, with limited retries, and messages must still pass authentication (PR #190439). Operators who run customer intake through a mailbox should note that the trigger does not backfill mail already present when monitoring begins, according to the same documentation page.
WhatsApp direct messages could be lost when a sender’s phone mapping arrived shortly after the message (PR #193052). Newly queued messages could be retried from a different sender after a channel’s default account changed, and older queued messages without a saved account cannot recover the original default (PR #191819). v2026.11.1 separately fixed conversations on Telegram, Discord and webhooks that stopped reaching the agent after request handlers or earlier turns finished. Channel setup is covered in this site’s guide to OpenClaw chat apps.
Logs and stored secrets
v2026.11.2 also reduces what OpenClaw writes to disk. It stops copying assistant replies into specific Gateway delivery and stalled-session logs, removes message previews from verbose iMessage logs, and fixes conditional config changes that recorded new secrets in local audit history (PR #191318). The notes state that existing audit records are not rewritten, so an operator who used those conditional options may want to review that history.
Practical steps for a one-person operation
The automations documentation provides the commands for an inventory. openclaw automations list shows the jobs, and openclaw automations runs with a job ID shows run history. openclaw cron remains an alias for the same commands.
- Update, following the guardrails described in this site’s report on update checks, and compare the job list with what is expected to exist.
- Check that recent announcements went to the correct conversation, because earlier incorrect identities are not repaired.
- Review any reminder that mentions heartbeats or wakes, and confirm it still exists.
- Check a mailbox-driven job against the mailbox itself for messages received during past DNS problems.
- Start event automations with read-only instructions and an isolated session, and confirm results in run history rather than relying on the webhook response.
The OpenClaw scheduling guide covers job design in more detail, and readers comparing OpenClaw with other agent systems can use the AI agent harness guide. MCP Events remains experimental, so its supported profile and setup steps may change in later releases.