xbar: how to uninstall it cleanly

Dragging the app to the trash is not the whole job. The app that puts script output into the macOS menu bar keeps three separate things on disk: the bundle in Applications, a folder of plugin scripts in the user library, and a small set of preference and cache files. Deleting the first one leaves the other two exactly where they were.

That matters less because of disk space and more because of what those plugin scripts contain. A plugin is an executable that runs on the machine every few minutes. Plenty of published plugins read an API, and plenty of installed copies have a token pasted directly into the file. Removing the app stops those scripts from running. It does nothing about the credentials sitting inside them.

The three places to look

The bundle lives at /Applications/xbar.app unless it was launched from somewhere else. The plugin directory is documented in the project readme:

The plugin directory is folder on your Mac where the plugins live, located at ~/Library/Application Support/xbar/plugins.

The remaining files are generated by the app itself. The Homebrew cask definition lists them explicitly, which makes it a useful reference even for an installation that never went through Homebrew. As checked on 10 September 2026, the cask names four paths for removal: ~/Library/Application Support/xbar, ~/Library/Caches/com.xbarapp.app, ~/Library/Preferences/com.xbarapp.app.plist and ~/Library/WebKit/com.xbarapp.app.

The WebKit folder is there because the app is built on a web view rather than native menus, so it keeps a browser style working directory the way a browser would. It holds nothing worth preserving. The same is true of the cache folder and the preference file. Only the first path, the application support folder, contains anything that cannot be recreated by reinstalling.

Stop it running before deleting anything

Click the menu bar icon and choose the quit item. Skipping this step is the most common way to end up with an icon that appears to survive its own deletion: the process stays resident, keeps drawing its item, and only disappears at the next logout.

Then remove the login registration. On macOS Ventura and later that list sits in System Settings under General, in Login Items and Extensions. Leaving the entry in place after deleting the bundle produces a notice at every login about an item that can no longer be opened. The Homebrew cask handles both steps automatically, listing a quit action for the bundle identifier com.xbarapp.app and a login item removal for xbar. A manual uninstall needs the same two actions performed by hand.

A second reason to quit properly is that the app writes its state on exit. Force quitting from Activity Monitor, or killing the process from a terminal, can leave the preference file describing plugins that are about to be deleted. That inconsistency is harmless in isolation, but it shows up later as a confusing reinstall, where a fresh copy of the app starts by complaining about scripts that no longer exist.

There is a timing consideration here for anyone running plugins that talk to a network service. Until the app is quit, those scripts are still firing on their schedule. Anyone planning to revoke API tokens afterwards will find the picture cleaner if the traffic has already stopped, since the service side logs will show a clean cutoff rather than requests continuing during the audit.

Removing the app itself

For a Homebrew installation, the command form keeps the package database consistent:

brew uninstall --cask xbar
brew uninstall --zap --cask xbar

The first form removes the bundle. The second adds every path in the zap list, including the plugin folder. That distinction is worth reading twice. Running the zap variant before opening the plugin folder means discarding scripts that may hold live credentials without ever having looked at them.

For a manual installation, find the bundle first. It is not always in Applications, since the app runs perfectly well from a Downloads folder and many installations never got moved. Activity Monitor will show the executable path for the running process, which is faster than searching by name.

On a Mac with more than one user account, the bundle is shared but the plugin folder and preferences are per account. Cleaning up in one account leaves an identical set of files in every other one. Treat the bundle removal and the per account cleanup as separate tasks with separate checklists.

What to read in the plugin folder before deleting it

Plugin filenames follow a documented pattern of name, refresh interval and extension, so date.1m.sh runs once a minute. The interval accepts seconds, minutes, hours and days, written as 10s, 1m, 2h or 1d. This makes the folder listing informative on its own: the filenames say how often each script was waking up and hitting whatever it hits.

The contents deserve a pass before anything gets emptied from the trash. A short checklist covers most of it:

• Open each script in a text editor and search for token, key, secret and password. Anything found is a live credential, not a file artifact.
• Revoke those credentials at the issuing service. Deleting the script removes the copy on the Mac and changes nothing on the service side.
• Note which external commands each script calls. General purpose tools like curl and jq were probably already installed. Anything more specific was likely installed for that one plugin and is now orphaned.
• If any of this is worth keeping, copy the whole folder somewhere else rather than picking out individual files, since configuration lives alongside the scripts.

