Summary

When a plugin's runtime config fails its declared schema during openclaw startup, the entire worker process exits with code 1 instead of marking that single plugin disabled and continuing. This is a single-tenant single-plugin failure mode that takes down everything else (channels, other plugins, scheduled jobs, etc).

Reproduction

1. Install any openclaw plugin whose manifest declares a config field with a pattern or other strict validator (example: communityRepo: { type: "string", pattern: "^[^/]+/[^/]+$" }).
2. Have the runtime openclaw.json initialize that field as "" (e.g. via a config-reset workflow that uses empty defaults).
3. Boot the worker.

Observed (live worker logs, 2026-04-22 17:07 UTC)

F {"0":"Config invalid","logLevelId":5,"logLevelName":"ERROR",...}
F {"0":"File: /mnt/openclaw-state/orgs/<org>/openclaw.json",...}
F {"0":"Problem:",...}
F {"0":"  - plugins.entries.community-feedback.config.communityRepo: invalid config: must match pattern \"^[^/]+/[^/]+$\"",...}
F {"0":"Run: openclaw doctor --fix",...}
F Run: openclaw doctor --fix
[container exits 1 → CrashLoopBackOff]

The whole worker crash-looped (Probe of StartUp failed with status code: 1 × 80+ events) until a human edited the openclaw.json to provide a valid value for the offending field. WhatsApp channel went down. Trip-broadcast poller went down. Concierge for the entire tenant went down — all because of one optional plugin's empty config.

Suggested behavior

When config validation fails for a single plugin entry, the loader should:

1. Log the error clearly (it already does this — keep it).
2. Mark that plugin entry as disabled (or failed) in the in-memory registry. Skip its register(). Surface the failure in openclaw doctor output.
3. Continue booting the rest of the gateway / other plugins / channels.
4. The plugin's tools become unavailable; the agent gets a clear "plugin not loaded" error if they're called.
5. Optionally: emit a structured event (log + maybe webhook) so an operator dashboard can detect the disabled state.

This matches how openclaw already handles plugin LOAD failures (silent skip per "Plugins fail SILENTLY if wrong" — repo memory). Config-validation failures should be no harsher: invalid config = same as failed load = skip + continue.

Why this matters

Plugin authors can't always anticipate every operator misconfiguration. With strict validators + boot-time crash, any plugin author who ships a non-optional config field with a regex effectively has the power to take down the whole worker if the operator doesn't seed a valid value. Today the safe pattern is "all config optional + runtime-check in tool execute()". That's overly defensive and pushes validation to call time instead of boot time, where it should be.

Acceptance criteria

• Config validation failure for plugin entry X causes plugin X to be disabled but worker continues to boot.
• openclaw doctor lists disabled plugins with the failing config-path → schema-rule that caused it.
• Other plugins, channels, and gateway are unaffected.
• openclaw doctor --fix either prompts to seed a valid value OR strips the offending field and re-validates.

Workaround we use today

Make every plugin config field optional and runtime-check in the tool's execute(). Throw a friendly user-visible error from the tool if a required field is missing. This works but means plugin authors lose the ergonomics of declarative schema validation and must re-implement validation imperatively in every tool entry-point.

Related downstream work

• sidekykai/sidekyk-verticals#55 — plugin that triggered this (community-feedback). We're also patching the plugin to make communityRepo optional as a workaround until upstream lands a fix.

Severity

Medium-to-high. Single-plugin config bugs cause tenant-wide outage. Workaround exists but adds boilerplate to every plugin and gives up declarative validation.