Signals / OpenClaw profile

OpenClaw

Sourced signals for OpenClaw: release changes, governance moves, runtime shifts, and operator consequences. Each links to the run that produced it. The OpenClaw profile carries the current evergreen state.

June 2026

  1. 2026-06-23 / OpenClaw

    OpenClaw shipped automatic Codex plugin approvals to stable — the one gate that loosened this window

    • PR #92625 (stable v2026.6.9, June 21) adds automatic Codex plugin approvals — a gate opened in a fortnight when nearly everyone else was closing them. It cuts against the consent-over-default grain even from a vendor with real accessibility discipline.
    • Operators on v2026.6.9 should audit the new automatic Codex plugin approvals against their trust posture; convenience relaxed a consent gate that was previously explicit.
  2. 2026-06-23 / OpenClaw

    OpenClaw's WCAG 2.1 AA accessibility pass reached stable

    • PR #89822's WCAG 2.1 AA pass reached stable v2026.6.8 (June 16), having been beta-only last window: dark-mode contrast lifted to the 4.5-to-1 floor (verified >=4.8:1), real keyboard `:focus-visible` rings, and a 12-pixel font floor across 136 elements. The cleanest 'reached the operator' event of the fortnight.
    • Operators should verify their dashboard against the stable WCAG AA build — check dark-mode contrast and tab through for a visible focus ring; a previously beta-only accessibility capability is now on the default channel.
  3. 2026-06-13 / OpenClaw

    A WCAG 2.1 AA pass (beta) and a deliberate consent-over-convenience choice on search

    • OpenClaw shipped a measured WCAG 2.1 AA pass on its browser dashboard (contrast above 4.5:1, a focus ring, a 12px font floor across 136 elements) in a BETA tag (v2026.6.7-beta.1), plain-language mobile provider states, and pinned-commit ClawHub skill installs. It also made key-free web search an explicit opt-in (stable v2026.6.8), trading zero-config convenience for explicit consent on where queries egress.
  4. 2026-06-12 / OpenClaw

    Exec approvals fail closed on timeout, and HTTP override surfaces are admin-gated

    • v2026.6.6 made exec approvals fail closed on timeout (a pending dangerous command now denies rather than proceeds) across a dozen-surface boundary sweep that also closed a deleted-agent ACP bypass; v2026.6.8 gated HTTP session/model override surfaces behind admin privileges. The correct reversibility default for a surface aimed at non-experts.
  5. 2026-06-03 / OpenClaw

    Skill Workshop adds a pending-proposal approval workflow with CLI/Gateway review and a skill_workshop agent tool

    • Skill Workshop introduces a new pending-proposal lifecycle that an operator must approve or reject via CLI or Gateway before a skill takes effect, inserting a human-in-the-loop gate into skill provisioning.
    • The skill_workshop agent tool lets agents themselves file proposals, expanding the automation surface; operators must decide who may review and who may self-approve.
    • Decision is for the control-plane admin/skill-author: configure the review path and authority for skill proposals.
  6. 2026-06-03 / OpenClaw

    Enhanced plugin isolation tightens the plugin sandbox boundary in the 2026.6.1 line

    • Enhanced plugin isolation changes the sandbox boundary around plugins, including the externalized Tokenjuice and GitHub Copilot plugins now run as separate plugins.
    • Operators running third-party or externalized plugins should re-test plugin behavior against the tightened isolation, since capabilities previously available in-process may now be constrained.
    • Single runtime-admin decision: verify plugins still function under the new isolation after upgrade.

May 2026

  1. 2026-05-27 / OpenClaw

    Content-boundary hardening suite across inbound surfaces

    • Operators evaluating OpenClaw against 'is it safe to put agents on real channels' can use this suite as evidence of a threat model, not just a feature list.
    • Gateway operators should verify whether `gateway.auth.rateLimit` was unset in their config — the on-by-default ratelimit changes observable behavior for non-browser/HTTP auth flows.
    • Plugin authors should treat `allowFrom` sender allowlists as the canonical inbound boundary; post-dispatch filtering is the older model.
  2. 2026-05-13 / OpenClaw

    Per-sender tool policies via channel-scoped sender keys

    • Operators running OpenClaw with public-facing channels can now restrict dangerous tools by requester identity rather than only by agent. Review your tool surfaces and decide whether the broader trust model (per-channel × per-sender) belongs in your deployment.
    • Authority restriction now extends across global, agent, group, core, bundled, and plugin tool surfaces — operators should re-audit which surfaces hold authority decisions in their deployment and whether the requester-level layer makes some prior per-agent restrictions redundant.
    • Three claim-level updates land in the same release: memory-wiki ingest now requires admin scope, Obsidian search requires write scope, and `openclaw models auth login --provider openai` defaults to ChatGPT/Codex login (API-key setup is now behind `--method api-key`). Setup scripts assuming read-only or API-key-first paths need to be updated.
  3. 2026-05-12 / OpenClaw

    Per-agent message restrictions, gated code install, and onboarding wayfinding

    • Operators deploying public-facing or sandboxed agents should evaluate `tools.message.crossContext` and `tools.message.actions.allow` overrides to restrict agent message sends to the current conversation without changing the global bot policy.
    • Operators running long-horizon OpenClaw sessions should know that session memory is now bounded: the memory dreaming promotion cap compacts oldest auto-promoted sections while preserving user-authored notes. Unbounded auto-memory growth is no longer the default behavior.
    • Operators deploying OpenClaw for new users should test the improved CLI onboarding wayfinding: setup, onboarding, configure, and channel commands now explain the next useful command at each step.
  4. Accessibility is becoming a frontier capability.

  5. Persistent agent state is becoming a product surface

    • Developers need to know which goals, memory patches, recaps, sessions, and skill maintenance loops shaped a serious run.
  6. Permissions, secrets, and sandboxes are moving into the foreground

    • The harness must make trust state visible: what can be read, what can be changed, which credentials are exposed, and where execution happens.
  7. Accessibility is a frontier capability, not marketing polish

    • Everyday adoption depends on setup recovery, visible progress, voice/chat surfaces, readable UI, OAuth clarity, and fewer dead ends.
  8. Agent systems are growing control planes

    • Once agents coordinate across tasks, runtimes, gateways, and integrations, operators need liveness, cost, role, session, and recovery controls.
  9. Integrations are volatile; the operating loop has to be durable

    • Provider lists, plugin systems, transports, and model profiles will keep changing.

<- All signals