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

• Repository: openclaw/openclaw
• Author: hteo1337
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64387

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 #64403: fix(plugins): prefer CLI metadata for lazy primary commands

• Repository: openclaw/openclaw
• Author: ly85206559
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/64403

Description (problem / solution / changelog)

Summary

• Problem: lazy startup eagerly registers the selected plugin primary through the full runtime registrar, which can pull in heavy plugin runtime work for commands like memory.
• Why it matters: commands such as openclaw memory --help should return immediately instead of blocking on unnecessary runtime activation.
• What changed: thread preferMetadataCommands into the lazy plugin CLI loader, prefer the non-activating metadata registrar only when the metadata/runtime command roots match exactly, and keep runtime registration when metadata is only a command stub.
• What did NOT change (scope boundary): no change to eager mode, no cross-plugin conflict policy change, and no metadata fallback when the command-root coverage is incomplete or the metadata registrar cannot actually materialize the command.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Memory / storage
• UI / DX
• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Integrations
• API / contracts
• CI/CD / infra

Linked Issue/PR

• Closes #64354
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the selected lazy primary path eagerly registers the matching plugin command group, but the loader always preferred the full runtime registrar even when a metadata registrar could register the same command roots without activating the heavy runtime path.
• Missing detection / guardrail: there was no regression coverage for "selected lazy primary prefers metadata when safe, falls back to runtime when metadata only partially covers the command roots, and falls back when metadata is only a command stub".
• Contributing context (if known): the affected report was openclaw memory --help hanging on Linux in #64354.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/cli.test.ts
• Scenario the test should lock in: selected lazy primaries use the metadata registrar when it fully covers the command roots, stay on the runtime registrar when metadata only partially covers them, and also stay on the runtime registrar when metadata only advertises a command stub.
• Why this is the smallest reliable guardrail: the regression is in loader/registration selection logic, and the unit test can assert the exact registrar chosen without needing a full plugin runtime.
• Existing test that already covers this (if any): lazy-registers descriptor-backed plugin commands on first invocation
• If no new test is added, why not: N/A

User-visible / Behavior Changes

openclaw memory --help and other selected lazy-primary memory CLI entrypoints avoid the heavy runtime registration path when metadata can safely materialize the same command surface. No config or default changes.

Diagram (if applicable)

Before:
[selected lazy primary] -> [force runtime registrar] -> [heavy runtime path]

After:
[selected lazy primary] -> [prefer safe metadata registrar when roots match and registrar can materialize commands]
[selected lazy primary] -> [fallback to runtime registrar when metadata coverage is incomplete or only a command stub]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Windows 10 (local verification); issue repro in #64354 was Debian 13
• Runtime/container: Node v24.7.0 locally
• Model/provider: N/A
• Integration/channel (if any): CLI / plugin loader
• Relevant config (redacted): default local config

Steps

1. Run pnpm test src/plugins/cli.test.ts
2. Run pnpm test extensions/memory-core/src/cli.test.ts
3. Run pnpm build
4. Run pnpm check

Expected

• The targeted CLI regression tests pass.
• The memory-core CLI test reaches execution normally.
• Build/check results reflect the current repo state rather than the older local failures originally noted on this PR.

Actual

• pnpm test src/plugins/cli.test.ts passed (15/15).
• pnpm test extensions/memory-core/src/cli.test.ts passed (47/47).
• pnpm build still fails locally, but now in unrelated runtime-postbuild dependency staging for amazon-bedrock.
• pnpm check still fails locally on unrelated tsgo errors in extensions/tlon/src/monitor/index.ts and ui/src/ui/app-settings.ts.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: reran the targeted plugin CLI regression test and the previously blocked extensions/memory-core CLI test locally; both passed.
• Edge cases checked: partial command-root coverage still falls back to the runtime registrar, and command-stub metadata registrars do not replace the runtime registrar for the selected lazy primary.
• What you did not verify: I did not reproduce the original Debian issue on a Linux install, and repo-wide build / check are still blocked locally by unrelated failures outside this PR.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: lazy-primary selection could still choose a metadata registrar that advertises the right command roots but does not accept a registration context.
  • Mitigation: record whether a registrar accepts CLI context and keep the runtime registrar when metadata only provides a zero-arg command stub.

Changed files

• src/plugins/cli-registry-loader.ts (modified, +80/-9)
• src/plugins/cli.test.ts (modified, +122/-0)
• src/plugins/cli.ts (modified, +6/-1)
• src/plugins/registry-types.ts (modified, +1/-0)
• src/plugins/registry.ts (modified, +1/-0)