Hidden Bar on Mac: how to set it up

The app is installed, an arrow appeared in the menu bar, and clicking it makes roughly everything vanish at once. That is the point where most people stop configuring and start living with a bar that is either fully hidden or fully cluttered. The setup that actually helps takes about ten minutes and is mostly one decision repeated a few times: which icons stay to the right of the separator.

What follows is the order that decision is easiest to make in, based on the project documentation and the current distribution channels.

First, confirm which build is installed

Three channels distribute this app, and they do not carry the same version.

Channel Version available Last updated Stated macOS floor
Mac App Store 1.8 June 1, 2021 macOS 10.12
GitHub releases v1.10 March 3, 2026 see note below
Homebrew cask hiddenbar 1.10 tracks the GitHub release see note below

Checked September 10, 2026, against the App Store listing metadata and the project repository.

The note: the manual in the repository states a requirement of macOS 13 Ventura or later, and tells anyone on 10.13 through 12.x to use v1.10, described as the last release built on the older autostart mechanism. The App Store build is free of charge, as is every other channel. The Homebrew cask reports 28,968 installations over the trailing 365 days, which is a rough signal of how many people take the non App Store route.

This matters before anything else because screenshots, menu labels, and behavior notes found online may describe a build that is five years newer or older than the one installed. If a setting described here is missing, the version is usually the reason.

Decide what stays to the right, not what to hide

The separator is the whole model. Icons sitting to its left slide off screen when the bar collapses. Icons to its right always stay visible. So the setup question is not which icons to hide, it is which three or four earn a permanent slot.

A workable sort:

Values you read. Battery percentage, input source, a recording indicator, a VPN state. The icon carries information that changes, and glancing at it is the entire purpose. These stay right.

Controls you press several times a day. Volume, display arrangement, a clipboard history, a window manager. Frequency decides this one. Anything pressed fewer than a couple of times a week does not qualify.

Confirmations. Sync finished, backup ran, the update daemon is alive. These report success, and success is the boring case. Send them left.

Icons nobody remembers installing. Before hiding these, check whether the app itself offers a preference to leave the menu bar entirely. Hiding an icon that should not exist wastes a slot in the hidden zone too.

A worked example makes the budget concrete. A typical bar on a working Mac holds something like fifteen items: the system group at the far right, then a cloud sync client, a password manager, a screenshot tool, a note capture tool, a VPN client, a display arrangement helper, a text expander, a backup agent, an update checker, an audio routing utility, and two or three menu bar widgets picked up along the way. Of those, the sync client and the backup agent are confirmations, the update checker is a confirmation, and the text expander runs entirely from the keyboard and never needs its icon at all. That is four items removed from consideration before the sorting even starts. The password manager and the screenshot tool are pressed daily and stay right. The VPN client depends on whether its state matters at a glance, which is a personal answer rather than a general one.

The point of running through the list this way is that the crowding usually comes from the confirmation group, and that group is the easiest to move because nothing is lost by hiding it. A failed backup announces itself with a notification. A successful one does not need a slot.

On a MacBook with a notch, the right side is narrower than it looks, because hidden items end up sitting under the notch area and cannot be revealed there. Three or four permanent slots is a realistic budget, not a conservative one.

To move an icon across the separator, hold Command and drag it. That gesture belongs to macOS, not to this app, and macOS remembers each app's position afterwards. Option-clicking the arrow toggles the separators into view without expanding the bar, which makes the drag target easier to see while sorting.

The six preferences, and the two that change daily use

Right-click the arrow, or left-click the separator, to reach the preferences window. Six settings live there.

Setting Effect
Start Hidden Bar when I log in Registers a login item, revocable in System Settings under General then Login Items
Show preferences on launch Opens the settings window at every start
Auto collapse Re-hides after a chosen delay
Global shortcut A system wide key to expand or collapse. Function keys display as F18 rather than Fn18
Enable always hidden section Adds a second zone that stays hidden even when expanded
Use full menu bar on expanding Temporarily changes the app's activation state so a crowded bar has more room while expanded

Two of these change how the setup feels. The login item is the difference between a bar that stays sorted and one that reverts to its raw order after every restart. Auto collapse is the difference between hiding as a state and hiding as a gesture: with a delay set, expanding to check something reverts on its own, so nobody has to remember to close it. The collapse countdown defers while the pointer sits anywhere in the menu bar, so it does not fire mid click.

The global shortcut is worth setting only after confirming the combination is not already claimed by another app. A silently conflicting hotkey looks exactly like a broken feature.

Three settings that exist only in Terminal

The project documents three preferences with no interface. All are written with defaults against the identifier com.dwarvesv.minimalbar, and the app has to be quit and relaunched afterwards.

