Finder not responding on a Mac: read the symptom before restarting

The spinning wheel appears, the desktop stops taking clicks, and the menu bar will not drop down. The usual advice is to restart the Mac, which does often clear it, but a restart also throws away the evidence. The same thing comes back next week and nothing has been learned. What follows separates the symptom into its three real shapes, then lists the moves in order of how much they cost, starting with the ones that leave every other open app untouched.

Three different symptoms share one name

The phrase covers at least three distinct states, and they do not have the same fix.

In the first, Finder is alive but will not produce a window. Clicking its Dock icon does nothing. The menu bar reads normally, desktop icons are visible, and other apps behave. Only the code that builds a new window is stuck.

In the second, the window appears but stays empty. The toolbar and the view switcher are drawn, the file list is not. Sometimes a progress indicator runs in the path bar and never finishes. This points at the location being opened rather than at the app.

In the third, Finder is frozen outright. The pointer becomes a spinning wheel over the desktop, clicks are ignored, and the Dock shows that the application is not responding. Nothing in Finder answers, including the menu bar.

The distinction matters because the first and third states are usually cleared by relaunching Finder, while the second comes straight back after a relaunch. A relaunch rebuilds the app, and the app was never the problem. Deciding which of the three is on screen takes about five seconds and saves most of the time that follows.

Relaunching Finder is not restarting the Mac

Finder is built so that it cannot be quit the way other apps can. There is no Quit item that leaves the desktop empty. Instead macOS offers a relaunch, and that relaunch is far cheaper than a restart.

The quickest route is to hold Option and click the Finder icon in the Dock. The menu that opens contains a Relaunch item. Choosing it tears down Finder and builds it again. Every other open app keeps running, and unsaved work in those apps is not touched.

The second route is the Apple menu, then Force Quit. Select Finder in the list and the button label changes from Force Quit to Relaunch. This path still works when Finder is frozen hard enough that the Dock menu will not open, and it can be reached from the keyboard when the pointer is unresponsive.

Move	What it interrupts	When it fits
Relaunch from the Dock	Finder windows only	Frozen or refusing to open a window
Relaunch from Force Quit	Finder windows only	Dock menu will not open
Log out and back in	Every open app in the account	Relaunch clears it, then it returns within minutes
Restart the Mac	Everything, including background jobs	Nothing above worked, or the whole system is slow

What happens after the relaunch is the real diagnostic. If Finder comes back and stays healthy, the freeze was transient. If it freezes again within seconds, something Finder reads at startup is the cause, and the next section applies.

The common cause is a location Finder cannot reach

When Finder starts, it checks the locations it is expected to show: the folder that was open last, and every entry in the sidebar. If any of those cannot answer, Finder waits. A wait long enough to look like a freeze is still just a wait.

Network shares are the usual culprit. A share added to the sidebar is contacted on every launch. If the server is asleep, or the Mac is on a different network than it was yesterday, that contact hangs until it times out. During the timeout the window is unusable, and the eventual result is a message saying the server at that address cannot be reached.

There is a fast test for this. Turn Wi-Fi off and relaunch Finder. With no network at all, the lookup fails immediately instead of hanging, so a Finder that opens normally with Wi-Fi off has just identified its own problem. Removing that share from the sidebar stops the freeze from returning on every launch.

External drives produce the same pattern. A drive that was unplugged without being ejected can stay half mounted from Finder's point of view. Reconnecting it and ejecting it properly clears the stale entry. The Recents view has the same weakness, because it gathers items from many locations and inherits the slowest one. Setting new windows to open at the home folder avoids the whole class of problem.

When one folder is the problem, not the app

The second symptom, an empty window, almost always traces back to the folder being opened rather than to Finder.

Folders with very large item counts are slow to list, and slower still in icon view, because a thumbnail is generated for every visible item. The same folder often opens without trouble in list view. Switching the view before opening it, rather than after, is what makes the difference. Gallery view carries the heaviest cost, since it renders a large preview of the selected item as well.

