›_ Claude Code Issues
Claude Code Issues / #58239

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

Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 10 comments · opened May 12, 2026 · closed Aug 25, 2026

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.

View original on GitHub ↗

9 Comments

github-actions[bot] · 3 months ago

Found 1 possible duplicate issue:

  1. https://github.com/anthropics/claude-code/issues/55692

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

kiki830621 · 3 months ago

Stronger regression timeline evidence (94 successes → 10 failures across the 1.6608.2 update)

After more careful log analysis I have a much clearer regression timeline than what the original report included. Posting here so Anthropic engineers can git-bisect to the specific 1.6608.2 change with confidence.

Method

Read every entry in ~/Library/Logs/Claude/mcp-server-macOS Calendar & Reminders.log (note: filename uses display_name not technical name, easy to miss — the older mcp-server-che-ical-mcp.log file is stale from before Claude Desktop renamed the log convention in mid-January). Counted successful operations vs access denied responses.

Counts

| Metric | Count |
|--------|-------|
| Successful Created event / Updated event / Created reminder via .mcpb install | 94 |
| Calendar access denied failures via .mcpb install | 10 |

The 94 successes span 2026-01-15 → 2026-04-29 (the entire 3.5 months .mcpb was active on this host pre-1.6608.2). The 10 failures all cluster after 2026-05-11.

Timeline of the break

2026-01-15T15:34:49Z  ✓ Created event "線上討論：gAB收斂問題研究…"  (first success)
                      ...
                      (92 more successful create/update calls over 3.5 months)
                      ...
2026-04-27T23:24:27Z  ✓ Created event (...)
2026-04-29T00:31:03Z  ✓ Created event (...)                      ← LAST SUCCESS

2026-05-09  /Applications/Claude.app/Contents/ mtime              ← Claude.app 1.6608.2 install
            (CFBundleShortVersionString = "1.6608.2")

2026-05-11T09:53:22Z  ✗ Calendar access denied (non-interactive   ← FIRST FAIL
                        session detected)
2026-05-11T14:30:59Z  ✗ Calendar access denied
                      ...
                      (8 more denied attempts)
2026-05-12T05:35:02Z  ✗ Calendar access denied                     ← MOST RECENT FAIL

The 12-day gap between last success (Apr 29) and first fail (May 11) is when Claude Desktop 1.6608.2 landed on this host (May 9). No other system-level changes (macOS update, TCC database manipulation, MCP code change) occurred in that window — the che-ical-mcp binary itself hadn't been updated between v1.9.0 (Apr 30) and v1.10.0 (May 12, after the failures started).

Two-stage error message wording note

The first 2 failures (2026-05-11 09:53) used wording "Calendar access denied (non-interactive session detected). macOS TCC cannot show permission dialogs in non-interactive sessions". The remaining 8 failures used "Calendar access denied. Please grant permission...".

