Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug] plugins.allow config ignored — false 'plugins.allow is empty' warning fires 13+ times on gateway restart (v2026.4.2) [2 pull requests, 1 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#62521•Fetched 2026-04-08 03:03:06
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
100yenadmin100yenadmin
Participants
100yenadmin100yenadmin

Root Cause

Root Cause (code-verified)

Fix Action

Workaround

None — the warning is cosmetic and can be filtered in log monitoring, but the underlying issue (config not fully normalized before warnWhenAllowlistIsOpen() is called) should be fixed.

PR fix notes

PR #64387: fix(plugins): include activationSourceConfig in loadOpenClawPlugins destructuring

Description (problem / solution / changelog)

Summary

  • resolvePluginLoadCacheContext returns activationSourceConfig in its result object (used to thread the original raw config through to activation-source creation)
  • loadOpenClawPlugins destructures the result but omits activationSourceConfig
  • The compiled build (2026.4.9, loader-BSIqIOsD.js) injects a diagnostic log inside loadOpenClawPlugins that references activationSourceConfig as a bare variable
  • Since the variable was never destructured, this causes ReferenceError: activationSourceConfig is not defined, crash-looping the gateway on every startup attempt

One-line fix

Add activationSourceConfig to the destructuring at loadOpenClawPlugins line ~1092.

Reproduction

  1. Install OpenClaw 2026.4.9 via pnpm/npm
  2. Start the gateway (openclaw gateway start or via LaunchAgent)
  3. Gateway crash-loops: starting... → loading configuration… → resolving authentication… → crash → repeat every ~4s
  4. ~/.openclaw/logs/gateway.err.log shows: Gateway failed to start: ReferenceError: activationSourceConfig is not defined

Evidence

Gateway error log (repeating every ~4 seconds):

2026-04-10T14:14:03.652+03:00 Gateway failed to start: ReferenceError: activationSourceConfig is not defined
2026-04-10T14:14:07.982+03:00 Gateway failed to start: ReferenceError: activationSourceConfig is not defined
2026-04-10T14:14:12.218+03:00 Gateway failed to start: ReferenceError: activationSourceConfig is not defined

Compiled code trace

In loader-BSIqIOsD.js:

Line ~1996 — resolvePluginLoadCacheContext declares and returns activationSourceConfig:

const activationSourceConfig = options.activationSourceConfig ?? options.config ?? {};
// ...
return { env, cfg, normalized, activationSourceConfig, activationSource, ... };

Line ~2336 — loadOpenClawPlugins destructures but omits it:

const { env, cfg, normalized, activationSource, autoEnabledReasons, ... } = resolvePluginLoadCacheContext(options);
//                              ^ missing activationSourceConfig here

Line ~2446 — a diagnostic log references it as a bare variable:

if (shouldActivate) logger.warn(`[plugins-diag] ... activation.plugins=${JSON.stringify(activationSourceConfig?.plugins ?? null)}`);
// ReferenceError: activationSourceConfig is not defined

Environment

  • OpenClaw: 2026.4.9 (0512059)
  • Node.js: v25.9.0
  • OS: macOS 26.3.1 (arm64)

AI-assisted

  • AI-assisted (Claude Code / Opus 4.6)
  • Tested locally: applied equivalent patch to compiled loader-BSIqIOsD.js, confirmed gateway starts successfully
  • I understand what the code does

Related issues

Fixes #64357

Related (same symptom family — false plugins.allow is empty warnings):

  • #62049, #64170, #62521, #63693, #63182

Possibly related (plugin loading crashes/hangs):

  • #64306, #64354

Test plan

  • pnpm build && pnpm check && pnpm test passes
  • Gateway starts without crash-loop on fresh install
  • openclaw doctor no longer shows activationSourceConfig ReferenceError

Changed files

  • scripts/check-no-raw-channel-fetch.mjs (modified, +1/-1)
  • src/plugins/loader.ts (modified, +2/-0)
  • test/scripts/lint-suppressions.test.ts (modified, +1/-0)

PR #63848: fix: pass cfg to getMemoryEmbeddingProvider in memory-search resolution

Description (problem / solution / changelog)

Summary

Resolves false positive plugins.allow warnings emitted during resolveMemorySearchConfig/mergeConfig. The cfg parameter was not forwarded to getMemoryEmbeddingProvider calls, causing plugin capability resolution to fall back to a config-less path that triggered allowlist warnings even when plugins.allow was populated in the loaded config.

Closes #63693

Changes

  • Forward cfg parameter to getMemoryEmbeddingProvider in memory-search resolution path

Testing

  • Verified that plugins.allow warnings no longer appear when memory search config is resolved with a valid config

This PR was developed with AI assistance (Claude). Built with islo.dev

Changed files

  • src/agents/memory-search.ts (modified, +5/-4)

Code Example

"plugins": {
    "allow": ["telegram","eva-xt","subagent-context-limiter","lossless-claw","cortex","browser","minimax","anthropic","openai"]
}

---

[plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: cortex (...), eva-xt (...), lossless-claw (...), subagent-context-limiter (...). Set plugins.allow to explicit trusted ids.

---

if (params.allow.length > 0) return;
// ... emits warning
RAW_BUFFERClick to expand / collapse

Bug Summary

On every gateway restart, warnWhenAllowlistIsOpen() fires 13+ times in the plugin loader, despite plugins.allow being explicitly configured with 9 entries. This is distinct from #62049 (which affects openclaw status) — this fires in the gateway startup plugin loader path.

Environment

  • OpenClaw: v2026.4.2 (commit d74a12264aa5)
  • OS: macOS (Darwin arm64)
  • Node.js: v25.8.2
  • Config path: ~/.openclaw/openclaw.json

Configuration

plugins.allow IS set in openclaw.json:

"plugins": {
    "allow": ["telegram","eva-xt","subagent-context-limiter","lossless-claw","cortex","browser","minimax","anthropic","openai"]
}

Observed Warning (fires 13+ times on restart)

[plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: cortex (...), eva-xt (...), lossless-claw (...), subagent-context-limiter (...). Set plugins.allow to explicit trusted ids.

Root Cause (code-verified)

The warning is emitted by warnWhenAllowlistIsOpen() in dist/loader-BkajlJCF.js (line ~2155):

if (params.allow.length > 0) return;
// ... emits warning

The check evaluates params.allow as empty at call time, even though the config file has 9 entries. The warning fires before full config normalization completes — the allow array from plugins.allow is not yet resolved into the params.allow parameter passed to this function during gateway startup.

The function is called multiple times during the plugin discovery/loading phase of gateway startup, which is why the warning fires 13+ times rather than once.

Impact

  • Cosmetic only — plugins DO load correctly via plugins.load.paths
  • However, the repeated false warning is misleading and clutters logs, making it difficult to spot real warnings
  • Users may incorrectly believe their allowlist is not being enforced (it is)

Difference from Related Issues

  • #62049 — Same false-positive warning, but triggered by openclaw status CLI. PR #62106 addresses that path by downgrading the warning level, but the gateway startup loader path is not covered by that fix.
  • #61613 — Gateway overwrites plugins.allow with invalid IDs on restart (separate but related gateway restart issue)
  • #59549 — False provenance warnings even with correct allowlist config (related allowlist resolution issues)

Expected Behavior

warnWhenAllowlistIsOpen() should not fire when plugins.allow is configured. Config normalization should resolve the allow array into params.allow before plugin discovery begins during gateway startup.

Alternatively, the function should read the allow list directly from config rather than relying on a pre-normalized params object.

Workaround

None — the warning is cosmetic and can be filtered in log monitoring, but the underlying issue (config not fully normalized before warnWhenAllowlistIsOpen() is called) should be fixed.

Suggested Fix

Ensure warnWhenAllowlistIsOpen() is only called after full config normalization, OR pass the raw config plugins.allow array as a fallback when params.allow is empty. The fix in PR #62106 (for the status path) should be extended to the gateway startup loader path as well.

extent analysis

TL;DR

The warnWhenAllowlistIsOpen() function fires excessively due to params.allow being empty during gateway startup, despite plugins.allow being configured, and can be fixed by ensuring config normalization completes before the function is called.

Guidance

  • Review the dist/loader-BkajlJCF.js file (around line 2155) to understand how warnWhenAllowlistIsOpen() is triggered and how params.allow is populated.
  • Verify that the plugins.allow configuration in openclaw.json is correctly formatted and matches the expected plugin IDs.
  • Consider extending the fix from PR #62106 to the gateway startup loader path to address this issue, ensuring that warnWhenAllowlistIsOpen() is called after full config normalization or using the raw plugins.allow array as a fallback.
  • To mitigate the issue temporarily, log filtering can be used to reduce the noise from these warnings, but a proper fix should be implemented to prevent potential confusion about allowlist enforcement.

Example

No specific code example is provided due to the complexity of the issue and the need for a thorough review of the codebase, especially around config normalization and the warnWhenAllowlistIsOpen() function.

Notes

The issue seems to be related to the timing of config normalization and the warnWhenAllowlistIsOpen() function call. Ensuring that the config is fully normalized before calling this function or using the raw config as a fallback should resolve the issue. However, a detailed code review and potential adjustments to the config loading process may be necessary.

Recommendation

Apply a workaround by filtering the logs to reduce noise from these warnings, and prioritize implementing a fix similar to PR #62106 for the gateway startup loader path to ensure warnWhenAllowlistIsOpen() is called after config normalization is complete.

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…
#generation error#database connection#vector store#embedding generation#cache error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING