I often use my Mac while listening to a podcast from my iPhone through my AirPods. I found that when I triggered Handy in that situation, the recording overlay behaved normally but Handy captured nothing. There was no error, no transcription, and nothing in History. I would only discover after I had finished speaking that everything I had said was gone, which was very frustrating.
It took me a while to connect this to the AirPods. The problem occurs consistently when my iPhone is playing audio through them, even though the Mac still shows them as connected. Stopping playback on the iPhone makes Handy work again immediately.
Steps to reproduce
- Make the same AirPods available to both an iPhone and a Mac with automatic switching enabled.
- Play audio from the iPhone through the AirPods.
- On the Mac, start a Handy recording using the AirPods microphone.
- Speak for several seconds, then stop the recording.
Expected: The Mac takes control of the AirPods microphone and Handy creates a transcription.
Actual: The overlay behaves normally, but Handy captures no audio, creates no transcription, and saves nothing to History.
Investigation
I reproduced the problem with a small CoreAudio test client. The input stream appears healthy: callbacks fire, buffers arrive in real time, and no errors are reported. However, every audio sample is exactly zero. As a control, recording from the Mac's built-in microphone under the same conditions produces normal audio, which isolates the failure to the AirPods route.
The built-in Apple apps QuickTime Player and Voice Memos do not have the problem. Starting a recording in either app stops playback on the iPhone and allows the Mac to capture microphone audio from the AirPods.
Inspecting QuickTime's audio-only recording path showed that it keeps a muted output path open alongside the microphone input. Opening a silent output stream on the same AirPods for the lifetime of Handy's recording produces the same result and fixes the problem.
I have been using a patched build with this change during normal use. Starting a Handy recording now stops playback on the iPhone and captures the transcription.
I could not find documented guidance explaining why the concurrent output stream is required, or a documented, supported API for asking macOS to take control of the AirPods microphone from another Apple device.
Related issues
#1886 discusses the Bluetooth playback tradeoff when using an AirPods microphone.
#1899 also involves an empty transcription, but its recording contains a non-zero number of samples. In this case the sample count is exactly zero and no History entry is created.
System Information
App Version: 0.9.5
Operating System: macOS 26.6.2 (25G83)
CPU: Apple M1 Max
GPU: Apple M1 Max integrated GPU
Other: MacBook Pro (MacBookPro18,4), AirPods Pro, iPhone running iOS 26.6
Logs
This recording contained fifteen seconds of speech:
[08:48:06] TranscribeAction::start called for binding: transcribe
[08:48:21] TranscribeAction::stop called for binding: transcribe
[08:48:22] Recording stopped and samples retrieved in 39ms, sample count: 0
[08:48:22] Recording produced no audio samples; skipping persistence
I can provide complete logs from both failing and successful captures if needed.
I often use my Mac while listening to a podcast from my iPhone through my AirPods. I found that when I triggered Handy in that situation, the recording overlay behaved normally but Handy captured nothing. There was no error, no transcription, and nothing in History. I would only discover after I had finished speaking that everything I had said was gone, which was very frustrating.
It took me a while to connect this to the AirPods. The problem occurs consistently when my iPhone is playing audio through them, even though the Mac still shows them as connected. Stopping playback on the iPhone makes Handy work again immediately.
Steps to reproduce
Expected: The Mac takes control of the AirPods microphone and Handy creates a transcription.
Actual: The overlay behaves normally, but Handy captures no audio, creates no transcription, and saves nothing to History.
Investigation
I reproduced the problem with a small CoreAudio test client. The input stream appears healthy: callbacks fire, buffers arrive in real time, and no errors are reported. However, every audio sample is exactly zero. As a control, recording from the Mac's built-in microphone under the same conditions produces normal audio, which isolates the failure to the AirPods route.
The built-in Apple apps QuickTime Player and Voice Memos do not have the problem. Starting a recording in either app stops playback on the iPhone and allows the Mac to capture microphone audio from the AirPods.
Inspecting QuickTime's audio-only recording path showed that it keeps a muted output path open alongside the microphone input. Opening a silent output stream on the same AirPods for the lifetime of Handy's recording produces the same result and fixes the problem.
I have been using a patched build with this change during normal use. Starting a Handy recording now stops playback on the iPhone and captures the transcription.
I could not find documented guidance explaining why the concurrent output stream is required, or a documented, supported API for asking macOS to take control of the AirPods microphone from another Apple device.
Related issues
#1886 discusses the Bluetooth playback tradeoff when using an AirPods microphone.
#1899 also involves an empty transcription, but its recording contains a non-zero number of samples. In this case the sample count is exactly zero and no History entry is created.
System Information
App Version: 0.9.5
Operating System: macOS 26.6.2 (25G83)
CPU: Apple M1 Max
GPU: Apple M1 Max integrated GPU
Other: MacBook Pro (MacBookPro18,4), AirPods Pro, iPhone running iOS 26.6
Logs
This recording contained fifteen seconds of speech:
I can provide complete logs from both failing and successful captures if needed.