Best possible solution:

Resolve BlueBubbles password SecretRefs through the runtime secret-resolution contract before webhook auth comparison, then add focused regression coverage and a changelog entry.

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

Yes, by source inspection: current main accepts SecretRef passwords but the webhook auth callback calls .trim() on the password value. I did not run a live Vitest reproduction, so this is source-reproducible rather than directly reproduced.

Is this the best way to solve the issue?

No. The direction is right, but this diff swaps the crash for fail-closed authentication because normalizeSecretInputString() does not resolve SecretRefs; the maintainable fix should compare against an actually resolved password string.

Full review comments:

• [P2] Resolve the SecretRef before comparing the webhook token — extensions/bluebubbles/src/monitor.ts:197
  The new call still does not resolve SecretRef objects: normalizeSecretInputString() returns undefined for any non-string, so a configured SecretRef becomes "" and safeEqualAuthToken() always fails. This prevents the reported SecretRef-backed webhook password from authenticating; use the runtime secret-resolution path or a resolved account value before this comparison.
  Confidence: 0.93
• [P3] Add the required changelog entry — extensions/bluebubbles/src/monitor.ts:197
  This is a user-facing fix for a shipped BlueBubbles plugin auth regression, but the PR only changes monitor.ts. Repo policy requires a CHANGELOG.md entry for user-facing fix changes, so the release notes would miss this fix.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.88

Acceptance criteria:

• pnpm test extensions/bluebubbles/src/monitor.webhook-auth.test.ts
• pnpm exec oxfmt --check --threads=1 extensions/bluebubbles/src/monitor.ts extensions/bluebubbles/src/monitor.webhook-auth.test.ts CHANGELOG.md
• pnpm check:changed

What I checked:

• Current main crash path: Webhook auth currently calls .trim() directly on target.account.config.password, while BlueBubbles config accepts password through buildSecretInputSchema(), so a raw SecretRef object can reach a string-only operation. (extensions/bluebubbles/src/monitor.ts:196, 5f5e0a3633c2)
• SecretRef is an accepted BlueBubbles password shape: Existing tests assert that a SecretRef password is treated as configured and accepted by the BlueBubbles config schema when serverUrl is set. (extensions/bluebubbles/src/setup-surface.test.ts:306, 5f5e0a3633c2)
• Proposed helper does not resolve SecretRefs: normalizeSecretInputString() returns undefined for any non-string input, so the PR's changed line would turn a SecretRef object into an empty auth token instead of resolving it to the configured password. (src/config/types.secrets.ts:139, 5f5e0a3633c2)
• Runtime secret-resolution contract exists: BlueBubbles declares channels.bluebubbles.password and account passwords as secret_input string targets, and the runtime assignment helper applies resolved secret values back into config before use. (extensions/bluebubbles/src/secret-contract.ts:8, 5f5e0a3633c2)
• PR surface lacks changelog: The provided PR file list contains only extensions/bluebubbles/src/monitor.ts, but this is a user-facing fix for a shipped BlueBubbles plugin regression. (690462114cb9)

Likely related people:

• Vincent Koc: Available local history blames the webhook auth block, the secret-input helper, and the relevant BlueBubbles files to commit bcfa5bc32b787fce5ce40afd300562559c50f6a9; this is the clearest routing signal in the checkout. (role: introduced behavior / recent maintainer; confidence: medium; commits: bcfa5bc32b78; files: extensions/bluebubbles/src/monitor.ts, src/config/types.secrets.ts, extensions/bluebubbles/src/secret-contract.ts)

Remaining risk / open question:

• The exact path that let a raw SecretRef reach the external BlueBubbles webhook target still needs confirmation; the final fix may need to touch runtime secret-contract loading or account startup, not only the auth callback.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 5f5e0a3633c2.