The app was right. The window underneath it was not

The app in the Dock was the correct one, the icon in the menu bar looked normal, and the dictation still landed somewhere unexpected — a second Mail draft, a Notes window from three days ago, a Terminal tab that was not the one being worked in. This is a narrower problem than dictating into the wrong app entirely: the app was correct the whole time, and the window inside it was not the one that had keyboard focus when the key came up.

The cause: focus belongs to a window, not to an app

macOS keyboard focus is tracked per window. An app being frontmost — its menu bar showing, its icon highlighted in the Dock — says nothing about which of its windows currently has the text cursor. Coii VoiceInput pastes into whichever field has focus at the moment the hotkey is released, following the same rule a real keystroke would. If the intended window is not the one with focus, the words go to whichever one is, even though both belong to the same app.

The shapes this actually takes

Two drafts of the same kind of document. A reply started this morning and a new message started an hour later, both open in Mail, both look identical from the Dock. Only one has the blinking cursor.

Multiple windows of a browser. A second browser window, opened for a separate task and left in the background, is a distinct focus target from the one on screen — dictating into a text box on the visible window works correctly only if that window, specifically, has focus, not just the browser as a whole.

Several Terminal or code editor windows. A second terminal window running a long build, or a second editor window with a different file open, is easy to lose track of when both are visible at once. The active tab or pane — the one with the blinking cursor — is the one that receives the text, not the one currently being looked at.

A Slack workspace switch. Moving between two Slack workspaces, or between a DM and a channel in separate windows, changes which text field has focus even when the app itself never lost the foreground.

The silent focus stealers

Some causes are less visible than switching windows on purpose, because nothing about the screen looks obviously different:

A software update or permission prompt. macOS occasionally raises a system dialog — a permission request, an update reminder — that takes focus the moment it appears, even if it is small and easy to miss while looking at the sentence being spoken rather than the screen.

A notification banner, clicked out of habit. Clicking a banner to dismiss it, rather than letting it disappear on its own, moves focus to whatever the banner opened or brought forward.

Stage Manager or a Spaces switch mid-dictation. Swiping to another Space, or letting Stage Manager bring a different window's tile forward, changes focus the same way manually clicking would — it does not require realizing it happened for the effect to be the same.

Waking from sleep or a screen lock. A Mac that locks or sleeps mid-dictation and gets unlocked afterward sometimes returns focus to a different window than the one open before the interruption, depending on what else happened while it was locked.

The fix, and it is a habit rather than a setting

There is no setting that locks dictation to a specific window — the app pastes wherever focus is at release, deliberately, because that is what makes it work the same way typing does. The actual fix has three parts, in order of how often each one matters:

Click into the intended window's text field immediately before pressing the hotkey, even if that window was already visible on screen a moment ago. A window that looks focused because it is on top is not the same guarantee as a window that has an active text cursor in it.

Do not swipe between Spaces, trigger Stage Manager, or click anything else while the key is held. Any of these can move focus mid-dictation without an obvious visual cue, and the words go wherever focus lands at release, not where it was when the key went down.

Check for a dialog before dictating something long. A quick glance at the screen before starting a longer dictation catches a software update prompt or permission dialog that would otherwise take focus silently partway through.

Diagnosing it after the fact

Look at which window actually received the new line of text — its title bar or tab name says which one had focus, and that is usually enough to spot the pattern (two Mail drafts, two Terminal tabs) rather than treat it as random. Redictate a single short word into the correct window, with nothing else touched in between, to confirm the fix worked before trying a longer sentence again.

Recovering the words, regardless of which window took them

Every dictation is written to local history the instant the key is released, before the app's engine produces a result and before the text is pasted anywhere. A paste into the wrong window does not cost the words: open the app, find the row, copy it, and paste it into the window that was actually meant. The general recovery steps for a dictation that did not land where expected cover the same history-based recovery in more detail, including the cases where nothing visibly received the paste at all.

How this differs from dictating into the wrong app entirely

Dictating into the wrong window is narrower than dictating into the wrong app: the correct app was frontmost the entire time, and only the window within it was not the one with focus. The fix is the same principle in both cases — keyboard focus at release decides the destination — applied one level down, to a specific window rather than to which app is running.

Ruling out a hotkey conflict first

Before assuming a window-focus problem, confirm the hotkey is actually reaching the app at all: hold it in an empty text field and check for the level meter appearing. If nothing happens, the hotkey may be claimed by another app rather than a focus issue, which is a different fix entirely and worth ruling out before troubleshooting which window has focus.

Password fields and windows that block pasting outright

A window that refuses pasted text — most commonly a password field — can look like a wrong-window problem when it is actually a field that never accepts the paste regardless of which window had focus. The transcript still lands in history either way, which is the detail that tells the two problems apart: a wrong-window paste shows up somewhere unexpected, and a blocked paste does not show up anywhere at all.

What macOS is actually doing under the hood

Coii VoiceInput reads focus through the macOS accessibility API, the same system that tells a screen reader which field has the cursor. It is not guessing which window is "probably" the intended one — it asks the system which window currently has focus and pastes there, which means the fix for a wrong-window paste is entirely about making sure the right window actually holds focus at the moment the key comes up, not about anything the app itself could infer differently.

Setting up a hotkey that survives a busy, multi-window day

The walkthrough for setting up a dictation hotkey covers choosing a combination unlikely to collide with a window manager, Stage Manager, or another app's own shortcuts — worth revisiting if wrong-window pastes are happening often enough that the hotkey itself, not just focus, might be part of the pattern.

Multiple monitors make this more likely, not less

A second or third monitor multiplies how many windows can sit visibly on screen at once, which multiplies how many of them can plausibly look like the intended target. Focus is global across monitors, not tied to whichever screen the mouse happens to be over — a window on the left monitor can hold focus while attention and the mouse cursor are both on the right one, and dictating without checking which monitor's window actually has the cursor is a common way a wrong-window paste happens on a multi-monitor desk specifically. The fix does not change with more screens: click into the intended field, on whichever monitor it lives on, immediately before pressing the hotkey.

A quick check worth building into a longer dictation

For anything longer than a sentence or two, a one-second glance at the screen before pressing the hotkey — confirming the correct window is not just open but has the blinking cursor in the field meant to receive the text — costs less than redictating a paragraph that landed somewhere unexpected. This matters more on a day with several similar windows open at once than on an ordinary one, and it is worth treating as part of starting the dictation rather than an optional extra step: press the hotkey only after confirming focus, not before.

What a week of tracking this pattern tends to show

Wrong-window pastes are rarely random once a few of them have happened — they tend to cluster around the same handful of situations: the same two Mail drafts left open together, the same habit of clicking a notification banner without noticing what it opened, the same Spaces swipe made out of habit mid-sentence. Noticing the pattern across a week, rather than treating each instance as an isolated one-off, is usually enough to catch the specific habit responsible and adjust it, which does more to prevent the next one than any setting could.

Building the habit of checking focus, not the window's appearance

A window that looks active because it is visible and on top is a weaker signal than a window that has an actual blinked cursor in a text field. Dictating into any app on a Mac works reliably once that distinction becomes automatic — clicking the field, not just the window, before pressing the hotkey — and it is the single habit that prevents nearly every wrong-window paste before it happens rather than after.

None of this is a flaw specific to dictating rather than typing — a real keystroke sent to the wrong window is exactly as invisible in the moment as a dictated one, the only difference being that a wrong keystroke usually shows up as an obvious typo mid-word, while a wrong-window dictation lands as a complete, correctly-spelled sentence in a place nobody meant it to go, which is part of why it takes a beat longer to notice.