troubleshoot-tcc — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited troubleshoot-tcc (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill is the first thing to try when calendar / reminder tools fail. Most "calendar tools don't work" reports are TCC (Transparency, Consent & Control) state issues rather than code bugs.
User-reported symptoms that map to TCC issues:
accessDenied / insufficientAccess / unknownAuthState errorfind ~/Library/Application\ Support/Claude -name CheICalMCP 2>/dev/null | head -1Expected: a path under local.mcpb.che-cheng.che-ical-mcp/server/CheICalMCP.
If empty → .mcpb not installed in Claude Desktop. Send user to https://github.com/PsychQuant/che-ical-mcp/releases/latest
--print-tcc-path (v1.9.0+ diagnostic flag)BINARY=$(find ~/Library/Application\ Support/Claude -name CheICalMCP 2>/dev/null | head -1)
"$BINARY" --print-tcc-pathThe output is the single source of truth — read it carefully:
| Output line | Meaning |
|---|---|
Calendar: fullAccess (granted) | OK, this side is fine |
Calendar: notDetermined | Never asked → go to Step 4 (run --setup) |
Calendar: denied | Explicitly denied → go to Step 3 (reset) |
Calendar: writeOnly | Partial access (macOS 14+) → user must manually upgrade in System Settings → Privacy & Security → Calendar |
Calendar: restricted | System policy (Screen Time / MDM) — outside our control |
Same logic applies to Reminders line.
denied or post-upgrade silent fail)tccutil reset Calendar com.checheng.CheICalMCP
tccutil reset Reminders com.checheng.CheICalMCPCaveat: TCC stores.mcpbclients by binary path rather than bundle ID.tccutil reset SERVICE BUNDLE_IDmay report "Successfully reset" but actually no-op when the underlying entry is path-keyed. If the issue persists after reset + Step 4, fall back to manual System Settings toggle (Step 5).
--setup"$BINARY" --setupTwo macOS dialogs should appear (Calendar + Reminders) — user clicks Allow on both.
If running over SSH or in a non-interactive shell, dialogs cannot appear — instruct user to run this in Terminal.app directly.
System Settings → Privacy & Security → Calendar:
+, navigate to the binary path from Step 1Repeat for Reminders.
Restart Claude Desktop after granting.
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%'"Expected: 2 rows with auth_value=2 (granted) and last_modified matching today's date.
Then trigger a tool call to confirm:
list 我今天的 eventsPre-v1.9.0 binary cached the granted state in hasCalendarAccess / hasReminderAccess flags for process lifetime. After v1.9.0 the cache is removed — every tool call freshly reads EKEventStore.authorizationStatus(for:), so TCC state changes surface immediately. Per-call status check means the error you see is the current truth, not a stale cached signal — fix the TCC state, retry the tool.
If --print-tcc-path shows both fullAccess (granted) but tools still fail with accessDenied or other errors:
--print-tcc-path output + the failing tool name + arguments--print-tcc-path diagnostic flag (closed in v1.9.0)authorizationStatus(for:) recommended pattern~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.