Mac Finder sidebar not showing: the switches involved

A Finder window opens and the left hand column is not there. Favourites, iCloud, locations, tags, all gone, and the file list has expanded to fill the space where they were. The menu item that should bring it back is either not doing anything or is dimmed and cannot be clicked. There are four separate switches involved and one dependency between them, and knowing which one is set wrong turns this from guesswork into a ten second fix.

What the View menu is actually reporting

The View menu holds the switches for every strip that can be added to or removed from a Finder window: the sidebar, the toolbar, the path bar, the status bar and the tab bar. Each of them toggles independently, and each shows its current state in the wording of the menu item, which reads Show when the strip is hidden and Hide when it is visible.

That wording is the first diagnostic. If the item says Hide Sidebar while nothing is visible on the left, the strip is not missing. It is present at a width close to zero, and the fix is to drag the divider, not to toggle the menu. If it says Show Sidebar and clicking does nothing visible, the window is probably not the one you think it is: a Finder window opened in full screen, or a save dialog, keeps its own state.

If the item is dimmed and cannot be clicked at all, that is the dependency, and it is covered two sections down. Dimmed is a different fault from off, and treating them the same is what produces the loop of clicking a menu item that never responds.

Four shortcuts cover every strip

Apple documents the keyboard equivalents for all of these in one place, and the exact wording is worth reading because it contains a condition that explains a common failure:

Option-Command-S: Hide or show the Sidebar in Finder windows.

Option-Command-P: Hide or show the path bar in Finder windows.

Command-Slash (/): Hide or show the status bar in Finder windows.

Source: support.apple.com

The toolbar has its own shortcut, Option-Command-T, and the documentation attaches a condition to it that the other three do not have: it hides or shows the toolbar when a single tab is open in the current Finder window. With two or more tabs open, the key combination does nothing, and the menu item is unavailable. That is not a bug report waiting to be filed. It is documented behaviour.

One more combination belongs on the list even though it is not a visibility switch. Control-Command-T adds the currently selected item to the sidebar, which is the fastest way to put a folder into Favourites without dragging it there.

The dependency that makes Show Sidebar unclickable

The sidebar cannot be displayed in a window whose toolbar is hidden. Choosing Hide Toolbar removes both strips at once, and from that point the Show Sidebar item stays visible in the menu but dimmed, because there is nowhere for it to appear.

That is why the most common report about this problem, that the menu item exists but will not respond, is nearly always the same underlying state. The window is in the mode with no toolbar. Choosing Show Toolbar restores it, and the sidebar either comes back on its own, if it was visible before the toolbar was hidden, or the Show Sidebar item becomes clickable again.

The reason this catches people is that Hide Toolbar is easy to trigger by accident. Option-Command-T is next to several combinations in regular use, and the resulting window, with no toolbar and no sidebar, looks less like a mode and more like a broken application. Checking the top of the window for a search field and back button takes a second and answers the question immediately.

The setting is stored per kind of window, not once

This is the part that makes the problem look inconsistent. The sidebar appears in a normal folder window but not in search results, or not in Trash, or not in the window that opens when a package is inspected, and no amount of toggling in one of them fixes the others.

Finder keeps a separate record for each kind of window. Reading the preferences file on a working Mac shows nine separate WindowState entries, one each for the computer view, the iCloud view, the network view, the package view, the search view, the recent searches view, the shared search view, the Trash view and one more, and every one of them carries its own ShowSidebar, ShowToolbar, ShowStatusBar and ShowTabView flags. On the machine checked, ShowStatusBar was false in some of those entries and true in others, which is the proof that they are genuinely independent rather than copies of one setting.

The practical consequence is simple. Toggling the sidebar in a search results window sets it for search results. If the sidebar is missing only in one context, go to that context and toggle it there.

Showing the strip and filling it are two different settings

A sidebar that is visible but nearly empty is a different fault with a different fix. The visibility switch is in the View menu. What appears inside is controlled in Finder Settings, on the Sidebar tab, where every possible row has a checkbox: the home folder, Documents, Downloads, Desktop, AirDrop, Recents, iCloud Drive, connected drives, tags and so on.

