Privacy-minimal mode: dictate → clipboard, no Accessibility / Screen Recording / global hotkeys required

[nuwan-forti]

Hey! First off, thanks for building FreeFlow, the no-subscription, no-server model is exactly what I want from a dictation tool, and the post-processing quality is great.

I want to start a conversation about supporting a stripped-down "privacy-minimal" mode for users who don't want to grant the app full control of their computer.

The concern

To use FreeFlow today, a user is asked to grant:

• Microphone — unavoidable, makes sense
• Accessibility ("control this computer") — used to auto-paste and read selected text
• Screen Recording — used to read the active window for context-aware spelling

For people who are privacy-conscious or work on shared/enterprise machines, that surface area is uncomfortable. "Allow this app to control your computer" is a strong ask for what is, fundamentally, speech-to-text.

The setup wizard currently hard-blocks progress on the Accessibility step, the in-app alert pops on launch and on every Start Dictating attempt, and even the menu bar shows persistent red/orange banners. The app can't be used at all without those permissions, even for users who'd happily trade auto-paste and context-aware spelling for the ability to use it.

The proposal

Add a "minimal mode" (or "manual paste mode") that:

1. Lets the setup wizard be completed without granting Accessibility or Screen Recording — Skip buttons, or a single "I don't want auto-paste / context" toggle up front.
2. Doesn't install the global keyboard event tap (which itself triggers the macOS "control your computer" prompt) when the user opts out of global hotkeys.
3. Uses the existing menu bar Start Dictating / Stop Recording as the trigger.
4. Writes the transcript to the clipboard (already does this) and skips the auto-paste keystroke. User pastes manually with Cmd-V.
5. Hides or downgrades the "Accessibility Required" / "Screen Recording Permission Needed" banners when the user has explicitly opted out.

Why this is worth doing

• It's a small expansion of an already-built code path: the app already writes the transcript to the clipboard before posting Cmd-V, and the menu bar already has a manual Start/Stop button.
• The post-processing prompt and Groq pipeline already work great without context — context-aware spelling is a nice-to-have, not a must-have, for many users.
• It opens the door for users on managed/work Macs where Accessibility is policy-restricted.
• It's a differentiator: most dictation apps demand the same broad permissions. "FreeFlow works without giving up your computer" would be a strong privacy story consistent with the existing "no FreeFlow server" stance.

What I tried locally (proof it's a small change)

I've been running a personal fork with the following modifications, and the basic dictate → clipboard flow works end to end:

• Added a Skip button to the Accessibility and Screen Recording setup steps.
• Made startHotkeyMonitoring() a no-op so the CGEventTap is never installed — this alone removes the macOS system permission prompt.
• Removed the hasAccessibility guard in prepareRecordingStart (the existing CGEvent-based auto-paste silently no-ops without permission, and the clipboard write already happens regardless).
• Removed the in-app alert popups and menu bar warning banners for users who've opted out.
• Defaulted preserveClipboard to false so the transcript stays on the clipboard for manual paste.

Happy to clean it up into a PR if there's interest in supporting this officially — wanted to get a read on whether this aligns with the project's direction first.

[marcbodea]

Not a bad proposal at all, and it is aligned with the project's goals. I would make it a clear choice during setup, and store that preference, so we can still show the menu bar warning and errors when permissions are missing, since macOS weirdness sometimes break them.