Voice dictation gets stuck on "Voice mode is busy" and only an app restart clears it
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
Voice dictation stops working after I switch away from the app while a recording is running. Pressing the shortcut afterwards shows a toast that reads "Voice mode is busy" and "Another voice recording is already in progress. Try again in a moment." The mic button looks idle, and there is no control anywhere to stop the recording the app claims is running. Restarting the app is the only recovery I have found.
The toast is wrong. No recording is in progress. The app is refusing to start one.
### What the logs show
I hit the toast at about 21:01 UTC on 2026-08-17. In `~/.copilot/logs/github-app..log` there is not a single `github_app::voice::real` line between 18:00:00 and 21:09:50 UTC. The count is zero. The previous voice session had ended cleanly more than three hours earlier, and the next one started well afterwards:
```
2026-08-17T17:57:45.192769Z INFO github_app::voice::real: Starting voice transcription session model_alias=nemotron-speech-streaming-en-0.6b
2026-08-17T17:59:08.696735Z INFO ... Live voice transcription stream stopped session_id=99ef85e9-8e70-4ab3-8d38-34a15e09bd45
<-- toast appeared in here, around 21:01 UTC, with zero voice log lines in the whole gap -->
2026-08-17T21:09:50.187144Z INFO github_app::voice::real: Starting voice transcription session model_alias=nemotron-speech-streaming-en-0.6b
```
`start_voice_transcription_session` logs `Starting voice transcription session` as its first step, so the missing line means the frontend never called the backend at all. Neither piece of the toast text appears anywhere in `github.exe`. Both point to the same conclusion: the guard that raises this toast lives in the frontend, and the backend is idle and healthy the whole time.
Windows agrees that the microphone is free. Under `HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\microphone\NonPackaged`, the entry for `github.exe` records a real `LastUsedTimeStop` timestamp rather than `0`, so no capture is open.
So a frontend flag that tracks "a recording is in progress" is sticking in the on position, most likely when the composer loses focus or unmounts while recording, so the stop path never runs. Once it sticks, nothing in the UI clears it.
### Steps to reproduce
1. Turn off Settings, then Voice dictation, then Push to talk, so the shortcut toggles start and stop.
2. Press the shortcut to start recording.
3. Switch to another application, or to another session in the app, while it is still recording.
4. Come back and press the shortcut again.
The mic button shows as idle and the toast appears. It stays that way until the app restarts.
This does not happen on every attempt, but it has happened repeatedly over several days.
### What I expected
The shortcut should start a recording whenever no recording is actually running. Failing that, there should be a visible way to cancel a recording that the app believes is in progress.
### Environment
- GitHub Copilot app 1.1.10 on Windows
- WebView2 151.0.4129.86
- Voice model `nemotron-speech-streaming-en-0.6b`
- Push to talk off, shortcut `Ctrl+Space`
- Microphone is `Remote Audio`, redirected into a Remote Desktop session
### Suggestions
Two changes would help even without a full fix. Clear the frontend flag when the backend reports no active session, since the backend already knows. And give the toast an action that forces the state to reset, because today the only way out is restarting the whole app.
Contributor guide
Research direction
Start by tracing the frontend guard that emits the “Voice mode is busy” toast, then compare its state with the backend’s start_voice_transcription_session logs when the composer or session loses focus. Done means switching away during recording no longer leaves the shortcut blocked, and a later shortcut press starts recording without restarting the app.
Written by the indexing model from the issue text.
Assessment
- Domain
- audio-video-rtc, desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100