Hidden Bar not working on Mac: what to check

The arrow does nothing. Or it collapses the bar and the icons come straight back. Or everything hides except the one icon that was supposed to stay. These read like the same fault and they are not: a menu bar hider has three failure surfaces that barely touch each other, and reinstalling addresses roughly one of them.

Sorting the symptom first saves the hour that usually goes into resetting preferences that were never the problem.

Three symptoms, three different owners

No entry point. The arrow or the separator is missing from the menu bar, or clicking it produces nothing. This is about whether the app is running and whether it is registered to start.

Nothing hides. The controls are there, the bar collapses, and the icons stay put. Or the bar expands on its own. This is about the operating system and the auto collapse behavior.

The wrong icons hide. Items that should be visible disappear, or a specific icon cannot be targeted. This is about ordering, and it is the only one of the three that is fixed by dragging.

Keep them separate. A fix for one has no effect on the other two, and mixing them is what turns a five minute check into an afternoon.

The reason this matters more than it sounds: the three categories fail in ways that mimic each other from the outside. An app that never started looks identical to an app whose hiding mechanism stopped working, because in both cases pressing the arrow does nothing visible. An icon sitting on the wrong side of the separator looks identical to an icon the app refuses to hide. Testing which category applies takes one action each. Check whether the app appears in the list of running applications, collapse the bar and watch whether anything moves, and note whether the icons that disappear are the intended set.

The installed version decides which instructions apply

Before checking anything else, establish which build is on the machine, because the documentation online describes several.

Source	Version	Dated
Mac App Store listing	1.8	June 1, 2021
Latest GitHub release	v1.10	March 3, 2026
Homebrew cask hiddenbar	1.10	tracks the GitHub release

Checked September 10, 2026. The repository manual states macOS 13 Ventura or later as the requirement for current code, and directs anyone on 10.13 through 12.x to v1.10, which it describes as the last release using the older autostart mechanism. The App Store metadata lists a floor of macOS 10.12 for build 1.8.

A missing preference, a setting that behaves differently than documented, or a fix that does not exist in the interface usually resolves to this gap rather than to a fault.

Permissions are not usually where this breaks

The reflex for a menu bar utility that will not work is to open System Settings and look for a missing Accessibility grant. For this app that search comes up empty by design.

The architecture notes describe a sandboxed application with no network entitlement, no file access, no helper process, and no subprocess use. It does not manipulate other apps' icons at all. It inflates the width of a status item it owns, which pushes everything to the left of that item off screen. Nothing about that requires permission over other applications, so the absence of an entry in the Accessibility list is normal rather than a sign of a broken install.

Two permission adjacent things can still stop it:

Gatekeeper on a non App Store download. A zip from the releases page is subject to the usual first launch check. If that check was declined, the app never ran, which explains an arrow that never appeared. The general handling of downloaded apps is documented by Apple Support.

A hotkey already claimed. The global shortcut registers through a small wrapper around the Carbon hotkey API. If another app registered the same combination first, the later registration quietly fails and the key does nothing. Changing the combination is faster than diagnosing which app took it.

A bar that resets after every restart is a login item problem

Sorted icons that revert to their raw order after a reboot point at one thing: the app is not starting with the session.

Current builds register through the macOS 13 login item mechanism, which means the entry appears in System Settings under General and then Login Items, and can be revoked there. The awkward case is a registration that was denied once. Re-ticking the checkbox inside the app does not always restore it. The documented sequence is to enable the entry in System Settings first, then toggle the app's own preference off and on.

There is a second case for long time users. Older versions installed a separate small launcher application, and that kind of registration persists in the operating system's background task database rather than being cleaned up automatically. Launching a current build runs a one time migration that deauthorizes the legacy entry. So an unfamiliar launcher item in the Login Items list is not evidence of malware, and the answer is to run the current version once rather than to hunt through the file system.

Running the app manually and never registering it is also a legitimate configuration. In that setup, a fresh order after each restart is expected behavior, not a fault.

The controls themselves can be dragged off the bar

