Voice dictation in Claude Desktop app captures audio but never transcribes (inserts a stray "/") on macOS

Resolved 💬 3 comments Opened Jun 4, 2026 by dennisdonohoe Closed Jul 10, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Voice dictation in the Claude Desktop app (the microphone button in the Claude Code session composer) never produces any transcription on macOS.

When I click the mic and speak:

  1. The input box briefly shows a greyed-out placeholder "Hey, "
  2. That disappears and a stray forward slash "/" is inserted into the composer (as if invoking a slash command)
  3. No transcribed text ever appears

This happens for every session, every time.

Notably, voice/dictation works fine elsewhere on the same machine and same account:

  • Dictation in the browser on claude.ai works
  • Dictation in the browser on ChatGPT works
  • Voice input in the OpenAI Codex desktop app works

Only the Claude Desktop app fails.

What Should Happen?

Speaking should insert the transcribed text into the composer the same way dictation already works on claude.ai in the browser with this account.

Error Messages/Logs

Local diagnosis on macOS (Apple Silicon). The app is built correctly for mic capture, and audio IS captured — the failure is DOWNSTREAM of capture (transcription / result handling).

Entitlements & config (all correct):
- /Applications/Claude.app and its audio-service helper ("Claude Helper.app") both have:
    com.apple.security.device.audio-input = true
- Info.plist has NSMicrophoneUsageDescription and NSSpeechRecognitionUsageDescription
- Renderer launched with: quickEntryDictation: supported, customQuickEntryDictationShortcut: supported
- AudioService runs in the entitled helper: --utility-sub-type=audio.mojom.AudioService --service-sandbox-type=audio

Live unified-log capture (`log stream`) during one reproduction:

# Microphone permission is GRANTED (no denial) for the audio-service helper PID:
tccd  AUTHREQ_CTX  service=kTCCServiceMicrophone  preflight=no   (target = audio service pid)

# ~10 kTCCServiceMicrophone TCCAccessRequest calls fired in ~100ms (msgID 612.277 .. 612.286) — abnormal tight request loop

# Audio IS captured at the moment of speech:
Claude Helper[audio service] (AudioToolboxCore) AudioConverter ...   (active while speaking)

Conclusion: microphone permission granted + audio captured, yet NO transcription is produced and a stray "/" is inserted instead. The break is in the dictation transcription pipeline / result handling, not in capture or OS permissions.

Steps to Reproduce

  1. Open the Claude Desktop app on macOS and start (or open) a Claude Code session.
  2. Click the microphone button in the session composer (next to the "+" and the mode selector).
  3. Speak a sentence, e.g. "testing one two three".
  4. Stop / release as normal.

Observed: a greyed-out "Hey, " placeholder flashes, a stray "/" is inserted into the composer, and no transcription ever appears.
Expected: the spoken words are transcribed into the composer.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.161 (Claude Code), bundled in Claude Desktop app 1.11187.1

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is the Claude Desktop app, not the CLI in a terminal — so the "Platform" and "Terminal/Shell" fields below don't map cleanly to this report.

Environment:

  • App: Claude Desktop 1.11187.1 (Electron 41.6.1)
  • Bundled Claude Code: 2.1.161
  • OS: macOS, Apple Silicon
  • Account: Claude.ai login (not an API key)

The same account dictates successfully in the browser on claude.ai, so the account / network / transcription service is reachable — the problem is specific to the desktop app's dictation path (quickEntryDictation), and reproduces across all sessions.

Possibly related empty-transcription reports (those are CLI/Windows, not the desktop app): #38827, #38983, #38712.

Distinctive triage signal: tccd logged ~10 kTCCServiceMicrophone access requests in ~100ms during a single dictation attempt while audio capture (AudioConverter) was active — i.e. capture works, but no text is ever produced and a "/" is inserted instead.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