---
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