OpenClaw v2026.5.24-beta.1: Perf, boundary review

The security lens for v2026.5.24-beta.1 is its trust boundary. The official record describes an access, approval, or trust-boundary change; this reading keeps the exact tag visible and turns the source bullets into checks an operator can actually repeat.

Pre-release status matters here: stage the tag beside the stable package and do not infer support for every account or platform. A release tag describes the project change. Your Gateway's provider, channel, platform, and account support should be recorded separately.

Boundary review

01 / Gateway/perf

Source signal. reuse process-stable channel catalog reads, avoid repeated bundled-channel boundary checks, and rotate gateway watch CPU profiles so benchmark runs do not accumulate unbounded artifacts.

The operator question around Gateway/perf is where the reply lands after a restart. Record the conversation identifiers before testing and compare them after the channel is healthy again.

02 / Gateway/perf

Source signal. cache stable install-record, channel-catalog, bundled-channel, and Telegram session-store metadata during process-local hot paths to reduce repeated JSON and manifest reads.

For Gateway/perf, delivery is only proven when identity survives an interruption. Keep a disposable channel, send one request, and check for a single reply in the intended thread.

03 / Gateway/perf

Source signal. reuse immutable plugin metadata snapshots across startup, config, model, channel, setup, and secret metadata readers so hot paths avoid repeated plugin file stats and manifest registry reloads.

Read Gateway/perf as an authorization checkpoint: prove who may act, what the action can reach, and how the rejected attempt is surfaced to the operator.

04 / Gateway/update

Source signal. avoid fetching unrelated tags during dev-channel git updates so moved release tags do not block branch-based updates.

The operator question around Gateway/update is where the reply lands after a restart. Record the conversation identifiers before testing and compare them after the channel is healthy again.

What the implementation list adds

MiniMax

store OAuth token expiry as an absolute millisecond timestamp so OAuth profiles no longer appear expired on every request.

Treat MiniMax as a boundary change. Exercise one permitted request and one refused request with a test identity, then keep both decisions in the log.

Operator checklist before rollout

1. Before touching persistent state, capture the version, host, provider, and workspace for Gateway/perf.
2. Read the linked release record and verify a backup whenever the change can alter configuration or session data.
3. Interrupt one delivery after admission, reconnect the transport, and compare the final reply with the original conversation.
4. Force a short transport interruption and verify that retry or recovery preserves the original thread and sender.
5. Close the test with the evidence attached, and do not widen the rollout while a behavior remains unexplained.

openclaw --version
openclaw gateway status
openclaw security audit

Keep the source trail attached

Close the loop with an explicit next action: keep the candidate isolated, proceed with the staged upgrade, or stop and investigate. Do not treat a green install as proof that the runtime path is correct.

Regression cases from the source

Gateway/update. avoid fetching unrelated tags during dev-channel git updates so moved release tags do not block branch-based updates. Treat the fix as a boundary condition and retain the source wording beside your local result.

MiniMax. store OAuth token expiry as an absolute millisecond timestamp so OAuth profiles no longer appear expired on every request. Keep the reproduction and the post-fix result together in the acceptance record.

This page is a practical reading of the v2026.5.24-beta.1 source record; the release index and Gateway security guide remain the references to use for migrations and support boundaries.