I Praised WisprFlow. Then I Built a Tool to See What It Does on My Mac

In March I wrote a glowing post about WisprFlow. I use it every day, I recommended it to friends, and I described it as running on-device. I still think the dictation is excellent. This post is the update I owe anyone who read the first one, because a few weeks ago I started looking at what the app actually does on my Mac, and some of it surprised me.

I want to be careful with how I say this. Everything below is my own experience on my own machine: my settings, my logs, my opinions. It is not a security audit, and it is not an accusation. It is what one curious user found after deciding to look.

Update, 12 June 2026: WisprFlow's team has since responded. They confirmed the bug and shipped a fix, corrected one of my guesses about the meeting feature, and answered the privacy questions directly. I have left my original write-up below as it was and added their full response near the end, under "Update: WisprFlow Responded."

I Wrote the Glowing Review First

For context, here is the original: Speech to Text with WisprFlow. I meant every word. It got my Lithuanian accent right from the first sentence, it made me much faster, and I still reach for it daily. In that post I also wrote that it runs locally on-device. Hold onto that line, because it is the part I got wrong.

Disclosure up front: that earlier post contains an affiliate link to WisprFlow, and I have earned referrals from it. I am telling you that so you can weigh everything here knowing I had every reason to keep praising the tool, not to criticise it.

What Actually Started This

On 4 June I was working with my AirPods on and Spotify playing. The audio kept dropping to a muffled, phone-quality sound, and at the same time I noticed the microphone activating. My first guess was a Bluetooth glitch. Then I noticed the timing: the drop and the mic lined up too often to be coincidence. So instead of guessing, I decided to measure it.

So I Built a Monitor

I built a small tool that reads macOS's own audio and Bluetooth logs and records every time any app opens the microphone: which app, whether a keyboard shortcut was pressed, and how long the mic stayed open. It runs only on my Mac and only reads my own system logs. Here is what it looks like.

What the Logs Showed

Over a single logged window on 8 June, on my machine, the tool recorded around 70 automatic microphone opens by WisprFlow: no shortcut pressed, and no recent typing before them. More than two dozen of those opened an actual recording stream. The typical automatic open held the microphone for around half a minute, and one held it for nearly two minutes.

One honest correction on the timeline. By the time I was logging, the audio dropping had already stopped (zero of the phone-quality downgrades appeared in that window), so the sound problem and the mic-opening turned out to be two separate things. The audio issue is what got my attention. The mic opening on its own is what I kept digging into.

Then I Read the Config File Behind the Settings Screen

Next I built a second view that reads WisprFlow's local configuration file on my Mac and translates every setting into plain language, including the ones the normal settings screen does not surface. This is a screenshot of that view from my own install.

On my install, here is what stood out to me:

• Background meeting detection was switched on. With it on, my logs show the app opening the mic in the background on its own. My read is that the feature samples audio to detect meetings. That is my inference from the pattern I logged, not something I can see inside the app. (Update: WisprFlow says this inference is wrong, that the detection is a passive usage check rather than audio sampling. See the update at the end.)
• Cloud sync was on. This is the part that corrects my earlier post. I had described WisprFlow as on-device, but my own settings show a cloud-sync option enabled, and based on that I no longer believe the dictation on my install was staying purely on-device the way I had assumed. I cannot see inside their servers. This is my reading of my own settings.
• A large local history sat on disk: thousands of past dictations and over a thousand raw voice recordings stored on my machine.
• A login token was stored in plain text on my Mac. In the local config file on my own install (version 1.5.695), what looked to me like a login token was sitting in a readable file rather than in the macOS Keychain. That is what I saw in my own copy. I have not tested other versions or setups.
• Analytics and crash-reporting components were present in my install. From what I could see, some telemetry-related activity still appeared with the usage-sharing toggle off, which I read as crash or diagnostic reporting being separate from the usage toggle. I could be misreading what each component does. This is my interpretation of my own install.

I want to keep this fair. These are settings, not secrets, and most apps collect some of this. Everything in this list is what I saw in my own configuration. What unsettled me was the combination plus the defaults: a tool I trusted for dictation was set, out of the box, to open the microphone in the background and sync to the cloud, and I only knew because I went looking.

The One Change That Made a Difference

