Best possible solution:

Keep the extension-owned approach, but regenerate the bundled channel config metadata and any required config baselines, then confirm the BlueBubbles endpoint against a real supported server or adjust docs/default behavior to the actual shipped upstream contract before maintainer approval.

Do we have a high-confidence way to reproduce the issue?

Do we have a high-confidence way to reproduce the issue? Yes for the current-main gap and the generated-metadata drift: rg shows the feature absent on main, and the generated BlueBubbles schema lacks the newly documented key while validation consumes that generated schema. The successful transcript-fetch path remains unclear because it is only unit-mocked and not live-verified in the PR body.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Unclear in its current form: keeping the behavior in the BlueBubbles plugin and using the existing ctx.Transcript hook is the right boundary, but the generated config surface and upstream endpoint proof need to be fixed before this is a maintainable default-on feature.

Full review comments:

• [P2] Regenerate bundled channel config metadata — extensions/bluebubbles/src/config-schema.ts:111
  Adding inboundAudioEnricher only to the runtime zod schema leaves the generated BlueBubbles channel schema stale. Config validation seeds bundled channel schemas from src/config/bundled-channel-config-metadata.generated.ts and that generated schema still has additionalProperties: false, so channels.bluebubbles.inboundAudioEnricher can be rejected or omitted from schema/UI surfaces. Please run the channel config metadata generator and commit the generated output.
  Confidence: 0.91
• [P2] Prove the BlueBubbles transcript endpoint before shipping — docs/channels/bluebubbles.md:550
  The docs promise BlueBubbles Server v1.14.0+ support for /api/v1/message/audio-transcript/:guid, but the public BlueBubbles Server releases I inspected currently top out at v1.9.9 and the public message router source does not expose this route. Since the PR only live-verifies the 404 fallback, this may ship a default-on feature that silently no-ops for current upstream users. Please link or test against the upstream implementation/release, or scope the docs/default to the patched deployment that actually provides the endpoint.
  Confidence: 0.76

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm config:channels:check
• pnpm config:schema:check
• pnpm config:docs:check
• pnpm test extensions/bluebubbles
• pnpm tsgo:extensions

What I checked:

• PR diff inspected: The diff adds channels.bluebubbles.inboundAudioEnricher, the new audio transcript client/enricher path, monitor-processing wiring, docs, changelog, and tests. (extensions/bluebubbles/src/config-schema.ts:111, 4b0d9db0caee)
• Generated channel metadata is stale: The generated BlueBubbles schema still ends its properties without inboundAudioEnricher and keeps additionalProperties: false, so the documented opt-out field is absent from generated metadata. (src/config/bundled-channel-config-metadata.generated.ts:641, ffcc0d1fe171)
• Validation uses generated channel schemas: Config validation seeds bundled channel schemas from GENERATED_BUNDLED_CHANNEL_CONFIG_METADATA and validates channels.<id> with that JSON schema, so stale generated metadata can reject the new BlueBubbles config key. (src/config/validation.ts:928, ffcc0d1fe171)
• Runtime config schema also relies on metadata: Runtime config schema loading avoids importing bundled channel config-schema modules on schema requests and builds channel schemas from collected manifest/metadata entries. (src/config/runtime-schema.ts:18, ffcc0d1fe171)
• Current main lacks this feature: Current main has no inboundAudioEnricher, audio-transcript, getAudioTranscript, or BlueBubbles-specific audio attachment helper in OpenClaw code/docs. (ffcc0d1fe171)
• Existing transcript hook path supports the PR direction: The existing pre-agent hook emits message:transcribed when ctx.Transcript is populated, so the PR's no-new-SDK-seam approach matches current hook plumbing. (src/auto-reply/reply/message-preprocess-hooks.ts:25, ffcc0d1fe171)

Likely related people:

• @steipete: Recent current-main commits touched the BlueBubbles monitor/client/config surface and generated config metadata/validation-adjacent paths, including the latest broad BlueBubbles refactor visible in blame. (role: recent maintainer and generated-config adjacent owner; confidence: high; commits: 4987482e4c54, 1c300cec5d80; files: extensions/bluebubbles/src/monitor-processing.ts, extensions/bluebubbles/src/client.ts, extensions/bluebubbles/src/config-schema.ts)
• @coletebou: Introduced the recent BlueBubbles reply-context API fallback across the same account config and monitor-processing area this PR extends. (role: recent BlueBubbles feature owner; confidence: medium; commits: 76930da7ebc7; files: extensions/bluebubbles/src/monitor-processing.ts, extensions/bluebubbles/src/config-schema.ts)
• @omarshahine: Appears in prior merged BlueBubbles reply-context work as a co-author/reviewer, beyond authoring this PR, so they are a plausible domain follow-up person. (role: adjacent current-main contributor/reviewer; confidence: medium; commits: 76930da7ebc7; files: extensions/bluebubbles/src/monitor-processing.ts, extensions/bluebubbles/src/config-schema.ts)

Remaining risk / open question:

• The PR's success path depends on an upstream audio-transcript endpoint that was not found in the public BlueBubbles Server source/release data inspected, and the PR body says a successful BB >= claimed-version live run is still missing.
• The new config key is documented but absent from generated bundled-channel metadata, which can make the opt-out invalid or invisible in config/schema surfaces until regenerated.
• One public check run for the PR head is failing (check-additional), so merge readiness still needs CI follow-up even after code fixes.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 42d73fd955af.