[BUG] Desktop dictation: live transcript is correct Latin script, but finalization rewrites the whole paragraph into Devanagari

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?

When I dictate Urdu using the microphone button in the Claude Code desktop app's chat input, the live streaming transcript is correct — it appears in Latin script (Roman Urdu), which is what I want.

The moment I stop dictation, the finalization step rewrites the entire paragraph into Devanagari (Hindi script).

So the speech recognition itself is working. Something in the post-stop finalization/commit pass re-renders the already-correct transcript into a different script and discards what was streamed.

Context: I speak Urdu. Urdu is not among the 20 supported dictation languages; Hindi is. Urdu and Hindi are near-identical in speech and differ mainly in script, so the recognizer appears to detect Hindi and the finalization step renders it in Devanagari.

This looks related to #78682 (dictation ignoring the language setting) and #94755 (macOS dictation misrecognized as English), but the symptom here is narrower and points at a specific stage: the streamed text is right, only the committed text is wrong.

What Should Happen?

Stopping dictation should commit the transcript that was already displayed during recording — in Latin script.

The finalized text should match what was streamed, not be re-rendered into a different writing system.

Error Messages/Logs

No error is shown. A dictation event recorded in the desktop app's own Local Storage shows English being sent as the language, so the client side looks correct:

    "area":"code", "input":"session", "language":"en-GB",
    "activation":"tap", "connected":true, "backend":"pcm", "outcome":"committed"

The strings `hindi`, `hi` and `devanagari` do not appear anywhere in the app's storage.

Steps to Reproduce

1. Open the Claude Code desktop app (Code tab) on Windows.
2. Click the microphone button in the chat input.
3. Speak several sentences in Urdu (or Hindustani).
4. While still speaking, watch the input box — the text streams in correctly, in Latin script.
5. Stop the dictation.
6. The entire paragraph is replaced with the same content written in Devanagari.

Step 4 is the important one: the bug is only visible if you compare the text during recording against the text after stopping. Reproduced in both tap mode and with the mic button; no special configuration is needed.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Desktop app 2.2553.1 (the CLI is not installed on this machine, so claude --version is unavailable)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

What I ruled out before filing

• ~/.claude/settings.json — no language key was set. Setting "language": "en" does take effect for Claude's reply language (replies switched to English immediately), but made no difference to the dictation result.
• ~/.claude.json — no language or voice key.
• Project-level .claude/ — does not exist for this project.
• The desktop app's own Code-tab settings — no language or dictation key is exposed at all (only archiving, notifications, branch prefix, keep-awake, output style).
• The app's Local Storage — holds "language":"en-GB".
• Windows input languages — only en-US is installed.
• The microphone dropdown has no language picker, only microphone device selection.

So there is no misconfiguration on this machine to correct: the client reports English, and the finalized transcript still comes back in Devanagari.

Impact

There is no setting that fixes this, and the settings reference exposes no option for transcript finalization, post-processing, translation, streaming-only mode or raw transcript access. The only workaround is to abandon Claude Code's dictation and use the operating system's own voice typing.

Suggested area

The finalization / commit pass that runs after recording stops, rather than the streaming recognizer — since the streamed text is correct and only the committed text is wrong.