Barbee not working on Mac: what to check

A menu bar utility that worked yesterday and does nothing today is rarely broken in the way it looks. Most of the time the cause sits somewhere else: a permission that silently stopped applying after an update, a login item that got switched off, a second tool competing for the same icon positions, or a system level behaviour that changed with the last macOS release. Working through those in order takes less time than reinstalling and hoping.

Separate the symptom before touching anything

Four different failures all get described as "it stopped working", and they have almost nothing in common underneath.

The app's own icon is missing from the menu bar. Either the process is not running, or there is no room left in the bar to draw it.

Icons refuse to hide, or reappear on their own. Something else is rewriting icon positions, which usually means two tools of this type are running at once.

Hidden icons cannot be summoned, or clicking them does nothing. This is a permissions problem in the large majority of cases.

The whole Mac feels slower, particularly when scrolling. This is not about the menu bar at all. It points at the event monitoring layer that a resident utility installs system wide.

The third and fourth look similar from a chair and are fixed in completely different places. Deciding which one applies before starting saves a full round of trial and error.

Confirm the version and the platform first

The App Store product page lists version 4.3, released on 15 June 2026, requiring macOS 11.0 or later, at 11.2 MB. The first release was 9 May 2021. Anything older than 4.3 should be updated before spending time on diagnosis, because the 4.3 release notes name three items directly related to sluggishness: optimised automation issues, reduced CPU energy consumption, and optimised mouse interference issues.

Updates for a Mac App Store app arrive only through the App Store updates tab. There is no in app updater and no download on a vendor site to fall back on. If automatic updates are disabled, the updates tab has to be opened by hand. Note the macOS version and build number at the same time, from the About This Mac window, because both are needed later if a report gets filed.

Check that it is running, and that it starts on login

If the icon is absent, open the app directly from the Applications folder. If the icon appears, the process simply was not running, and the question becomes why it did not launch at login.

Automatic startup lives in System Settings, under General, in the Login Items panel. That screen holds two lists: items a user added, and background items registered by installed apps. Entries in the second list can revert to off after a reinstall or a major system update, and turning the switch back on restores the behaviour.

If the process is running and the icon still cannot be seen, the bar itself may be full. macOS drops menu bar icons starting from the left side of the status area when there is not enough horizontal space, and on notched machines the notch sets that boundary. A telltale sign is an icon that vanishes only while an app with a long menu list is in front, or immediately after connecting or disconnecting an external display.

One more check belongs here, because it looks like a bug and is not one. Some tools in this category can hide their own icon, either as a setting or as a side effect of a hidden group that grew to include it. When that happens the app is running perfectly and simply has no visible handle. Opening the app again from the Applications folder usually brings its window or its icon forward, and from there the setting can be reversed. Activity Monitor answers the underlying question in a few seconds: search the process list by name, and if the process is there, the problem is visibility rather than launching, which sends the investigation down the display and permission path instead of the startup one.

Remove the permission entry, then grant it again

Rearranging other applications' status icons is, from the system's perspective, reaching into another process. macOS gates that behind the privacy lists in System Settings under Privacy and Security. Accessibility and Input Monitoring are the two that matter for control and for keyboard or scroll triggers. Tools that redraw the bar visually also require Screen Recording.

The failure mode worth knowing is a permission that is listed and switched on but no longer effective. It happens when an app update changes the signed binary, or when a same named app is reinstalled from a different source. Toggling the switch off and on frequently does not clear it. The reliable fix is to select the entry, remove it with the minus button, quit the app completely, launch it again, and grant the permission from the prompt that follows.

Permissions are read at launch, so restart the app after each change. Change one thing, relaunch, observe. Changing three settings at once and then seeing improvement teaches nothing about which one mattered, and the next time the same symptom appears the work starts from zero again.

Read what has already been reported against macOS 26

The developer keeps a public feedback repository on GitHub, and its issue list is the fastest way to find out whether a symptom is specific to one machine. Three entries are relevant to current systems.

An entry dated 1 August 2026 describes system wide scroll latency:

