OpenClaw v2026.5.3-1: Plugins/security, what to verify

A release page is most useful when its claims can be traced. For v2026.5.3-1, the source points to an access, approval, or trust-boundary change. The notes below separate what the project says from the result you should measure on your own installation.

Stable status describes the release line, not every local provider or channel. Check the version-specific notes before upgrading. Treat the version as one input to the decision. Local credentials, enabled plugins, channels, and host support still need their own evidence.

Evidence to keep

01 / Plugins/security

Source signal. stop the install scanner from blocking official bundled plugin packages when process.env access and normal API sends only appear in distant parts of the same compiled bundle.

The useful evidence for Plugins/security is the refusal path as well as the success path. Use synthetic credentials and record the policy that made each decision.

Changes and fixes worth comparing

Read the narrow change in context

v2026.5.3-1 is a stable checkpoint with a deliberately small surface. The source names Plugins/security: stop the install scanner from blocking official bundled plugin packages when process.env access and normal API sends only appear in distant parts of the same compiled bundle. A narrow patch still has a clear job: it should remove one failure or preserve one compatibility promise without changing unrelated configuration.

Keep this patch beside the evidence for the release line. Compare the installed tag, package version, and service owner before applying it. If this entry is a correction release, record the broken behavior that led you here, then repeat that exact scenario after the update. That evidence is more useful than a general claim that the package installed successfully.

The adjacent source detail is Plugins/security: stop the install scanner from blocking official bundled plugin packages when process.env access and normal API sends only appear in distant parts of the same compiled bundle. Read both signals together, because a hotfix can alter the boundary around a plugin, channel, session, or installer even when the version number looks like a minor suffix.

A small worksheet for this version

• Write the old version, the new version, and the package or tag that actually changed.
• Capture one reproduction before the update and the same reproduction after it.
• Record the first useful log line, the final user-visible result, and any rollback command that was tested.
• Leave unrelated channels, skills, and provider defaults untouched until the correction is understood.

Run the smallest useful rehearsal

1. Write down the baseline for Plugins/security, including the installed version, host, provider, and workspace.
2. Confirm what can be restored, then take a verified backup before applying the candidate package.
3. Try the boundary with synthetic data from inside and outside the permitted scope, then save the effective policy.
4. Leave the production policy unchanged until both the accepted and refused results have been reviewed.
5. Keep the experiment bounded; an unexpected result belongs in the release record before any wider rollout.

openclaw --version
openclaw gateway status
openclaw security audit

Leave a usable maintenance note

Save the command, output, source link, and environment used for this check. Future operators should be able to tell whether a difference belongs to the release or to local provider, channel, or platform state.

Keep the full v2026.5.3-1 notes with your test result. Read the official release index for neighboring versions and the Gateway security guide for configuration limits.