Hidden Bar: how to uninstall it cleanly

Dragging the app to the Trash is the easy part. What sends people looking for instructions is what happens after: a login item that still carries the name, or a menu bar whose icons come back in an order nobody recognises. Both have specific causes, and both take a couple of minutes to settle once the cause is named.

Hidden Bar is a sandboxed AppKit utility. It ships no daemon, no helper process, and no network entitlement, so the cleanup surface is unusually small. Four folders in the home library, one login item registration, and the app bundle. That is the whole list. What follows is how to confirm which build is installed, the order to remove things in, where the leftovers live, and why the ghost login item shows up.

First, check whether removing it will fix anything

Three different situations send people to an uninstall page, and only one of them is actually solved by uninstalling.

The hiding stopped working. On macOS 27 betas, the menu bar was re-architected and the length inflation trick the app depends on no longer hides anything. That is tracked as a known issue in the project. Removing the app on that machine changes nothing about the underlying problem, because the mechanism itself is what broke.

Icons are stuck under the notch. On notched MacBooks, items pushed into the hidden zone can end up behind the camera housing, where the trick cannot reach them. The project documents this as an architectural limit, with a spillover or second-bar design as the candidate fix. Again, deleting the app does not address it.

The tool is no longer needed, or something else is going in. This is the case where an uninstall is the right move.

Naming which of the three applies takes ten seconds and saves a pointless round trip. In the first two cases, deleting the app returns every icon to the menu bar and leaves the original complaint exactly where it was.

Confirm which build is on the Mac

The same app arrives through three channels, and they are not at the same version. Checked on 2026-09-10:

Source	Version	Notes
Mac App Store	1.8	Last updated 2021-06-01. Listed minimum is macOS 10.12. Free
Homebrew cask hiddenbar	1.10	Pulls the GitHub release. Supports a zap that removes settings
GitHub releases	Newer than 1.10	Requires macOS 13 Ventura or later. Builds outside the App Store are notarized

The gap matters for removal. A copy that has been sitting there since the App Store build will still be carrying the old login item mechanism, which is the one that leaves a ghost. A Homebrew copy can be removed with settings in a single command. A ZIP downloaded from the releases page is not tracked by anything, so every part of it comes out by hand.

Two checks settle it. Open the app's preferences from the context menu on the arrow and read the version. Then run brew list --cask and see whether hiddenbar appears. If it does not appear and the version is 1.8, it came from the App Store.

Remove things in this order

Sequence matters only a little, but getting it wrong adds a trip back to System Settings.

1. Click the arrow so the hidden section is expanded. This is purely so the current state is visible before anything changes.
2. Open System Settings, go to General, then Login Items, and turn off the Hidden Bar entry.
3. Right-click the arrow and choose Quit.
4. Move Hidden Bar.app from the Applications folder to the Trash.

Step 2 comes before step 3 because once the app is gone, its own preference toggle is gone with it, and the login item has to be chased down in System Settings anyway.

Quitting is what brings the icons back. The app never moves another application's status item, and macOS offers no API that would let it. What it does is inflate the width of its own separator item to roughly twice the width of the widest attached display, which shoves everything to the left of it past the edge of the screen. Once the app quits, the separator goes with it, and every pushed icon reappears on its own.

The four folders it leaves behind

After the app bundle is gone, these are the only paths that remain. They are the exact set the Homebrew package definition marks as safe to remove.

Path	What is in it
~/Library/Containers/com.dwarvesv.minimalbar	The sandbox container. Settings live here
~/Library/Application Scripts/com.dwarvesv.minimalbar	Scratch space the sandbox uses
~/Library/Containers/com.dwarvesv.LauncherApplication	Container for the old autostart helper
~/Library/Application Scripts/com.dwarvesv.LauncherApplication	Scratch space for that helper

The reason nothing sits outside the home library is stated plainly in the project's own architecture notes:

There is no helper app, no daemon, no network. Everything happens inside three NSStatusItems and one window. Source: github.com, architecture notes checked 2026-09-10

No launch daemon in /Library, no privileged helper tool, no cache directory to hunt down. All four paths are inside the user's own library, so no administrator password is needed. In Finder, use Go then Go to Folder and paste the path.

