Summary

• Problem: BlueBubbles config validation had two sources of truth: the plugin-owned schema in extensions/bluebubbles/src/config-schema.ts and a duplicate strict schema in src/config/zod-schema.providers-core.ts.
• Why it matters: adding a valid BlueBubbles plugin config field could still fail core OpenClawSchema.safeParse with must NOT have additional properties, as seen with channels.bluebubbles.sendTimeoutMs in Architecture: remove duplicate BlueBubbles schema in core (boundary violation) #69238.
• What changed: removed the duplicate core BlueBubbles schema, exposed the plugin-owned raw schema through extensions/bluebubbles/channel-config-api.ts, and pointed the inherited-allowlist regression test at that plugin-owned schema.
• What did NOT change (scope boundary): did not refactor other channel schemas, generated channel metadata, runtime config normalization, or BlueBubbles runtime behavior.

Change Type (select all)

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

Scope (select all touched areas)

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

Linked Issue/PR

• Closes Architecture: remove duplicate BlueBubbles schema in core (boundary violation) #69238
• Related fix(bluebubbles): configurable sendTimeoutMs, bump send default to 30s #69193
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: channels.bluebubbles.sendTimeoutMs should not be rejected by the duplicate core BlueBubbles schema.
• Real environment tested: local OpenClaw checkout on Linux, Node 22.16.0.
• Exact steps or command run after this patch: pnpm exec tsx -e 'import { OpenClawSchema } from "./src/config/zod-schema.ts"; import { validateConfigObjectRaw } from "./src/config/validation.ts"; const cfg={channels:{bluebubbles:{serverUrl:"http://localhost:1234",password:"secret",sendTimeoutMs:45000}}}; const core=OpenClawSchema.safeParse(cfg); console.log(JSON.stringify({core:core.success, raw:validateConfigObjectRaw(cfg,{validateBundledChannels:true}).ok}));'
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Console output from a local OpenClaw checkout after this patch:

  {"core":true,"raw":false}
  

  The core schema no longer rejects the BlueBubbles plugin field; the remaining raw JSON-schema failure is the existing generated metadata requirement for enrichGroupParticipantsFromContacts.
• Observed result after fix: Console output after adding the generated-required field:

  {"ok":true}
  

  Raw bundled-channel validation accepts the same sendTimeoutMs config through the plugin/generated validation path.
• What was not tested: live BlueBubbles server messaging, because this change only removes duplicate config schema ownership.
• Before evidence (optional but encouraged): issue Architecture: remove duplicate BlueBubbles schema in core (boundary violation) #69238 documents openclaw config set channels.bluebubbles.sendTimeoutMs 45000 failing with must NOT have additional properties from the duplicate strict core schema.

Root Cause (if applicable)

• Root cause: core carried a BlueBubbles-specific strict Zod schema that duplicated the plugin-owned schema and drifted from it.
• Missing detection / guardrail: the existing regression test imported the core duplicate instead of asserting against the plugin-owned config schema surface.
• Contributing context (if known): plugin-owned fields also flow through generated bundled-channel metadata, so duplicating the schema in core created an unnecessary extra validation surface.

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/config/config.allowlist-requires-allowfrom.test.ts
• Scenario the test should lock in: BlueBubbles account-level allowlist validation uses the plugin-owned schema exported from extensions/bluebubbles/channel-config-api.ts, not a duplicate core schema.
• Why this is the smallest reliable guardrail: it keeps the existing inherited-allowlist behavior assertion while removing the core schema dependency that caused drift.
• Existing test that already covers this (if any): extensions/bluebubbles/src/setup-surface.test.ts covers BlueBubbles plugin schema behavior directly.
• If no new test is added, why not: existing coverage was updated to use the correct owner surface; no new behavior was added.

User-visible / Behavior Changes

BlueBubbles plugin config fields are no longer blocked by a duplicate core-only schema before plugin/generated channel validation runs.

Diagram (if applicable)

Before:
channels.bluebubbles.* -> OpenClaw core BlueBubbles schema -> plugin/generated schema

After:
channels.bluebubbles.* -> generic channels config -> plugin/generated schema

