The 2026.4.29 release train is one of those OpenClaw updates where the changelog is too large to read linearly.

There is the final release, plus four betas:

Taken together, the owner-level story is not “many fixes.”

It is this:

OpenClaw is getting better at staying responsive when real work, real memory, real channels, and real plugins pile up.

That is the category that matters once your assistant stops being a toy and starts living in your actual operating loop.

TL;DR

After updating to 2026.4.29, most OpenClaw owners should care about six things:

  1. Active conversations should steer better — follow-up messages now default toward steering the active run instead of becoming awkward queued side traffic.
  2. Visible replies are becoming enforceable — operators can require source chats to use message(action=send) for visible output, reducing silent group-chat completions and accidental reply routing.
  3. Memory is becoming more operator-grade — people-aware wiki metadata, per-conversation Active Memory filters, partial recall on timeout, and REM preview diagnostics make memory more inspectable and less all-or-nothing.
  4. Slow hosts should feel less broken — startup, status, TUI, plugin runtime-deps, model catalogs, stale sessions, and event-loop diagnostics all got practical reliability work.
  5. Channels got a lot of boring-but-important hardening — Slack Block Kit limits, Telegram send/polling/webhook/proxy paths, Discord startup/rate limits, WhatsApp liveness, Matrix/Teams/Feishu edges, and media delivery all moved toward fewer stuck turns.
  6. Model/provider/security boundaries are stricter — NVIDIA is bundled, Codex/OpenAI-compatible behavior is safer, local model checks are less hostile, and tool/security policy got sharper defaults.

The normal upgrade move still applies:

openclaw update
openclaw doctor --fix

Then test the loops you rely on: active chat follow-ups, memory recall, your main channels, your default model, cron jobs, and any plugin-heavy startup path.

1. Active runs are easier to steer instead of interrupt

One of the most important changes is deceptively simple: active-run queueing now defaults toward steer.

That means follow-up messages can be drained at the next model boundary instead of sitting in a legacy one-at-a-time queue pattern.

If you use an assistant in real chat, this matters constantly.

Humans do not wait for the perfect moment to add context. They send:

  • “Actually use the staging URL.”
  • “Don’t delete that file.”
  • “Also check Telegram.”
  • “Ignore the previous bit, I found the error.”

The assistant should not treat every one of those as a separate future turn if the active run can still use the correction.

2026.4.29 moves OpenClaw closer to that behavior.

It also adds spawnedBy metadata on subagent chat and broadcast payloads, which makes child-session routing cleaner for clients. That is less visible day to day, but important if you run multi-agent workflows where spawned work needs to report back to the right parent context.

The owner takeaway: busy conversations should feel less like a brittle command queue and more like a steerable work session.

If you rely on long-running turns, test this after updating:

  • send a normal request,
  • add a correction while it is running,
  • verify the correction affects the same run or lands predictably after it.

2. Visible reply routing is becoming a real control surface

OpenClaw has a subtle but important distinction:

  • an assistant can produce a final answer in its private runtime context,
  • or it can explicitly send a visible message to the source chat.

In private one-on-one sessions, those can feel the same.

In group chats, Discord/Slack-style surfaces, Telegram topics, native commands, and automation runs, they are not the same at all.

2026.4.29 adds a global messages.visibleReplies control so operators can require visible output to go through message(action=send), while the existing group-chat override remains available.

That pairs with fixes for group-chat prepared dispatch paths where a turn could complete without a visible reply if the message tool was unavailable.

This is very operator-relevant.

A silent completion is one of the worst failure modes for an assistant. The model “finished,” but the human saw nothing. Now you are debugging the wrong layer.

For owners, the useful question is:

Where should replies be visible by default, and where should the assistant stay private unless it explicitly sends?

That is not a cosmetic setting. It is a trust boundary.

After updating, I would test your primary group-chat flow and one native command flow. Make sure success, failure, approvals, and media replies all appear where you expect.

3. Memory is getting more inspectable, not just bigger

The memory work in this release is substantial.

The headline is people-aware wiki metadata: canonical aliases, person cards, relationship graphs, provenance reports, evidence drilldowns, and better search modes for person lookup and question routing.

That is the kind of memory feature that can easily become too magical if it is not inspectable.

The good sign in this release is that the memory direction is not just “recall more.” It is:

  • recall with provenance,
  • filter recall by conversation,
  • return partial recall when the hidden memory sub-agent times out,
  • preview bounded REM dreaming output through a read-only doctor RPC,
  • reduce noisy generated wiki search hits,
  • prefer readable body snippets over generated metadata.

That is the right shape.

For an agent owner, memory is only useful if you can answer three questions:

  1. Where did this claim come from?
  2. Should this conversation have access to that memory?
  3. If recall times out, did we get something useful or nothing at all?

2026.4.29 improves all three.

The per-conversation Active Memory filters are especially practical. Broad memory recall in every context is risky. A group chat, a personal DM, a customer support thread, and a background task should not automatically share the same recall surface.

After updating, check your memory config if you use Active Memory heavily. Make sure broad sessions, group chats, and sensitive conversations have the recall behavior you actually want.

4. Slow-host startup got serious attention

A lot of this release is about the pain you only feel when running OpenClaw on real infrastructure.

Not a clean laptop demo. A VPS. Docker. CapRover. Windows/WSL. Low-core hosts. Plugin-heavy installs. Local models. Slow filesystems. Restarts after package updates.

