Founding member access recorded.
Checkout cancelled.

Signals · OpenClaw profile

OpenClaw

Every signal accepted for OpenClaw. Each links to the run that produced it. The OpenClaw profile carries the current evergreen state.

June 2026

  1. 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.
  2. 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. Bitter needs a wrap, adapt, refuse decision for every frontier surface.

  6. 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.
  7. 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.
  8. 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.
  9. Agent systems are growing control planes

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

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

← All signals