I turned off background meeting detection. On my machine the automatic mic-opens dropped from roughly 40 in the hour before I changed the setting to about 2 in a later hour, even while I was actively using the mic. That single toggle did more than anything else I tried, which is also the strongest sign that the meeting feature was what kept opening the mic.

Is It Malicious? My Honest Read

No. I want to be precise here, because it matters and because it is the fair thing to say. I found no evidence of malicious intent, and nothing in my logs shows audio being secretly sent anywhere. The pattern I saw, opening a recording stream for tens of seconds near activity and never actually saving a meeting, is most consistent with a background meeting-detection feature doing its job, not with spying.

So my concern is not about motive. It is about defaults and transparency. An app I recommended was configured to open the microphone in the background and sync to the cloud, while I was telling people it ran on-device. That gap between what I believed and what was happening is the real story here, and it is on me as much as anyone.

What I Did About It

1. 1.Turned off background meeting detection.
2. 2.Set my system microphone input to the built-in mic, so a background mic-open does not grab my headset.
3. 3.Reviewed cloud sync and what was stored locally.
4. 4.Raised the behaviour with WisprFlow's support team directly.

I will update this post if and when they respond. If they tell me something that changes the picture, I would rather correct the record than be right.

Update: WisprFlow Responded (12 June 2026)

WisprFlow's team got back to me, and they took the questions seriously. They confirmed the core of what I found, fixed the real bug, corrected one of my guesses, answered the privacy questions directly, and apologised for the earlier replies that had sent me the wrong way. Here is their side so you can weigh both.

• They confirmed the diagnosis. The earlier reply I got, which blamed a macOS function-key quirk, was wrong. The real cause was the one I had landed on: the meeting auto-detection feature opening a session at the end of dictation.
• The audio drop was a real bug, and it is fixed. The AirPods dropping to phone quality was a session forcing the headset off high-quality A2DP onto the hands-free HFP route, the exact codec switch I had described. They shipped the fix in version 1.5.684. They had me down as still on 1.5.619, from before the fix, and told me to update. My own install actually reads 1.5.695, which is already past 1.5.684, and that matches my logs: the audio drops were gone in the window I measured. So on my machine that part is already resolved.
• They corrected my read of the meeting feature. I had guessed auto-detect was sampling audio to spot meetings. They say it is a passive, read-only check of whether another app such as Zoom or Teams is using the microphone, that it opens no recording stream of its own, that it ignores WisprFlow's own process, and that nothing is recorded or uploaded unless I click the prompt to open it myself. They also say other people in the room are never captured in the background. I cannot see inside the app, but on their account it is a usage check, not audio sampling, and I am updating my guess accordingly.
• Cloud storage and retention are controls I can set. They pointed me to a Privacy Mode, which they call Zero Data Retention, that stops dictation being stored or used to train models, and to a local-storage option that can auto-delete or never write to disk. So the cloud behaviour I flagged is configurable rather than fixed, if you go and set it.
• They backed the fix I had already made and logged two requests. They confirmed that turning off auto-detect meetings stops the background checking entirely, which is the switch I had already flipped. And they logged my two asks: do not open a recording session on a Bluetooth headset, and honour the input device I have actually selected.

One honest open question stays on my side. My tool logged sessions it classified as recording streams opening on their own, and their description is of a passive check that opens no stream of its own. I cannot fully square those two from the outside, so I have asked them about it and will add what I learn. I am noting the gap, not resolving it.

What their reply does not change: background meeting detection and cloud sync were switched on by default on my install, and I only understood that after going looking, so my point about defaults still stands. What it does change: the concrete audio bug is fixed, my audio-sampling guess was wrong and I have said so, and the motive question still reads the way I first answered it, as no evidence of malice. Credit where it is due. They engaged, they corrected the record, and they were straight with me the second time around.

What I Would Tell You If You Use WisprFlow

I have not uninstalled it. The dictation is still the best I have used, and I still use it after changing my settings. But if you rely on it, open the settings and decide for yourself:

• Check whether background meeting detection is on.
• Check whether cloud sync is on, and decide if you are comfortable with your dictations leaving your device.
• Look at how much history is stored locally, and clear it if you do not need it.
• If your work is sensitive, treat any always-on listening feature as opt-in, not default.

One last note for the record. This is my personal experience on my own Mac, based on my own settings and system logs and my own reading of them. It is not a security audit and not an allegation of wrongdoing. I shared my findings with WisprFlow, and their response is in the update above, put as fairly as I can.