That wording difference is a che-ical-mcp artifact, not separate bugs — our v1.9.0 had hardcoded isLaunchd=true detection that triggered the "non-interactive" branch; we removed that in v1.10.0 (closed as PsychQuant/che-ical-mcp#113). Same underlying EKAuthorizationStatus.denied return from EventKit in both cases.

Implication

The same binary at the same path, called from Terminal context, still returns fullAccess for authorizationStatus(for: .event). So:

  • Binary's TCC.db entry: intact and granted (auth_value=2)
  • Binary's codesign: unchanged (Developer ID + notarized, no cdhash drift)
  • macOS version: unchanged across the gap
  • Only thing that changed in the failure window: Claude Desktop 1.6608.2 install

The structural gaps I noted in the original report (missing com.apple.security.personal-information.calendars entitlement on Claude.app, missing NSCalendarsFullAccessUsageDescription in Info.plist) are the most likely mechanism by which 1.6608.2 broke previously-working behavior — but they may have existed pre-1.6608.2 too, with some other compensating layer (different disclaimer wrapper version, different responsible-process attribution, sandbox profile difference, etc.) that 1.6608.2 removed.

If the diff between 1.6608.2 and the immediately-prior release isn't obvious to whoever owns the MCP runtime team internally, comparing process-chain spawn behavior and TCC attribution logic on a host with .mcpb extension installed should surface it quickly. Happy to provide more host-level diagnostic output if useful — full ~/Library/Logs/Claude/ + TCC.db schema dump available on request.

Cross-reference

  • Tracker on our side: PsychQuant/che-ical-mcp#132 (closed-as-tracker, no local code action needed)
  • Same disclaimer wrapper symptom (ENOENT) noted earlier: #52684
  • Same .mcpb vs claude_desktop_config.json divergence: #55903
z45znng7k9-star · 3 months ago

Am seeing the same issue as described with MacOS Tahoe 26.5 Developer Beta, Claude for Mac 1.6608.2 (ebf1a1).
Can see a disclaimer process running for the mcpb as follows:
USER 5036 0.0 0.0 435299696 688 ?? S 4:17PM 0:00.00 /Applications/Claude.app/Contents/Helpers/disclaimer /Users/USER/Library/Application Support/Claude/Claude Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP

kiki830621 · 3 months ago

2026-05-20 retest — issue still reproducing on Claude Desktop 1.7196.3

This thread was labeled invalid on 2026-05-12 without explanation. I retested today on Claude Desktop 1.7196.3 (latest, ~588 minor versions ahead of the originally-reported 1.6608.2) and the regression reproduces deterministically.

If invalid means "wont-fix by design" — fair, but please leave a comment. The current state (label says no, thread says nothing) leaves external maintainers and users guessing.

Parallel A/B test on same host, within 4 minutes

| MCP install path | Tool call | Result |
|---|---|---|
| Claude Code plugin (~/bin/CheICalMCP) | list_calendars + create_event + delete_event | ✓ All succeeded |
| Claude Desktop .mcpb extension | list_calendars (type=event) | ✗ denied |
| Claude Desktop .mcpb extension | list_calendars after server restart | ✗ denied |

Same machine, same TCC.db grants, same MCP server binary (che-ical-mcp v1.10.0, Developer ID signed + notarized). The only variable is the spawn parent — ~/bin/... spawned by Claude Code wrapper works; same binary extracted by .mcpb installer and spawned by Claude Desktop is denied at the framework layer.

Structural delta on 1.7196.3

/Applications/Claude.app/Contents/Info.plist:

present: NSAudioCaptureUsageDescription, NSBluetoothAlwaysUsageDescription,
         NSBluetoothPeripheralUsageDescription, NSCameraUsageDescription,
         NSMicrophoneUsageDescription, NSSpeechRecognitionUsageDescription
missing: NSCalendarsFullAccessUsageDescription
missing: NSRemindersFullAccessUsageDescription

codesign -d --entitlements -:

present: com.apple.security.personal-information.location
         com.apple.security.personal-information.photos-library
missing: com.apple.security.personal-information.calendars
missing: com.apple.security.personal-information.reminders

macOS 14+ requires both the entitlement and the NSCalendarsFullAccessUsageDescription Info.plist string for any process in Claude.app's sandbox / responsible-process scope to obtain Calendar/Reminders access through EventKit — regardless of TCC.db grant state for the spawned binary path.

Reproducer

  1. Install Claude Desktop 1.6608.2 or later (incl. 1.7196.3)
  2. Install any .mcpb extension that calls EventKit (e.g. che-ical-mcp)
  3. In a Claude Desktop chat: ask it to list calendars → observe Calendar access denied
  4. Compare with same binary installed as Claude Code plugin → works

What would unblock this

One of:

  • (a) Add NSCalendarsFullAccessUsageDescription + NSRemindersFullAccessUsageDescription to Info.plist + matching entitlements to Claude.app
  • (b) Provide a per-.mcpb-extension entitlement-request mechanism in the manifest
  • (c) Document Calendar/Reminders as unsupported for .mcpb extensions so we permanently route users to the Claude Code plugin path

Cross-ref: PsychQuant/che-ical-mcp#132.

SpoonJimSquareSocks · 3 months ago

2026-05-20 retest on Claude Desktop 1.8089.1 — partial fix observed (Reminders), Calendar still denied

Following @kiki830621's retest from earlier today. Adding evidence one Claude Desktop version newer.

Setup

  • Claude Desktop 1.8089.1 (mtime 2026-05-19, ~893 minor versions ahead of the 1.7196.3 retest above)
  • macOS 26.5
  • CheICalMCP v1.10.0 (same binary referenced upstream — Developer ID signed, team 6W377FS7BS)

Reminders is now unblocked. Calendar is still denied.

Two MCP tool calls run consecutively in the same session through the .mcpb extension:

update_reminder(id=..., dueDate=2026-05-24T09:00)  → success; round-trips to iCloud
list_calendars(type=event)                          → "Calendar access denied. Please grant permission..."

The Reminders write actually persists to iCloud (verified in the Reminders app and at icloud.com). Prior to 1.8089.1, both Reminders and Calendar writes were denied on the same .mcpb extension setup.

Inference: 1.8089.1 appears to ship a partial fix covering Reminders attribution but not Calendar. The two surfaces are no longer symmetric. Worth checking whether NSRemindersFullAccessUsageDescription + com.apple.security.personal-information.reminders made it into 1.8089.1's Info.plist / entitlements while their Calendar counterparts did not — that would explain the asymmetry cleanly.

Workaround (2) from the issue body — does NOT bypass the disclaimer wrapper

The original issue body lists option (2) as:

Configure MCP server via legacy claude_desktop_config.json instead of .mcpb extension (may bypass disclaimer wrapper, depends on launch path)

Tested on 1.8089.1 today. Setup: disabled the .mcpb extension, added an mcpServers entry in claude_desktop_config.json pointing at a local binary copy, Cmd+Q + relaunch.

Process tree at the moment of failure:

/Applications/Claude.app/Contents/Helpers/disclaimer /Users/<user>/bin/CheICalMCP
/Users/<user>/bin/CheICalMCP

Helpers/disclaimer wrapper is still in the chain. Same Calendar denial as the .mcpb extension. Workaround (2) can be downgraded from "may bypass, depends on launch path" to "does NOT bypass (confirmed 2026-05-20 on 1.8089.1)". The wrapper is wired in at the Claude Desktop spawn layer regardless of which MCP install path the user picks.

Net

  • Two independent users (this thread above + this comment) confirm the bug reproduces on macOS 26 + multiple Claude Desktop builds
  • Bug now confirmed to persist on Claude Desktop 1.8089.1 (the build released yesterday, 2026-05-19)
  • Reminders side has been partially fixed in 1.8089.1; Calendar side has not
  • Both .mcpb extension AND legacy claude_desktop_config.json install paths are affected identically

Cross-ref: PsychQuant/che-ical-mcp#132 comment with fuller diagnostic detail.

SpoonJimSquareSocks · 3 months ago

2026-05-20 evening — partial fix in 1.8089.1 has a timezone-metadata regression

Following up on my 16:49 comment earlier today. The "Reminders writes work post-1.8089.1" claim holds against EventKit ground truth — verified via schappim/ekctl, which reads local EventKit directly and agrees with the MCP on all 8 reminders I touched today. Writes are landing in EventKit correctly.

BUT iCloud Web (icloud.com/reminders) renders many of those same reminders with a consistent -4h time-of-day shift — exactly the host's UTC offset (UTC-4). Mac Reminders.app Today view shows the same staleness. Examples (host-local time, titles anonymized):

Reminder                       ekctl/MCP     iCloud Web
-----------------------------  ------------  ------------
Reminder A (one-shot)          Mon 12:00 PM  Mon 08:00 AM
Reminder B (recurring weekday) Mon 3:30 PM   Mon 11:30 AM
Reminder C (one-shot)          Sun 2:00 PM   Sun 10:00 AM
Reminder D (one-shot)          Thu 9:00 AM   Thu 5:00 AM
Reminder E (one-shot)          Sun 9:00 AM   Sun 5:00 AM
...4 more with the same -4h pattern

Counter-examples (same host, same session): reminders created by an earlier batch on 2026-05-19 sync and render correctly. So the regression is selective — something about how 1.8089.1's update_reminder + create_reminder paths serialize timezone metadata into the record that's pushed to iCloud. EventKit-local serialization is fine.

Smoking gun: -4h delta is identical to the host's UTC offset, applied across ~9 reminders, across both updates-of-existing and creates-of-new.

Actual alarms fire from EventKit (right time). iCloud Web display + Mac Reminders.app Today view both render wrong (-4h). Users will see "wrong" times in the apps but their phones/Macs will fire alarms at the correct local time.

Reproducer: any update_reminder or create_reminder MCP call from Claude Desktop 1.8089.1 with an ISO-8601 due_date that includes a non-UTC TZ offset (e.g. 2026-05-25T12:00:00-04:00). MCP returns success; ekctl reads back the correct local time; iCloud Web renders 12:00 - 4h = 08:00.

Cross-ref: PsychQuant/che-ical-mcp#132.

SpoonJimSquareSocks · 3 months ago

Correction to my earlier comment — not actually a Claude Desktop regression

My comment from a few hours ago framed the iCloud Web -4h reminder shift as a Claude Desktop 1.8089.1 regression. Wrong framing. A controlled A/B with schappim/ekctl (a standalone Swift EventKit CLI, no Claude Desktop in its path) reproduces the identical -4h shift. So Claude Desktop is exonerated for this specific iCloud-Web rendering bug.

Actual root cause: EventKit reminders are being written with dueDateComponents.timeZone == nil — a floating wall-clock value. Native apps interpret floating as local time (correct); iCloud Web interprets it as UTC and re-converts (shifted by host offset). Documented with full A/B detail at PsychQuant/che-ical-mcp#132.

Fix is one line in the writer (dueComponents.timeZone = TimeZone.current). Not a Claude Desktop issue — the Calendar entitlement bug remains the real upstream problem this thread tracks, unchanged.

Apologies for the misdirected diagnosis earlier today.

kiki830621 · 2 months ago

Update (2026-06-11): still broken on Claude Desktop 1.11847.5 — root cause narrowed to missing TCC usage strings; server-side fix shipped and verified, ball is now entirely on Claude.app's side

Three developments since the original report, with fresh evidence from the current Desktop build.

1. Claude.app 1.11847.5 still ships zero Calendar/Reminders usage strings

Checked today on the latest auto-updated build:

$ defaults read /Applications/Claude.app/Contents/Info.plist CFBundleShortVersionString
1.11847.5

$ plutil -p /Applications/Claude.app/Contents/Info.plist | grep -c UsageDescription
9    # audio capture, bluetooth ×2, camera, desktop/documents/downloads folders, microphone, speech recognition

$ plutil -p /Applications/Claude.app/Contents/Info.plist | grep -icE "NSCalendar|NSReminder"
0    # ← no NSCalendarsFullAccessUsageDescription, no NSRemindersFullAccessUsageDescription

$ ls /Applications/Claude.app/Contents/Helpers/
chrome-native-host    disclaimer    # disclaimer spawn chain unchanged

macOS will not render a TCC permission dialog unless the app the request is attributed to declares the matching usage string. EventKit requests from a .mcpb are attributed to Claude.app (via the disclaimer helper chain documented above), Claude.app declares no Calendar/Reminders strings → the dialog is structurally impossible: no prompt, no Privacy & Security entry, no GUI path for the user to grant anything.

This is the same finding as #63032 ("Claude Desktop's Info.plist missing TCC usage strings, blocks all EventKit-based MCP servers"), which was auto-closed by the triage bot on 2026-05-31 as "doesn't appear to be about Claude Code" — a misfire: it's a Claude Desktop bug, filed where Desktop issues are tracked. Please re-triage; the evidence above reproduces it on today's build.

2. The MCP-server side has done its half — verified necessary but not sufficient

As the maintainer of the repro server (PsychQuant/che-ical-mcp): v1.11.0 now ships com.apple.security.personal-information.calendars + .reminders entitlements (macOS 26.5's prompting policy requires them on hardened-runtime binaries — PsychQuant/che-ical-mcp#154). An independent affected user verified on a real machine: checksum / Developer ID chain / notarization / entitlements all confirmed clean on the installed binary — and the prompt still cannot fire from the Claude Desktop context, while the identical binary works from contexts that don't attribute to Claude.app. There is nothing further a server binary can do.

3. The clean control: grants survive, prompting is the only broken link

On the affected machine, a legacy Developer-ID-keyed Reminders TCC row keeps working under Claude Desktop, while Calendar — whose row needs a re-prompt to heal — stays dead. Existing grants pass through the attribution chain fine; the single broken link is the OS being unable to display a new prompt on Claude.app's behalf.

Ask

Add to Claude.app's Info.plist:

<key>NSCalendarsFullAccessUsageDescription</key>
<string>MCP servers you install may access your calendars to manage events.</string>
<key>NSRemindersFullAccessUsageDescription</key>
<string>MCP servers you install may access your reminders to manage tasks.</string>
</key>

(or have the disclaimer helper adopt the disclaim posix_spawn attribute so TCC responsibility lands on a process that declares them). Two plist strings unblock every EventKit-based MCP server for every .mcpb user.

Refs: #63032 (same root cause, bot-closed), PsychQuant/che-ical-mcp#154 (server-side fix + real-machine verification), PsychQuant/che-ical-mcp#132 (downstream tracking).

kiki830621 · 1 month ago

Update (2026-07-03): server-side workaround now shipped for the prompting bug + a separate Desktop injection bug found

Thanks @SpoonJimSquareSocks and @z45znng7k9-star for the co-repro and A/B work on this thread. Two developments.

1. This thread's bug is unchanged, but the server side now scaffolds around it

The core issue this thread tracks is unchanged: Claude.app still ships no NSCalendarsFullAccessUsageDescription / NSRemindersFullAccessUsageDescription, so the OS cannot render a Calendar/Reminders prompt for an EventKit request attributed to Claude.app. A brand-new user with no prior grant, relying on Claude Desktop to prompt them, is still structurally stuck.

What has changed is that the repro server (che-ical-mcp) now ships a full out-of-band grant path so users can work around the missing prompt without Claude Desktop:

  • --setup — a foreground SwiftUI setup window (run from Terminal) that shows live Calendar/Reminders authorization status and has Grant buttons. Because it runs in a normal foreground GUI context (not under Claude.app's disclaimer attribution chain), the TCC prompt actually fires, and the grant is written keyed to the server binary's own bundle id + Team ID.
  • --print-tcc-path — a read-only diagnostic that prints the binary path, bundle id, current EKAuthorizationStatus for Calendar + Reminders, and ready-to-paste tccutil / sqlite3 commands. Lets a user (or a supporter debugging remotely) verify grant state without opening Claude at all.
  • Plus the com.apple.security.personal-information.calendars / .reminders entitlements shipped earlier (referenced in my 2026-06-11 comment).

The key mechanism: once the grant exists for the binary's own bundle id + Team ID (not Claude.app's), it is reused across every launch context — Claude Desktop included — so Desktop no longer needs to prompt. On a host where the grant was established this way, EventKit access works fine under Desktop today.

The takeaway for Anthropic is the reverse: every EventKit-based .mcpb author is now forced to build their own foreground-setup + grant-detection scaffolding to route around Claude.app's inability to prompt. Adding the two NSCalendars… / NSReminders… usage strings to Claude.app's Info.plist (or having the disclaimer helper disclaim TCC responsibility) would remove that duplicated workaround burden for every EventKit MCP server at once. The ask from my 2026-06-11 comment stands.

2. A separate Desktop injection bug found (not this thread's TCC issue) — filed as #73787

While chasing why che-ical went completely absent from Desktop conversations under 1.18286.0 (a different symptom from this thread's "access denied" — here the whole server has zero tools injected), I root-caused a second, unrelated Claude Desktop bug: a literal & in a manifest display_name makes Desktop 1.18286.0 silently drop the entire MCP server from every conversation (handshake + tools/list complete, no tool injected, no log). Confirmed by single-variable intervention ("… & …" → "… and …" in display_name = dropped → injecting). It affects any .mcpb, not just EventKit ones.

Filed separately so it can be triaged on its own subsystem: #73787.

Cross-ref: PsychQuant/che-ical-mcp#166 (downstream fix + regression guard).

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: MCP server connection issues, IDE & terminal integration

Browse all Claude Code issue topics →