Bartender not working on Mac: what to check

Everything that was tucked away is suddenly back in the menu bar. Or the settings still look right, but the icons refuse to move into position. Faults in a menu bar utility are usually a five minute fix once the cause is identified, and a long afternoon when settings get changed at random first.

There is a reason to check things in a fixed order. Tools that read and rearrange the menu bar depend almost entirely on macOS permissions, then on staying resident, then on the order in which login items start. Following that order, most cases end at step one. What follows is how to name the symptom precisely, how to reset permissions properly, which behaviors are macOS working as designed and cannot be fixed at all, and what to collect before contacting support.

Name the symptom before touching anything

"Not working" covers at least four distinct faults, and they do not share a cause.

• Nothing hides. Settings open normally, but marking an item as hidden has no visible effect.
• Items hide, but cannot be brought back. Clicking, scrolling, or swiping in the menu bar produces no response.
• Order changes after every restart or login. The configuration survives, the arrangement does not.
• The app does not launch, or quits shortly after launching.

The first two point at permissions. The third points at how item positions are recorded. The fourth points at a macOS version mismatch or a half finished installation. Changing settings while the symptom is still vague makes it impossible to tell what actually fixed it.

Before starting, note two numbers: the macOS version from About This Mac, and the app version from the app menu. Both are needed later if the fault turns out to need support, and both occasionally reveal the cause on their own.

When permissions stop taking effect, remove and re-add

A menu bar tool reads the contents of the bar and moves items around, which requires approval under Privacy and Security. A very common state is that the app is listed, the toggle is on, and nothing works. It shows up most often after a macOS update.

The fix is not to toggle the switch off and on. It is to delete the entry entirely, relaunch, and grant approval from scratch. The published guidance describes the same sequence.

Open System Settings > Privacy & Security, remove Bartender from Screen & System Audio Recording and Accessibility, then relaunch Bartender and grant access again. Source: macbartender.com

In practice that means four steps. Open System Settings, go to Privacy and Security, open Screen and System Audio Recording, select the app, and remove it from the list. Do the same in the Accessibility list. Quit the app completely, using its own quit command or by confirming in Activity Monitor that no process remains. Relaunch, approve the prompts as they appear, and restart if macOS asks for it.

If that does not help, look for a duplicate entry. Launching the same app from two locations, for example once from the disk image and later from the Applications folder, can leave macOS treating them as two different apps with separate approvals. When two entries appear, remove both, then launch only the copy sitting in the Applications folder.

The purple indicator is macOS, not the app

A recurring report is a purple indicator appearing in the menu bar every time hidden items are revealed. That is not a fault. It is how macOS signals that an app is reading part of the screen, and no setting inside the app removes it.

This is a macOS feature and is not caused by Bartender. This cannot be hidden or disabled. Source: macbartender.com

The same page documents two ways to reduce how often it appears: reveal items by scrolling or swiping in the menu bar rather than using the separate bar below it, and use keyboard shortcuts instead of pointer interaction. It also states that only the menu bar region is read, not the desktop or the rest of the display.

For anyone comparing tools, this is a design difference worth noticing early. A tool that reads the bar as an image needs screen recording approval and produces the indicator. A tool built another way needs neither. Which permissions each approach requires is set out on the How it compares page.

Order that resets on every restart has its own setting

When the configuration survives a reboot but the arrangement does not, there is a specific control for it. Turning on item indexing in Advanced Settings lets the app keep track of items so the same order is preserved between restarts.

The reason indexing is needed at all is that menu bar items do not always carry a stable identifier. Some apps present themselves slightly differently on each launch, and indexing is the record that absorbs that variation.

Three other causes produce a similar symptom:

• Login item ordering. If a dozen background apps race to appear at login, the menu bar tool may finish arranging before the last of them shows up. Reducing the number of login items, or delaying the ones that support it, usually settles this.
• External display timing. If a display is not recognized yet at login, the available width changes mid-arrangement and positions shift.
• Per-space configuration. With multiple virtual desktops in use, separate arrangements can be stored per space, so what looks like a reset is a different space.

