Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix status: false positive `plugins.allow` warning from core memory search resolution [3 pull requests, 2 comments, 3 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#63693•Fetched 2026-04-10 03:42:11
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Author
raul-santamariaraul-santamaria
Participants
ArtyomkunArtyomkunjacobarossjacobarossraul-santamariaraul-santamaria
Timeline (top)
commented ×2cross-referenced ×2referenced ×1

openclaw status can emit a false positive plugin allowlist warning from the core status path.

In the affected environment, the loaded config has a non-empty plugins.allow, but openclaw status still prints a warning claiming that plugins.allow is empty. The warning surfaces against a custom non-bundled plugin, but the triggering path appears to be OpenClaw core status/memory-search resolution, not plugin-specific logic.

Root Cause

Based on code-path tracing, the warning is emitted by the plugin loader, but it is reached indirectly from OpenClaw core status / agents.*.memorySearch resolution.

Relevant flow:

  • resolveMemorySearchConfig(cfg, agentId) in memory-search-*.js
  • resolveMemorySearchConfig() calls getMemoryEmbeddingProvider(...) without passing cfg
  • getMemoryEmbeddingProvider(id, cfg) falls back to listMemoryEmbeddingProviders(cfg)
  • listMemoryEmbeddingProviders(cfg) falls back to resolvePluginCapabilityProviders({ key: 'memoryEmbeddingProviders', cfg })
  • that path reaches plugin capability/provider resolution and eventually the plugin loader
  • the loader then emits warnings as if plugins.allow were empty

Relevant locations observed locally:

  • memory-search-*.js
    • resolveMemorySearchConfig(cfg, agentId)
    • calls to getMemoryEmbeddingProvider(provider), getMemoryEmbeddingProvider(fallback), and getMemoryEmbeddingProvider(resolved.provider) without cfg
  • memory-embedding-provider-runtime-*.js
    • getMemoryEmbeddingProvider(id, cfg)
  • capability-provider-runtime-*.js
    • resolvePluginCapabilityProviders(params)
  • loader-*.js
    • loader warning path

Fix Action

Workaround

No safe config-only workaround found.

Current operational workaround: ignore the warning after independently verifying that the loaded config already has a populated plugins.allow.

PR fix notes

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

Description (problem / solution / changelog)

Summary

  • Fixes a bug where cfg was not passed to getMemoryEmbeddingProvider during memory-search resolution, causing it to fall back to defaults instead of using the configured embedding provider.

Closes #63693

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

Changed files

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

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)

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)
RAW_BUFFERClick to expand / collapse

status: false positive plugins.allow warning from core memory search resolution

Summary

openclaw status can emit a false positive plugin allowlist warning from the core status path.

In the affected environment, the loaded config has a non-empty plugins.allow, but openclaw status still prints a warning claiming that plugins.allow is empty. The warning surfaces against a custom non-bundled plugin, but the triggering path appears to be OpenClaw core status/memory-search resolution, not plugin-specific logic.

Version

OpenClaw 2026.4.9

Environment

  • Config path: ~/.openclaw/openclaw.json
  • State dir: ~/.openclaw
  • plugins.allow is populated in the loaded config

Steps to reproduce

  1. Run openclaw status
  2. Observe that a plugin allowlist/trust warning is printed before the status output
  3. Run openclaw status --json
  4. Observe that the warning does not appear

Additional isolation:

  • buildPluginCompatibilityNotices({ config: overview.cfg }) does not reproduce the warning
  • The warning appears during the memory/status execution path
  • resolveMemorySearchConfig(cfg, 'main') reproduces the warning
  • getMemoryEmbeddingProvider('ollama', cfg) does not reproduce the warning

Expected behavior

If the loaded config has a populated plugins.allow, openclaw status should not emit warnings claiming that plugins.allow is empty.

Actual behavior

openclaw status emits a plugin allowlist/trust warning as if plugin allowlisting were empty, even though the loaded config contains a populated plugins.allow.

Root cause

Based on code-path tracing, the warning is emitted by the plugin loader, but it is reached indirectly from OpenClaw core status / agents.*.memorySearch resolution.

Relevant flow:

  • resolveMemorySearchConfig(cfg, agentId) in memory-search-*.js
  • resolveMemorySearchConfig() calls getMemoryEmbeddingProvider(...) without passing cfg
  • getMemoryEmbeddingProvider(id, cfg) falls back to listMemoryEmbeddingProviders(cfg)
  • listMemoryEmbeddingProviders(cfg) falls back to resolvePluginCapabilityProviders({ key: 'memoryEmbeddingProviders', cfg })
  • that path reaches plugin capability/provider resolution and eventually the plugin loader
  • the loader then emits warnings as if plugins.allow were empty

Relevant locations observed locally:

  • memory-search-*.js
    • resolveMemorySearchConfig(cfg, agentId)
    • calls to getMemoryEmbeddingProvider(provider), getMemoryEmbeddingProvider(fallback), and getMemoryEmbeddingProvider(resolved.provider) without cfg
  • memory-embedding-provider-runtime-*.js
    • getMemoryEmbeddingProvider(id, cfg)
  • capability-provider-runtime-*.js
    • resolvePluginCapabilityProviders(params)
  • loader-*.js
    • loader warning path

Proposed fix

Pass cfg through the memory-search calls to getMemoryEmbeddingProvider(...), at least in:

  • mergeConfig(...)
  • resolveMemorySearchConfig(...)

That should keep provider resolution on the same config object already verified to contain plugins.allow.

Impact

  • False security/trust warnings in openclaw status
  • Misleading diagnosis for users and operators
  • Looks like a config/runtime mismatch even though the issue is in the local status-path resolution flow

Workaround

No safe config-only workaround found.

Current operational workaround: ignore the warning after independently verifying that the loaded config already has a populated plugins.allow.

Notes

This report is based on direct reproduction and code-path tracing in a local OpenClaw 2026.4.9 installation. No local source patch was applied.

extent analysis

TL;DR

Passing the configuration object cfg through the memory-search calls to getMemoryEmbeddingProvider(...) is likely to fix the false positive plugin allowlist warning.

Guidance

  • Verify that the plugins.allow field is populated in the loaded configuration file ~/.openclaw/openclaw.json.
  • Check the code flow in memory-search-*.js and memory-embedding-provider-runtime-*.js to ensure that cfg is being passed correctly to getMemoryEmbeddingProvider(...).
  • Test the proposed fix by modifying the resolveMemorySearchConfig(...) function to pass cfg to getMemoryEmbeddingProvider(...) and verify that the warning is no longer emitted.
  • Consider adding additional logging or debugging statements to help identify the root cause of the issue.

Example

// In memory-search-*.js
resolveMemorySearchConfig(cfg, agentId) {
  // ...
  getMemoryEmbeddingProvider(id, cfg); // Pass cfg to getMemoryEmbeddingProvider
  // ...
}

Notes

The proposed fix assumes that passing the cfg object through the memory-search calls will resolve the issue. However, further testing and verification are needed to confirm that this fix works as expected.

Recommendation

Apply the proposed fix by passing cfg through the memory-search calls to getMemoryEmbeddingProvider(...), as this is likely to resolve the false positive plugin allowlist warning.

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…

FAQ

Expected behavior

If the loaded config has a populated plugins.allow, openclaw status should not emit warnings claiming that plugins.allow is empty.

#installation#dependency error#configuration error#environment variable#network issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING