The ClawHub Trust Gate That Lasted Half a Day
ClawHub, OpenClaw's plugin marketplace, gained a new security layer yesterday morning: a trust verification gate that would query ClawHub's security API before downloading any plugin package and warn users about releases flagged as risky. The feature touched every plugin installation path — plugins install, plugins update, core update sync, onboarding, and repair. Documentation was added across three reference pages covering the new acknowledgement requirement, a dedicated --acknowledge-clawhub-risk CLI flag for automation, and the underlying trust-check mechanism.
By the afternoon, the entire feature was reverted. The reason: the trust gate violated OpenClaw's non-interactive contract. Automated workflows using the --yes flag — which is supposed to suppress all interactive prompts — could still be interrupted by the new trust acknowledgement dialog. For operators running unattended updates, CI pipelines, and cron-driven maintenance, this was a breaking change disguised as a safety feature. In at least one reported case, the prompt caused an agent to “go rogue” when the unexpected interactive gate disrupted its execution flow.
All three documentation pages that were added for the trust gate — plugin reference, CLI update reference, and CLI plugins reference — were rolled back as part of the revert. The changelog entry was removed. From a documentation standpoint, the feature never existed.
The concept isn't dead — the security case for pre-install trust checks on third-party plugins is sound. But the implementation will need to respect the automation boundary before it ships again. When --yes means “yes to everything,” a security gate that ignores that flag isn't adding protection. It's adding unpredictability.
Device Pairing Stops Silently Minting Operator Tokens
A more consequential security fix landed without fanfare. OpenClaw's setup-code device pairing workflow had a flaw: when a fresh device connected via the bootstrap flow, the system would silently approve the pairing and mint operator-scoped device tokens — tokens with elevated privileges — without requiring any explicit approval from the instance owner.
The fix is threefold. Bootstrap profiles are now scoped to node-level access only, stripping the automatic operator role grant. Fresh connections return a pending state instead of auto-approving. And the handshake response no longer includes bonus operator tokens that the connecting device never asked for.
This is the kind of vulnerability that's easy to overlook because it lives in an onboarding flow that most users experience exactly once. But the exposure was real: anyone who could initiate a setup-code pairing could walk away with operator-level access to the instance without the owner ever seeing a prompt. The behavioral shift is significant — pairing now requires explicit approval before durable tokens are granted.
The Gateway Finally Forwards Temperature and Top-P
OpenClaw's OpenAI-compatible HTTP gateway — the /v1/chat/completions and /v1/responses endpoints that let any OpenAI SDK client talk to OpenClaw agents — had been accepting temperature and top_p parameters in requests. Accepting them, validating nothing, and then quietly throwing them away before forwarding to the upstream provider.
The result: developers who set temperature: 0 for deterministic output were getting the provider's default sampling behavior instead. Cost-control layers that set tight token budgets via top_p were having their constraints silently ignored. Orchestration frameworks like LangChain and LlamaIndex that rely on these parameters for reproducible chains were getting non-reproducible results through OpenClaw with no error, no warning, and no indication that anything was wrong.
Both parameters are now extracted, validated, and threaded through the full stream pipeline to upstream providers. Invalid values correctly propagate provider validation errors back to the caller. The API documentation has been updated to describe the forwarding behavior and notes a caveat: the ChatGPT-based Codex Responses backend uses fixed sampling, so top_p is stripped server-side for that specific backend.
Subagent Tasks Step Out of the Shadows
When an OpenClaw agent spawns a subagent, it delegates a task — a set of instructions describing what the child agent should do. Until now, that task text was buried in the subagent's system prompt: invisible in transcripts, invisible in logs, invisible to anyone reviewing what the agent actually did. The parent said “do X,” the child did something, and the connection between the two was hidden behind the system prompt wall.
Task delegation now produces a visible [Subagent Task] message in the child session's transcript. The system prompt retains runtime rules and routing context but no longer contains the actual task body. The task marker appears exactly once, indentation is preserved, and the delegated instructions are fully auditable in the child's conversation history.
This matters for trust and debugging. When a subagent produces unexpected output, the first question is always “what was it told to do?” Previously, answering that required digging into system prompt internals. Now it's the first message in the transcript.
Plugin Doctor Stops Issuing False Clean Bills of Health
The openclaw plugins doctor command had a credibility problem. It could detect stale plugin configuration references — entries in plugins.allow, plugins.entries, and plugins.slots.* that pointed to plugins no longer installed or had changed identifiers — but it would report those warnings and then conclude with “No plugin issues detected.” The diagnostic tool was finding problems and then declaring the patient healthy.
The fix integrates the stale-config scanner into the doctor command's health determination. When only configuration warnings exist but the runtime install tree is healthy, the command now reports “No plugin install-tree issues detected; configuration warnings remain.” It's a small change in output text and a significant change in operator trust. A diagnostic tool that lies about its findings is worse than no diagnostic tool at all.
Codex Stops Hijacking Your Home Directory
OpenClaw's Codex integration had an overly aggressive isolation strategy. When launching Codex app-servers locally, the system rewrote the HOME environment variable to point to a synthetic directory under the agent's Codex home. The intent was isolation. The effect was breaking every subprocess tool that reads configuration from the user's home directory — git, gh, cloud CLIs, and even openclaw itself.
The fix narrows the isolation boundary. CODEX_HOME remains per-agent, keeping Codex configuration, authentication, plugins, and thread state isolated. But HOME now passes through normally, letting subprocess tools find their configuration files where they expect them. Callers who need hermetic launch behavior can still override HOME explicitly. The migration documentation has been updated to describe the corrected isolation boundary.