OpenClaw 2026.4.21 Release: Better Image Generation, Safer Commands, and Under-the-Hood Fixes

OpenClaw’s v2026.4.21 release landed on April 21, 2026. It doesn’t introduce flashy new features, but it fixes several practical pain points: upgrading the default image‑generation model, making plugin dependencies recoverable, tightening command permissions, keeping Slack messages inside their intended threads, speeding up browser automation, and cleaning up npm install warnings.

If you’re running OpenClaw as a gateway or automation hub, this release matters. Let’s walk through each change – what changed, why, and how it affects you.

1. Image Generation: Defaults to gpt-image-2 with 2K/4K Size Hints

What changed?

Previous versions used an older default image model. Starting from 2026.4.21, the bundled image‑generation provider and the live media smoke tests both default to gpt-image-2 (OpenAI’s newer model).

At the same time, the documentation and tool metadata now explicitly advertise 2K and 4K size hints. When you call the image API, you can simply ask for “2K” or “4K” quality without calculating pixel dimensions.

Why this change?

gpt-image-2 produces better detail, style consistency, and higher resolution compared to older models. Switching the default gives new users a better out‑of‑box experience.

Standardising 2K/4K hints reduces guesswork. Instead of typing width=2560&height=1440, you can write size="2K" – the tooling maps it to the correct pixel dimensions.

What does this mean for you?

  • If you never manually configured the image provider, upgrading automatically switches you to gpt-image-2.
  • If you explicitly set another model in your config, this update does not override your choice.
  • Internal smoke tests (live media) now use the same model, so testing matches production.
  • Documentation will start showing 2K / 4K as valid size hints – use them directly.

What if generation fails?

The release also improves logging. When a provider or model candidate fails to generate an image, OpenClaw now writes a warning‑level log – naming the failed candidate and the reason – before falling back to the next available provider.

Previously, intermediate failures were invisible unless all candidates failed. Now, even when a later provider succeeds, you can see in the gateway log which earlier attempts failed. This is a big help for debugging API keys, rate limits, or network glitches.

2. Plugin Dependencies: doctor Can Recover Runtime Dependencies

The problem

OpenClaw has a plugin system. Some plugins depend on external channel adapters (e.g., Discord, Telegram) or specific providers (OpenAI, Google). In a packaged install (binary, deb, rpm), if a plugin’s runtime dependency is missing, the old workaround was to install a whole set of core dependencies globally – which is messy and often overkill.

What’s fixed?

The plugins/doctor subcommand has been updated. Running openclaw doctor now:

  1. Checks each enabled plugin’s runtime dependencies.
  2. Automatically installs only the missing dependencies, using the correct path information from the packaged environment – without pulling in the entire core dependency set.

In plain English: you used to need a whole toolbox to replace one missing screw. Now doctor gives you just that screw.

Real‑world use case

Imagine you installed OpenClaw from a binary package, then enabled a plugin that requires @slack/web-api. If that dependency wasn’t bundled (or was skipped due to version conflicts), the old doctor might suggest npm install -g with a long list of packages. Now it pinpoints the plugin’s directory and installs only the missing package.

This is especially useful for production and containerised deployments, where you don’t want to keep a full Node.js toolchain around.

