[jdustinlewis]

Fixes #2278. Needs #2281 for back-to-back calls (see "Why testing was inconsistent" below).

Why

Auto-call detection doesn't recognize Helium. Helium's mic and playback run on one shared helper (net.imput.helium.helper), which the main browser and every installed shortcut (net.imput.helium.app.*) all use. So "the helper has the mic" doesn't mean "this is Meet", and "the Meet shortcut is running" doesn't mean "a call is on". Details are in #2278.

Product Impact

• Affects: meetings
• Lane: meeting reliability
• Why this matters: these calls get joined from Helium. If the prompt can't be trusted, recordings get missed or auto-detect gets turned off.

What changed

• MeetingPromptProvider.browserBundleIDPrefixes now includes net.imput.helium. The mic check, the probe filter and the calendar "meeting tab is active" check all use that one list. The exact browser-ID set on the runtime snapshot is gone.
• Only the frontmost app's window counts as focused, and the frontmost app gets read first. A ChatGPT tab sitting in the background doesn't count.
• A Chromium shortcut's start URL is classified and then dropped; it's never stored or logged. A Meet shortcut counts as a call site if it's in front, or if it opened within 15 s of the mic starting. Chat, Calendar and Gmail shortcuts never count.
• Going back to a call-site window clears an early "not a call" sticky. Switching to an ordinary page doesn't.
• The first title read holds the prompt for at most 1 s, so a hung Accessibility read can't keep a real call quiet.
• Spec notes are in docs/auto-call-detection-spec.md.

Why testing was inconsistent

Earlier live tests kept going the same way: the first Meet call prompted, and later calls never did. It looked like a Helium detection problem, but it wasn't.

Hitting Record on a detected call muted prompts for that provider for 30 minutes (or until the matching calendar event ended), and the mute stayed on after the call ended. So the first call prompted, and every Meet call after it within 30 minutes stayed quiet, whatever Helium was doing. A watch of mic owners showed it plainly: Helium's helper held the mic for minutes with Helium in front, and no prompt showed. Skip and Remind me set their own mutes too, which explains the earlier runs where the prompt was dismissed instead.

That's a main bug that affects every app, so it's fixed separately in #2281 (issue #2280). Without #2281, this PR still prompts for the first call, but not the next one within 30 min.

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 at a1d87fa89: all 50,121 tests passed. Its build.sh step refused to rebuild over the test app that was running, so the build ran separately, below)
• bash build.sh --no-open at a1d87fa89, in a clean worktree: passed
• bash run-tests.sh filtered: BrowserCallEvidence 85/85, MeetingPromptDetector 153/153, MeetingPromptHeuristics 128/128, MicActivityMonitorProbeFilter 40/40
• 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: real Helium Meet calls on a build of this branch plus Let the next call prompt after a recorded call ends #2281 (2026-10-30). Results below. That build came before the review fixes in a1d87fa89. They're small and covered by tests, but haven't been live-tested.

Live results:

Scenario	Result
Meet in a Helium tab, several calls in a row, each one recorded	prompts each time, within seconds
Meet in the installed Meet app (shortcut), several calls	prompts each time, after about a minute
ChatGPT voice for over 1 min, Meet app idle on its home screen in the background	no prompt
Meet app home screen brought to the front while ChatGPT voice holds the mic	prompts (known limitation, below)

A second quiet run (ChatGPT for 2+ min, then the Meet home screen for 1–2 min) also stayed quiet. That one doesn't prove much, though: it came right after the false prompt above, and how that prompt was answered affects what happens next.

The Meet app is slower because its window title doesn't use the in-call pattern a tab does, so it falls back to waiting for steady mic use.

Checks I could not run, and why:

• run-integration-smoke.sh wasn't run on its own; check.sh picked the checks for this diff.
• No test on a calendar-link join through the shortcut since the latest build.

Mac or hardware test still needed? Only to recheck the rows above on another Mac. Steps: Helium plus Accessibility permission, then each scenario in the table. On main, none of the call rows prompt, because Helium isn't recognized.

Known limitation

If you bring the Meet app forward while it's on its home screen and another Helium tab (ChatGPT voice) holds the mic, the app prompts. The shortcut's title looks the same on the home screen as in a call, and the "Meet shortcut in front counts as a call site" rule takes over. It's a narrow case (you have to switch to Meet while something else is talking) and was accepted for this PR. Dropping that rule is the likely fix if it turns out to matter. The Meet app already takes about a minute to prompt, which suggests real calls aren't relying on that rule.

Risk Review

• Privacy / local-first behavior reviewed: no window titles, meeting names or shortcut URLs are logged, stored or sent.
• 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 three P2s, all fixed in a1d87fa89 with tests that fail without each fix: a 1 s title-read cap that never fired on its own; a Meet shortcut claiming another browser's mic, or claiming after it quit; and calendar "meeting tab is active" counting every Chrome/Safari web app. The second round came back clean
• UI changes: none
• No private transcripts, audio, tokens, personal paths, or customer data are included

Notes

• The first commit message still says "WIP". Squash-merging will replace it with this PR's title.
• com.apple.CoreSpeech shows up holding the mic beside the Helium helper in every call. It didn't affect detection, and I didn't look into it further.

🤖 Generated with Claude Code