xbar menu bar icon: hide it or keep it

The right side of the menu bar has filled up, and xbar is part of the reason. What is not obvious is how much of it xbar accounts for. Unlike most resident apps, xbar does not occupy a single fixed icon that can be identified at a glance and dealt with once. Its footprint changes with what has been installed, and it changes width while sitting there.

This is a walk through how xbar actually consumes menu bar space, what can be adjusted from inside a plugin, what cannot be adjusted at all, and how to decide which entries earn a permanent slot.

One plugin means one menu bar slot

xbar is a host for small executables. Each plugin placed in the plugin folder gets its own independent entry in the menu bar. Three plugins mean three entries, sitting side by side, each with its own dropdown.

That alone is a different mental model from a typical status item. A weather app takes one slot forever. xbar takes as many slots as there are plugins, and the count grows quietly, because installing a plugin feels like adding a feature rather than adding an icon.

Width matters as much as count. A plugin prints text to standard output, and that text becomes the menu bar label verbatim. An entry showing USD/JPY 147.82 takes several times the horizontal space of an entry showing a single glyph. Two plugins that both occupy "one slot" can differ enormously in how much room they actually eat.

The split between what shows in the bar and what shows in the dropdown is decided inside the plugin output itself. A line containing only three hyphens acts as the divider. Everything below it appears only after a click. Everything above it appears in the bar, and when there is more than one such line, xbar cycles through them.

That cycling is worth noticing. Each rotation changes the label width, which nudges every icon to its right. An icon that was under the pointer a second ago may not be there when the click lands.

Count the slots before deciding anything

Guessing at the problem produces guesses at the solution. The plugin folder gives an exact number. It lives at ~/Library/Application Support/xbar/plugins, reachable from Finder through Go to Folder.

Every executable file in that folder is one menu bar slot. The filenames also encode behavior, which makes the listing more useful than a plain count. The convention is {name}.{time}.{ext}, where the middle segment sets the refresh interval. Documented forms include 10s for ten seconds, 1m for one minute, 2h for two hours, and 1d for a day.

So a single directory listing answers three questions at once: how many slots are in use, which of them redraw most often, and which are likely to shift width. In practice the noisiest entry is usually a ten second plugin printing a changing number, and it is often the only one that needs attention.

Three questions that sort the keepers from the rest

Preference is a weak basis for this decision, because everything installed was installed on preference. Behavior is a stronger one.

Does seeing it change the next action? Build status, a meeting countdown, and a recording indicator all pass. Looking at them leads directly to doing something differently. This class earns permanent visibility.

Does the value change often enough to be worth watching? A number that moves once a day does not need a live readout. Checking it on demand loses nothing.

How many times has it actually been clicked this week? Zero clicks in seven days is strong evidence that the entry is decoration rather than instrumentation.

An entry that fails two of the three is a candidate for folding away. Most setups reduce to one or two permanently visible entries and a longer tail that only needs to be reachable.

Order is not stable, so do not build on it

Menu bar items can be rearranged by holding Command and dragging. That is standard macOS behavior and it works on xbar entries.

The arrangement, however, is not guaranteed to survive. A report filed in October 2021 describes custom positions resetting after waking from sleep or after running a full refresh, and it remains open in the project tracker. Anyone who arranges entries carefully and then finds them shuffled the next morning is seeing a known behavior rather than a local fault.

The display notch on recent MacBook models adds a second source of instability. When a frontmost app has a long application menu, items on the right get pushed past the visible area and silently disappear. Which entry falls off the edge depends on the app in focus, so the boundary moves during the day.

Both effects have the same practical implication. Manual ordering is not a durable fix. Reducing the number of permanently visible entries is, because a short row survives reshuffling and truncation intact.

Shrink the output before removing the plugin

Removal is not the only lever. xbar plugins accept parameters after a pipe character on each line, and several of them affect footprint directly.

Method	Slot count	Effect on the bar	Reversing it
Leave as is	Unchanged	Full label stays	Nothing to do
Add length=10	Unchanged	Label truncated with a tooltip	Remove the parameter
Move below the divider	Unchanged	Label disappears, dropdown keeps it	Move the line back up
Remove the file	One fewer	Entry disappears	Put the file back

