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>
3.5 KiB
| title | domain | category | tags | status | created | updated | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Fantastical MCP Server: Permission Denied on Launch (macOS Quarantine) | troubleshooting | productivity |
|
published | 2026-04-26 | 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
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:
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:
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:
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:
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:
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 |