[Bug] Claude Desktop 1.6608.2 — MCPB extension Calendar/Reminders access regression (responsible-process attribution via disclaimer wrapper)

Summary

Claude Desktop 1.6608.2 (release date around 2026-05-09) broke EventKit (Calendar + Reminders) write access for .mcpb extension MCP servers on macOS. The same .mcpb extension worked correctly with prior Claude Desktop versions through early May 2026 — confirmed by surviving auth_value=2 (granted) rows in TCC.db dated April 2026.

Related to #52684 (same disclaimer wrapper) and #55903 (same .mcpb MCP install vs claude_desktop_config.json divergence).

Environment

• Claude Desktop: 1.6608.2 (CFBundleShortVersionString=1.6608.2, build install date 2026-05-09)
• macOS: 26.0 (Tahoe), Darwin 25.4.0, arm64
• Affected MCP: local.mcpb.che-cheng.che-ical-mcp (CheICalMCP v1.10.0, Developer ID signed + notarized via che-mcps-notary profile)
• Binary path: ~/Library/Application Support/Claude/Claude Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP

Reproduction

1. Install any .mcpb MCP extension that calls EKEventStore.requestFullAccess(to: .event) and writes events
2. In a pre-1.6608.2 Claude Desktop session, accept the standard TCC prompt — this writes a path-based grant: kTCCServiceCalendar | <mcpb-extracted-path>/server/CheICalMCP | auth_value=2
3. Update Claude Desktop to 1.6608.2
4. Re-open Claude Desktop, call a write tool (e.g. create_event)

Expected: Event is created. Same behavior as pre-1.6608.2.

Actual: EventKit returns denied. The MCP server's wrapper translates this to Calendar access denied. Please grant permission... Surfaced through the JSON-RPC response to the client.

Evidence

TCC.db state (path-based grants from April 2026 still present, no longer effective)

SELECT service, client, auth_value, datetime(last_modified,'unixepoch','localtime')
FROM access
WHERE client LIKE '%CheICalMCP%';

kTCCServiceCalendar  | <mcpb-extracted-path>/server/CheICalMCP | 2 | 2026-04-01 13:53:15
kTCCServiceReminders | <mcpb-extracted-path>/server/CheICalMCP | 2 | 2026-04-30 16:24:55

We also tried inserting a bundle-ID-based grant for com.anthropic.claudefordesktop (same csreq blob as the existing kTCCServiceSystemPolicyDesktopFolder row, so Claude.app's codesign requirement validates). Still denied. So this is not just a missing TCC entry — it is an attribution / framework-layer block.

Process attribution evidence

$ ps -A -o pid,command | grep CheICalMCP
PID    /Applications/Claude.app/Contents/Helpers/disclaimer <mcpb-path>/server/CheICalMCP
PID+   <mcpb-path>/server/CheICalMCP

The disclaimer wrapper sits between Claude.app and the MCP binary in the process chain. Same wrapper as reported in #52684.

Claude.app entitlements (likely the structural gap)

$ codesign -d --entitlements - /Applications/Claude.app | grep -iE "calendar|reminder"
(no output)

Claude.app embedded entitlements declare camera, microphone, bluetooth, USB, location, photos, virtualization, allow-jit. They do NOT declare:

• com.apple.security.personal-information.calendars
• com.apple.security.personal-information.reminders

Claude.app Info.plist

$ plutil -p /Applications/Claude.app/Contents/Info.plist | grep -iE "Usage|Calendar|Reminder"
NSAudioCaptureUsageDescription => ...
NSBluetoothAlwaysUsageDescription => ...
NSBluetoothPeripheralUsageDescription => ...
NSCameraUsageDescription => ...
NSMicrophoneUsageDescription => ...
NSSpeechRecognitionUsageDescription => ...

Missing:

• NSCalendarsFullAccessUsageDescription (required by macOS 14+ for full Calendar access)
• NSCalendarsUsageDescription (legacy)
• NSRemindersFullAccessUsageDescription
• NSRemindersUsageDescription

Same binary, different context

The exact same binary at <mcpb-extracted-path>/server/CheICalMCP returns fullAccess for EKEventStore.authorizationStatus(for: .event) when invoked directly from Terminal. Confirmed via the binary's diagnostic --print-tcc-path flag. So the binary itself is healthy — the responsible-process attribution chain under the disclaimer wrapper changes which TCC client the request is attributed to.

Hypothesis

Claude Desktop 1.6608.2 introduced (or significantly changed) the disclaimer wrapper layer. The wrapper alters TCC responsible-process attribution so:

| | Pre-1.6608.2 | 1.6608.2+ |
|--|--------------|-----------|
| Process chain | Claude.app → MCP binary | Claude.app → disclaimer wrapper → MCP binary |
| TCC attribution | Binary path | com.anthropic.claudefordesktop (responsible bundle) |
| Effect | April path-based grants worked | April grants invalidated; no fallback grant for com.anthropic.claudefordesktop Calendar |

Even adding a bundle-ID-based TCC grant manually does not unblock — strongly suggesting the framework layer (sandbox entitlements + Info.plist NSCalendarsFullAccessUsageDescription requirement on macOS 14+) blocks the EventKit API before TCC daemon is consulted.

Impact

Any .mcpb MCP extension that needs Calendar or Reminders access is broken under 1.6608.2+. Affects MCP authors who relied on the user-triggered TCC prompt flow that worked prior to this release.

Workarounds available to end users:

1. Use Claude Code CLI instead of Claude Desktop (binary spawn context differs — no disclaimer wrapper, responsible-process attribution stays with the shell)
2. Configure MCP server via legacy claude_desktop_config.json instead of .mcpb extension (may bypass disclaimer wrapper, depends on launch path)
3. Use a non-Apple Calendar API (Google Calendar, etc.)

None of these are great. (1) is fine for power users but breaks the .mcpb distribution promise. (2) loses the auto-update + integrated install flow. (3) doesn't help users who actually want macOS Calendar integration.

Suggested fix (any one resolves)

1. Add com.apple.security.personal-information.calendars + .reminders entitlements to Claude.app (and disclaimer wrapper) codesign manifest, plus NSCalendarsFullAccessUsageDescription + NSRemindersFullAccessUsageDescription to Info.plist. This is the minimum change.
2. Allow .mcpb extension authors to declare required entitlements in their manifest.json, and have the disclaimer wrapper honor them per-extension. Cleaner long-term: extensions opt in to elevated access rather than the host app declaring everything possible.
3. Revert disclaimer wrapper for .mcpb extensions, or move TCC responsible-process attribution back to the binary path. Preserves existing per-binary TCC grants but loses whatever sandbox isolation disclaimer was added for.

Cross-reference

This issue is the upstream root cause for a class of denied failures we tracked in our own MCP extension at PsychQuant/che-ical-mcp#122. The closed issue body has been updated with editorial clarification that the install context was .mcpb (Claude Desktop), not the ~/bin/CheICalMCP (Claude Code plugin) install. Our v1.10.0 ships a [banner] startup line that surfaces TCC drift signals to operators — useful for diagnosing this same class of issue on user hosts going forward.