Itsycal not working on Mac: what to check

Reports of Itsycal misbehaving look varied but collapse into three shapes. The icon is missing from the menu bar. The icon is there but the agenda is empty. Everything shows up but the numbers disagree with Calendar or with a colleague's screen. Each shape sits in a different layer, so the order of checks matters more than the number of them. Reinstalling first is the most common wasted step, because two of the three shapes are not caused by the app at all.

Sort the symptom before touching anything

Spend thirty seconds classifying the problem. Guessing leads to changing settings that were not involved, which makes the original state harder to recover.

• Nothing visible in the menu bar, with no way to tell whether the app is even running
• Icon present, calendar opens, but the agenda is empty or missing some events
• Icon and events both fine, but a date or a week number does not match another app

The first is about menu bar capacity and a system level setting. The second is about calendar access permission and which calendars are ticked. The third is usually not a defect at all, but a calendar standard behaving as documented. Nothing in the app's own preferences fixes the first, and no amount of reinstalling fixes the third.

When the icon is missing

The official help names two common causes, and neither is a bug in the app.

The first is width. Menu bar items fill in from the right while application menus grow from the left, and when they meet, further items are not drawn. There is no dimming, no truncation, and no error.

When the menu bar fills up with menu items, macOS silently hides new items it can't find room for. Source: mowglii.com

The same passage notes that a notch makes this more likely, since it occupies space in the middle of the bar. The fix is to remove other items until the icon appears, then hold Command and drag it toward the right so it is less likely to be dropped next time.

The second cause applies to macOS 26 Tahoe and later. The help describes a Menu Bar panel in System Settings that governs whether an app is permitted to appear there. If that permission is the blocker, reinstalling changes nothing, because the app is running correctly and the system is declining to draw it.

There is a related cosmetic change in the same macOS generation. The release notes state that some menu glyphs are disabled by default on macOS 26, and that entering defaults write com.mowglii.Itsycalapp EnableTahoeMenuIcons -bool YES in Terminal restores them. A report of "the menus look different since the update" is often this, not damage.

When events do not appear

An empty agenda has two candidate causes, and checking them in order is faster than checking them at random.

Start inside the app. The published help explains that the General tab of the Settings panel lists the calendars configured in the Mac Calendar app, and that events appear only for the ones ticked. A fresh install with nothing ticked produces an empty agenda while everything else works. The Settings panel opens from the small gear icon below the calendar.

If that list is empty rather than unticked, the cause is one layer down: calendar access permission at the system level, granted under Privacy and Security in System Settings. Dismissing the permission prompt when it first appeared leaves the app with nothing to enumerate, which looks identical to an app that cannot read calendars because of a bug.

A partially empty agenda is a third case. The help states that delegate calendar events cannot be displayed directly, with a documented workaround when those calendars are Google calendars: select them in Google Calendar sync settings so they appear as ordinary calendars in the Mac Calendar app, at which point they become visible here too.

Missing join buttons belong in this layer as well. Those buttons appear when a meeting link is detected in an event, and by default they activate fifteen minutes before the start time and switch off when the meeting ends. The release notes document a hidden setting that keeps them enabled indefinitely for people who revisit the same room repeatedly.

When the numbers disagree

Wrong dates and wrong week numbers are usually documented behaviour rather than faults, and this is where reinstalling wastes the most time.

For dates that look wrong outright, the help states that only the Gregorian calendar is currently supported. A system configured for a different calendar will produce dates that do not match.

Week numbers split into two separate cases. The number down the left side of the calendar follows ISO 8601 and is correct by that standard. The text in the menu bar is drawn by macOS, which interprets the datetime pattern and by default does not follow ISO 8601. The documented fix is to change the calendar to ISO 8601 in the Language and Region panel of System Settings. Note also that the release notes for 0.13.2 say a datetime pattern in the menu bar is formatted according to ISO 8601 automatically, so behaviour here depends on which build is installed. Check the version before changing system settings.

Confirm it is running before assuming it is broken

An app that failed to launch and an app that launched but could not be drawn look exactly the same: an empty spot in the menu bar. Separating those two states is worth doing early.

