A menu bar app is missing after a macOS update. A diagnosis order
· 6 min read
You update macOS, the Mac restarts, and something that used to sit in the menu bar is not there. Nothing else appears wrong.
Updates touch several things that affect whether a background application runs, and they do it without reporting what changed. The causes are few and the checks are quick, in this order.
One: is it running?
ps -Ao pid,comm | grep -i punchcard
Substitute the app name. A result means it is running and the icon is hidden rather than absent, which is a space problem rather than an update problem. Quit two or three other menu bar apps and watch for it to reappear. When a menu bar icon disappears covers that case.
No result means it is not running, and the rest of this applies.
Two: did it lose permission to start at login?
The most common cause. System Settings, General, Login Items.
Look at both sections. Open at Login is what you added. Allow in the Background is where apps register helpers, and this is the one updates reset.
An application switched off in the second list will not start until you launch it manually. Switching it back on, then launching the app once, usually restores normal behaviour.
Login items on a Mac covers the full picture, including the launch agents that do not appear in this panel.
Three: were its permissions revoked?
macOS revokes granted permissions when an application’s signature changes, and a major update can trigger re-evaluation.
System Settings, Privacy & Security. Check Accessibility, Screen Recording, Full Disk Access and Automation for the app. An entry present but switched off is your answer; toggle it on.
An app that depends on Accessibility to read window titles may run but produce nothing useful when this happens, which reads as a partial failure rather than an obvious one.
This is a reason to prefer tools that need no permissions: there is nothing to revoke, so this entire category does not arise. Time trackers that ask for Accessibility permission, and one that does not covers the trade.
Four: is the application still there?
Major upgrades occasionally relocate applications they consider incompatible.
ls /Applications | grep -i punchcard
ls ~/Applications 2>/dev/null | grep -i punchcard
ls "/Users/Shared/Relocated Items/Applications" 2>/dev/null
That last folder is where macOS puts things it moved during an upgrade. If the app is there, drag it back to Applications and launch it.
Five: is it crashing on launch?
If the app is present and starts but does not stay running, it is crashing.
open ~/Library/Logs/DiagnosticReports
Recent files named for the app confirm it. You do not need to read them. The action is to check for an update to the app, since a new macOS version occasionally breaks something that the developer then fixes.
Also worth checking:
log show --last 30m --predicate 'eventMessage CONTAINS "Punchcard"' 2>/dev/null | tail -20
Six: is it quarantined or blocked?
An application that has been moved, re-downloaded or restored from a backup can carry a quarantine flag, and Gatekeeper may block it silently on first launch after an update.
xattr -l /Applications/Punchcard.app
If com.apple.quarantine appears, launching the app from the Finder with a right-click and Open gives you the dialog to allow it, which clears the flag properly. Do that rather than removing the attribute by hand, so the check still happens.
System Settings, Privacy & Security also shows a message about recently blocked software, with a button to allow it.
What this means for the day’s record
A tracker that did not start records nothing until you notice, which is usually mid-morning. That produces a day missing its beginning.
Do not reconstruct the missing hours and merge them into the record. Note them separately, by hand. A receipt with a pencilled line is more honest than a clean-looking day that is partly invented, and the distinction matters if the record is ever used for anything. How to see your workday when you forgot to track it covers reconstructing without pretending.
The practical habit is to check the menu bar after every macOS update, before starting work. It takes two seconds and saves a partial day.
Where Punchcard sits
Punchcard requests no macOS permissions, so step three above does not apply to it: there is nothing to revoke. It registers to start at login, which does appear in Allow in the Background and can be reset by an update like anything else, so step two is the one to check.
It has no networking code and no helper processes, so there is no updater to fail and no daemon to be blocked. If it is not in the menu bar after an update, it is one of steps two, four, five or six, and in practice it is almost always two.
The order, condensed
ps -Ao pid,comm | grep -i <app>. Running means hidden, not missing.- System Settings, General, Login Items, both sections.
- Privacy & Security, if the app needs permissions.
- Check
/Applicationsand/Users/Shared/Relocated Items. ~/Library/Logs/DiagnosticReportsfor crashes.xattr -lfor a quarantine flag, and Privacy & Security for a Gatekeeper block.
Questions
Why does macOS reset login items? Registrations are tied to an application’s signature and location. An update that re-evaluates either can invalidate the registration, and macOS errs towards not running things it is unsure about.
Should I reinstall the app? Not as a first step. Reinstalling fixes steps four and six, and it also discards your settings. Work through the list first.
Everything looks right and it still will not stay running. Check for an app update. A new macOS version occasionally breaks an application until its developer ships a fix.
Will I lose recorded data? The record already written is unaffected by any of this. What is lost is the time between the update and noticing, because nothing was running to observe it.