Permission setup issue

[z45znng7k9-star]

I'm having trouble getting CheICalMCP to be assigned necessary permissions.

Running
"/Users/damianhalloran/Library/Application\ Support/Claude/Claude\ Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP --setup"
assigns the permissions to Terminal instead of CheICalMCP.

And there is no +/- button in System Settings -> Privacy & Security -> Calendar so it can't be added manually.

I'm running macOS Tahoe 26.5 Developer Beta, with latest Claude and 1.7.2 of CheICalMCP. It worked ok in earlier versions.

Any other suggestions?
Thanks.

[z45znng7k9-star]

Have downloaded latest version and gone through troubleshooting steps with following results:

1. sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db
   "SELECT service, client, auth_value, datetime(last_modified,'unixepoch','localtime') FROM access WHERE client LIKE '%CheICalMCP%'"

Is empty

2. BINARY=$(find ~/Library/Application\ Support/Claude -name CheICalMCP 2>/dev/null | head -1)
   "$BINARY" --setup

Responds with:
_"CheICalMCP Setup — Requesting Calendar & Reminders permissions...
(This triggers macOS TCC permission dialogs for this binary)

Calendar access: ✓ granted
Reminders access: ✓ granted

If permissions were denied, grant them manually:
System Settings → Privacy & Security → Calendar → enable CheICalMCP
System Settings → Privacy & Security → Reminders → enable CheICalMCP"_

3. CheICalMCPB is not in System Settings → Privacy & Security → Calendar and there are no +/- buttons for Calendar or Reminders. Some settings here do have the buttons and some don't.

I have done a system and Claude restart.

Thanks.

[z45znng7k9-star]

Library/Application\ Support/Claude/Claude\ Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP --print-tcc-path
CheICalMCP TCC diagnostic info (1.9.0)

Binary path:
/Users/damianhalloran/Library/Application Support/Claude/Claude Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP

Bundle identifier:
com.checheng.CheICalMCP

Current EventKit authorization status:
Calendar: fullAccess (granted)
Reminders: fullAccess (granted)

Reset TCC + re-prompt (run from Terminal, NOT over SSH):
tccutil reset Calendar com.checheng.CheICalMCP
tccutil reset Reminders com.checheng.CheICalMCP
"/Users/damianhalloran/Library/Application Support/Claude/Claude Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP" --setup

Inspect TCC database directly:
sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db
"SELECT service, client, auth_value, datetime(last_modified,'unixepoch','localtime') FROM access WHERE client LIKE '%CheICalMCP%'"
(auth_value: 0=denied, 1=unknown, 2=granted, 3=limited)

System Settings (manual toggle):
System Settings → Privacy & Security → Calendar
System Settings → Privacy & Security → Reminders

Additional signing info:
codesign -dv "/Users/damianhalloran/Library/Application Support/Claude/Claude Extensions/local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP"

[kiki830621]

@z45znng7k9-star Thanks for the detailed troubleshooting log — your symptoms match exactly the Claude Desktop regression we diagnosed earlier today. Sorry for the time you sank into this — turns out it's not a setup mistake on your end and not a che-ical-mcp bug either; it's a Claude Desktop 1.6608.2 regression that needs Anthropic to fix.

How your observations map to the evidence

What you reported	What it means
"--setup from Terminal → shows ✓ granted"	Terminal-context calls use the binary's path-based TCC entry, which works fine
"--print-tcc-path shows fullAccess (granted)"	Same — Terminal context authorizationStatus sees the granted state
"But CheICalMCP isn't in System Settings → Privacy & Security → Calendar list"	Claude Desktop 1.6608.2+ shifted TCC responsible-process attribution to com.anthropic.claudefordesktop (the parent app), so System Settings now lists Claude.app instead of your binary
"No +/- buttons in Calendar / Reminders pane"	macOS 26 (Tahoe / Sequoia behaviour) doesn't allow user-driven add for Calendar / Reminders — Apple's design requires the app itself to declare NSCalendarsFullAccessUsageDescription and trigger the TCC prompt. Claude.app doesn't declare it, so there's no way to add it via the UI
"It worked OK in earlier versions"	This is the smoking gun for the regression. My logs show 94 successful .mcpb create_event calls between 2026-01-15 and 2026-04-29, then 10 consecutive denials starting 2026-05-11. The only system-level change in the 12-day gap is the Claude.app 1.6608.2 install on 2026-05-09

You and I are seeing the exact same pattern. Damian, your report is the second independent user reproduction of this regression — that strengthens the bug report a lot.

Full diagnosis + tracking

Root cause analysis, 94-vs-10 timeline, and the structural entitlement / Info.plist evidence are all written up here:

• Local tracker: PsychQuant/che-ical-mcp#132
• Upstream Anthropic bug report: anthropics/claude-code#58239 ← This is what Anthropic engineers will be looking at; your troubleshooting log is strong corroborating evidence

If you're willing, please drop a +1 / your reproduction on anthropics/claude-code#58239 — especially mentioning that you're on macOS Tahoe 26.5 Developer Beta. My machine is on the 26.0 release version, so your data confirms the regression hits both Beta and stable channels. The more independent reproductions Anthropic sees, the faster they'll prioritise.

Workarounds while we wait for Anthropic

Until Anthropic ships the fix, use any of these instead:

Path	Status	How
Claude Code plugin (recommended)	✓ Works	claude plugin install che-ical-mcp@psychquant-claude-plugins — Claude Code's spawn model doesn't go through the broken 1.6608.2 disclaimer wrapper
Legacy claude_desktop_config.json	⚠ Untested	Edit ~/Library/Application Support/Claude/claude_desktop_config.json to point at the binary directly; may bypass the broken wrapper
Google Calendar API + manual move	✓ Works	Bypass macOS Calendar entirely

The latest README now also carries a ⚠️ banner about this with the same workaround table.

Apology + thanks

Genuinely sorry for the wasted troubleshooting time. The --setup / --print-tcc-path diagnostics were designed as "TCC self-debug" tools, but they all assume "macOS TCC is doing nothing weird" — they didn't anticipate Claude Desktop itself changing responsible-process attribution. v1.10.0's startup banner added stale-process drift detection, but this specific framework-layer block is beyond what the binary can detect on its own. Once Anthropic fixes the regression, we'll revisit whether the banner can also flag "Claude Desktop wrapper is intercepting your TCC grant" — but for now there's no signal on the binary side that would catch this.

Thanks again for the very detailed report. The log helped a lot with the diagnosis.

[z45znng7k9-star]

Latest version everything is fixed. Thank you for the excellent persistence.

[kiki830621]

@z45znng7k9-star Great to hear it — thanks for circling back to confirm.

For the record, what was blocking you turned out to be two separate Claude Desktop problems stacked on top of each other, both now fixed:

• The permission-attribution regression you hit (Terminal getting the grant instead of CheICalMCP, with nothing addable in System Settings) — fixed in v1.11.0, which ships the com.apple.security.personal-information.* entitlements so macOS can rewrite the TCC row on the healing re-prompt.
• A second one that landed later: a literal & in the manifest display_name made Claude Desktop 1.18286.0 silently drop the whole server from every conversation. Fixed in v1.14.0 by changing & to and.

So "latest version" (v1.14.0) is where both fixes meet. Appreciate your patience through the long diagnosis — the detailed logs you posted were a big part of what made the root cause findable.