The rows for hard disks, external disks and connected servers are worth checking first, because they are the ones people report as missing most often, and because a drive that is unchecked there will never appear no matter how many times it is plugged in.

Removing a row is not the same as deleting anything. The sidebar holds references, so dragging a folder out of Favourites removes the shortcut and leaves the folder exactly where it was on disk. That asymmetry is worth stating plainly, because hesitation about tidying the list usually comes from not being sure.

The rows show display names, not paths

There is a second kind of confusion that gets reported as a sidebar problem and is not one. The names in the sidebar are display names, and on a system running in Japanese they are not the names on disk. The row labelled 書類 is the directory Documents, and the one labelled アプリケーション is Applications. The translation is triggered by an invisible marker file named .localized sitting inside the folder, which is present in /Applications and in the standard folders inside the home directory.

This matters the moment the sidebar stops being the destination. Clicking the row opens the right folder every time. Typing what the row says into Go to Folder, or into a terminal, produces No such file or directory, because that path does not exist. The command was correct and the name was not.

The reliable way to get from a sidebar row to a usable path is to drag it into a Terminal window, which inserts the real absolute path rather than the label. Shift-Command-G opens Go to Folder, which accepts the on disk name, and a folder dragged into that field fills it in the same way.

Reading the current state without guessing

Two commands answer the question before you start clicking.

defaults read com.apple.finder SidebarWidth prints the stored width as a number. On the machine checked it returned 218. A value close to zero means the strip is present and collapsed, which is the case where the menu says Hide Sidebar and nothing is visible. Reading the file more closely shows that the width is not stored once: FK_SidebarWidth and FK_SidebarWidth2 are both present, and on the machine checked they held different values, 218 and 258. Changing the width by dragging updates what Finder is currently using, so the divider remains the thing to trust over either number.

plutil -p ~/Library/Preferences/com.apple.finder.plist prints the whole preferences file in readable form, and piping it through grep -A 6 WindowState shows each of those per window records with its flags. Reading true or false there is faster than opening a window of every kind to test them by hand.

If a change made with defaults write does not appear, the missing step is that Finder holds its settings in memory. killall Finder restarts it and reloads them. Open windows close, so it is worth finishing what is in them first, but nothing is lost beyond the window positions.

One thing that command does not do is stop Finder. It is a process that the system restarts immediately, by design, which is why the Quit item is absent from its menu unless it has been enabled deliberately. Anyone arriving from a Windows machine, where the file manager can be ended in the task manager and started again, tends to expect the sequence to take longer than it does. On a Mac the window reappears within a second or two, and the settings it reads on the way back up are whatever is in the preferences file at that moment.

Before you throw the preferences file away

The advice that circulates for this problem is to move com.apple.finder.plist to the Trash and restart. It does work, and it also resets every Finder preference at once: view styles, sort orders, the toolbar layout and the sidebar contents. It is a last resort, not a first step.

The sidebar contents themselves are not in that file. They live in the shared file list data under the user Library, and on a recent macOS that folder is protected: listing it from a terminal without Full Disk Access returns Operation not permitted. That protection is also why the fix cannot be applied by editing a file by hand, and why the supported route is the Sidebar tab in Finder Settings.

What the sidebar cannot do once it is back

Getting the strip back solves visibility. It does not solve the reason the sidebar was being relied on, which is usually that the same few folders are visited constantly and the path to them is long. A list of shortcuts shortens the trip, but it still only opens a folder. Everything after that, running a command against what is in it, comparing it with another folder, moving a result somewhere else, happens in a different window.

A file manager that keeps a terminal in the same window collapses that step, because the listing and the prompt are pointed at the same directory and neither has to be told where the other is. The Features page covers what that arrangement handles. For how it sits against the dual pane managers and Finder replacements that solve a different part of this, the Compared with other file managers page lays the differences out without ranking them, and the FAQ answers the practical questions about running it alongside Finder rather than instead of it.

What to change first

Check whether the toolbar is hidden before anything else, because a dimmed Show Sidebar has exactly one common cause. Then toggle the sidebar in the specific kind of window where it is missing, since the setting is stored separately for each. If the sidebar is being used as a substitute for a shorter path between finding a folder and doing something in it, Atriens addresses that second problem directly.