[jdustinlewis]

Fixes #2280.

Why

When you hit Record on a detected call, markAccepted mutes prompts for that provider until the matching calendar event ends (+5 min). With no event, the mute lasts 30 min. The mute stayed on after the call ended, so the next call of the same kind never prompted. Back-to-back meetings hit this most. Seen live: one recorded Meet call, then three more Meet calls over the next 7 minutes, and none of them prompted.

Product Impact

• Affects: meetings
• Lane: meeting reliability
• Why this matters: a prompt that doesn't show for the second meeting of the day means that meeting doesn't get recorded. It affects every provider (Zoom, Teams, browser calls), not just Meet.

What changed

• When the detected-call session ends and no recording is running, Record's mute drops to recordedCallEndGrace (60 s), with one re-check scheduled at that point. A mic flap at hang-up stays quiet, and the next call prompts.
• If the session ends while a recording is still running, it could be a mute: Safari lets go of the mic on mute. So the mute stays on until a session ends, or a new one starts, with the recording stopped.
• A recorded calendar event keeps its own snooze, so its reminder doesn't come back.
• stop() now cancels the re-check.
• Sources/Meeting/AGENTS.md describes the rule.

How I checked it

• scripts/dev/agent-preflight.sh
• bash scripts/dev/linux-checks.sh (runs without Swift)
• Selected checks from .agents/test-matrix.yml for the files changed (bash check.sh: deterministic proof PASS, 50,077 tests passed)
• bash build.sh --no-open
• bash run-tests.sh --filter MeetingPromptDetector: 147/147. Four new tests:
  • the next call prompts after a recorded call ends
  • a mic flap inside the grace stays quiet
  • a mute while recording keeps the recorded call quiet after Stop
  • hanging up before Stop still lets the next call prompt
• The new tests fail without the fix (1 fails with the cut disabled, 2 fail with the recording check removed)
• Performance budget passed
• bash run-integration-smoke.sh if I touched Sources/Meeting/ or Sources/TranscriptedCore/
• swift test if I touched Package.swift, Sources/TranscriptedCore/, or the public core seam
• bash run-e2e-smoke.sh / swift test --package-path Tools/<Package> if the matrix maps them
• Manual check:

Checks I could not run, and why:

• Real back-to-back calls with this build. The bug itself was reproduced live on 2026-10-30, on a build without this fix.
• run-integration-smoke.sh and build.sh weren't run on their own; check.sh picked what to run for this diff.

Mac or hardware test still needed? Yes:

1. Join a Meet or Zoom call, hit Record on the prompt, stop recording, and leave. Then join another call of the same kind within a minute or two. Expected: a prompt within about 60 s of leaving the first call. On main: no prompt for 30 min.
2. Same, but leave the call before hitting Stop, then stop, then join the next call. Expected: a prompt right away. On main: no prompt.
3. In Safari, record a Meet call, mute for a while, unmute, and hit Stop while still in the call. Expected: no prompt for that call. (main also stays quiet here; this checks the fix didn't break it.)

Risk Review

• Privacy / local-first behavior reviewed: no new logging, analytics, or telemetry
• No new analytics properties or Sentry tags
• Checked the text-pin tests for every file I edited (check-source-pins.py --changed-only: pass)
• Storage path or migration impact reviewed: none
• Public-facing copy: none changed
• Release/update impact: none
• Agent PRs got an independent deep review of the full diff: two rounds of independent Claude review. The first found a P2 (a mid-call mute could make the recorded call prompt again after Stop), which is fixed and has tests. The second came back clean.
• UI changes: none
• No private transcripts, audio, tokens, personal paths, or customer data are included

Notes

• Known edge, accepted: in Safari, mute while recording, hit Stop while still muted, then unmute. That counts as a new call and prompts.
• Also accepted: hang up while recording, then a mic flap from the old call arrives after Stop. That prompts right away, because the detector can't tell it apart from a back-to-back call.
• Found while testing Helium support (Prompt to record a Helium Google Meet call, including the Meet shortcut #2278, draft Prompt to record Helium Google Meet calls, including the Meet shortcut #2279). This fix doesn't depend on that work.

🤖 Generated with Claude Code