Mac hidden files: show them without breaking anything

Almost every answer to a mac hidden files show search is the same keyboard shortcut, and for the immediate problem that is enough. It stops being enough about ten minutes later, when a folder that was supposed to appear still does not, or when something that appeared turns out to be a system directory that should not be touched. The reason is that macOS hides things in three unrelated ways. One shortcut reveals two of them. Knowing which mechanism is in play tells you whether the file is a config file worth editing, an Apple directory worth ignoring, or a protected path that will refuse to change no matter what is typed.

Three mechanisms, one word

The first mechanism is the leading dot. A name that starts with a period is treated as hidden by convention, honoured by both Finder and the shell. This is where .zshrc, .gitignore, .env and .DS_Store live. Nothing about the file is special. The name is the whole mechanism.

The second is a file flag. macOS stores a hidden flag in the file metadata, entirely separate from the name. A folder with an ordinary visible name can carry it and disappear from Finder. This is how ~/Library is hidden, and it is why renaming it or looking for a dot in front of it explains nothing.

The third is not hiding at all, but it gets confused with hiding constantly. Some paths are protected by System Integrity Protection and carry a restricted flag. They can often be seen, but they cannot be modified, and the error that comes back reads like a permissions problem rather than a policy one.

Sorting a given file into one of these three before acting on it saves most of the wasted time. A dot file is yours to edit. A flagged folder is usually Apple's, but not always. A restricted path is off limits by design.

Why a hidden file is suddenly needed

The search rarely comes from curiosity. It comes from a specific errand, and the errand determines which of the three mechanisms is involved.

Development work supplies the most common one. Shell configuration, credentials in a .env file, ignore lists, editor settings and per-project tool configuration all live in dot files, and every one of them has to be readable and editable rather than merely visible. These are the files where turning the toggle on is a convenience, not the point.

Application support data supplies the second. Preferences, caches, container folders, mail data and browser profiles sit under the home Library folder, which is hidden by a flag rather than a dot. Support instructions send people there constantly, usually to remove a cache or copy a profile before a reinstall, and the folder's absence from the home window is the first obstacle every time.

Troubleshooting supplies the third. Something is consuming disk space, or a folder is refusing to sync, or a file that should be gone keeps reappearing. Here the hidden entries are usually the answer rather than the target: a per-volume trash directory, an index being rebuilt, a version history store.

These three errands want different tools, which is why one shortcut disappoints so often. Editing a dot file wants a terminal or an editor with the path. Reaching Library wants a direct route rather than a global reveal. Investigating disk usage wants visibility across a whole tree at once, which is closer to a search than to a toggle. Naming the errand first makes the rest of this straightforward.

The toggle that answers most searches

In any Finder window, pressing Command-Shift-Period switches hidden items on and off. It is a toggle rather than a setting buried in preferences, it applies to every Finder window at once, and it survives until it is pressed again.

What it reveals is both dot files and flag-hidden folders. Open the home folder with it on and ~/Library appears alongside .zshrc, .Trash and a long list of dot directories left behind by development tools. Items revealed this way are drawn dimmed, which is a useful signal: the dimming means "this is only visible because the toggle is on", not that anything is wrong with the file.

Two things about the toggle are worth internalising. It changes what Finder draws, not what exists, so nothing about the disk changes when it is pressed. And leaving it on permanently is a mixed blessing. The home folder of a working machine accumulates dot directories from every tool ever installed, and scrolling past them to reach the four folders that matter is its own small tax. Most people end up toggling it on for a task and off again afterwards.

What the shell shows, and the two entries nobody wants

The terminal has no hidden files in the Finder sense. It has options.

ls on its own omits anything starting with a dot. ls -a includes everything, including the two entries . and .. that refer to the current and parent directory. ls -A includes the dot files but leaves those two out, which is almost always what is actually wanted. On a home directory that has been used for real work, the difference between ls and ls -A can be several screens of output.

The flag mechanism is invisible to all of these. ~/Library shows up in ls output normally, because the shell does not consult the hidden flag at all. That asymmetry explains a common confusion: a folder that is missing in Finder but present in the terminal is not a sync problem or a corrupted view, it is a flag doing exactly what it was set to do.

