Home Build Kits Bundles Resources FAQ 🛒 0

Resources / Archive release review

What OpenClaw 2026.4.29 Actually Changes

OpenClaw 2026.4.29 is a governance-and-operability release. The practical signal is more inspectable memory behavior (people-aware wiki and provenance), tighter control over where active recall is allowed, and an operator-grade safety rail around restrictive tool profiles. It is not evidence for a broader memory rollout, automatic dreaming promotion, session-memory injection, or “set-and-forget” channel reliability.

Archive review Memory governance Channels

New current baseline

Upgrade notes to treat as real work

What changed that actually matters

  • Memory grows a people-aware wiki with provenance: OpenClaw adds agent-facing people metadata, aliases, person cards, relationship graphs, privacy/provenance reports, evidence drilldown, and search modes that make “why does it believe this?” a first-class operator question.
  • Active recall can be scoped per conversation: Active Memory now supports allowedChatIds and deniedChatIds so operators can allow recall only on the lanes that have earned it (direct, group, or channel), while keeping broad sessions skipped.
  • Timeouts get partial recall instead of total loss: when the hidden memory sub-agent times out, OpenClaw can return a bounded partial recall summary so useful context is not discarded entirely.
  • Messaging visibility is easier to enforce: messages.visibleReplies lets operators require visible output to go through message(action=send) (not accidental side effects), tightening operator observability across chat sources.
  • Restricted tool profiles got stricter: configured tools.exec/tools.fs sections no longer implicitly widen restrictive profiles; operators who need those tools under messaging/minimal must declare explicit alsoAllow entries.
  • Channel reliability got targeted fixes: WhatsApp delivery and liveness fixes (plus other channel edge cases) reduce “it hung” support churn without changing the rollout boundary.

Why operators should care

You can turn “memory” into an auditable surface. People wiki + provenance shifts memory from “it said so” to “here is what it thinks, why it thinks it, and where the evidence came from.”
Recall scope becomes a real control, not a social norm. Allowed/denied chat ID filters let you keep active recall narrow even when you operate many lanes, which reduces accidental widening and cross-channel leakage.
Support and incident response gets less brittle. Partial recall on timeout is not correctness, but it is often the difference between “memory disappeared” and “we still recovered something bounded enough to keep the workflow moving.”
Operator observability improves. Visible-reply enforcement makes it easier to tell which outputs were actually sent, which helps when you run multi-channel agents and need deterministic audit trails.
Security posture is less accidental. Tightening restrictive profiles so they are not widened implicitly is a usability hit for some configs, but it prevents “I didn’t mean to allow exec” drift in production-y lanes.

What this does not change

  • It does not justify a broader autonomous-memory claim.
  • It does not turn people wiki/provenance into “truth” without review.
  • It does not remove the need for contradiction review, rollback discipline, or governance tiers.
  • It does not make channels (including WhatsApp) “set-and-forget.”
  • It does not make restrictive profiles permissive again; it makes the intent more explicit.
  • It does not make LanceDB the default next move or enable session-memory injection.

The safe public interpretation is more auditable memory behavior and tighter recall control, not expanded autonomous long-term memory.

Risks and areas to watch

  • People wiki can amplify wrong claims faster: treat relationship graphs and “who said what” as evidence tooling, not a trust upgrade.
  • Chat ID scoping is easy to misconfigure: audit allowed/denied lists the same way you audit channel routing and tool permissions.
  • Visible-reply enforcement can surface hidden coupling: if you relied on implicit send side effects, this release makes that coupling more obvious (and you may need to clean it up).
  • Restricted-profile upgrades may break silently: if a config depended on implicit tool widening, add explicit alsoAllow and verify the startup warnings are gone.
  • WhatsApp still needs field verification: treat liveness and delivery notes as “fewer sharp edges,” not proof that the channel is now deterministic.

Who should care most

If you are... This release matters because...
governing active memory across multiple chats you can allow recall only where it is earned, instead of widening by habit
owning memory provenance and trust tiers people wiki and provenance reports make review rules easier to operationalize
supporting multi-channel operators visible-reply enforcement reduces ambiguity about what was actually sent
running restrictive profiles in production-ish lanes exec/fs widening requires explicit intent, which reduces accidental permission drift
deciding whether to widen active memory the answer is still “not from this release alone”

Which CWYN product fits this release best

If the main gain you want from 2026.4.29 is a safer, more auditable memory surface (provenance, people-aware claims, and scoped recall) without turning it into a broader memory promise, start with the OpenClaw Discernment Control Kit.

If you are still fighting first healthy activation, transcript hygiene, memory-health verification, and retrieval debugging, start with the OpenClaw Native Memory Activation Kit first.

If activation, recall scoping, provenance review rules, support triage, channel routing, and approval controls are already tangled together, use the OpenClaw Memory Architecture Bundle.

The practical takeaway

OpenClaw 2026.4.29 is meaningful because it makes memory governance more inspectable and recall scope more controllable. The best rollout response is not to widen memory. It is to tighten review rules, narrow recall lanes intentionally, and use the new provenance surfaces to make “what do we trust?” an explicit operator habit.

Need the safest next move?

Use the selector if you want the smallest correct offer for the current blocker instead of forcing a bigger architecture decision.

Open selector Get checklist

Need the support-and-rollout layer?

Start with activation if the gain you want is memory freshness, transcript hygiene, memory-health verification, and a conservative support baseline.

View activation kit Back to resources

Release-eval rubric

  • Change type: governance, memory activation, support posture
  • Operator value: high for scoped recall + provenance review
  • Best-fit product: discernment first
  • Public-safe claim: more auditable memory, not broader memory proof

What to keep conservative

  • No broader active-memory claim
  • No default LanceDB migration language
  • No session-memory injection claim
  • No “provenance implies truth” story

Source and validation

Official OpenClaw 2026.4.29 release OpenClaw rollout path Native Memory Activation Kit Memory Architecture Bundle