If you have ever released the dictation hotkey and then gone looking for something you copied five minutes earlier only to find your just-dictated sentence sitting on the clipboard instead, this is what happened, why it is supposed to be temporary, and what to do if it is not.
Where the clipboard actually comes in
Coii VoiceInput has two ways to deliver text into the field you were using. The first is the macOS accessibility API, which hands the app your transcript directly — no clipboard involved, nothing to overwrite, nothing to restore. Most native Mac apps support this, and it is the path used whenever it is available.
The second is a synthetic paste: the app puts your transcript on the clipboard for a moment, sends a Cmd+V, and then puts back whatever was on the clipboard before you started dictating. This only happens in apps whose text fields do not expose themselves to accessibility — a smaller set than most people expect, but not an empty one.
Both paths land your words in the field you left. The difference is invisible in the normal case, which is exactly the problem: when the restore step is delayed, interrupted, or simply not noticed, it looks like your clipboard got overwritten by the app rather than borrowed by it.
Why it looks like a problem when it usually is not
The sequence — copy something, dictate, discover your copied item is now your dictated sentence — has one very ordinary explanation: you looked at the clipboard during the fraction of a second between the paste and the restore. On a fast Mac this window is short enough that you would need to be checking the clipboard at almost the same instant you released the hotkey to see it at all. On an older machine, or if something else on the system is under load, the window is a little longer and a little more likely to be visible.
The other explanation is that you dictated into an app that uses the clipboard path, then immediately copied something else — a URL, a line from a terminal, another sentence — before checking whether your original item was still there. At that point the restore has nothing to restore into, because you overwrote it yourself, a step later, with something unrelated to Coii VoiceInput.
Step 1 — find out which path your app is using
Open the app you dictate into most and dictate a short test sentence into an empty field. Immediately after releasing the hotkey, without doing anything else, open a second app and check the clipboard (paste into a blank Notes document works fine for this). If your last-copied item is still there untouched, you were on the accessibility path the whole time and none of this applies to that app. If your dictated sentence is what shows up, the app used the clipboard fallback, and the general rules below matter for it.
git log --oneline -20
Step 2 — know which apps you actually need to worry about
Terminal and most terminal emulators are the clearest case: there is no accessibility surface for a shell prompt to receive text through, so every dictation into one is a clipboard round trip. Dictating into a terminal covers the rest of what is different about that environment.
A second group is apps built on web technology that do not wire their text fields up to the system's accessibility layer — some Electron-based editors and a handful of browser-embedded tools fall here, and which specific ones do changes as those apps update, so testing your own is more reliable than a list.
Password fields are a related but separate case, because macOS itself refuses pasted content into some of them regardless of which path an app takes. Whether dictation works in password fields is its own question with its own answer, and it is not really about the clipboard at all.
Ordinary native apps — Mail, Notes, Slack, most code editors, most word processors — take the accessibility path. If you mostly dictate into apps like these, the clipboard fallback is something you can read about without it ever touching your actual workflow.
Step 3 — mind the half-second, not the whole session
The only window where anything can go wrong is the moment between release and restore, and the only way to disturb it is to copy something else during that moment. In practice this means: don't select and copy a second thing in the instant right after you let go of the hotkey. Wait for the paste to visibly land, which for a short sentence is close to instant, and the clipboard is already back to normal by the time you would reasonably reach for something else.
This is not a habit most people need to build deliberately — it only comes up if you are dictating and copying in a tight loop, which is unusual. It is worth knowing about if you are, say, dictating a commit message and pulling text from several other sources in quick succession.
Step 4 — know what Universal Clipboard adds to this
If you have Handoff on and are signed into the same Apple ID on more than one device nearby, macOS syncs your clipboard between them automatically — that is a system feature, not something any app controls. Because the clipboard fallback does briefly place your transcript there, it is possible for that brief value to be the one Universal Clipboard picks up and offers on your other device, before the restore happens on your Mac.
This is macOS's own syncing behavior working exactly as designed on whatever the clipboard happens to contain at that instant — Coii VoiceInput itself sends nothing anywhere; its network use is limited to fetching the model once, activating your licence, and a clock check at launch, and dictation works the same with Wi-Fi off entirely. If you would rather your dictated sentences never show up as a Universal Clipboard suggestion on your iPhone, turning Handoff off on the devices you don't want syncing is a macOS setting, not something inside this app.
Step 5 — treat history as the record, not the clipboard
The clipboard was never meant to be where your dictated text lives — it is a relay, on its way to the field you were typing into. The actual record is your history: every dictation is written there, both the raw transcript and the version after any filters ran, independent of whether the paste used accessibility or the clipboard, and independent of whether it landed at all.
If you are ever unsure whether a paste succeeded, or whether your clipboard still holds what you expect it to, check your dictation history rather than the clipboard. It answers the question directly instead of leaving you inferring it from what happens to be sitting in a system-wide slot that a dozen other things can also touch.
Step 6 — remember that clipboard managers watch everything
If you run a third-party clipboard manager — the kind that keeps a scrollable history of everything you have ever copied, rather than just the single most recent item macOS itself remembers — it is watching the system clipboard at a lower level than any single app, and it will log the momentary value Coii VoiceInput's fallback writes there, the same as it logs anything else written to the pasteboard.
This means you may open your clipboard manager's history later and find your dictated sentence sitting in it as its own entry, even though the clipboard itself was restored a fraction of a second afterward and the sentence never displaced anything from your point of view. There is nothing wrong here, and nothing to configure on Coii VoiceInput's side to change it — a clipboard manager's job is to notice every write, and a synthetic paste is, at the level it operates on, indistinguishable from you pressing Cmd+C yourself. The entry is harmless, and most clipboard managers let you delete individual entries if having a transcript show up among your copied snippets bothers you.
This is also a second, independent reason the clipboard fallback is never where you should look for a dictation you are trying to recover. A clipboard manager's history is not indexed by which app you dictated into or when relative to your workflow — Coii VoiceInput's own history is, and it is the more direct route back to a specific sentence regardless of what else happens to be watching your pasteboard.
What to do if a restore genuinely fails
This is uncommon, but it can happen if the app you dictated into crashed in the instant between paste and restore, or if something else on the system wrote to the clipboard in that same instant. Two things are true if it does. First, the clipboard only ever holds one item, so whatever you had copied before is gone and cannot be recovered from the clipboard itself — there is no undo history for it. Second, your dictated text is not at risk, because it was written to Coii VoiceInput's history before the paste was even attempted, so you have not lost anything by losing the restore.
If you notice this pattern repeating in one specific app rather than as a one-off, that app is a candidate for reporting to see whether its focus handling is the actual cause — a paste that fails to land and a paste that lands somewhere unexpected often have the same underlying trigger.
FAQ
Is this a bug, or is it supposed to work this way?
It is supposed to work this way. The clipboard fallback exists because some apps have no other way to receive text, and restoring what was there before is the part of the design that makes it invisible in the case that matters — which is the overwhelming majority of dictations.
Does this happen every time I dictate?
No. It only happens in apps that do not support the accessibility path, which is a minority of what most people dictate into day to day. Native Mac apps almost always skip the clipboard step entirely.
Can I check whether an app used the clipboard after the fact?
Not directly after the fact, but you can test it in the moment as described in Step 1 — dictate a short line and check the clipboard immediately afterward.
Does a slow paste mean my clipboard is at risk longer?
The restore is tied to the paste completing, so a slower app can mean a slightly longer window, yes. It is still measured in a fraction of a second for any app actually receiving the keystroke, not something you would need to plan around.
The habit that avoids all of this
If keeping a specific item on your clipboard matters to you — a link you are about to paste into several places, a snippet you are reusing — the simplest rule is to finish that round of pasting before you start a dictation that goes into an app on the clipboard path. It costs nothing, because reading your history after the fact is already how you would check on a dictation you were unsure about, and it means the two things you are juggling never compete for the same slot at the same moment.
For most dictation, into most apps, none of this is something you will ever need to think about — the accessibility path is the common case, and the clipboard fallback restores what it borrowed before you have time to notice it was gone. Knowing which of your own regular apps falls into which group, once, is enough to stop wondering about it every time you dictate into them again. Speech-to-text on a Mac covers the rest of how text actually gets from your voice into the field you were working in, and the trial is long enough to see which path your own apps take.