Hover to expand. Off by default. When enabled, resting the pointer on the menu bar for about half a second expands the hidden section. It removes a click, and it also means the bar opens whenever the pointer passes near the top of the screen. Running a few days without it first makes the trade obvious.

A custom auto collapse delay. The preferences window offers a fixed list of durations. The underlying key accepts any number of seconds, so a value between the listed options is possible.

A forced interface language. The app follows the system language order by default. The key overrides that, which is the documented answer when the app is stuck showing a language nobody selected.

Removing any of them is a matter of deleting the same key, after which the interface value applies again.

Skip the always hidden section on day one

The second zone sounds like the natural next step, and the documentation attaches a condition to it. Items placed in the always hidden zone are reliably pushed off screen only while the separators themselves are hidden, which is the state reached by option-clicking the arrow. With separators visible, always hidden items can reappear after expanding. The manual describes this coupling as a known limitation under rework and advises against putting critical icons there for now, because recovering an item stuck off screen means Command dragging it back.

A first pass with one hidden zone answers the real question anyway: whether the bar is crowded because too many icons exist, or because too many of them are being kept visible for no reason. If a category of icon survives two weeks of never being expanded, that is when a permanent zone starts to make sense.

Multiple displays need no extra setup

macOS draws the menu bar on every attached screen, so the width used to push icons off screen is derived from the widest display currently connected, not the active one. Plugging in or removing a monitor triggers a recalculation automatically. There is no per display configuration to maintain.

Icon positions themselves are stored by macOS per app, which is why a changed display arrangement can leave the ordering looking scrambled even though nothing about the app changed. The fix is the same Command drag used during the first sort.

How updates arrive depends on the channel chosen earlier

Setup is not finished at the point the icons are sorted, because each distribution route hands over update responsibility differently, and that difference outlives the initial configuration.

App Store installs update through the App Store, which means no action and, at present, no new versions either: the listing has stood at 1.8 since June 2021. GitHub downloads update when someone downloads a newer zip and replaces the app, which is a manual step that tends to be skipped for a year at a time. Homebrew installs update alongside every other cask when an upgrade command runs, which is the closest thing to automatic for the non App Store route.

None of these is wrong, and the practical consequence is worth stating plainly: the version installed on day one is likely to be the version still running two years later unless the update path was chosen deliberately. For an app with 14,687 stars, 463 forks, and an MIT license, source availability guarantees the code stays inspectable, not that a given machine stays current.

The related question is what happens when the operating system changes underneath. The hiding technique used here relies on inflating a status item's width, and macOS caps that width at 10,000 points. Any OS release that alters how the menu bar lays itself out can affect that mechanism, which is why checking the repository's issue list before a major macOS upgrade is a more useful habit than checking it after something breaks.

What the setup does not solve

Once a group of icons is collapsed, reaching one of them means expanding the bar, which restores the crowded row for as long as it stays open. For an icon carrying a badge or a live count, that round trip happens several times a day and cancels part of what the sorting achieved. Tools differ here: whether a hidden item can be clicked and its menu opened while the bar is still collapsed is a design decision, and the features page sets out how that works when it is supported.

The other difference worth checking before settling in is how each tool behaves around the notch and how it handles updates, since the trick used to hide icons is not the same across this category. That comparison sits on the how it compares page, and the questions that come up during installation, permissions included, are collected in the FAQ.

What to change first

Set the login item, set an auto collapse delay, then move exactly three icons to the right of the separator and leave everything else on the left for a week. Adjust from there rather than sorting all of them at once. If the expand and collapse round trip turns out to be the part that grates, that is a tool choice rather than a settings problem, and Koffret is one of the options built around it.

Frequently asked questions

Why did a newly installed app's icon appear already hidden?

Because macOS inserts a brand new menu bar icon at the far left slot, and that slot is inside the zone this app pushes off screen. It is macOS positioning behavior rather than the app moving anything: no app can reposition another app's menu bar icon. Command drag the icon to the right of the separator once and macOS remembers the placement.

Does this app need Accessibility permission?

No. The app is sandboxed, has no network entitlement, and does not use file access or a helper process. The one authorization involved is the login item, which appears in System Settings under General then Login Items and can be revoked there.

Is the App Store version equivalent to the GitHub release?

Not currently. The App Store listing shows version 1.8 dated June 1, 2021, while the newest GitHub release is v1.10 from March 3, 2026. Both are free. Choosing GitHub or Homebrew means newer code and manual updates, unless the Homebrew cask is upgraded along with everything else.

The arrow disappeared from the menu bar. Is the app gone?

Probably not. Command dragging the app's own arrow or separator off the bar removes its only interface, and current builds restore those items on the next launch. Quitting and reopening the app is the documented recovery, so a reinstall is rarely needed.

Back to all posts