Personal Google Workspace / Gmail Calendar (CalDAV / Native OAuth)

Spent the majority of the day with Gemini trying to resolve an issue. Google calendar went from being fully synchronized in Thunderbird to a persistent "momentarily not available" state.

I asked Gemini to create a recap of the issue and what we tried to resolve.

Also posted in the Thunderbird sub.

—

Here is a concise summary you can paste directly into a Mozilla Bugzilla report or Thunderbird support forum post:

Environment

• OS: Windows 11 (64-bit)
• Application: Mozilla Thunderbird 154.0 (64-bit)
• Account Type: Personal Google Workspace / Gmail Calendar (CalDAV / Native OAuth)

Issue Summary Thunderbird fails to maintain a persistent connection to a primary Google Calendar via native CalDAV integration.

Upon subscribing to the primary calendar, events render successfully for a few seconds before the status updates to "momentarily not available" with a yellow warning icon. Attempts to create or modify events fail or trigger read-only status.

Note: Secondary Google calendars (including shared calendars and newly created sub-calendars under the same Google account) function perfectly with full read/write capabilities under identical network and app conditions.

Troubleshooting Steps Attempted

• Credential & Authorization Resets:
  • Deleted saved Google OAuth tokens in Thunderbird (Saved Logins) and revoked Thunderbird access in Google Account permissions to force fresh OAuth consent screens.
  • Attempted direct CalDAV server URLs (/caldav/v2/[user]/events, /caldav/v2/[user]/user, and legacy /calendar/dav/[user]/events).
  • Tested connecting using a Google App Password instead of OAuth.
• Network & Cache Cleared:
  • Flushed Windows DNS (ipconfig /flushdns) and reset the Winsock catalog.
  • Cleared Thunderbird cookies, cache, and deleted local SQLite database caches (cache.sqlite, deleted.sqlite).
  • Toggled IPv6 (network.dns.disableIPv6 = true) and HTTP/2 (network.http.spdy.enabled.http2 = false) in Thunderbird's Config Editor.
  • Changed connection settings to "No proxy."
  • Temporarily disabled local antivirus and firewall real-time HTTPS inspection.
• Isolation Testing:
  • Created a brand-new, clean Thunderbird profile (thunderbird.exe -P) with no add-ons or existing settings. Primary calendar setup produced the exact same failure.
  • Created a secondary/sub-calendar under the same Google Account on the web. Added the sub-calendar to Thunderbird; it connected immediately with full read/write access and zero dropouts.

Conclusion The failure is isolated strictly to the primary calendar identifier endpoint on the Google/Thunderbird CalDAV sync handler. Sub-calendars utilizing distinct calendar ID strings function normally within Thunderbird.