Voice typing inside a Citrix session depends on a microphone-redirection chain most locked-down deployments break. Pithflow sidesteps it: it captures your voice on the endpoint you're sitting at, cleans up the transcript, and delivers finished text into the Citrix window the same way your typing and pasting already arrive. Nothing installs on the VDA.
On paper, yes. Citrix's audio policy reference defines a Client microphone redirection setting, allowed by default, that lets a session record from your local microphone. But the same documentation spells out the dependencies: Client audio redirection must also be allowed — if it's disabled, the microphone policy "has no effect" — and, for security, Citrix Workspace app alerts users when a server tries to access the microphone, so every session starts with a permission prompt someone can decline without realizing what they just turned off.
That's the best case. In regulated environments — the hospitals, banks, and insurers that run Citrix precisely because it keeps data off endpoints — security baselines often prohibit these policies outright. The result is familiar to anyone who has pressed Win+H inside a published desktop: the voice typing panel opens, listens, and types nothing.
Because dictation is the most demanding thing you can ask of redirected audio. Your voice has to be captured on the endpoint, compressed, carried across the ICA/HDX channel to the VDA, and handed to a speech recognizer running on a shared server — and then the recognizer you get is Windows voice typing, with no tone control and no cleanup pass. Every hop is a place for the audio to degrade or the chain to silently break, and when it breaks, the error message is usually nothing at all.
This is why "citrix voice typing" searches lead to policy checklists instead of dictation apps. The fix being sold is plumbing repair. The alternative is to stop sending audio across the wire entirely.
Pithflow's remote-desktop architecture keeps the microphone where it works: on your endpoint. You hold a hotkey and speak; Pithflow captures the audio locally, runs AI cleanup on the transcript, and delivers the finished text through the keyboard and clipboard forwarding your Citrix session already uses. Concretely, it places the text on your local clipboard and pastes it into the focused window, with a typed-keystroke fallback. To the VDA, the text arrives the way all your other text arrives.
The honest caveat: that delivery depends on the input channels Citrix forwards. Citrix's clipboard redirection documentation says bidirectional clipboard redirection is enabled by default — and pasting into the session only needs the client-to-session direction, which survives even the common Restrict session clipboard write lockdown. But if your admins set Client clipboard redirection to Prohibited, the paste path is blocked. Don't roll this out on faith: pilot one seat first.
| To dictate in Citrix, you need… | Win+H (in-session) | Pithflow (endpoint) |
|---|---|---|
| Citrix audio policies configured | Client audio + microphone redirection both allowed | None — audio never crosses ICA |
| Workspace app mic permission prompt | Yes, per Citrix docs | No — mic stays local |
| Anything installed on the VDA | Built in | Nothing |
| Punctuation and cleanup of the transcript | Raw speech-to-text | AI cleanup before it lands |
| Survives clipboard redirection = Prohibited | n/a | Paste path blocked — pilot one seat first |
Only if the whole audio chain cooperates. Citrix's own policy reference lists Client audio redirection and Client microphone redirection — both must be allowed, and Citrix Workspace app alerts the user before a server can access the microphone. When any link in that chain is off, Win+H opens inside the session and hears nothing. Pithflow skips the chain: the microphone never leaves your endpoint.
No. Pithflow installs only on the local Windows machine you run Citrix Workspace app from. Nothing runs on the VDA, no policy needs to change for the microphone, and there is no server-side component for IT to approve.
That can block Pithflow's primary delivery path. Pithflow puts the finished text on your local clipboard and pastes it into the focused window, with a typed-keystroke fallback. If the Client clipboard redirection policy is set to Prohibited, the paste path is gone. Pilot one seat on the free tier first — a single dictation into your real session tells you where you stand.
Not on the thin client itself. Pithflow is a Windows app, so it needs a Windows endpoint running Citrix Workspace app. If your endpoint is an IGEL, Linux, or ChromeOS thin client, Pithflow has nowhere to run — that's a real limitation, not a configuration issue.
Free tier: 2,000 words a week. Installs only on your endpoint — nothing touches the VDA.
Not on Citrix? See the full remote desktop dictation guide, or compare against the other tool built for this problem: Pithflow vs DictaFlow.