Backups add one more wrinkle. A Time Machine history contains the pre deletion state of these scripts, so a credential that was never revoked remains readable in the backup long after the original file is gone. Revoking at the source is the step that actually closes it.

The project documentation also notes that plugins must be made executable with chmod and recommends an env shebang. That is a reminder of what the folder actually holds. These are programs, not settings files, and they were written or edited by whoever installed them.

There is a partial removal worth considering as well. Someone who is uninstalling because of menu bar crowding, rather than because the tool stopped being useful, can keep the plugin folder and delete everything else. Scripts survive a reinstall, and a folder of working scripts represents real time spent, especially where the plugin was adapted to a specific API or output format. Preferences and caches get rebuilt on first launch, so nothing is lost by discarding those. The reverse choice, keeping preferences without the scripts they refer to, has no benefit at all.

What partial removals leave behind

Half finished uninstalls produce a recognisable set of symptoms, and each one maps to a step that was skipped. An icon that stays in the menu bar after the bundle is gone means the process was never quit. A login notice about an item that cannot be opened means the entry in Login Items and Extensions is still registered. A reinstalled copy that immediately shows old plugins means the application support folder was left in place, which is sometimes exactly what was intended and sometimes a surprise.

One symptom has a different cause. If a helper command installed for a plugin is still on the system, something like a CLI tool pulled in through a package manager, it will keep occupying disk space and may keep appearing in shell completions, with no connection to the app that prompted its installation. Package managers do not track why a package was installed, so the only record is whatever the plugin script says about its dependencies. Reading those scripts before deletion is the only chance to capture that list.

The release history, stated plainly

The current release listed on the project page is v2.1.7-beta, published on 29 October 2021. That version raised the plugin execution timeout from one minute to two. The project is MIT licensed, and the stated requirement is macOS Catalina 10.15 or newer. The Homebrew cask still carries the same version, so distribution continues.

A long gap between releases is a fact, not a verdict. An app that works on the installed version of macOS keeps working until something in the OS changes underneath it. What the gap does affect is the expectation of a fix when that day arrives. Someone deciding whether to reinstall after a macOS upgrade is really deciding how much tolerance there is for a tool that may not get adjusted.

The same three questions apply to whatever replaces it: when was the last release, which macOS versions are named in the requirements, and is it sold once or billed on a schedule. Those three answers narrow a list of candidates faster than any feature comparison.

How many menu bar slots this actually frees

This app is unusual in that each plugin claims its own menu bar item. An installation with weather, a stock ticker, a battery readout and a network status indicator occupies four slots, not one. Removing the app therefore frees four, which is a larger effect than uninstalling almost any other single application.

What it does not fix is everything else up there. Cloud storage, a password manager, a backup agent, two chat clients, a meeting app and an input switcher each claim their own slot and none of them are going anywhere. On a laptop with a notch, the practical limit arrives sooner than the count suggests, because items that overflow past the notch simply stop being drawn.

It is also worth noticing what the removal changes about how the menu bar reads. Plugin output is text, often several characters wide, so those four slots were not four icons but four labels of varying length. Removing them shifts every remaining icon to the right by an unpredictable amount, which is why a menu bar can feel unfamiliar for a day afterwards even though nothing else was touched. Anyone who navigated by position rather than by shape will need a short adjustment period.

Sorting the survivors by how often each one gets clicked is the useful next move. Most lists split into three groups: items clicked several times a day, items glanced at for status and clicked occasionally, and items that have never been clicked once. The third group is usually the largest, and it is entirely made of things that could be hidden without any loss.

What to change first

Quit the app, clear the login item, then open the plugin folder and read the scripts before anything reaches the trash. Revoke any credential found there at the service that issued it. Once the four leftover paths are handled, sort the remaining menu bar items by click frequency and hide the ones in the never clicked group, which is the job Koffret exists to do. For a side by side look at how these tools differ in what they can reach while collapsed, see how it compares, and for the requirements and current build, download.