What public OpenClaw incident reports taught operators in May through July 2026

July 25, 2026 · News · OpenClawBlog Team

An OpenClaw Gateway can report healthy while the next message is never dispatched. A package update can finish while the model route a user needs is broken. Between May and July 2026, public issue reports repeatedly described that gap.

This is not an incident-rate survey. The public record is a mixture of operator reports, maintainer investigations, and linked fixes. Some issues were marked as needing more information, and the reports do not prove that every installation or platform was affected. Their value is narrower: they show which checks were missing when a real workflow failed.

A green update is not a working update

In a May 12 beta-update audit, the Gateway was live after an upgrade from 2026.5.10-beta.1 to 2026.5.12-beta.2. Channels were connected, the updater reported success, and the plugin doctor found no issue. The first direct Codex/OpenAI smoke test still failed after the updater installed @openclaw/codex@beta; the report identified a missing module path. It also says that the Codex route had already been broken before the update, so this does not prove the update caused the original failure. It does show that the default checks did not cover the route the operator actually needed.

A separate May 24 Windows report described a different failure. After moving from 2026.5.20 to 2026.5.22, basic CLI commands took 30 to 60 seconds or appeared to hang. The reporter said a downgrade restored sub-second behavior and recorded the result across 12 attempts in that environment. That is useful evidence about one Windows setup, not a universal statement about the release.

Proposed check, not a test run: treat an update as accepted only after a before-and-after record includes the exact version, Gateway readiness, the provider and model route, one representative turn, and the channel path that matters. A successful updater command is evidence about the update process. It is not functional acceptance.

Rollback must include the state around the package

On May 21, issue #84809 reported that a 2026.5.19 update or backup flow removed ~/.openclaw/workspace. The workspace held memory files, scripts, local skills, and plugin configuration. A Time Machine restore brought the Gateway back, but the report still found a missing local plugin path and inconsistent managed npm peer links. In other words, restoring service did not automatically restore a consistent application state.

The report did not isolate the exact internal code path and was later closed as not planned. It should therefore be read as a documented operator incident, not as proof of a confirmed general defect. The operational point is still clear. OpenClaw's rollback and recovery documentation says that the automatic pre-update copy is a configuration safeguard, not a full-state recovery point. For a significant change, it recommends an independent, verified backup.

Decision criteria before an update:

• Can the package or version be rolled back independently?
• Can the workspace, transcripts, queues, skills, and plugin directories be restored?
• Can local plugin paths and package links be checked after recovery?
• Is the backup verified before the update begins?

If the answer covers only the package version, the recovery plan is incomplete.

Connected is not the same as delivered

A June 18 compaction report described a large session near the context limit. The report's logs show compaction attempts being abandoned after 60 seconds even when the provider returned a result after roughly 143 to 187 seconds. The result was discarded, the session reached overflow, and repeated retries consumed more work without repairing the conversation. The exact implementation details belong to that report; the broader operator risk is easier to state: a timeout can become a data and cost problem when the underlying operation continues.

In July, a Telegram durable-ingress incident described two group messages that were spooled during a Gateway restart but never dispatched. The report attributed the loss to a stale claim surviving a process-identity collision, followed by a global update-ID watermark rejecting delayed replays. Other chats continued to work, which made the incident harder to spot from a simple channel-connected check.

Proposed reliability check, not a test result: record each important message through the sequence accepted, queued, dispatched, delivered, and acknowledged. Alert on repeated incomplete compactions, overflow loops, delayed replays, and queue items that remain claimed without progress. A healthy process and a non-empty queue do not prove that work reached the user.

A silent state needs a visible owner

Another July 14 report, issue #107322, described a Gateway stuck in a draining state after restart. New agent work was rejected, while a cron heartbeat continued and durable ingress held Telegram updates. Restarting the container cleared the condition and allowed queued updates to replay. The report also identified an observability gap: the transition that closed admission was not logged, so the operator had no clear initiating event.

The public v2026.7.2-beta.1 release record, published July 15, listed fixes for Telegram durable-ingress loss, the restart admission wedge, stalled reply sessions, and one-shot cron lifecycle races. That shows how the incident records were translated into explicit recovery work. It was a prerelease, however. A release note is evidence that a fix was listed and tested in that release process, not proof that every stable installation had received it.

What belongs in the incident record

OpenClaw's operator incident-response guidance asks for a timestamp, host operating system and version, a redacted transcript or log tail, the action taken, and the exposure boundary. Those fields are useful for availability incidents too, even when there is no sign of compromise.

Proposed report packet:

• Exact OpenClaw version or commit, installation method, operating system, and runtime.
• The last known-good event and a timestamped failure sequence.
• The provider, model, channel, session, queue, or message identifiers involved.
• What passed before and after the failure, including rollback, restore, or restart results.
• Redacted logs and configuration differences, with secrets kept out of the report.

This makes a report more than a symptom. It lets another operator distinguish a package regression from a pre-existing route failure, a delayed operation from a lost message, and a recoverable state from a silent wedge.

What the reports do not prove

These incidents do not establish how often the failures occurred, whether they affected all platforms, or whether the reported root causes were independently reproduced in every environment. The Windows issue, for example, describes a specific setup and carries review labels. The workspace report documents damage and recovery work but does not isolate the internal deletion path. The compaction report records a timing pattern, not a benchmark for every provider.

The safer conclusion is practical. Before calling an OpenClaw installation healthy, verify the version, run the real model path, confirm that state survives the change, observe work through delivery, and keep a tested recovery route. If one of those checks is missing, the system may still be usable, but its health claim is partial.

Sources

• Beta audit: 2026.5.10-beta.1 to 2026.5.12-beta.2 update findings
• Data-loss report concerning the 2026.5.19 update and backup flow
• CLI hang report for OpenClaw 2026.5.22 on Windows
• In-turn compaction timeout and retry-storm report
• Telegram durable-ingress message-loss report after restart
• Gateway permanently stuck draining after restart
• OpenClaw rollback and recovery documentation
• OpenClaw operator incident-response guidance
• OpenClaw v2026.7.2-beta.1 release notes