Diagnosing this one takes patience. After enabling indexing, restart twice and compare both results. A single restart cannot distinguish a real fix from a launch order that happened to differ.

A pointer that moves on its own can be by design

Reports of the pointer twitching during work also come up. The documented explanation is that the app moves the pointer periodically in order to keep track of the menu bar layout, and that an on demand mode exists which avoids doing so unless asked.

Whether this counts as a fault changes what to do about it. If it is the documented behavior, a setting resolves it. If it is not, the trail goes back to permissions and versions. The quickest test is regularity: movement at steady intervals points at the design, movement only after a specific action points at something else.

Behavior like this is common in menu bar utilities. macOS exposes very little about the state of the bar, so developers reach for indirect methods, and those methods sometimes look inexplicable from the outside. Whether the indirect method can be switched off is a fair question to ask of any candidate. A tool that lets a hidden icon be clicked while the bar stays collapsed has fewer reasons to move the pointer in the first place, which is one way implementation differences surface in daily use.

When versions do not match, no setting will help

If permissions are clean and the app is running, check the version pairing. Bartender 6 is documented as built for macOS Tahoe and Sequoia, and for a Mac staying on Sonoma the same license covers Bartender 5 instead. On an older macOS, installing the newest build will not behave as expected no matter what gets configured.

Check in this order. Open About This Mac for the macOS version. Open the app menu for its version number. Then confirm on the official download page which macOS releases that build targets.

Right after a major macOS release, this check matters more than usual. Background utilities frequently need weeks to catch up with a new system, and menu bar tools are among the most affected because so much of what they do sits close to system internals. On a machine where menu bar organization is part of daily work, confirming compatibility before upgrading macOS avoids a week of workarounds. Which capabilities are available on which system versions is described on the Features page.

When the app will not launch at all

The fourth symptom, an app that refuses to start or quits seconds after starting, has a different shape from the other three, because nothing is running long enough to configure. Two causes account for most of it.

The first is a half finished installation. Running an app directly from the mounted disk image works once and then behaves unpredictably, since the volume can be unmounted while approvals still point at it. The documented installation is to download the build, open the disk image, drag the app into Applications, and launch it from there. Older versions can be removed once the new one is confirmed working, and not before.

The second is leftovers from a previous version. When two builds have both been launched at some point, macOS may hold approvals for the old bundle while the new one asks for its own. The symptom looks like a crash, but it is a permission prompt that never resolves. Removing every entry for the app from the permission lists, launching only the copy in Applications, and approving from scratch clears it.

If neither applies, download the build that matches the installed macOS release rather than the newest one. The downloads section keeps every supported release alongside its release notes, which is also the quickest way to check whether a fault already has a fix in a later build.

Collect four things before contacting support

If none of the above resolves it, the next step is the developer. Published guidance asks for four pieces of information:

• the macOS version
• the app version
• what was expected to happen
• what actually happened

A screen recording helps more than a still image for anything involving movement, such as items reshuffling or a click that produces no response. Contact details are available from the support page on the official site.

Writing this out has a side effect worth noting. Putting expected behavior and actual behavior into two sentences frequently reveals a misread setting, and the report never needs sending.

What the pattern of questions shows

Sorting reader questions by topic puts permissions and macOS updates well ahead of anything about features. That reflects the structure of this category. The menu bar belongs to macOS, so any tool operating there works inside somebody else's rules, and most faults appear at that boundary rather than inside the app.

Faults at that boundary share three traits. Adjusting settings in detail does not help. They appear in clusters right after a macOS update. Re-granting permission fixes them. Any symptom matching those three is fastest to solve by starting with a clean permission reset instead of a settings tour.

The second thing visible in those questions is that a tool requiring fewer permissions simply never produces some of these symptoms. No screen reading approval means no purple indicator and nothing to re-grant after an update. Permission count is a maintenance cost that never appears on a feature table, which makes it worth checking before installation rather than after.

What to change first

Reset the permissions properly, remove and re-add rather than toggling, then restart twice and see whether the order holds. If the symptoms return with the next macOS update, treat the number of permissions a tool requires as a selection criterion, not a detail. Setup steps and system requirements are on the Koffret download page.