openclaw - 💡(How to fix) Fix enabledByDefault: true in plugin manifest doesn't auto-enable community-origin plugins (bundled-only short-circuit) [2 pull requests]

Summary

The plugin-manifest field enabledByDefault: true (top-level in openclaw.plugin.json) auto-enables bundled plugins on install, but silently has no effect for community plugins installed via openclaw plugins install or clawhub package install. As a result, community plugins shipping the canonical SKILL.md requires.config: ["plugins.entries.<id>.enabled"] gate come up with their skill blocked on a fresh install, and operators must manually run openclaw plugins enable <id> before the skill loads — even though the plugin author opted in via the manifest field.

Steps to reproduce

1. Author a community plugin with:
   • openclaw.plugin.json containing top-level "enabledByDefault": true (the same form @openclaw/azure-speech, @openclaw/anthropic, @openclaw/browser, etc. use).
   • skills/<name>/SKILL.md frontmatter:

     metadata: { "openclaw": { "requires": { "config": ["plugins.entries.<plugin-id>.enabled"] } } }

     This is the canonical pattern — every official skill I checked uses it (tavily/skills/tavily, open-prose/skills/prose, etc.).
2. Publish to ClawHub: clawhub package publish .
3. On a fresh OpenClaw install: openclaw plugins install clawhub:<package>.
4. Check openclaw plugins list and the skills panel.

Expected

The plugin shows as enabled and the skill loads — same behavior bundled plugins with enabledByDefault: true get.

Actual

• Plugin tools load and are callable. Smoke tests pass.
• SKILL.md shows blocked with reason Missing requirements: config:plugins.entries.<plugin-id>.enabled.
• Operator must run openclaw plugins enable <plugin-id> to flip the flag manually, after which the skill activates correctly.

Root cause (from reading dist source)

In dist/config-normalization-shared-*.js, the early-return that auto-enables on enabledByDefault: true is bundled-only:

if (params.origin === "bundled" && params.enabledByDefault === true) return {
  enabled: true,
  activated: true,
  explicitlyEnabled: false,
  source: "default",
  cause: "bundled-default-enablement"
};

The manifest parser (dist/manifest-*.js) reads raw.enabledByDefault === true regardless of origin, and isPluginEnabledByDefaultForPlatform accepts any plugin. But the auto-enable activation path only fires for bundled — community plugins fall through to the manual-enable-required path.

Impact

• Every community plugin that follows the documented canonical SKILL.md gate pattern hits this. Two concrete examples already in the wild:
  • @tangleclaw/openclaw-google-oauth — 24 Google Workspace tools
  • @tangleclaw/openclaw-ebay-research — eBay read-only research tools
• Operators get a silently degraded agent on install: tools work, but the SKILL.md instructional layer (which biases the agent against narrating-without-calling, surfaces clickable result URLs, encodes recipes, etc.) doesn't load. Smoke tests pass; the agent just runs noisier than it should.
• The bundled-vs-community asymmetry isn't documented in building-plugins or skills. Authors who follow the docs hit this without warning.

Proposed resolutions

Open to any of these:

1. Honor enabledByDefault: true for community plugins. Remove the origin === "bundled" restriction from the auto-enable short-circuit. Running openclaw plugins install is the operator's explicit opt-in; the manifest field is the plugin author's "I should be on by default." Both consents are present.
2. Auto-flip plugins.entries.<id>.enabled = true on openclaw plugins install, regardless of manifest. Treats install as the opt-in universally. More intrusive — changes baseline install behavior for plugins without the manifest field too.
3. Document the bundled-only restriction loudly if the asymmetry is intentional defense-in-depth, and recommend an alternative SKILL.md gating pattern that doesn't depend on the enabled-flag.

Happy to test a candidate fix locally against either listed plugin and report back.