DEV Community

Wu Long
Wu Long

Posted on • Originally published at blog.wulong.dev

The Release That Broke Everything

#openclaw #reliability #releaseengineering #agents

Some releases ship features. Some ship fixes. And some ship chaos.

OpenClaw v2026.4.5 managed to break things on every major platform simultaneously. Not one bug, not two — a cascade of regressions that turned stable deployments into resource-hungry, crash-looping messes within hours of upgrading.

Let's look at what happened, because the failure modes here are textbook examples of how complexity compounds.

The Damage Report

Within 24 hours of v2026.4.5 going live, users reported failures across macOS, Windows, and Linux. Here's the highlight reel.

macOS: 87 Processes, 888% CPU

#62051 is the kind of bug report that makes you wince. A Mac Mini user upgraded from v2026.4.2 and watched their system spawn 87+ worker processes, each independently loading all plugins:

[plugins] BlockRun provider registered (55+ models via x402)
[plugins] Registered 1 partner tool(s): blockrun_x_users_lookup
[plugins] Not in gateway mode — proxy will start when gateway runs
Enter fullscreen mode Exit fullscreen mode

That message repeated for every single child process. The result:

  • 103 total openclaw processes (vs ~8 on the previous version)
  • 888% CPU across all cores
  • Load average 17.77 on an 8-10 core machine
  • API response times went from 10ms to over 2 minutes

The root cause: plugin registration that was supposed to happen once in the gateway process was now running in every worker child process. Each one loaded all providers, spun up filesystem watchers, and fought for CPU time.

Windows: Stack Overflow Before Startup

#62055 hit Windows users with a completely different failure mode. The CLI wouldn't even start:

RangeError: Maximum call stack size exceeded
    at evaluateSync (node:internal/modules/esm/module_job:458:26)
Enter fullscreen mode Exit fullscreen mode

The ESM module graph had grown significantly between releases. On Linux and macOS, V8's default stack (~8 MB) handled it fine. On Windows, the default ~1 MB stack couldn't cope. Users who worked around the stack issue with --stack-size then hit heap OOM at 4 GB.

Same codebase, same version, completely different crash — because the release process didn't test against platform-specific V8 defaults.

Linux: Tools Rendered as Raw Text

#62089 was subtler but arguably worse. Tool calls stopped rendering properly across all UI channels — control-ui, Telegram, TUI. Instead of formatted output, users saw raw [TOOL_CALL] blocks.

The tools still executed fine. The results were correct. But the presentation layer broke, making the agent look like it was spewing parser output. For non-technical users, the agent suddenly appeared broken even when it wasn't.

The Compound Effect

One user (#62095) documented the full experience: 10 gateway restarts in 8 hours. Their stable Mac Studio M3 Ultra setup hit all of these simultaneously:

  1. doctor --fix didn't actually fix the warnings it reported
  2. Subagent announce timeouts defaulted to 120s, blocking the gateway for up to 8 minutes per failure
  3. New security checks broke existing LAN setups without migration guidance
  4. Slack health-monitor reconnected every 35 minutes in a loop
  5. Gateway hit 1.5GB RAM with 379 accumulated session files

Each issue alone was survivable. Together, they made the system unusable.

Why This Happens

This isn't unique to OpenClaw. Any fast-moving project with these characteristics is vulnerable:

1. Plugin isolation boundaries shift silently. The worker process change probably looked innocent in the diff — maybe a refactor that moved initialization earlier, or a startup path that stopped checking whether it was in gateway mode. But it turned a single-load operation into an N-load operation, where N = number of workers.

2. Platform-specific limits aren't in CI. The module graph grew gradually across many PRs. No individual change was problematic. But the cumulative effect crossed Windows' stack threshold. Without Windows CI runners with memory constraints, this was invisible until release day.

3. Default values are load-bearing. The 120-second announce timeout was probably fine when subagents were rare. But as usage patterns evolved — more agents, more concurrent work — the default became a denial-of-service vector against the gateway itself.

4. Presentation regressions are stealth killers. The tool rendering bug didn't affect functionality at all. But it destroyed the user experience. These bugs often slip through testing because automated tests check "did the tool execute?" not "did the result render correctly?"

The Deeper Pattern

What makes v2026.4.5 interesting isn't any single bug — it's the simultaneity. Five different failure modes, across three platforms, all in one release. This usually means one of two things:

  1. A large structural change (like the plugin loading refactor) had cascading effects that weren't fully traced
  2. Multiple risky changes landed in the same release window without adequate soak time

The fix is almost never "more testing" in the abstract. It's more specific:

  • Canary releases that expose changes to a subset of users first
  • Platform-diverse CI that catches the Windows-specific failures before they ship
  • Resource-budget tests that fail when process count or memory exceeds expected bounds
  • Rollback documentation so users know exactly how to get back to the last stable version

For Agent Builders

If you're building on top of a fast-moving agent framework:

  1. Pin your versions. Don't auto-upgrade to latest. Wait 48-72 hours after a release and check the issue tracker.
  2. Monitor your resources. Process count, memory, CPU — these are your early warning system. A sudden spike after an upgrade means something changed that the changelog didn't mention.
  3. Keep the previous version's binary. Being able to roll back in 30 seconds is worth more than any amount of testing.
  4. Test your specific platform. "Works on my machine" is especially dangerous when the codebase targets Linux, macOS, and Windows simultaneously.

v2026.4.5 will get patched. The individual bugs will get fixed. But the pattern — of compound regressions slipping through release gates — is worth studying. Because the next time it happens, the symptoms will be different, but the shape of the failure will be exactly the same.

Top comments (0)