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

[keylimesoda]

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.

[JiwaniZakir]

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.