[BUG] Desktop: MCP servers needing Calendar/Reminders (EventKit) access still get silently denied — recurring, previously reported and auto-closed as stale (#55692, #76936, #58239)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

A local MCP server that needs macOS Calendar/Reminders (EventKit) access never gets a working permission grant when its subprocess is spawned by Claude Code — every call fails with "access denied," no system permission dialog ever appears, and the requesting process never shows up as an entry in System Settings -> Privacy & Security -> Reminders/Calendar for the user to grant manually.

This is not a new report. The same root cause has been reported at least three times before and closed each time as "not planned" by the stale-issue bot without a maintainer fix, most recently #55692 ("Desktop bundle missing NSRemindersUsageDescription... TCC silently denies all Reminders MCP calls"), and also #76936 and #58239. #55692 in particular already contains a TCC system log confirming the exact mechanism: tccd refuses the authorization request because the app bundle's Info.plist has no NSRemindersUsageDescription key. The bot's own closing comment says to open a new issue if still relevant -- it still is, so I'm doing that instead of commenting on a closed thread I don't have permission to reopen.

My own reproduction today, independent of the MCP server used in the prior reports (I'm using a different third-party Calendar/Reminders MCP, CheICalMCP -- https://github.com/PsychQuant/che-ical-mcp), confirms the exact same failure signature, plus a few additional data points not in the earlier reports:

• Granting the permission via the binary's own --setup flow run interactively from Terminal.app succeeds for Terminal's own context (it shows up correctly in System Settings -> Privacy & Security with a real granted state) -- but this grant does not transfer to Claude Code's own spawned subprocess, which still fails identically afterward.
• A full restart of the Claude Code app does not help either (ruling out a simply-stale cached authorization status in an already-running MCP subprocess).
• Neither "Claude" nor the MCP binary itself ever appears anywhere in System Settings -> Privacy & Security -> Reminders or -> Calendar, even after repeated attempts -- only "Terminal" shows up there, from the interactive-Terminal grant. This is consistent with macOS attributing the EventKit permission request to whichever app is TCC's "responsible" process for the child, and that responsible app (Claude Code) apparently never successfully completes a real request at all.

What Should Happen?

A local MCP server that requests Calendar/Reminders (EventKit) access should trigger the standard macOS permission dialog when spawned by Claude Code, exactly as it does when the identical binary is launched directly from Terminal. Once granted, the app (or the responsible parent Claude Code is attributed as) should appear in System Settings -> Privacy & Security -> Reminders/Calendar so the user can manage the grant, the same as any other well-behaved macOS app. Likely fix, per #55692's own investigation: add NSRemindersUsageDescription and NSCalendarsUsageDescription to the Claude Code app bundle's Info.plist.

Error Messages/Logs

Error returned from the MCP server's own list_reminders tool call, live in an interactive Claude Code session:

Error: Reminders access denied. Please grant permission:
1. Open System Settings → Privacy & Security → Reminders
2. Enable access for the MCP server or Terminal
3. Or grant this exact binary access by running its setup from Terminal: "/Users/<me>/bin/CheICalMCP" --setup
4. Restart Claude Desktop/Code

Followed all 4 steps in order (Terminal setup completed successfully, confirmed via the binary's own TCC diagnostic; full Claude Code restart performed) — identical error persists afterward, called from within Claude Code again.

Steps to Reproduce

1. Configure any local stdio MCP server that needs Calendar or Reminders access via EventKit (e.g. CheICalMCP -- https://github.com/PsychQuant/che-ical-mcp -- or apple-reminders, or any custom binary calling EKEventStore.requestFullAccessToReminders/requestFullAccessToEvents).
2. In an interactive Claude Code session, invoke an MCP tool that triggers that permission request for the first time (e.g. list_reminders).
3. Observe: the call returns "access denied" (or the completion handler resolves false/notDetermined, depending on the MCP server's own error handling) with no system permission dialog ever appearing, and no entry for the app/binary in System Settings -> Privacy & Security -> Reminders or -> Calendar.
4. From a separate interactive Terminal.app window, run the identical binary directly (e.g. /path/to/binary --setup, or whatever the server's own manual-grant flow is) with the same arguments: the system permission dialog appears normally, granting succeeds, and it shows up correctly in System Settings under Terminal's own entry.
5. Return to the Claude Code session and retry step 2: the identical "access denied" error persists -- the grant from step 4 does not transfer.
6. Fully quit and reopen Claude Code, then retry step 2 again: still fails identically.

This matches the exact reproduction and root-cause diagnosis already written up in #55692 (missing NSRemindersUsageDescription in the Info.plist, confirmed there via a direct TCC system log showing tccd refusing the request for exactly that reason) and #76936 (same class of bug for Calendar specifically, describing the identical "works from Terminal, not from Claude Desktop" split). This report exists because both of those were auto-closed as stale by the repo's bot without a fix ever landing, and the bot's own message asks for a new issue if still relevant.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.219 (Claude Code, macOS desktop app)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

"Terminal/Shell" above is set to Other because this isn't happening inside any terminal emulator at all -- the failing context is the Claude Code/Claude Desktop macOS app itself running as its own standalone app bundle (process tree rooted at /Applications/Claude.app/Contents/MacOS/Claude), spawning the MCP server as its own child process. That distinction is the crux of this bug: the identical MCP server binary works fine when launched from a real terminal emulator, and only fails when Claude Code's own app is the spawning parent.

Related issues for context (all closed as "not planned"/stale, none actually fixed):

• #55692 -- exact same failure for Reminders, with a TCC log confirming the missing NSRemindersUsageDescription key
• #76936 -- same class of bug specifically for Calendar (their case: Reminders worked, Calendar didn't; in my case both fail)
• #58239 -- describes it as a "responsible-process" regression in an MCPB extension context

Happy to run any additional diagnostics (log show --predicate 'subsystem == "com.apple.TCC"', PlistBuddy dump of the app's Info.plist, etc.) if a maintainer wants more data.