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.

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.
• 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.

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 have shared my findings with WisprFlow and will update this post with their response.