iStat Menus: how to uninstall it cleanly

A system monitor is one of the few Mac utilities that cannot do its job with ordinary application privileges. Reading fan speeds and temperature sensors requires a process running with elevated rights, and that process does not live inside the application bundle once it is installed. It lives in a shared system location and is registered to start at boot. That single fact explains why an iStat Menus uninstall done by dragging the icon to the Trash leaves something behind, and why the removal route the developer provides is worth using instead of a manual hunt through folders.

The build examined for this article is version 7.30, downloaded from the developer site on 10 September 2026.

What is actually installed

Opening the distributed archive shows the app is a container for several separate executables rather than a single binary. Four pieces matter for removal.

The first is a menu bar agent with the identifier com.bjango.istatmenus.status. It is marked as a background-only app, which is why it has no Dock icon and no window of its own. It draws the items across the top of the screen.

The second is a helper agent, com.bjango.istatmenus.agent, also background-only.

The third is the piece that complicates removal: a daemon named com.bjango.istatmenus.daemon. Its bundled configuration file names the executable path as /Library/Application Support/iStat Menus 7/com.bjango.istatmenus.daemon, sets it to run at load, and marks it to be kept alive. That combination means the system restarts it if it stops. The location is outside the user library, in the area shared by all accounts on the machine.

The fourth is a privileged installer, com.bjango.istatmenus.installer, whose role is to place the daemon in that shared location during setup.

The daemon is the reason a manual delete is unsatisfying. Removing the application removes the thing that reads the daemon, not the daemon itself, and nothing about the registration disappears when the bundle does.

The supported removal route

The developer documents a removal path inside the app, and it covers the pieces that a manual delete misses.

To uninstall iStat Menus, please choose iStat Menus › Uninstall from the menu bar, then click Uninstall. This works, even if your trial period is over. If you have already manually deleted iStat Menus, then please download it again and run the uninstaller.

Source: bjango.com

Two details in that passage answer the questions people usually arrive with. Removal still works after the trial has expired, so there is no need to reinstall a license just to get the app to cooperate. And if the bundle has already been thrown away, downloading it again and running the uninstaller is the documented fix rather than a workaround.

The same menu carries a Reinstall command. When the goal is to fix behaviour rather than to leave, that is the faster first attempt, because it replaces the resident components without touching settings.

The Mac App Store build is removed differently

Two builds of this app exist and they are not interchangeable for removal purposes. The store build is sandboxed, which changes both what it can do and how it comes off the machine.

	Developer site build	Mac App Store build
Price on 10 September 2026	2,065 yen single, 2,582 yen family	2,000 yen
Minimum macOS	11.0	14.0
Fan speed control	Yes	No, per the developer
Removal	Uninstall command inside the app	Pause, quit, drag to Trash, then remove two helper files by hand

For the store build, the documented sequence is to click the pause button to the right of the Global label in the top tab, quit the app, and drag it to the Trash. If the separate helper was installed, two items are named for manual removal: /Library/LaunchDaemons/com.bjango.istatmenus.helper.mas.plist and /Library/Application Support/iStat Menus Helper/.

Anyone unsure which build is on the machine can check the purchase history in the App Store. The two are billed separately, so an upgrade path from one to the other does not exist.

Save three things before removing anything

Removal takes a couple of minutes. Rebuilding a configuration from memory takes considerably longer, and three items are worth capturing first.

Settings. The developer states that every setting can be exported and imported through the File menu, and that the same menu holds a reset to defaults. Anyone who has tuned thresholds, notification rules, or which sensors appear in the bar should export before removing. That file is equally useful when moving to a new Mac.

The license. A recovery page on the support site emails license details back after entering the purchase address. That makes the key recoverable, but recovery costs a round trip. Copying it somewhere first costs nothing.

A picture of the menu bar. A monitoring app usually contributes several items, and after they disappear it is easy to forget which readings were being watched. One screenshot settles later questions about what needs replacing, and it also records the order the items were in, which is the part nobody reconstructs correctly from memory.

