Native ScreenCaptureKit call recording captures audio but does not start live-transcription sidecar

[silverstein]

Summary

Starting a desktop recording from the Zoom Call detected flow selects native ScreenCaptureKit call capture. The recording successfully captures both microphone and system audio, but it does not start or feed the recording live-transcription sidecar. As a result, live Sidekick/Coach consumers receive no transcript during the meeting even though the final post-stop transcription succeeds.

A manual recording started immediately afterward in the production app selected the standard audio-capture path and produced live transcript events normally. This makes the failure specific to the native-call capture path, not microphone permissions or audio availability.

Environment

• macOS
• Zoom desktop call
• Minutes Dev bundle: com.useminutes.desktop.dev, version 0.23.0
• Minutes production bundle: com.useminutes.desktop, version 0.23.0
• Both bundles have com.apple.security.device.audio-input entitlement
• Reproduced: 2026-07-27

Reproduction

1. Join a Zoom meeting.
2. In Minutes Dev, use the Call detected recording action.
3. Confirm recording is active.
4. Check minutes transcript --status during the meeting.
5. Speak and allow remote participants to speak.
6. Stop the recording and allow final processing to complete.
7. Start a manual recording in Minutes production during the same meeting and compare live transcript status.

Actual behavior

Native-call recording (Minutes Dev)

The recording-start event advertised only native-call capabilities:

{
  "event_type": "recording.started",
  "source": "capture",
  "capabilities": [
    "native-call.capture",
    "screen-capture-kit",
    "mode.meeting"
  ]
}

During the recording:

{
  "active": false,
  "line_count": 54,
  "diagnostic": "sidecar status unavailable"
}

No fresh live.utterance.final events were emitted for that session.

However, the stopped capture produced a healthy 91-second native-call artifact with separate stems:

• Voice stem: mean -34.8 dB, max -13.3 dB
• System stem: mean -23.3 dB, max -3.8 dB
• Post-stop Whisper processing: 28 segments / 183 words
• Final artifact: 211 words

This proves microphone and system-audio capture were functioning.

Manual recording control (Minutes production)

The immediately following manual recording advertised:

{
  "event_type": "recording.started",
  "source": "capture",
  "capabilities": [
    "audio.capture",
    "live.utterance.final",
    "mode.meeting"
  ]
}

Its live status became healthy and live.utterance.final events arrived during the meeting.

Expected behavior

A desktop recording started through native ScreenCaptureKit call capture should provide the same live-transcription contract as the standard recording path:

• start the recording sidecar;
• feed it an appropriate live stream derived from the native microphone/system stems;
• write live-transcript-status.json and live-transcript.jsonl;
• emit live.utterance.final events;
• include live.utterance.final in the recording.started capabilities when available.

If live transcription cannot be supported on the native path, the UI and capability contract should state that explicitly instead of allowing Sidekick/Coach to silently attach to an audio recording with no live evidence.

Likely code gap

The standard capture functions in crates/core/src/capture.rs call start_live_sidecar(...) and feed captured samples through live_tx.

The native desktop path in tauri/src-tauri/src/commands.rs::start_native_call_recording starts the ScreenCaptureKit helper and emits native-call.capture / screen-capture-kit, but does not start or feed the live sidecar.

This appears to be an architectural wiring gap rather than a TCC permission failure.

Impact

High for live-assistance workflows: the durable recording succeeds, but terminal Sidekick and Coach silently receive no live transcript on the primary native desktop call-capture path.

[silverstein]

Confirmed in code, and the fix is more tractable than a full rebuild. Notes:

Verified gap. start_native_call_recording (commands.rs) never calls start_live_sidecar; the standard path (capture.rs:1184/1603) does. The sidecar itself is already decoupled — start_live_sidecar just returns an mpsc SyncSender<Vec<f32>> and runs live_transcript::run_sidecar_mpsc on its own thread, consuming 16 kHz mono f32 chunks. It does not care where samples come from.

Why it's tractable (Rust-only). The Swift helper (system_audio_record.swift) already writes the voice/system stems incrementally via writeStemSamples on each didOutputSampleBuffer; stdout carries only JSON status. And call_capture.rs already exposes stem_paths(), annotated // used once pipeline stem attribution is wired up. So the fix is a stem-tailer: a failure-isolated thread that tails the growing stem WAV(s) from the known data offset (the header stays unfinalized until stop, per #519, but the PCM is written progressively), downmixes/resamples to 16 kHz mono via the existing resample helper, and feeds live_tx. No Swift changes, no dev-app rebuild loop; everything downstream (streaming whisper, live JSONL, the relay Sidekick/Coach attach to) is reused. Must honor the capture-reliability invariant: if the tailer wedges, capture and stem preservation continue untouched.

Plan:

1. 0.23.1 (now): honesty fix. Until live works on this path, make the capability gap explicit so Sidekick/Coach don't silently attach expecting a transcript.
2. Next release: the stem-tailer, built with synthetic growing-WAV fixtures (unit-testable in isolation) plus a one-time real-Zoom-call verification, and live.utterance.final added to the native recording.started capabilities once the sidecar is live.

Building on feat/native-call-live-transcript.