A single unreadable item can also stall a listing. The way to find it is to open the folder in list view sorted by name and watch where the list stops. The item that would come next alphabetically is the candidate. Moving that one item elsewhere usually lets the rest of the folder appear.

To test whether Finder itself is healthy, bypass the sidebar entirely. Choose Go, then Go to Folder, and type a path that is certainly local, such as the home folder. If that opens and lists normally, Finder is fine and the previous location was the fault. This one test separates an app problem from a location problem without changing any settings.

Rule out the account before blaming the Mac

If relaunching helps only briefly and no location looks suspect, the next suspect is Finder's own preference file. It lives in the Library folder inside the home folder and stores view styles, sidebar entries, and window positions. A corrupted copy can stall the launch.

Before treating that file as the cause, create a second user account and log in to it. Finder starts there with fresh settings and an empty sidebar. If it behaves normally in the new account, the fault is in the original account's settings, not in macOS and not in the drive. If the new account freezes the same way, the preference file is innocent and the problem is wider.

When the file does need to go, rename it rather than delete it. Finder writes a new one on the next relaunch, and the old name can be restored if that made things worse. What is lost either way is cosmetic: view styles, sidebar order, window sizes. No document is affected.

Rebuilding those settings also empties the sidebar, which means this step quietly performs the fix from the previous section as well. That overlap is worth knowing, because it explains why the preference file often gets credit for a problem that was really an unreachable share.

Symptoms that are not Finder's fault at all

Some freezes get blamed on Finder because Finder is the window they happen in. The cause sits elsewhere, and relaunching does nothing.

Spotlight indexing is the classic case. After a large copy, a macOS update, or a new external drive being connected, the index is rebuilt in the background. Searches return partial results, a folder listing can lag, and the fans run. Nothing is broken. The load falls away once indexing finishes, and interrupting it only means it starts over later.

iCloud Drive produces a similar pattern. Files kept in iCloud and evicted from local storage have to be downloaded before they can be read, so a folder full of evicted items appears to hang while the download runs. The status shown next to each item distinguishes the two cases: a cloud icon means the file is not local yet. Opening such a folder without a working connection is a wait with no end.

A third case is another app holding a file open. Copying, moving, or emptying the Trash cannot finish while something else has the file, and macOS says as much with a message naming the file as being in use. The command line tool that lists open files will name the process that holds it. Quitting that app releases the file, and the stalled operation completes on its own.

The shared signal in all three is that the rest of the system stays responsive. Other apps accept clicks, the menu bar drops down, and only file operations are slow. True Finder freezes take the desktop with them. When everything else works, the answer is to identify what is running and let it finish, not to relaunch anything.

Escalate in order, not by cost

Once relaunching, checking locations, and testing a second account have all failed, the search widens. Three moves remain, and they are worth taking in this order.

Safe mode comes first. It boots with the minimum set of components, so an extension installed months ago stops being a variable. On a Mac with Apple silicon, hold the power button while the Mac starts until the startup options screen appears, then choose safe mode there. On an Intel Mac, hold Shift during startup. Apple lists both paths among the startup key combinations. A Finder that behaves in safe mode points at something added later.

Verifying the drive comes second. Inconsistencies in the file system make directory reads hang, which looks exactly like a Finder fault. Disk Utility has both a verify and a repair function, and the same checks can be run from the command line. Repairing the startup volume requires booting into recovery first.

A macOS update comes third, because some freezes are specific to one release. Back up before installing it. Erasing and reinstalling belongs after all of the above, not before: done early it recreates the same setup and the same freeze, with the cause still unknown.

What to change first

Decide the order now, while nothing is frozen: read the symptom, relaunch from the Dock, suspect the sidebar, test a second account, then escalate. Write down which step worked, because the same share or the same folder will do this again.

If the freezes keep tracing back to hopping between a file window and a terminal, the fix is structural rather than diagnostic. A file manager with a built-in terminal keeps the listing and the command line in one window, so one side stalling still leaves the other usable, and Atriens is built on that arrangement. How it differs from the tools already installed is set out on the comparison page, and the cost is on the pricing page.