The same notes describe the app as sandboxed and hardened, with no network entitlement and no interprocess communication surface. That is worth knowing for a different reason than tidiness: it sets the boundary on what a removal can possibly leave behind. Utilities that run a privileged helper to read sensors or control fans have to place files in /Library and register a launch daemon, and those survive a Trash operation because they were installed with elevated rights. Nothing of that kind applies here.

If it came from Homebrew

brew uninstall --cask hiddenbar quits the app and removes the bundle. brew uninstall --zap --cask hiddenbar does the same and deletes the four folders above.

One caveat. The cask tracks version 1.10, and the releases page has moved past that. On a Mac where Homebrew installed it and a newer ZIP was later dropped in on top, the two records disagree. The zap still clears the folders, but the app bundle itself has to go to the Trash by hand.

Why a login item survives the delete

Older versions registered startup through a separate helper app with the bundle identifier com.dwarvesv.LauncherApplication. macOS records registrations like that in its background task management database, and that database does not garbage collect entries whose origin has disappeared. Delete the app and the record stays.

Current versions run a one-shot migration on first launch that deauthorizes the legacy registration. That produces a slightly counterintuitive piece of advice: before uninstalling an old copy, update it and launch it once. The migration runs, the legacy entry is released, and the uninstall leaves nothing behind.

If a ghost entry is already there, System Settings, General, Login Items is the first place to clear it. Select the entry and remove it. That is enough in almost every case. The heavier option, resetting the whole background task database from Terminal and restarting, exists but touches the login item settings of every other app on the machine, so it is worth exhausting the simple route first.

There are no permissions to revoke

A habit worth unlearning during any Mac uninstall is the sweep through System Settings, Privacy and Security, looking for entries to switch off. For this particular app there is nothing there to find, and understanding why saves the search.

Hiding icons requires no privileged access at all. The whole mechanism is one status item changing its own width, which any app is allowed to do to itself. That is also why the approach has hard limits: an application cannot reposition or hide another application's status item, so the only lever available is geometry.

The optional extras stay inside the same boundary. The global keyboard shortcut is registered through the Carbon hotkey API, which does not require Accessibility access the way synthesising or intercepting keystrokes would. Hover to expand, when it is switched on, installs a global mouse-moved monitor that reads pointer position and discards the rest of the event. Neither of those puts an entry in the Accessibility, Input Monitoring, or Full Disk Access lists.

So the checklist after removal is genuinely short. Login Items in System Settings, four folders in the home library, one app bundle. Anything else that looks related, such as a stray entry with a similar name in Login Items, points back to the legacy helper covered in the previous section rather than to a permission grant.

One item does sit in a system list on recent macOS versions. Starting with macOS 26, applications must be allowed to display menu bar items under a dedicated Menu Bar control in System Settings. That entry belongs to the operating system rather than to the app, and it disappears on its own once the app is gone.

Putting the menu bar back in order

The moment the app quits, every icon it was pushing off-screen returns. The order will not match what it was before, because the positions were shuffled while the separator was in play.

Rearranging is a ⌘-drag on each icon. macOS stores the placement per application, so a single pass holds. The one behavior worth knowing is that macOS inserts any brand-new status item at the far-left slot, which means each newly installed app adds one more icon to the left end of the row.

Two questions are enough to decide what earns a permanent slot. Does seeing it carry information on its own, such as whether something is connected or a sync has finished? Is it clicked several times a day? An icon that fails both has no reason to occupy space, whether or not a hiding tool is installed.

Resetting settings without uninstalling

For a machine where the goal is a clean configuration rather than removal, the settings live under the domain com.dwarvesv.minimalbar. The project's manual documents three preferences that exist only through that domain and have no interface: hover to expand, the auto-collapse delay in seconds, and a language override.

To undo one key, defaults delete com.dwarvesv.minimalbar followed by the key name. To reset everything, quit the app, move ~/Library/Containers/com.dwarvesv.minimalbar to the Trash, and launch it again. Because the app is sandboxed, that container is the whole of its state. Nothing else needs touching.

What to change first

If the uninstall was step one of a replacement, the deciding factor is not how many features the next tool lists. It is whether a hidden icon can be clicked without unfolding the bar first, since unfold, scan, click, fold is a loop that repeats all day. The How it compares page lays out how different tools approach hiding, including the macOS versions they require, and Features covers separating icons that should stay out of sight permanently from ones that should surface on demand. Trying the behavior on the actual Mac is faster than reading about it, and Koffret is free to test.