The length parameter truncates a line to a set number of characters and attaches an ellipsis, with the full string still available as a tooltip. The dropdown=false parameter does the reverse of what its name suggests to some readers: it keeps a line in the status bar while omitting it from the dropdown.

Merging is the underused option. Two plugins printing related numbers can be rewritten as one script that prints a compact summary above the divider and the detail below it. Two slots become one. Plugins are ordinary scripts owned by whoever installed them, so there is no obligation to keep the output as shipped.

One constraint applies to merged scripts. xbar limits how long a plugin may run, and version v2.1.7-beta raised that ceiling from one minute to two minutes. A combined script needs to finish inside that window.

Read the plugin before judging it

A plugin that looks noisy is sometimes only badly configured, and the configuration is visible in the file. Opening the script in any text editor shows three things worth checking before deciding its fate.

The first is the metadata block near the top. Plugins carry comment tags such as xbar.title, xbar.desc, and xbar.author, which state what the thing is for. On a machine where five plugins were installed over two years, this is often the fastest way to remember why a given entry exists at all.

The second is any xbar.var declaration. Variables let a plugin expose settings that appear as editable preferences in the app, using types of string, number, boolean, or select. Their values are stored in a JSON file that sits next to the plugin and shares its name with a .vars.json suffix. A plugin printing more detail than needed can often be quieted by changing one of these values rather than by editing code.

The third is the output structure. Lines beginning with two hyphens become submenu items, and each additional pair of hyphens nests one level deeper. A plugin that appears to dump twenty lines into the dropdown may simply have its grouping switched off.

None of these change the slot count. They change how much noise a slot generates, which is often the actual complaint.

Test the decision instead of predicting it

Predicting which entries will be missed is unreliable, because the prediction is made while looking at the menu bar rather than while working.

A two week trial settles it. Move every uncertain entry below the divider so that it stays installed and stays reachable, then leave the arrangement alone. Anything opened during those two weeks has proven that it belongs in reach. Anything untouched can have its file moved out of the plugin folder without further deliberation.

Removing a single plugin needs no uninstaller. Moving the file out of the plugin folder and refreshing xbar is sufficient, and moving the file back restores the entry exactly as it was. That reversibility is what makes the trial cheap enough to actually run.

For anyone going further and removing xbar itself, the Homebrew cask definition names the locations involved: ~/Library/Application Support/xbar, ~/Library/Caches/com.xbarapp.app, ~/Library/Preferences/com.xbarapp.app.plist, and ~/Library/WebKit/com.xbarapp.app. The login item is registered under the name xbar, which is worth confirming in System Settings so that nothing relaunches at the next restart. Copying the first of those folders elsewhere preserves every custom plugin and every variable value, which makes the removal reversible too.

What changes when a menu bar manager is added

When trimming stops being enough, the next step is folding entries behind a manager. xbar introduces one specific wrinkle here. Its entries have labels that keep changing, and a request to give xbar items stable identifiers for the benefit of menu bar managers was filed in February 2022 and is still open. Selecting which xbar entry to hide tends to be done by its current text rather than by a fixed name.

The other thing worth checking is what happens after folding. If reaching a hidden item requires expanding the whole bar first, the folding gets abandoned within a week. Tools differ on this point, and the one that matters is whether a hidden icon can be clicked and its menu opened while the bar stays collapsed. The behavior available in a collapsed state is set out on the Features page, and the tradeoffs between different approaches to hiding are laid out on How it compares.

Where the project stands, as context for the decision

Two public numbers help frame how much effort to invest here. Homebrew analytics record 299 installs of the xbar cask in the last 30 days, 1,091 in 90 days, and 3,908 in a year, so new installations are still happening at roughly ten a day.

At the same time, the last tagged release is v2.1.7-beta from October 2021, and the application repository last saw a commit in September 2024. The plugin repository is more active, with commits as recent as August 2026. The license is MIT and there is no charge for any of it.

For menu bar space specifically, that pattern points one way. Improvements to how xbar presents itself in the bar are not arriving on a schedule, so the arrangement is whatever the person at the keyboard decides to make it.

What to change first

Open the plugin folder, count the files, and move everything that has not been clicked in a week below the divider line rather than deleting it. That single pass usually returns most of the width without losing any information. If the remaining entries still crowd the bar, compare how different tools handle a collapsed state before installing one, starting from Koffret.