[BUG] OpenClaw plugin: factory callback receives no config — api.pluginConfig not forwarded

Bug Description

The OpenClaw plugin's register() function in examples/openclaw-plugin/index.js passes config to createContextEngine via the factory callback argument (pluginConfig), but OpenClaw's gateway does not pass plugin config through the factory callback. Instead, it makes config available on api.pluginConfig.

Current Code (broken)

export default function register(api) {
  api.registerContextEngine(pluginMeta.id, (pluginConfig) => {
    return createContextEngine(pluginMeta, pluginConfig, api.logger);
  });
}

The pluginConfig parameter in the factory callback is undefined at runtime because OpenClaw's gateway places config on api.pluginConfig, not as a factory argument.

Result

createContextEngine receives undefined as its config, causing it to fall back to defaults (or fail) regardless of what the user configured in config.yaml.

Fix

Capture api.pluginConfig in the outer scope and fall back to it:

export default function register(api) {
  const config = api.pluginConfig || {};

  api.registerContextEngine(pluginMeta.id, (factoryConfig) => {
    return createContextEngine(pluginMeta, factoryConfig || config, api.logger);
  });
}

Environment

OpenClaw v2026.3.24 (npm)
Plugin v1.4.0
Discovered during initial setup — config values (baseUrl, userId, etc.) from config.yaml were silently ignored

Notes

This may also be an OpenClaw-side issue (gateway should arguably pass config to the factory callback). But the plugin can be made resilient either way with the fallback pattern above.

The root cause is an API contract mismatch: the plugin was written assuming OpenClaw's gateway passes config as a factory callback argument (similar to some other plugin systems), but OpenClaw actually binds it to api.pluginConfig on the registration object instead. This means pluginConfig in the callback is always undefined, so createContextEngine in examples/openclaw-plugin/index.js silently runs with no user configuration. The fallback pattern suggested (factoryConfig || config where config = api.pluginConfig || {}) correctly handles both the current behavior and any future gateway version that does pass config through the factory argument, making the plugin resilient to either convention.

Thanks for documenting this clearly. Just wanted to add: this pattern is a potential footgun for any new OpenClaw plugin author.

Consider adding a defensive note in the official plugin docs (or the example template) clarifying that:

Factory callbacks receive no arguments from OpenClaw
Config should always be captured from api.pluginConfig in the outer scope

The silent failure mode is particularly nasty — we spent ~30 minutes wondering why our config values weren't being picked up before realizing the parameter was undefined.

Also +1 to the proposed fix: the fallback pattern makes the plugin resilient even if OpenClaw's behavior changes in the future.

Closing this as part of the EverOS 1.0 issue triage. This report targets a legacy plugin/API integration from before the 1.0 refactor. The current OSS API is now POST /api/v1/memory/{add,flush,search,get}; legacy OpenClaw/plugin references are being marked as archived in PR #258: #258. If this still reproduces against current main and the 1.0 API, please open a fresh issue with a 1.0 repro.

Navigation Menu

Repository navigation

[BUG] OpenClaw plugin: factory callback receives no config — api.pluginConfig not forwarded #150

Bug Description

Current Code (broken)

Result

Fix

Environment

Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG] OpenClaw plugin: factory callback receives no config — api.pluginConfig not forwarded #150

Description

Bug Description

Current Code (broken)

Result

Fix

Environment

Notes

Activity

JiwaniZakir commented on Apr 1, 2026

jingchang0623-crypto commented on Apr 17, 2026

cyfyifanchen commented on Jun 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions