Why does openclaw status show plugins.allow is empty when it is not?

During config validation, resolvePluginProviders creates a synthetic config that only carries auto-detected providers and does not forward plugins.allow from your real config.

Are the plugin provenance warnings in v2026.4.15 real security issues?

No, they are false positives. The warnings fire because the memory-search cold plugin load path does not carry real allowlist context.

How to suppress false plugin warnings in openclaw status?

No user-side workaround yet. The upstream fix requires resolvePluginProviders to forward plugins.allow and plugins.installs from the active config.

Which versions are affected by false-positive plugin warnings?

First reported in v2026.4.5 (issue #62049), persists in v2026.4.15 (issue #69156). Multiple versions affected.

Does this affect plugin functionality or just the status output?

Only affects the status/diagnostic output. Plugins still function correctly despite the warnings.

← Back to dashboard

clawsmith.com/signal/openclaw-v2026-4-15-false-positive-plugin-allowlist-provenance-warnings

⚠ IssueWide OpencoreLive

v2026.4.15 Status Emits False-Positive Plugin Allowlist and Provenance Warnings from Memory-Search Cold Loads

openclaw status and openclaw status --deep emit false warnings like 'plugins.allow is empty' and 'loaded without install/load-path provenance' because resolvePluginProviders creates synthetic config that doesn't carry real allowlist/install context.

Product Idea from this Signal

A runtime watchdog that isolates OpenClaw plugins into monitored worker threads and kills any plugin that blocks the gateway event loop for more than 5 seconds

OpenClaw plugins (especially Active Memory, Dreaming, and provider bridges) run in the same Node.js event loop as the gateway. When one plugin blocks, it starves everything: Telegram polling stops receiving messages, API responses go blank, and conversations fail silently. Seven bug reports in April 2026 alone document cascade failures from a single plugin blocking the loop. This watchdog spawns each plugin in its own worker thread with a heartbeat monitor, kills and restarts any plugin that exceeds the event loop latency threshold, and logs the exact stack trace that caused the block.

CLIOPEN-SOURCEDEVTOOLRUNTIMENODE.JS

CompetitiveView Opportunity →