majorwiki/05-troubleshooting/fantastical-google-phantom-calendar-syncselect.md

title	domain	category	tags	status	created	updated
Fantastical Google Sync Error Flood — Phantom Calendars Fixed via syncselect	troubleshooting	productivity	fantastical google-calendar caldav sync macos syncselect	published	2026-04-24	2026-04-24

Fantastical Google Sync Error Flood — Phantom Calendars Fixed via syncselect

Fantastical floods its macOS unified log with Google Calendar sync errors, the app shows persistent sync failures in the UI, and re-adding the Google account inside Fantastical doesn't fix it. The cause is usually orphan calendar references — calendars that were deleted from Google Calendar but still enabled in Google's per-account CalDAV sync whitelist.

The Short Answer

Visit https://www.google.com/calendar/syncselect, uncheck any calendars that no longer exist or you don't want Fantastical / Apple Calendar to try syncing, click Save. Fantastical's error flood stops within one sync cycle.

This is a per-Google-account page — completely independent of Fantastical's settings, and independent of the calendar list inside Google Calendar's main web UI.

Background

Google Calendar has three separate notions of calendar "visibility" for a given account:

Surface	What it controls
calendar.google.com main UI — calendar list in the left sidebar	What you see in Google's own web interface
calendar.google.com/calendar/u/0/r/settings/calendar/... — per-calendar settings	Sharing, notifications, access control
google.com/calendar/syncselect — sync selection	What Google exposes to third-party CalDAV/Exchange clients (Apple Calendar, Fantastical, Outlook, Thunderbird, etc.)

Fantastical talks to Google via CalDAV. It asks Google for the list of calendars enabled for CalDAV sync. If syncselect still has a calendar flagged for sync but the calendar has been deleted from Google (or unshared from you), Google returns an inconsistent response — the CalDAV principal lists the calendar ID but any request for its data returns 404. Fantastical dutifully logs an error and retries next sync cycle. Multiply by the number of orphans and you get a flood.

Deleting a calendar from Google Calendar's main UI does not automatically remove it from syncselect. That's the gotcha.

Symptoms

• Fantastical UI shows "Sync Error" or a red badge on the account
• macOS unified log filling with lines like:

  [FBGooglePrincipalSyncSession.m] Unable to find Google Calendar information:
  <calendar-id>@group.calendar.google.com in (<list of real calendars>)
  

• dataaccessd logs Error Domain=kEKAccountErrorDomain Code=0 with lastSyncStartDate = (null)
• Fantastical's helper 85C27NK92C.com.flexibits.fantastical2.mac.helper spams XPC / CoreData token errors every 3 seconds (secondary symptom when the token store gets wedged in the retry loop)

Diagnosis

Step 1 — Spot the phantom calendar IDs in the log

log show --last 5m --style compact \
  --predicate 'eventMessage CONTAINS "Unable to find Google Calendar"' 2>/dev/null \
  | grep -oE 'information: [a-zA-Z0-9._%@-]+' | sort -u

Each line returned is a calendar ID Fantastical is asking Google for that Google can't find.

Step 2 — Get calendar names from Fantastical's local DB

The orphan IDs alone look random. To match them to what the calendars were called (so you know what to uncheck in syncselect), query Fantastical's SQLite DB:

DB="$HOME/Library/Group Containers/85C27NK92C.com.flexibits.fantastical2.mac/Database/Fantastical-8.fcdata"

for id in <each-orphan-id-here>; do
  echo "--- $id ---"
  strings "$DB" 2>/dev/null | grep "$id" | head -5
done

Fantastical stores the calendar's display name near each ID in the binary form. You may see names like Kitchen Lights, Major7, or other labels that remind you what the calendar was used for — often a deleted smart-home automation trigger, an old device's dedicated calendar, a former coworker's shared calendar, a subscribed sports or holiday calendar that moved.

Step 3 — Visit syncselect

Open https://www.google.com/calendar/syncselect in the same browser you're signed in with. You'll see every calendar Google knows about for this account, with a checkbox per entry:

• ✅ Live calendars you want on devices — leave checked
• ❌ Orphans, former smart-home triggers, deleted shared calendars — uncheck
• Unsure? Cross-reference against the names from Step 2

Click Save.

Fix

1. Uncheck orphans at https://www.google.com/calendar/syncselect, click Save.
2. Let Fantastical complete one more sync cycle (or quit + relaunch for faster turnaround).
3. Verify the log is clean:

   log show --last 2m --style compact \
     --predicate 'eventMessage CONTAINS "Unable to find Google Calendar"' 2>/dev/null \
     | wc -l
   

   Should return 0.

What you should NOT do as a first attempt:

• Remove and re-add the Google account inside Fantastical. This fixes some orphans but not all — Fantastical's local event cache keeps references to calendars that have associated cached events, so orphans with historical data survive a standard account re-add. Hit syncselect first.
• Delete Fantastical's .fcdata SQLite. Nuclear, loses local cache, unnecessary for this specific issue.

Gotchas & Notes

• syncselect is per-Google-account, so if you have multiple Google accounts in Fantastical, each needs its own visit. The URL will use whichever account you're currently signed in with in the browser.
• Calendar deletion from calendar.google.com doesn't propagate to syncselect. This is a Google quirk, not a Fantastical bug.
• The same fix applies to Apple Calendar.app if it's showing the same sync errors — Fantastical and Apple Calendar use identical CalDAV plumbing via macOS's dataaccessd.
• The phantom calendar IDs will remain in Fantastical's .fcdata for a while even after the fix — Fantastical doesn't aggressively garbage-collect cached event data. This is cosmetic and doesn't re-trigger sync errors as long as syncselect no longer lists them.
• The XPC Unable to create token NSXPCConnection loop is downstream of the sync error flood — when Fantastical's helper gets wedged on repeated failed syncs, its CoreData-backed OAuth token store can't initialize cleanly. Fixing syncselect + a full Fantastical quit (menubar → Quit Fantastical, not just Cmd+Q) + relaunch clears this too.

Related

• Recap skill — uses Google Calendar MCPs that are unaffected by this issue (MCPs go through Google's API directly, not CalDAV)
• Google's syncselect URL: https://www.google.com/calendar/syncselect