Skip to content

fix(macos): declare Calendar/Reminders usage strings so EventKit tools work (#302) - #377

Open
aniketshukla1 wants to merge 1 commit into
andrewyng:mainfrom
aniketshukla1:fix/302-macos-calendar-reminders-plist
Open

fix(macos): declare Calendar/Reminders usage strings so EventKit tools work (#302)#377
aniketshukla1 wants to merge 1 commit into
andrewyng:mainfrom
aniketshukla1:fix/302-macos-calendar-reminders-plist

Conversation

@aniketshukla1

Copy link
Copy Markdown

Summary

Closes #302.

Calendar/reminders MCP tools silently fail on macOS with no permission prompt. The app bundle's Info.plist declares usage strings for the microphone, Desktop, Documents, Downloads and Photos, but not Calendars or Reminders. macOS' TCC blocks EventKit access outright (rather than prompting) when the usage-description key is missing, so the user never gets a chance to grant access and the tool just fails.

Fix

Add the Calendar and Reminders usage strings to surfaces/gui/src-tauri/Info.plist (Tauri merges this file into the bundle's Info.plist).

macOS 14 split the calendar/reminders keys, so each is declared in both forms for compatibility:

Resource macOS 14+ SDK Legacy (older systems)
Calendar NSCalendarsFullAccessUsageDescription NSCalendarsUsageDescription
Reminders NSRemindersFullAccessUsageDescription NSRemindersUsageDescription

An app built against the 14+ SDK reads the ...FullAccess variant; older systems read the legacy key. Declaring both means the prompt works regardless of which SDK the release is built against or which macOS it runs on. Full-access (not write-only) is used because the calendar tools both read and create/delete events.

Why no entitlement is needed

The app is not sandboxed (entitlements.plist has only hardened-runtime keys, no com.apple.security.app-sandbox). It already follows the pattern of gating personal-information resources by the usage string alone — NSPhotoLibraryUsageDescription is present with no com.apple.security.personal-information.photos-library entitlement. Calendars/Reminders are the same class of resource as Photos, so they're handled the same way.

This is deliberately different from the microphone, which needed both a usage string and com.apple.security.device.audio-input — that's a hardened-runtime device resource, a different category from these personal-information resources. I've noted this reasoning in the file comment so the distinction is clear to future readers.

Verification

  • plutil -lint Info.plistOK
  • Each new key reads back via plutil -extract <key> raw

A full signed-bundle test would confirm the merged Info.plist end to end, but that needs a signed release build; the merge itself is standard Tauri behavior already proven by the existing mic/Photos keys.

…s work (andrewyng#302)

The bundle's Info.plist declared usage strings for the mic, Desktop, Documents,
Downloads and Photos, but not Calendars or Reminders. On macOS, TCC blocks
EventKit access OUTRIGHT (no prompt) when the usage-description key is absent,
so a calendar/reminders MCP tool silently fails with no way for the user to grant
access.

Add the Calendar and Reminders usage strings. macOS 14 split the key into a
...FullAccessUsageDescription variant (read by apps built against the 14+ SDK)
and the legacy key (older systems), so both are declared for each. Like the
existing Photos entry — and unlike the mic, a hardened-runtime *device* resource
that also needs an entitlement — these personal-information resources are gated by
the usage string alone on this non-sandboxed, hardened-runtime app.

Info.plist passes plutil -lint; each new key reads back via plutil -extract.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Calendar-related MCP tools fail

1 participant