The release hits that from several angles:

  • local clients wait for event-loop responsiveness before opening Gateway WebSocket connections,
  • gateway.handshakeTimeoutMs is configurable and default preauth timeouts are higher,
  • startup can return retryable UNAVAILABLE during the sidecar window instead of surfacing terminal handshake failures,
  • status/doctor paths avoid expensive channel summary and plugin runtime work when they only need liveness,
  • model catalogs can serve the last successful catalog while stale reloads refresh in the background,
  • packaged plugin runtime-deps get better mirrors, locks, stale-root pruning, and repair paths,
  • version-scoped update caches reduce stale compiled chunks after package updates,
  • /readyz can expose event-loop diagnostics so “slow” becomes observable instead of vibes.

This is the section I care about most.

When OpenClaw starts slowly, the user-facing symptom is usually misleading. It looks like auth failed, the gateway is unreachable, the TUI hung, Discord is dead, Telegram is silent, or a plugin broke.

Often the real problem is simpler: the process is alive but overloaded, blocked, warming caches, scanning plugin metadata, repairing runtime deps, or waiting on slow local control-plane reads.

2026.4.29 makes more of those states survivable and diagnosable.

The owner checklist here is simple:

  • run openclaw status,
  • run the deeper status/doctor path you normally use,
  • restart the gateway once,
  • watch whether channels reconnect without manual babysitting,
  • and check whether slow startup now reports degraded/retryable states instead of pretending the gateway is dead.

5. Channels got less fragile in the places people actually feel

The channel fixes are broad, but the theme is consistent:

do not let one platform edge case wedge the assistant.

Slack got a lot of Block Kit hardening: button/select limits, fallback text caps, approval metadata caps, long command menus, overlong URLs, and merged message-tool presentation blocks.

Telegram got durable streaming edits, bounded Bot API calls, proxy handling, webhook and polling liveness warnings, safe-send retries, topic/session metadata fixes, native command and exec approval improvements, and fewer duplicate-looking draft transitions.

Discord got startup/rate-limit handling, duplicate monitor suppression, better DM policy resolution, long CJK chunking, thread/session resolution, command privacy routing, and less “stuck in processing” behavior around Codex/ACP flows.

WhatsApp got stronger liveness signals, reconnect behavior, outbound delivery verification, pairing verification constraints, and better handling of unstable network sessions.

Matrix, Teams, Feishu, Signal, iMessage, and other surfaces got their own edge-case cleanup too.

It is not glamorous. It is exactly what chat-native software needs.

For OpenClaw, channels are not just notification adapters. They are the product surface. A channel bug is not “just integration work”; it is the assistant failing to show up.

After updating, test the channel that matters most to you with:

  • a normal text reply,
  • a long reply,
  • a file/media flow,
  • an approval or command flow,
  • and one restart/reconnect cycle.

That is more useful than reading every channel bullet in the changelog.

6. Models and security boundaries got sharper

There are two important model/provider stories.

First, NVIDIA is now a bundled provider with API-key onboarding, setup docs, static catalog metadata, and literal model-ref picker support. Bedrock Opus 4.7 thinking support improved. Codex/OpenAI-compatible streaming and replay paths got safer. Local models got less hostile fixed-size preflight behavior.

Second, model routing is getting more explicit.

The release fixes several cases where stale configs, missing credentials, auth-profile overlays, fallback behavior, or provider-specific quirks could make the selected runtime differ from what an owner thought was running.

That matters.

For agent operations, “it answered” is not enough. You need to know which provider answered, which runtime executed, whether a fallback was intentional, and whether a stale model entry is being quietly revived.

Security got a similarly practical pass:

  • restrictive tool profiles no longer get widened implicitly just because tools.exec or tools.fs is configured,
  • OpenGrep scanning was added to first-party code workflows,
  • owner allowlists and DM-open semantics were tightened across channels,
  • exec/elevated approval provider checks were fixed,
  • pairing/bootstrap scopes were bounded,
  • workspace PATH and npm exec-path injection risks were blocked,
  • outbound runtime scaffolding gets stripped before channel delivery.

The owner takeaway: 2026.4.29 may expose configs that were relying on loose defaults.

That is good.

If a restricted messaging profile suddenly needs explicit alsoAllow, or a stale model ref stops behaving like a valid choice, the fix is not to loosen everything. The fix is to make the intended access and model route explicit.

The short owner checklist

After updating to OpenClaw 2026.4.29:

  • Run openclaw doctor --fix and read the prompts before accepting repairs.
  • Test active-run steering by sending a correction while a turn is running.
  • Verify visible replies in your main group/channel surface.
  • Check Active Memory filters if you use memory in multiple chat contexts.
  • Restart the gateway once and confirm status/doctor do not falsely report a healthy-but-slow gateway as dead.
  • Test your highest-value channel with text, long replies, media, and approvals.
  • Verify your default model, any explicit model overrides, and any cron jobs with model settings.
  • If you run restricted tool profiles, check whether you now need explicit alsoAllow entries.
  • If you run Docker automation, look at OPENCLAW_SKIP_ONBOARDING and confirm restart/update behavior.

The useful story of this release is not the size of the changelog.

It is the direction:

OpenClaw is getting better at staying responsive under load, explicit about what reaches humans, and stricter about the boundaries that matter.

That is exactly where agent infrastructure needs to go.