3. Security Fix: Owner‑Only Commands No Longer Bypassed by Regular Users (#69774)

The vulnerability

This is the most important security fix in this release, reported and fixed by contributor @drobison00.

OpenClaw has a class of commands marked owner‑enforced – for example, shutdown, reload config, plugin install. To decide who can run them, the system checks:

  • Whether the sender’s identity matches the configured owner list, or
  • Whether the sender has the internal operator.admin role.

But the old logic had a dangerous fallback:

When enforceOwnerForCommands=true (the recommended secure setting) but commands.ownerAllowFrom was not set, the system mistakenly treated a wildcard allowFrom or an empty owner‑candidate list as “allow anyone”.

That meant a configuration like:

enforceOwnerForCommands: true
# commands.ownerAllowFrom is absent

…could let any user – including a random chat member who is not an owner – execute owner‑only commands. That’s a privilege escalation.

What’s changed in 2026.4.21?

  • A clear owner identity match (user ID in the owner list, or operator.admin role) is now strictly required for owner‑enforced commands.
  • An empty owner‑candidate list or a wildcard allowFrom is no longer sufficient.
  • If you really want to let everyone run a specific owner command, you must explicitly configure commands.ownerAllowFrom: ["*"] – and understand the security implications.

What you need to do

  • Review your config. If enforceOwnerForCommands is true, make sure the owner list is not empty, or commands.ownerAllowFrom has an explicit value.
  • If you previously relied on “no config means everyone can run owner commands”, you will need to add an explicit whitelist after upgrading.
  • Check your logs for any unexpected command executions from non‑owner users.

4. Slack Integration: Preserve Thread Aliases, Keep Messages in the Right Thread (#62947)

The symptom

When you send a message to Slack through OpenClaw and want it to land in a specific thread, you normally provide a threadTs parameter. In previous versions, the runtime system could lose that threadTs alias during forwarding or processing – causing the message to go to the parent channel instead of the intended thread.

Contributor @bek91 found and fixed this.

What’s fixed

Now, when the caller (e.g., an automation script or another plugin) supplies threadTs in an outbound message, the Slack adapter preserves the value and uses it correctly in the final API call.

The fix applies to both:

  • Messages sent via runtime.send
  • Messages generated internally by the gateway and delivered to Slack

Value for Slack users

This matters if you use OpenClaw for things like:

  • Sending monitoring alerts into an existing Slack discussion thread to keep context together
  • Having multiple bot replies appear inside the same thread instead of scattered
  • Bridging messages from other platforms into Slack threads

After upgrading, you no longer need extra workarounds to “re‑associate” threads.

5. Browser Automation: Invalid Accessibility Refs Fail Fast, Not on Timeout (#69924)

Background

OpenClaw includes a browser automation module that lets you interact with web pages using act commands (click, fill, read). One way to locate elements is via accessibility tree references, like ax1, ax2. These come from the browser’s accessibility API.

The problem

If you wrote an act path with a non‑existent accessibility reference – for example, ax99 when the page only has up to ax5 – the old OpenClaw would wait until the browser action timed out (often tens of seconds) before failing. That slowed down automation scripts dramatically, especially in batch operations or error‑handling flows.

What’s changed

From 2026.4.21, the system immediately validates any ax<N> reference against the current page’s accessibility tree. If the reference doesn’t exist, it rejects the act step right away and returns a clear error – no waiting for a timeout.

This fix was contributed by @Patrick-Erichsen.

Practical advice

  • If you write your own browser automation scripts, you’ll now find element‑locating mistakes much faster.
  • If you let an LLM generate act paths, the immediate error feedback helps the model correct itself quickly.
  • Note: this applies only to ax<N> references. Other selectors (CSS, XPath) behave as before.

6. npm Installation: Silence node-domexception Deprecation Warnings

Where did the warning come from?

When installing OpenClaw with npm, some users saw warnings like:

npm WARN deprecated node-domexception@1.0.0: Use your platform's native DOMException instead

This warning came from a deep dependency chain:

google-auth-library → gaxios → node-fetch → fetch-blob → node-domexception

node-domexception is an old package that simulated the browser’s DOMException in early Node.js versions. Now that Node.js natively supports DOMException, the package is deprecated. The warning didn’t break anything, but it cluttered install logs.

How was it fixed?

OpenClaw added an overrides field in the root package.json, aliasing node-domexception to a no‑op placeholder. When npm resolves the dependency tree, it skips the deprecated package and no longer prints the warning.

Contributor @vincentkoc handled this.

Impact on you

  • Running npm install for OpenClaw no longer shows the node-domexception deprecation warning.
  • No functional impact – the native DOMException is used instead.
  • If you maintain a derivative project based on OpenClaw, you can use the same override pattern as a reference.

FAQ

How do I check my current OpenClaw version?

Run:

openclaw --version

Or look at the first line of the gateway startup logs.

Which commands are “owner‑enforced”?

It depends on your plugins and configuration. Typical examples:

  • shutdown
  • reload
  • plugin install / uninstall
  • exec (if enabled)

You can customise owner‑only commands via commands.ownerOnly.

After upgrading, image generation stopped working. What should I do?

First, check the gateway logs for warning‑level messages about gpt-image-2 failures. The cause could be insufficient API key permissions or exhausted quota. You can temporarily fall back to a previous model in your config:

imageGeneration:
  provider: "openai"
  model: "dall-e-3"

Does the Slack thread fix require me to change my code?

No. As long as your calling code correctly passes the threadTs field, the fix works automatically after upgrading. If you previously used a workaround (e.g., manually linking messages in text), you can now simplify it.

What are ax references in browser automation?

ax stands for Accessibility Tree. The browser assigns temporary IDs to accessible elements, like ax1, ax2. You can write act ax1 click to click that element. After the fix, a non‑existent ax99 will fail immediately.

Why do I still see npm warnings after upgrading?

Make sure you are using OpenClaw v2026.4.21 or later. If you built from source, delete node_modules and package-lock.json and reinstall. If warnings persist, they may come from a different dependency chain – but the main node-domexception warning is gone.

How to Upgrade to This Version

Docker

Pull the latest image and restart:

docker pull openclaw/openclaw:v2026.4.21
docker stop openclaw
docker rm openclaw
docker run -d --name openclaw -v ./config:/config openclaw/openclaw:v2026.4.21

npm global install

npm update -g @openclaw/core

Binary packages (Linux / macOS)

Download the archive for your platform from the GitHub Releases page and replace the existing executable.

Recommended post‑upgrade steps

  • Run openclaw doctor once to check plugin dependency status.
  • Review your logs for any unexpected permission denials (if non‑owners were previously calling owner commands, they will be rejected after upgrade).
  • Test your Slack threading and image generation calls.

Summary Table

Area Problem Fix Affected users
Image generation Old default model, unclear size hints Default to gpt-image-2, document 2K/4K All users generating images
Logging Image failure intermediates invisible Add warn‑level logs for each failed candidate Anyone debugging image issues
Plugin dependencies Hard to recover missing runtime deps in packaged installs doctor installs only missing deps Users with plugins in constrained environments
Security Non‑owners could bypass owner‑only commands Strict owner verification, remove dangerous fallback All users with enforceOwnerForCommands=true
Slack threadTs alias lost, messages go to wrong thread Preserve threadTs in outbound sends Users sending messages to Slack threads
Browser Invalid ax references cause long timeouts Immediate validation and rejection Users doing browser automation
npm install node-domexception deprecation warning Override to silence the warning Anyone installing via npm

Final Thoughts

OpenClaw 2026.4.21 is a classic stability and security maintenance release. It doesn’t add shiny new features, but it solves several annoying, real‑world problems: a privilege escalation hole, hard‑to‑fix plugin dependencies, missing log visibility, wayward Slack threads, wasteful automation timeouts, and noisy install warnings.

If you value production reliability and maintainability, this upgrade is worth it. It’s especially valuable for heavy Slack users, browser automation scripts, and anyone exposing OpenClaw to multiple users.

After upgrading, pay attention to owner‑command permission logs to ensure expected behaviour. If you run into any issues, the OpenClaw GitHub Issues is the place to report them – the community maintainers are usually quick to respond.