The direct test is to launch it again from the Applications folder and watch for a change. If it was already running, nothing new happens. If the icon then appears, the earlier state was a launch problem rather than a display problem.

A second test comes from the release notes for 0.15.11, which added a right click menu on the status icon offering quick access to settings and to quit. If a visible icon responds to a right click but not a left click, the process is alive and the issue is with the popover rather than the app.

For a status item that vanishes after every restart, look at Login Items under General in System Settings. An app that is not registered there has to be started by hand after each reboot, which is easily read as the app disappearing on its own.

Match the symptom to a version number

The project publishes a full version history, which makes some diagnoses a lookup rather than an investigation. Several entries describe symptoms that are easy to notice from the outside.

• Version 0.15.7 introduced a bug causing excessive CPU use, fixed in 0.15.8. A Mac running hot with fans up is worth checking against this before anything else
• A memory leak on macOS 26 was fixed in 0.15.9
• A daylight saving time transition was handled incorrectly and later fixed, along with a workaround for a macOS Sequoia issue where user calendars set to ISO 8601 ignored the EEE pattern
• Crashes after upgrading to macOS Ventura have a separate documented remedy linked from the help page

Interaction with menu bar hiding utilities is documented too. Version 0.15.11 changed how the app positions itself when menu bar space is tight or when a hiding utility is in use, placing the popover along the right side of the screen. Version 0.15.12 reverted that change, because it broke existing behaviour with the system's own menu bar auto hiding. Anyone running such a combination should read the version number before assuming a configuration error.

Updating is handled in app, since the project uses Sparkle for updates and MASShortcut for shortcut recording. Installations managed by Homebrew use the cask named itsycal.

When the calendar button opens the wrong app

A frequent report is that clicking the calendar button opens the stock Calendar app rather than the calendar application actually in use. This is a configuration question with the setting stored somewhere unexpected.

The published help states that the button opens the Mac's default calendar application, and that BusyCal or Fantastical will open instead once one of them is set as the default. The setting is not in this app at all. It lives in the General settings of the stock Calendar app, which is where macOS keeps the system wide default.

The help then adds an important qualifier: because of a bug in macOS, this sometimes fails to take effect, and it links to instructions to try in that case. Knowing that in advance prevents the usual loop of setting the default, testing, unsetting it, and testing again on the assumption that the click was registered wrong.

A related item in the release notes is worth knowing for anyone whose double clicks behave unexpectedly. Double clicking an event in the agenda opens it in the Mac Calendar app in day view, while right clicking offers the same action from a context menu, and clicking the calendar button opens month view. Three similar looking gestures with three different destinations produce reports that read like faults but are documented behaviour.

Check for forgotten hidden settings

Several options exist only as Terminal commands, and one applied months ago to fix something else can present later as a new fault.

The release notes document ShowEventPopoverOnHover for showing event details on hover, DoNotDrawOutlineAroundCurrentMonth for removing the outline around the current month, BaselineOffset for nudging menu bar text vertically, EnableMeetingButtonIndefinitely for keeping join buttons live, and ShowMeetingIndicator for putting an in progress meeting marker in the menu bar.

Each is applied with defaults write and removed by passing the same key to defaults delete. When observed behaviour contradicts the documentation, clearing this layer eliminates a whole class of confusion in one step.

What to report if none of it helps

The developer's site asks for a specific set of details: steps to reproduce, the app version, the macOS version, and the Mac model and year including whether it is Intel or Apple silicon, plus a crash report when the app is crashing.

Gathering those four is useful before sending anything. A version number can be matched against the release notes, and a macOS version determines whether the new Menu Bar permission panel applies. Roughly half the reports that get written answer themselves during collection.

What to change first

If the icon is missing, treat it as a width problem first and a software problem second, since capacity is the more common cause and costs nothing to test. Reduce the number of status items competing for that space, keeping the ones that are read and folding away the ones that are only occasionally clicked, which is what a menu bar manager is for. The FAQ covers how hidden items stay reachable, and Koffret is one way to try that approach on the machine that is showing the problem.