majorwiki/05-troubleshooting/fantastical-mcp-permission-denied.md
majorlinux 1524ca66d5 Add 3 articles; update nav and index (2026-04-29)
New articles:
- Python smtplib: Missing Date/Message-ID Headers Break Mail Clients
- Fantastical MCP: Permission Denied (macOS Quarantine)
- Ubuntu dist-upgrade Repo Quarantine

Updated: troubleshooting index, SUMMARY.md nav, WOL article edits.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-29 22:45:17 -04:00

98 lines
3.5 KiB
Markdown

---
title: "Fantastical MCP Server: Permission Denied on Launch (macOS Quarantine)"
domain: troubleshooting
category: productivity
tags: [fantastical, mcp, claude, macos, gatekeeper, quarantine, cowork]
status: published
created: 2026-04-26
updated: 2026-04-26
---
# Fantastical MCP Server: Permission Denied on Launch (macOS Quarantine)
Fantastical's MCP server fails to connect in Claude/Cowork with a `Server disconnected` error and no dialog or prompt to explain why. The binary is installed but macOS Gatekeeper silently blocks it from executing.
## The Short Answer
```bash
xattr -d com.apple.quarantine "/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app"
```
Fully quit and reopen Cowork. Fantastical MCP reconnects cleanly.
If the quarantine attribute isn't present, also try setting the executable bit:
```bash
chmod +x "/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app/Contents/MacOS/FantasticalMCP"
```
## Why This Happens
macOS automatically tags downloaded files with a `com.apple.quarantine` extended attribute. When you launch an app yourself, macOS shows a Gatekeeper dialog — click Open, and the quarantine flag is cleared. But the FantasticalMCP binary is never launched by the user directly; Claude/Cowork spawns it as a subprocess. There's no dialog, and Gatekeeper just returns `Permission denied`. Claude sees the process die immediately and logs `Server disconnected`.
This recurs after any Fantastical update that replaces the MCP binary — the new binary comes in quarantined again.
## Diagnosis
The log tells the whole story. Check:
```bash
tail -n 50 ~/Library/Logs/Claude/mcp-server-Fantastical.log
```
If you see this sequence, it's the quarantine issue:
```
Server started and connected successfully
Failed to spawn process: Permission denied
Server transport closed
Server disconnected.
```
## Full Fix
**Step 1 — Remove the quarantine flag:**
```bash
xattr -d com.apple.quarantine \
"/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app"
```
**Step 2 — Verify the attribute is gone:**
```bash
xattr "/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app"
```
Should return empty or only non-quarantine attributes. If `com.apple.quarantine` is still listed, re-run step 1.
**Step 3 — Fully quit and reopen Cowork:**
Cmd+Q (not just close the window). Closing the window leaves the MCP host process running — it won't retry the failed server until the app fully relaunches.
**Step 4 — Verify connection:**
Check the log again:
```bash
tail -n 10 ~/Library/Logs/Claude/mcp-server-Fantastical.log
```
You should see `Server started and connected successfully` with no `Permission denied` line following it.
## After a Fantastical Update
If this breaks again after Fantastical auto-updates, re-run the `xattr -d` command from Step 1. The update replaces the binary and macOS re-quarantines the new one.
## MCP Log Locations
| Log | Path |
|-----|------|
| Fantastical MCP | `~/Library/Logs/Claude/mcp-server-Fantastical.log` |
| All MCP servers | `~/Library/Logs/Claude/mcp*.log` |
| Combined MCP log | `~/Library/Logs/Claude/mcp.log` |
## Related
- [[Fantastical Google Sync Error Flood — Phantom Calendars Fixed via syncselect]]
- MCP debugging docs: https://modelcontextprotocol.io/docs/tools/debugging