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

3.5 KiB

Raw Blame History

title

domain

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`

3.5 KiB Raw Blame History