Command dragging is how icons move across the separator, and the app's own arrow and separator are ordinary status items subject to the same gesture. Pushing one of them past the edge removes the only interface the app has.

Older versions made that unrecoverable. Current builds force their own items visible at launch, so quitting and reopening the app brings them back. That makes relaunching the correct first response to a vanished arrow, ahead of any reinstall.

The inverse case is a third party icon that has vanished with no way to reach it. If the always hidden section is enabled, check there first. The manual is explicit that items in that zone are reliably pushed off screen only while the separators are also hidden, that always hidden items can reappear after expanding when separators are visible, and that critical icons should stay out of that zone until the behavior is reworked. Recovering an item stuck off screen means Command dragging it back into range.

Icons that were hidden before they were ever visible

A freshly installed app puts an icon in the menu bar and it is invisible from the start. Nothing was configured wrong.

macOS inserts a brand new status item at the far left slot. That slot sits inside the region this app pushes off screen, so a newly launched or newly updated app appears swallowed. The same thing happening again after an update has the same cause. No application can reposition another application's menu bar icon, so the tool cannot move the new arrival to safety on its own.

The fix is a single Command drag to the right of the separator, after which macOS remembers that placement per app. Pinning chosen icons in place through the app itself is described as under consideration alongside a larger redesign, not as a current feature.

When the operating system is the limit

Some symptoms have no setting behind them.

macOS 27 betas. The menu bar was re architected in that release cycle and width inflation stops hiding anything. A report covering this was opened on June 8, 2026 and remains under investigation. On a beta, this is the first thing to rule in, not the last.

The notch. Hidden items end up positioned under the notch area on notched MacBooks, and the technique cannot surface them there. Moving overflow into a separate bar is discussed in open feature requests rather than shipped.

A hard width ceiling. macOS caps a status item's length at 10,000 points, and the collapse width is derived from the widest attached display, recalculated when displays are connected or removed. Very wide multi display arrangements sit closer to that ceiling than a single laptop screen does.

Collapsing mid interaction. The auto collapse timer defers while the pointer is inside the menu bar band and re arms instead of firing. The check is positional, so a pointer sitting deep inside another app's open dropdown is below that band, and a collapse can fire while a menu is open. That is a known consequence of the approach rather than a timer bug.

Support runs through the project's issue tracker, which currently holds 101 open items. Searching it before writing anything usually finds the symptom already described, along with whether a fix exists.

An interface stuck in the wrong language

A less obvious failure is an app whose menus appear in a language nobody selected. This has been reported and has a documented answer, and it deserves handling before any other diagnosis, because unreadable preference labels make every other check harder.

Display language follows the system language order, so an unexpected result usually traces back to how that order is arranged rather than to a setting inside the app. Two routes exist. System Settings under General, then Language and Region, has a per application language option. The alternative is writing the AppleLanguages key against the identifier com.dwarvesv.minimalbar from Terminal, then quitting and relaunching the app so the change takes effect.

Worth stating plainly: an app showing the wrong language is still working. Nothing else needs to be reset because of it.

What a reinstall resets, and what it does not

Reinstalling gets reached for early and clears less than expected.

Icon order is stored by macOS per application, so a reinstall does not restore any previous arrangement and the Command dragging has to be redone. Settings written through Terminal live under the app's identifier and survive as well, which is why an unexpected hover to expand behavior or an odd auto collapse delay can persist across a clean install. What does get reset is the login item registration and the values in the preferences window, meaning a reinstall mostly undoes the parts that were quickest to configure.

Work in this order instead: identify the symptom category, confirm the build, check the login item, check which side of the separator the icon sits on, and treat reinstalling as the last step rather than the first.

What to change first

Start by naming which of the three symptoms is actually happening, then check the build version and the Login Items list before touching any preference. If the answer turns out to be a limit of the hiding technique rather than a setting, the useful comparison is how other tools handle the same cases: the how it compares page lays out the differences in approach, and the FAQ covers the permission and login item questions that come up during setup. For a bar where hidden items still need to be clicked without expanding everything, Koffret is built around that specific case.