Barbee appears to accumulate a very large number of disabled Core Graphics event taps over several days. As the number increases, scrolling becomes progressively delayed across every application. Source: github.com

The environment given is macOS 26.5.2 with version 4.3. A related report from 29 July 2026, covering the same event tap mechanism and the menu bar scroll listener, has since been closed. A much shorter entry from 17 June 2025 reports crashes on macOS 26.

There is a self test in there for anyone seeing the fourth symptom. If the scroll to toggle trigger is enabled, switch it off, leave the machine running for a few hours, and check whether the delay returns. Quitting the app entirely is the other half of the test: if scrolling recovers immediately after quitting, a resident process is responsible, and if it does not, the cause is elsewhere.

When the cause is the system update, not the app

A large share of menu bar failures appear on the morning after a macOS update, which makes the app look guilty. Three system side changes explain most of those cases, and none of them are fixed by reinstalling.

Privacy list entries can survive an update while quietly losing effect, which is the same failure described above and worth re checking specifically after any major version jump. Background item registrations can revert to off, so the Login Items panel deserves a second look even if nothing was changed there. And the layout rules of the menu bar itself get revised between releases, most visibly with the redesign that arrived in macOS 26, which altered spacing and the way items are drawn around the notch. A tool that positioned icons correctly under the previous system can end up half a pixel off under the new one until it is updated.

The practical response is sequencing. After a system update, open the App Store updates tab before diagnosing anything, because developers of this category of utility usually ship a compatibility release within weeks. Then re grant permissions, then check login items, and only then start looking at settings inside the app. Working in the opposite direction produces a long list of changed settings and no idea which one mattered.

Beta versions of macOS deserve a separate note. The public report of crashes on macOS 26 dates from June 2025, which places it in the beta period for that release. Running a utility that manipulates system UI on a beta system means accepting that breakage is expected and that the fix arrives on the developer's schedule, not the reporter's.

Reset the settings container before reinstalling

App Store apps run sandboxed, so preferences live inside a container in the user library rather than in the usual preferences folder. In Finder, choose Go, then Go to Folder, and open ~/Library/Containers/. The relevant folder name begins with the bundle identifier, com.HyperartFlow.Barbee.

Do it in this order:

1. Quit the app from its menu bar icon.
2. Move the container folder to the Desktop instead of deleting it.
3. Launch the app. Settings get rebuilt from defaults.
4. If the symptom is gone, delete the folder that was moved aside. If not, put it back.

Reinstalling afterwards is safe from a purchase standpoint. Anything bought through an in app purchase is tied to the Apple ID, and restoring purchases brings the unlocked state back, provided the Mac is signed in with the account that paid. Confirm that before deleting anything.

Two tools of the same kind cannot share a menu bar

This is the single most common cause of icons that reappear after being hidden. Every utility in this category works by moving status items along the bar and controlling their coordinates. Two of them running together overwrite each other continuously, and the visible result is icons that drift, orders that change on every login, and hidden items that come back.

The fix is to keep one and remove the rest, including from Login Items, where old experiments tend to survive long after the app itself was forgotten. This constraint is not specific to any one product. It is documented on the FAQ page for this category of tool, which states that running two of them at the same time turns icon placement into a tug of war and that only one should be left installed.

Filing a report that gets answered

Search the existing issues before opening a new one, and add to an existing thread when the symptom matches. Reports that got detailed responses in that repository all share the same five ingredients:

• App version and build number
• macOS version and build number
• Mac model, including the chip generation
• How long the machine had been running before the symptom appeared, and what triggers it
• What has already been tried, such as re granting permissions or quitting other resident apps

Screenshots of the bar in its broken state help. So does a note about which triggers are enabled, since scroll, hover and click behave differently.

What to change first

Start by deciding which of the four symptoms applies, then work top down: version, login item, permission entry removed and re granted, other tools quit, container reset. If a symptom turns out to be architectural rather than local, such as system wide scroll latency traced to a resident process, the decision moves from repair to selection, and the criteria worth comparing are how many clicks a hidden icon takes to reach and whether display arrangements are remembered. Those differences are described on the features page, alongside how it compares against other tools in the same category.