Independent OpenClaw reporting, releases, guides, and community coverage
Releases

OpenClaw beta.4 Hardens Security: Token Rate Limits and Safer Config Parsing

OpenClaw v2026.5.31-beta.4 tightens gateway security with bootstrap-token rate limiting, unsafe OAuth lifetime rejection, and bound request timers across providers.

Filed under Releases 3 min read Updated Jun 3, 2026
OpenClaw beta.4 Hardens Security: Token Rate Limits and Safer Config Parsing

OpenClaw v2026.5.31-beta.4 isn't just a feature release — it ships a meaningful cluster of security improvements that address how the gateway handles untrusted input, token lifetimes, and network resource bounds. These changes won't make headlines the way MiniMax M3 does, but they matter a lot if you're running a public-facing or multi-user gateway.

Bootstrap Token Verification Is Now Rate-Limited

The most significant gateway-facing change: bootstrap-token verification is now rate-limited (#88314). Bootstrap tokens are the credentials used to pair new nodes and agents with a running gateway. Without a rate limit, a brute-force attack against the pairing endpoint was theoretically viable — especially on gateways exposed via Tailscale or a public URL.

Beta.4 adds server-side rate limiting to the bootstrap token check so that repeated failed verification attempts are throttled. If you're using OpenClaw's device-pair flow to connect mobile nodes or remote agents, this change is transparent — legitimate pairing succeeds normally. It only bites attackers making rapid guesses.

Unsafe Config Values Are Now Rejected at Parse Time

A new config validation layer in beta.4 rejects values that could be exploited to hang or starve the gateway. Specifically, the parser now flags:

  • OAuth and token lifetimes that are unreasonably long (preventing tokens from living indefinitely)
  • Retry-after delays with values outside safe bounds
  • Inbound timestamp skew that exceeds acceptable drift (preventing replay-style attacks)
  • Response body size limits that are too large to be safe
  • Command timeout config outside the acceptable range
  • Sandbox observer token TTLs that exceed the maximum

Previously, these values were accepted silently and could cause resource exhaustion or create windows for abuse. Now they fail loudly at startup with actionable guidance, before the gateway serves any traffic.

Gateway WebSocket Calls Guarded After Close

Beta.4 guards against WebSocket calls that arrive after the connection is closed at the gateway level. This closes a class of race conditions where a closing channel connection could trigger downstream processing that assumed the session was still live — leading to confusing partial state and log noise that obscured real errors.

Provider Request Timers Are Bounded Everywhere

A broader pass across provider and plugin code ensures that every provider request path has a bounded timeout — including:

  • Local service probes
  • Model catalog queries
  • Usage and quota checks
  • Queue polling
  • Generated media polling (image, music, video)
  • TTS and audio provider requests
  • Provider OAuth flows

Previously, some of these paths could hang indefinitely if a provider was slow or unresponsive, causing the whole gateway turn to stall. Beta.4 makes all of them time out and surface a recoverable error instead.

Auth Profiles Written Atomically

A subtle but important fix: auth profiles are now written atomically (#88731). Previously, a crash or interrupt during auth profile save could leave a partial or corrupt file, causing the next startup to fail in confusing ways. The new atomic write path eliminates that failure mode and adds a force re-login recovery path for cases where the profile is detected as corrupt.

Copilot OAuth Timeouts Capped

GitHub Copilot OAuth request timeouts are now explicitly capped before creating abort signals. This prevents a stalled Copilot device-code flow from blocking indefinitely — the gateway now gives up, reports the failure cleanly, and leaves the turn recoverable.

What This Means for Gateway Operators

If you're running OpenClaw on anything other than a single-user local install — shared family server, team gateway, VPS, anything accessible over a network — these changes meaningfully reduce your attack surface. The bootstrap rate limit in particular closes a real gap that previous releases left open.

For most users, no config changes are needed. The new validation will only break configs with genuinely dangerous values, and the error messages now point directly at what needs fixing.

To get these protections:

npm install -g openclaw@latest
openclaw doctor

Full changelog on GitHub.

Daily Briefing

Get the Open-Source Briefing

The stories that matter, delivered to your inbox every morning. Free, no spam, unsubscribe anytime.

Join 45,000+ developers. No spam. Unsubscribe anytime.