Skip to content

Fantastical MCP Server: Permission Denied on Launch (macOS)

Fantastical's MCP server fails to connect in Claude Desktop/Cowork with a Server disconnected error and no dialog or prompt to explain why. The FantasticalMCP binary is installed but macOS refuses to exec() it, returning Permission denied.

There are two distinct causes that produce the identical log signature — check which one applies before reaching for a fix:

  1. Quarantine (Gatekeeper) — com.apple.quarantine xattr blocks execution. Original cause, 2026-04-26.
  2. Missing execute bit — an extension update rewrites the binary as mode 0600 (rw-------, no +x). exec() on a non-executable file returns EACCES = Permission denied. Observed 2026-07-15 on MajorMac; no quarantine attribute was present, so xattr -d would have been a no-op — only chmod +x fixed it.

The Short Answer

Run the diagnosis below to see which cause applies, then run the matching fix. When unsure, both commands are safe to run together:

BIN="/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app"
# Cause 1 — quarantine (no-op if attr absent):
xattr -d com.apple.quarantine "$BIN" 2>/dev/null
# Cause 2 — missing execute bit:
chmod +x "$BIN/Contents/MacOS/FantasticalMCP"

Then fully quit and reopen Claude Desktop/Cowork (Cmd+Q). Fantastical MCP reconnects cleanly.

Why This Happens

Cause 1 — quarantine. macOS tags downloaded files with a com.apple.quarantine extended attribute. When you launch an app yourself, Gatekeeper shows a dialog — click Open and the flag clears. But the FantasticalMCP binary is never launched directly; Claude spawns it as a subprocess. There's no dialog, Gatekeeper returns Permission denied, and Claude logs Server disconnected.

Cause 2 — missing execute bit. A Fantastical/extension update replaces the binary in place. On 2026-07-15 the replacement landed as mode 0600 (-rw-------) with the execute bit stripped. exec() on a file with no execute permission fails with EACCES, which surfaces as the same Failed to spawn process: Permission denied. The codesign stays valid (codesign --verify passes) — it's purely a filesystem-permission problem, not a signing or Gatekeeper one. This has now recurred across machines — MajorMac on 2026-07-15 and MajorAir on 2026-07-16 (both after the Jul 14 extension reinstall stamped the binary Jul 14 23:43) — so it is a systemic extension-packaging bug, not a one-off. Worth reporting to Flexibits.

Both causes recur after any Fantastical update that replaces the MCP binary.

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 one of the two Permission denied causes:

Server started and connected successfully
Failed to spawn process: Permission denied
Server transport closed
Server disconnected.

The connected successfully line is misleading

The wrapper logs Server started and connected successfully optimistically, before it actually spawns the child binary. The real failure is the Failed to spawn process line immediately after it — ignore the "success" line.

Distinguish the two causes:

BIN="/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app/Contents/MacOS/FantasticalMCP"
ls -l@ "$BIN"      # no 'x' in the mode (e.g. -rw-------) → Cause 2, missing execute bit
xattr "$BIN"       # lists com.apple.quarantine → Cause 1, quarantine

If the mode shows no x and xattr shows only com.apple.provenance (no quarantine), it is the execute-bit case — chmod +x, not xattr -d.

Full Fix

Step 1 — Apply the fix for the cause you identified above (running both is safe):

BIN="/Users/majorlinux/Library/Application Support/Claude/Claude Extensions/ant.dir.gh.flexibits.fantastical-mcp/server/FantasticalMCP.app"
# Cause 1 — remove the quarantine flag:
xattr -d com.apple.quarantine "$BIN"
# Cause 2 — restore the execute bit:
chmod +x "$BIN/Contents/MacOS/FantasticalMCP"

Step 2 — Verify:

# quarantine gone:
xattr "$BIN"                              # empty / no com.apple.quarantine
# execute bit present + signature intact:
ls -l "$BIN/Contents/MacOS/FantasticalMCP"   # mode should include 'x' (e.g. -rwx--x--x)
codesign --verify --verbose=1 "$BIN/Contents/MacOS/FantasticalMCP"  # "satisfies its Designated Requirement"

Step 3 — Fully quit and reopen Claude Desktop/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 or the extension auto-updates, re-run both Step 1 commands. Each update replaces the binary in place, and the new copy may arrive re-quarantined (Cause 1) or stripped of its execute bit (Cause 2) — the 2026-07-15 (MajorMac) and 2026-07-16 (MajorAir) recurrences were both the latter, with no quarantine present at all — only com.apple.provenance.

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