What to check after the app is gone

The place to look is Login Items, under General in System Settings. The developer notes that more than one entry can appear there, carrying either the app name or the company name, and the documented first response to the app misbehaving after a macOS upgrade is to switch those entries off and back on.

If an entry appears to be stuck after removal, there is a documented last resort: a Terminal command that resets the login items database. The developer is explicit that this affects login item settings for other applications and that the Mac needs a restart afterwards. That cost is real, so it belongs at the end of the list rather than the start.

There is a second, less obvious change to expect. The menu bar rearranges itself the moment several items disappear at once. Icons that macOS had been dropping for lack of space come back into view, and on a MacBook with a notch the effect is larger than most people expect, because the usable width there is smaller than the screen suggests. A menu bar that felt crowded before the removal can still feel crowded afterwards, with a different set of icons doing the crowding.

The permissions granted along the way

A monitoring app collects more than processor load, and the extra readings are gated behind system permissions that outlive the app unless they are cleared. The bundle declares two of them in plain language. Bluetooth access is requested so that battery levels of connected Bluetooth devices can be shown. Calendar access is requested so that events can appear in the app's calendar view.

Both are proportionate to the features they enable, and neither is unusual for this category. They are still worth reviewing at removal time, for two reasons.

The first is housekeeping. Permission records in System Settings are keyed to the app, and an entry that grants calendar access to something no longer installed is noise in a list that should be short enough to audit at a glance. Open Privacy and Security, work through Bluetooth and Calendars, and remove entries for apps that are gone.

The second reason is that the review answers the removal question itself. If neither Bluetooth battery levels nor calendar events were ever the point, most of the surface area being granted was never used, which makes the case for removal simpler. If the Bluetooth battery readout was the one feature that got looked at daily, removal is the wrong move and the real problem is width, not the app.

The same review is worth doing whenever a replacement gets installed. Menu bar utilities as a class ask for permissions that reach across into other software, and the honest way to compare two of them is to compare what each one needs to be granted, not just what each one costs. The current list of what this kind of tool asks for, and why, is set out on Features.

Removing the app is not the only way to get the space back

Before committing to removal, it is worth separating two complaints that look identical from the outside. One is that the readings are no longer wanted. The other is that the readings are wanted but the width they occupy is not.

For the second case, the app has a combined mode that merges multiple items into a single menu bar entry, with separate control over what shows in the bar and what appears in the dropdown. The developer describes it as particularly useful on laptops. That reduces the footprint to one slot while keeping the data a click away.

A simple test tells the two cases apart. For each reading currently on display, recall the last time it changed a decision. Battery level, a stalled sync, a recording indicator, an active VPN: these get read at a glance and change what happens next. A processor usage graph that nobody has acted on in a month is not being read, it is being rendered. Items in the first group earn permanent space. Items in the second group belong behind a click, and that holds regardless of which app they came from.

The layer the problem actually sits in

Utilities that occupy the menu bar fall into two layers, and the distinction decides whether removal helps for more than a week.

The first layer is apps that do a specific job and report on it: system monitors, charge limiters, sync clients, meeting tools. Removing one frees a slot. The slot then gets taken by whatever is installed next month, because nothing about the allocation has changed.

The second layer is tools that manage the bar itself, deciding which items get drawn regardless of how many apps want a place. Removing a monitor is a fix for one app. Changing the allocation is a fix that keeps working as the number of apps grows.

Which layer to use depends on the answer to the earlier test. If the readings were not being read, removal is correct and the job is finished. If they were being read and the width was the problem, the reading should stay and the allocation should change. A comparison of how tools in the second layer differ, with the date each price was checked, sits on How it compares, and the behaviour that separates them in daily use is described on Features.

What to change first

Export the settings, then run the uninstaller from inside the app rather than deleting the bundle, and check Login Items afterwards. If the readings mattered and only the width did not, install nothing else until the menu bar has been re-allocated deliberately, which is what Koffret is built to do.