Security Impact (required)

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

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Node 22.16.0, local checkout
• Model/provider: N/A
• Integration/channel (if any): BlueBubbles config schema
• Relevant config (redacted): channels.bluebubbles.serverUrl, channels.bluebubbles.password, channels.bluebubbles.sendTimeoutMs

Steps

1. Parse a config containing channels.bluebubbles.sendTimeoutMs through OpenClawSchema.safeParse.
2. Parse a generated-compatible BlueBubbles config through validateConfigObjectRaw(..., { validateBundledChannels: true }).
3. Run focused tests and the changed gate.

Expected

• Core config validation does not reject BlueBubbles plugin-owned fields.
• Bundled channel validation still uses the plugin/generated schema path.
• Focused tests and changed gate pass.

Actual

• OpenClawSchema.safeParse returned core: true for the BlueBubbles sendTimeoutMs repro.
• Raw bundled-channel validation returned ok: true when the generated-required enrichGroupParticipantsFromContacts field was present.
• Focused tests, formatting, and changed gate passed.

Evidence

Attach at least one:

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

Verification commands run:

pnpm docs:list
pnpm test src/config/config.allowlist-requires-allowfrom.test.ts extensions/bluebubbles/src/setup-surface.test.ts src/config/zod-schema.providers.lazy-runtime.test.ts src/config/bundled-channel-config-runtime.test.ts
pnpm exec tsx -e 'import { OpenClawSchema } from "./src/config/zod-schema.ts"; import { validateConfigObjectRaw } from "./src/config/validation.ts"; const cfg={channels:{bluebubbles:{serverUrl:"http://localhost:1234",password:"secret",sendTimeoutMs:45000}}}; const core=OpenClawSchema.safeParse(cfg); console.log(JSON.stringify({core:core.success, raw:validateConfigObjectRaw(cfg,{validateBundledChannels:true}).ok}));'
pnpm exec tsx -e 'import { validateConfigObjectRaw } from "./src/config/validation.ts"; for (const cfg of [{channels:{bluebubbles:{serverUrl:"http://localhost:1234",password:"secret",sendTimeoutMs:45000}}},{channels:{bluebubbles:{serverUrl:"http://localhost:1234",password:"secret",sendTimeoutMs:45000,enrichGroupParticipantsFromContacts:true}}}]) { const res=validateConfigObjectRaw(cfg,{validateBundledChannels:true}); console.log(JSON.stringify(res.ok ? {ok:true} : {ok:false,issues:res.issues.slice(0,4)})); }'
pnpm exec oxfmt --check --threads=1 CHANGELOG.md src/config/zod-schema.providers-core.ts src/config/config.allowlist-requires-allowfrom.test.ts extensions/bluebubbles/channel-config-api.ts
pnpm check:changed --base upstream/main --dry-run
OPENCLAW_LOCAL_CHECK=1 OPENCLAW_LOCAL_CHECK_MODE=throttled pnpm check:changed --base upstream/main --timed

Key output:

{"core":true,"raw":false}
{"ok":false,"issues":[{"path":"channels.bluebubbles.enrichGroupParticipantsFromContacts","message":"invalid config: must have required property 'enrichGroupParticipantsFromContacts'"}]}
{"ok":true}
[test] passed 2 Vitest shards in 40.12s
[check:changed] summary ... all ok

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: duplicate core schema removed; BlueBubbles plugin-owned schema is exported through the public config artifact; regression test now imports the plugin-owned schema; repro confirms core no longer rejects sendTimeoutMs.
• Edge cases checked: raw bundled-channel validation still runs and still enforces generated metadata requirements.
• What you did not verify: live BlueBubbles server send/receive behavior.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

• Risk: removing the exported core BlueBubbles schema could break an internal test import.
  • Mitigation: rg confirmed the only remaining consumer was moved to extensions/bluebubbles/channel-config-api.ts; core and extension typechecks passed.
• Risk: validation could accidentally skip BlueBubbles config checks.
  • Mitigation: raw bundled-channel validation repro and existing bundled-channel runtime tests confirm the plugin/generated schema path remains active.