To see the flags themselves, ls -lO adds a column between the group and the size. On a stock machine, /usr and /bin show restricted,hidden, /Volumes shows hidden, and most ordinary folders show a dash. That single command answers the question of which mechanism is hiding a given item, which is the question the search usually should have been.

The hidden flag, set and cleared

Flags are changed with chflags. The manual page describes the relevant keyword plainly: hidden sets the hidden flag, and putting no in front of a keyword clears it. So chflags nohidden ~/Library makes that folder permanently visible in Finder without turning on the global toggle, and chflags hidden ~/somefolder does the reverse for a folder that should stay out of the way.

This is the right tool for a narrow job: one folder that should always be visible, or one working directory that should not clutter a shared desktop. It is the wrong tool for browsing, because clearing the flag changes the disk while the Finder toggle changes only the view.

Two cautions apply. Clearing a flag on system directories is possible on unprotected paths and achieves nothing useful, since the reason they are hidden is that they are not meant to be browsed. And on protected paths it will fail regardless, because System Integrity Protection is enabled by default and restricted outranks any flag change. The status can be read with csrutil status, and the correct response to "System Integrity Protection status: enabled" is to leave it that way and find another route.

Reaching one hidden folder without revealing all of them

Most of the time the goal is not to see hidden files in general. It is to reach one specific folder, usually ~/Library, and Finder has two direct routes that avoid the toggle entirely.

The first is the Go menu.

Tip: To go to your Library folder, press and hold the Option key, then choose Library. Source: support.apple.com

The second is typing the path. Shift-Command-G opens the Go to Folder field, which accepts a path directly and autocompletes as it goes. It reaches hidden folders whether or not the toggle is on, which makes it the fastest route when the destination is already known. Pasting a path copied from a support article or a terminal window into that field is usually quicker than clicking through anything.

There is also a per-folder view option. With the home folder open, Command-J shows the view options for that window, and on the home folder specifically the list includes a checkbox for showing the Library folder. It affects that one folder rather than the whole system, which is often exactly the right scope.

The defaults command, and when it earns its place

The older approach still circulates widely:

defaults write com.apple.finder AppleShowAllFiles -bool true
killall Finder

It sets the same preference the keyboard toggle sets, and the second line is required because Finder reads the value at launch. killall Finder quits and relaunches it, which closes open Finder windows in the process.

For a person at a keyboard, the shortcut is better in every way. Where the command still earns its place is automation: a setup script that configures a new machine, or a step in a provisioning tool that should not depend on someone pressing keys. Setting the value to false and running killall Finder again reverses it.

The pitfall is treating the command as more authoritative than the shortcut. They write the same preference, so pressing Command-Shift-Period after running the command simply toggles it back, and the two are not layered.

What to leave alone once everything is visible

Turning the toggle on reveals directories that look like clutter and are not. At the root of a volume, entries such as .Spotlight-V100, .fseventsd, .DocumentRevisions-V100, .TemporaryItems and .Trashes belong to search indexing, file system event logging, document version history and the trash. Deleting them does not free meaningful space and does cause the system to rebuild them, sometimes noisily.

.DS_Store is the one people delete most often. Finder writes it in a folder to remember view settings, icon positions and window size for that folder. Deleting it loses those settings and Finder writes a fresh one on the next visit. It is harmless to remove and equally harmless to leave, and the only real reason to care is that it tends to end up in shared folders and version control, which is what .gitignore entries are for.

The last thing worth knowing is that Finder will not let a new file be named with a leading dot. Creating or renaming a config file therefore happens in a terminal, or in an editor that accepts the path, and the browsing usually happens in Finder. That split is the actual daily friction behind this search: the folder is in one window and the command that edits its contents is in another. Working in a file manager with a built-in terminal removes the switch, since the visible folder and the shell prompt share a window, and the comparison with other file managers is largely a comparison of how each design handles that same boundary.

What to change first

Use Command-Shift-Period for looking, Shift-Command-G for going somewhere specific, and chflags nohidden only for the one or two folders that should be permanently visible. Then check where the editing actually happens after each of those trips, because that is the window switch worth removing, and the one a tool like Atriens is built around.