Focus follows mouse on Mac: what's possible, and what to use instead

If you have ever used a Linux desktop, you know the feeling: you slide the pointer over a terminal, start typing, and the keystrokes land there. No click. On a Mac, the same move types into whatever window you last clicked. Focus follows mouse on Mac is the single most requested behaviour that macOS still does not ship — and the advice you find for it is a mix of one command that only works in one app, and utilities whose caveats nobody mentions until you install them.

Here's the honest map: what macOS does, what you can bolt on, where each option breaks, and the approach that solves the underlying problem without asking your wrist to aim at anything.

Does macOS have focus follows mouse?

No. There is no setting in System Settings, no hidden pane, and no supported system-wide defaults key. macOS is click-to-focus by design: the window you last clicked keeps keyboard focus until you click another one, or until an app raises a window itself.

This is not an oversight so much as a different model. macOS separates focus from raise in places Linux window managers usually don't, and it exposes several things you can do to a background window without focusing it at all:

• Scroll it. Point at any visible background window and use the scroll wheel or trackpad. It scrolls, and focus stays where it was.
• Move it without raising it. Hold ⌘ and drag a background window's title bar. It moves; the front window stays front.
• Click a control without bringing the whole window forward. Many standard controls — buttons, checkboxes, tabs — respond to a ⌘-click in a background window without raising it.

Those cover a surprising amount of what people actually want focus follows mouse for. They do not cover the main one: typing into the window under the pointer.

The one place it is built in: Terminal

Terminal.app has a real, supported focus-follows-mouse preference. It is not in the UI, but it is a documented Terminal setting rather than a hack:

defaults write com.apple.Terminal FocusFollowsMouse -bool true
killall Terminal

The important caveat is the one most write-ups bury: this affects Terminal windows and nothing else. Hovering a Terminal window focuses it; hovering Safari does nothing. Set it back with -bool false.

iTerm2 ships the same idea as a visible checkbox — Settings → Pointer → "Focus follows mouse" — and it too only governs iTerm2's own windows.

If you came here because a forum post told you a defaults write command enables focus follows mouse on macOS, this is that command, and this is why it did not do what you expected.

Third-party focus follows mouse on Mac

For system-wide behaviour you need a utility that watches the cursor and pushes focus using the Accessibility API. Every one of them therefore needs Accessibility permission, and every one of them is polling or event-tapping rather than hooking something macOS provides.

Tool	What it does	Cost	Watch out for
AutoRaise	Focuses and optionally raises the window under the cursor; tunable delay, ignore lists, cursor warping on ⌘-Tab	Free, GPL-3.0	Can't focus panes inside one window (tmux, iTerm splits); some non-native apps need a build flag
AutoFocus	Swift rewrite of the same idea with a modular rule system	Free during its public beta	Beta software at the time of writing
yabai	focus_follows_mouse set to autofocus (focus, don't raise) or autoraise	Free, open source	It's a full tiling WM, not a small utility; users report the setting silently stopping after a while and needing a restart
Hammerspoon	DIY: an event tap that focuses the window under the pointer	Free, open source	You are maintaining it; the naive version fires during Mission Control, sheets and menus
AeroSpace	—	Free, open source	Does not implement focus follows mouse; it is an open feature request
Let's Switch	A different answer — go to the window by keyboard instead of aiming at it	Free tier; Pro $9.99 once	Not focus follows mouse. It removes the reason you wanted it

AutoRaise is the one most people end up on, and it deserves that: it is open source, and its long options list exists because its author hit the same edge cases you will. If focus follows mouse is a habit you carried over from twenty years of X11, install it — we would rather you had the workflow you want than a click from us.

Why hover focus stays fragile on macOS

It is worth knowing what you are signing up for, because these are not bugs anyone can fully fix:

• There is no OS hook. Nothing tells an app "the pointer entered another app's window". Tools poll cursor position on a timer, so responsiveness and CPU use trade off against each other directly.
• Focus and raise are separate decisions. Focus-without-raise feels right until you realise you're typing into a window you can only half see. Raise-on-hover feels right until a window flies to the front because the pointer crossed it on the way to the menu bar.
• Delay tuning is personal and never finished. Too short and the desktop twitches as you move; too long and it feels broken. Modal sheets, menus, Mission Control and full-screen Spaces are all cases where "the window under the cursor" is simply the wrong answer.
• The permission is fragile. Accessibility grants get dropped by major macOS updates, and when they do, the tool goes quiet rather than complaining — see our guide to window tools that stop working.

The keyboard answer: stop aiming altogether

Step back from the mechanism and look at the goal. Nobody wants hover focus for its own sake. They want to get keyboard focus into a specific window without a click — which is a switching problem, not a pointing one.

That reframing matters, because hover focus only reaches windows that are already visible — and the window you want is usually the one buried behind three others. ⌘-Tab doesn't help either: it switches apps, so it gets you to "Chrome", not to the Chrome window with the docs in it.

Let's Switch is our answer to that. Hold ⌥-Tab and you get a live preview of every open window across every monitor, most recent first; tap Tab to walk the list, let go to land. ⌥-backtick cycles the windows of the current app. Both are free, permanently — not a trial. Pro ($9.99, once, no account, up to 20 devices per key) adds an ⌥-Space search palette when you have too many windows to flip through: type three letters of a window title and press return.

It is not focus follows mouse, and we won't pretend it is. It is faster than hovering for the case that actually matters, it does not need to watch your cursor, and it does not have a delay to tune. Pair it with Let's Tile — windows placed on a grid, by keyboard — and the mouse stops being part of the loop at all. That combination is the mouseless Mac workflow in two small apps, with no telemetry in either.

Which should you pick?

• You want the X11 habit back, exactly. Install AutoRaise, set a delay around a tenth of a second, and add your menu-bar apps to the ignore list.
• You only ever wanted it for terminals. Use the Terminal or iTerm2 setting above and stop there. It is supported, it is one line, and it has no side effects on anything else.
• You already run yabai. Set focus_follows_mouse autofocus in your config; you have the machinery already.
• You want the pointer out of the loop. Use a keyboard switcher. Hovering still costs you a hand movement and an aim — the thing you were trying to avoid.

Frequently asked questions

Is there a System Settings toggle for focus follows mouse? No. Not in macOS 26 Tahoe, and nothing announced for macOS 27 Golden Gate. Any guide showing you a checkbox is showing you a third-party app's preferences.

Does the defaults write command work system-wide? No. com.apple.Terminal FocusFollowsMouse is read by Terminal only. There is no equivalent global domain key, and writing one to NSGlobalDomain does nothing.

Can I get focus without raising the window? Yes — that is AutoRaise's delay 0 behaviour and yabai's autofocus mode. Be aware you will sometimes be typing into a window that is partly hidden behind another.

Will a focus-follows-mouse tool slow my Mac down? Not meaningfully at sane settings, but it is doing continuous work: a cursor-position poll on a short timer, plus Accessibility queries when the window under it changes. That is the cost of the missing OS hook.

Does any of this work on a trackpad? It works, but it fits badly. Trackpad users lift and reposition the pointer constantly, so the focused window changes far more than intended. This is the group for whom a keyboard switcher is the clearer win.