Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix False plugin-boundary warning: plugins.allow reported empty even when configured [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70161•Fetched 2026-04-23 07:28:32
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
0
Author
waynegaultwaynegault
Participants
steipetesteipetewaynegaultwaynegault
Timeline (top)
closed ×1commented ×1cross-referenced ×1

openclaw doctor and gateway startup emit [plugins] plugins.allow is empty even when plugins.allow is fully populated in openclaw.json. This simultaneously triggers false provenance warnings for every installed plugin (e.g. "untracked loaded plugin: lossless-claw"), despite those plugins being present in the configured allowlist.

Running openclaw config get plugins.allow returns the full populated list, directly contradicting the warning.

Root Cause

Root Cause (identified)

Three dist files read plugins.allow via getRuntimeConfigSnapshot() (the resolved/normalised config object). The normalisation step loses the plugins.allow array. The correct call is getRuntimeConfigSourceSnapshot() (raw source config), which preserves the array.

Fix Action

Fix / Workaround

Patching all three to prefer getRuntimeConfigSourceSnapshot() (with a JSON5 direct-file-read fallback) clears all warnings without any config change.

Code Example

[plugins] plugins.allow is empty — all plugin loads will be flagged as untracked
[plugins] untracked loaded plugin: lossless-claw (not in allowlist)
[plugins] untracked loaded plugin: openclaw-web-search (not in allowlist)

---

["gigabrain","browser","lossless-claw","openclaw-web-search","whatsapp","openrouter","deepseek","anthropic","google","github-copilot","moonshot","openai","memory-core","minimax","xai","voice-call"]
RAW_BUFFERClick to expand / collapse

Component: plugin loader, facade-activation-check, load-context Severity: Medium

Description

openclaw doctor and gateway startup emit [plugins] plugins.allow is empty even when plugins.allow is fully populated in openclaw.json. This simultaneously triggers false provenance warnings for every installed plugin (e.g. "untracked loaded plugin: lossless-claw"), despite those plugins being present in the configured allowlist.

Running openclaw config get plugins.allow returns the full populated list, directly contradicting the warning.

Reproducible Steps

  1. Ensure openclaw.json contains a non-empty plugins.allow array (any entries).
  2. Run openclaw doctor --non-interactive.
  3. Observe: [plugins] plugins.allow is empty warning.
  4. Run openclaw config get plugins.allow — returns the populated list.

Expected Behaviour

No plugins.allow is empty warning when plugins.allow is configured. No untracked-plugin provenance warnings for plugins present in the configured allowlist.

Actual Behaviour

Both warnings fire regardless of config content. The warning is a false positive — the config is correct, but the runtime reader discards the allowlist before checking it.

Root Cause (identified)

Three dist files read plugins.allow via getRuntimeConfigSnapshot() (the resolved/normalised config object). The normalisation step loses the plugins.allow array. The correct call is getRuntimeConfigSourceSnapshot() (raw source config), which preserves the array.

Affected files:

  • dist/loader-B9Yrel7b.js — plugin loader and warning emitter
  • dist/facade-activation-check.runtime.js — plugin activation boundary checker
  • dist/load-context-CeQ7N8VN.js — plugin runtime load-context resolver

Patching all three to prefer getRuntimeConfigSourceSnapshot() (with a JSON5 direct-file-read fallback) clears all warnings without any config change.

Environment

  • OS: Linux (xps15-9520)
  • OpenClaw version: 2026.4.21 (f788c88)
  • Branch/channel: main

Logs / Stack Trace

<details> <summary>Click to expand</summary> 
[plugins] plugins.allow is empty — all plugin loads will be flagged as untracked
[plugins] untracked loaded plugin: lossless-claw (not in allowlist)
[plugins] untracked loaded plugin: openclaw-web-search (not in allowlist)

openclaw config get plugins.allow output (same session, immediately after):

["gigabrain","browser","lossless-claw","openclaw-web-search","whatsapp","openrouter","deepseek","anthropic","google","github-copilot","moonshot","openai","memory-core","minimax","xai","voice-call"]
</details>

Suggested Fix

In dist/loader-B9Yrel7b.js, dist/facade-activation-check.runtime.js, and dist/load-context-CeQ7N8VN.js: replace calls to getRuntimeConfigSnapshot() that read plugins.allow with getRuntimeConfigSourceSnapshot(). If the source snapshot is not yet initialised, fall back to a direct JSON5 read of the config file path via resolveConfigPath().

extent analysis

TL;DR

Replace getRuntimeConfigSnapshot() with getRuntimeConfigSourceSnapshot() in the affected dist files to preserve the plugins.allow array.

Guidance

  • Identify the affected files: dist/loader-B9Yrel7b.js, dist/facade-activation-check.runtime.js, and dist/load-context-CeQ7N8VN.js.
  • Replace getRuntimeConfigSnapshot() with getRuntimeConfigSourceSnapshot() in these files to read the plugins.allow array correctly.
  • Implement a fallback to a direct JSON5 read of the config file path via resolveConfigPath() if the source snapshot is not yet initialized.
  • Verify the fix by running openclaw doctor --non-interactive and checking for the absence of the [plugins] plugins.allow is empty warning.

Example

// Before
const config = getRuntimeConfigSnapshot();
const pluginsAllow = config.plugins.allow;

// After
const configSource = getRuntimeConfigSourceSnapshot();
const pluginsAllow = configSource.plugins.allow;
if (!pluginsAllow) {
  const configPath = resolveConfigPath();
  // Direct JSON5 read of the config file
  const configFile = require('json5').parse(fs.readFileSync(configPath, 'utf8'));
  pluginsAllow = configFile.plugins.allow;
}

Notes

This fix assumes that the getRuntimeConfigSourceSnapshot() function returns the raw source config, which preserves the plugins.allow array. Additionally, the fallback to a direct JSON5 read of the config file path may have performance implications and should be carefully evaluated.

Recommendation

Apply the workaround by replacing getRuntimeConfigSnapshot() with getRuntimeConfigSourceSnapshot() in the affected files, as this directly addresses the identified root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#memory management#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING