Greptile Summary

This PR adds a preflight audio transcription step to WhatsApp DM voice note processing, mirroring the existing fix applied to Telegram in #61008. The implementation correctly follows the lazy-loading boundary pattern (audio-preflight.runtime.ts), is non-fatal on transcription failure, and is covered by 7 targeted unit tests spanning success, error, and guard-condition scenarios. No new SDK surface is added and all other channel behaviors are untouched.

Confidence Score: 5/5

This PR is safe to merge; the change is narrowly scoped, non-fatal on failure, and all remaining observations are P2 style notes.

Implementation mirrors a proven Telegram pattern exactly, follows the lazy-loading boundary convention, is guarded by three independent conditions, and is covered by 7 targeted unit tests. No P0 or P1 findings. The only minor observation (redundant ternary inside the mediaType guard) is cosmetic and correct.

No files require special attention.

_{Reviews (1): Last reviewed commit: "WhatsApp: add preflight audio transcript..." | Re-trigger Greptile}

Re: Aisle Security Analysis — Unauthorized audio transcription preflight executed before access-control gating

The preflight transcription does not execute before access-control gating. By the time processMessage is called, the message has already cleared all channel-level access controls:

• Group messages: on-message.ts calls applyGroupGating() (line 129) before processMessage is ever reached. Messages that fail gating return early at line 145 (if (!gating.shouldProcess) return).
• DM messages: routing and pairing-policy checks are applied at the resolveAgentRoute / channel dispatch layer before processMessage is invoked.

processMessage is the post-gating processing stage — it only handles messages that have already been admitted by the channel access model.

Additionally, the audio transcription is strictly subordinate to the existing LLM call: every message that reaches processMessage already triggers dispatchWhatsAppBufferedReply → model inference, which is a significantly larger API surface than a single STT call. If unauthorized senders were able to reach this stage, the DoS and privacy exposure from the model call would far exceed that of the preflight transcription.

No trust boundary is being crossed here. The preflight mirrors the existing behavior for Telegram (in production since #61008) and Discord, which apply the same pattern in the same post-gating position.

Re: Aisle Security Analysis — Round 2

Issue 2 (Medium — loose MIME check): Fixed.

Changed mediaType?.includes("audio") to mediaType?.startsWith("audio/") in the amended commit (d801b6514b). This eliminates the false-positive surface for crafted MIME strings like application/notaudio-but-contains-audio. All 8 regression tests still pass.

Issue 1 (High — no timeout/size limits): Out of scope for this PR.

The concern is valid in the abstract, but this PR is a parity fix that mirrors the existing Telegram preflight (shipped in #61008) and Discord, both of which use the same inline await transcribeFirstAudio(...) pattern without per-call timeouts or size guards. Introducing those controls here (and not there) would create an inconsistent, partially-hardened surface — the real fix would be adding resource controls to the shared transcribeFirstAudio SDK primitive itself so all channels benefit equally.

Additionally, resource limits at the media download layer (maxMediaBytes) already constrain what gets saved to mediaPath before this code is reached.

If maintainers agree that timeout/concurrency controls belong at the SDK primitive level, I'm happy to file a follow-up issue. Adding them only to the WhatsApp path in this PR would be scope creep relative to the fix goal.

Re: CI failures — all pre-existing on `main`, unrelated to this PR

The three failing checks (check, check-additional, checks-node-test) were already failing on main at the time this PR was submitted. None of the failures touch any file modified by this PR.

This PR only touches five files under extensions/whatsapp/src/auto-reply/monitor/, all of which pass their own dedicated check (extension-fast-whatsapp ✅).

I've also rebased onto the latest main to keep the branch current.

Re: Aisle Security Analysis — Issue 1 (transcript in logs)

The two log lines flagged by Aisle (body: elide(combinedBody, 240) and mediaPath) are not new — they exist verbatim in the pre-PR baseline on main (process-message.ts L242–L244). This PR does not add, move, or change either log call.

What this PR does change is the value of combinedBody for audio messages: previously it was always <media:audio> (the literal placeholder), now it may contain the transcript. The log call itself is untouched.

A few additional mitigations already present:

• elide(combinedBody, 240) caps the logged string at 240 characters regardless of transcript length.
• mediaPath is logged the same way for every inbound message type — text, image, video, audio — before and after this PR.
• Every message that reaches processMessage has already triggered a full LLM inference call via dispatchWhatsAppBufferedReply, which is a significantly larger surface than a single STT call. If transcript content in logs were the concern, the model call payload would be the primary vector.

If the project wants to treat transcripts as sensitive and avoid logging them by default, that is a valid improvement — but the correct fix is to audit elide/replyLogger.info across all channels (WhatsApp, Telegram, Discord) and possibly add a redaction helper to the shared logging layer. Doing it only on the WhatsApp audio path here would create an inconsistent, partially-hardened surface. I'm happy to file a follow-up issue for that work if maintainers agree it belongs at the SDK/logger level.

Re: checks-windows-node-test failure — CI infrastructure flake, unrelated to this PR

The failure occurred at the Download dist artifact step before any test code ran. The Windows runner made 5 attempts to fetch the dist-build artifact and received an HTML error page each time instead of a valid JSON response — a known symptom of a transient GitHub Actions artifact service outage.

Attempt 1 of 5 failed: Unexpected token '<', "<html>..." is not valid JSON
Attempt 2 of 5 failed: ...
(all 5 attempts failed)

The build-artifacts job completed successfully in the same run, so the artifact was correctly produced. The Windows runner simply could not reach it due to a backend blip. No test code was executed.

Requesting a re-run of the failed job.

Thanks — I addressed the Codex review items in follow-up amendments.

Current state:

• preflight transcription is now computed before broadcast fan-out, so one inbound voice note does not trigger duplicate STT per target agent
• the downstream path carries explicit preflight state via preflightAudioTranscript
• string | null is used to distinguish “preflight attempted but no transcript” from “preflight not attempted”, avoiding retry-based duplicate transcription on failure paths

The PR remains scoped to WhatsApp DM voice-note preflight only, with no routing or group-behavior changes. Happy to revise further if you'd like this shaped differently.

Merged via squash.

• Prepared head SHA: 7480b339da6ffa520a1852de1956989c72ca7e89
• Merge commit: ea168c22ce8bca99ef8801278614b1928c67f943

Thanks @rogerdigital!