Windows' built-in voice typing usually fails inside remote desktop sessions — the remote machine can't hear your local microphone. Pithflow fixes this by running on your local machine and typing the cleaned-up text into the remote window like a keyboard. No install on the remote side, no IT ticket, no audio redirection setup.
Dictation tools listen to a microphone on the machine where they run. In an RDP, Citrix, or VDI session, the apps you're typing into run on a remote machine — and that machine has no microphone. Unless your IT department configures audio-input redirection (most don't, and many security policies forbid it), Win+H and other in-session dictation tools open, wait, and hear silence.
This isn't a niche complaint. Microsoft's own Q&A forums carry long-running threads about the microphone not being recognized in Remote Desktop sessions and Speech Recognition failing to start on Remote Desktop servers ("Speech Recognition could not start because the language configuration is not supported"). The pattern is always the same: the dictation feature lives on the remote machine, and the remote machine can't reliably reach your microphone.
Pithflow never needs the remote machine to hear anything. It captures your voice on your local Windows machine, runs AI cleanup on the transcript, and hands the finished text to the focused window through the same input path your session already trusts — the keyboard and clipboard forwarding every remote desktop client ships with. The text lands in whatever field has focus, exactly as if you had typed or pasted it yourself.
You don't have to take a vendor's word for it. Install Pithflow on your local machine (the free tier is 2,000 words a week, no card), open your usual RDP or Citrix session, click into any text field in the remote window, hold your hotkey, and speak. If you can type into the remote window, the dictated text lands there — because as far as the remote session can tell, you did type it. That's the whole trick, and it's why no IT ticket is involved.
| In an RDP/Citrix session | Pithflow (local) | Win+H (in-session) | Cloud app installed in-session |
|---|---|---|---|
| Hears your microphone | ✓ (local capture) | Only with audio redirection | Only with audio redirection |
| Needs install on remote machine | No | Built in | Yes — often blocked by IT |
| Needs audio-input redirection configured | No — mic stays local | Yes | Yes |
| AI cleanup of the transcript | ✓ | — | Depends on app |
The mechanics differ per platform — which audio policy blocks the microphone, where the clipboard setting lives, and what your admin would have to change. These pages cover each one, with the vendor's own documentation cited:
Weighing the alternatives? If you landed here comparing tools, the DictaFlow alternative comparison is the honest head-to-head for this category — including the case where DictaFlow is the better pick.
Win+H runs inside the session where you invoke it. In a remote session, the remote machine can't use your local microphone as a dictation source unless audio redirection is configured — and on locked-down corporate VDI images it usually isn't. The dictation panel opens but hears nothing.
Pithflow runs on your local machine, not the remote one. It captures your microphone locally, cleans up the transcript, and delivers the finished text through the keyboard and clipboard forwarding your remote desktop client already uses for normal typing and copy-paste. To the remote session, it looks like you typed or pasted the text yourself.
No. Pithflow installs only on your local Windows machine — nothing runs inside the remote session. It relies on the keyboard and clipboard forwarding that RDP and Citrix ship enabled by default. If your IT has disabled clipboard forwarding entirely, test with the free tier first — one dictation tells you.
Any remote-desktop technology that forwards your local keyboard input — RDP, Citrix, and common VDI clients — receives Pithflow's typed output the same way. If you can type into the remote window, Pithflow can type into it too.