Focus follows mouse on macOS, without raising windows

Updated 2026-09-11 · 5 min read · by Okie Dockie

The two-click problem

You have two windows side by side. You are typing in the left one, you see a button in the right one, you click it — and nothing happens, because that click only focused the right window. Click again and the button finally responds.

macOS has worked this way forever. Some applications opt into click-through for some controls, which makes it worse rather than better: you can never quite predict whether a click will land. On Windows and on Linux this is not a thing people think about, which is why it is one of the first complaints from anyone switching.

It compounds with window tiling. The more windows you have arranged on screen — and the whole point of snap layouts is to have several — the more of your clicks are wasted on focusing.

Why the old tricks stopped working

Search for this and you will find a defaults write command for Terminal:

defaults write com.apple.terminal FocusFollowsMouse -bool true

It works, and it only affects Terminal. There is no system-wide equivalent. Older hacks that poked at the window server, and utilities built on them, stopped working as Apple tightened what unsigned code may do to other applications. Anything that still works today does so through the Accessibility API, with your explicit permission.

Focus without raising: the crucial distinction

This is where most implementations go wrong, and it is worth understanding before you install anything.

There are two separate ideas that sound like one:

• Focus — which window receives your keystrokes and clicks.
• Raise — which window is visually on top of the others.

What you want is focus. If hovering also raises, then every time your pointer crosses a window on the way to somewhere else, that window jumps to the front and rearranges your screen. Drag your mouse diagonally across four tiled windows and you have reshuffled the stack four times. Within a day it is unbearable, and it is the reason most people who try focus-follows-mouse turn it off again.

Focusing without raising is technically fiddly — it needs a specific, undocumented window-server call, and the obvious variant of that call is the raising one. Okie Dockie deliberately has no raise option at all. Hover a window, type into it, click into it; the stacking order never changes, and the window you had on top stays on top.

How to set it up

1. Install Okie Dockie and allow it under System Settings → Privacy & Security → Accessibility.
2. Turn on click-through focus from the menu bar icon.

That is the whole configuration. From then on the window under your pointer takes your keystrokes, and a click acts on the control you clicked instead of being swallowed. It is free — window behaviour is not the paid part of the app.

It costs effectively nothing to run: a single shared event tap, no polling and no timers, which is why the app uses about 36 MB of memory when idle, peaking around 86 MB only while a switcher or list is on screen.

The one case it cannot fix

Chromium-based browsers ignore a focus change that does not reorder windows. Hover from one Chrome window to another and Chrome will not accept the focus, because it is watching for the raise that never comes.

We could work around it by raising the window, and chose not to — bringing Chrome windows forward every time your pointer crossed one would be far more disruptive than the problem it solves. So: focus follows your mouse everywhere, except between two Chrome windows, where you still click once. Any tool that claims otherwise is raising windows, and you will notice.