Calendar access stays under your control.

01 / Data accessed

Google user data we access

Google authorization requests openid, email, https://www.googleapis.com/auth/calendar.events.readonly, and https://www.googleapis.com/auth/calendar.calendarlist.readonly. It also requests offline access so the local service can refresh in the background. If you separately enable editing, Flight Deck also requests https://www.googleapis.com/auth/calendar.events.owned for events on calendars you own.

The identity scopes provide the Google account identifier and email address used to label the connected account. The calendar-list scope provides calendar identifiers, names, colors, selection state, and deletion state. The events scope provides event identifiers, titles, times, all-day status, location, description, organizer, event status, meeting links, source links, and update times.

Personal Outlook.com authorization uses Microsoft's /consumers authority and requests openid, profile, offline_access, User.Read, and Calendars.Read. If you separately enable editing, Flight Deck also requests Calendars.ReadWrite.

Editing is optional for each account. Flight Deck does not send invitations, search availability, book rooms, or schedule events through a Flight Deck server.

02 / Data use

How we use Google user data

Flight Deck uses Google Calendar data only to display calendars and events, let you choose which calendars appear, select the current or nearest event, refresh the local read-only view, and open a meeting or source link when you request it.

If you enable editing, Flight Deck uses the added provider permission to create, update, copy, or delete events on calendars owned by that account. Only changes confirmed with Save are sent to the provider. Copying an event does not delete the original. Deletion requires separate confirmation.

The calendar-list scope is required to identify your calendars and support calendar visibility controls. The events scope is required to read events from those calendars. A narrower identity-only grant cannot provide either feature, and either calendar scope alone cannot provide both the calendar selector and the event views.

The developer cannot access your calendar data or tokens because the app sends neither to a Flight Deck server.

03 / Sharing

Sharing and disclosure

Flight Deck does not sell or disclose Google user data to the developer, advertisers, analytics services, or AI systems. Flight Deck does not integrate with AI services.

Your workstation communicates directly with Google and Microsoft to authorize the account, read selected calendars, refresh the local cache, and send changes that you explicitly save.

When you copy an event between Google and Outlook, the selected event fields are sent directly to the destination provider you selected. No copy passes through a Flight Deck server. The original remains unchanged unless you separately confirm its deletion.

Flight Deck Calendar's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

04 / Protection

Data protection

OAuth tokens

Flight Deck stores access and refresh tokens in the desktop Secret Service keyring under the omarchy-calendar application attribute.

Calendar cache

Flight Deck stores account identifiers and labels, calendar identifiers, names, and colors, event titles, times, locations, descriptions, organizers, status, and meeting and source links. It also stores provider event and series identifiers, revision keys, time zones, recurrence details, ownership and writability flags, attendee presence, supported meeting providers, synchronization state, and provider refresh health. The local SQLite cache is ~/.local/state/omarchy-calendar/calendar.db with private file permissions. Its parent directory is accessible only to the local user.

Network and links

Flight Deck communicates with Google and Microsoft over HTTPS. Meeting and source actions accept only HTTPS URLs returned with an event and pass each URL to the desktop opener without a shell.

Registration metadata

Bundled Google and Microsoft desktop registrations are public application metadata. They cannot grant account access without your browser consent and tokens. Local provider overrides use private file permissions.

The project does not collect, transmit, or retain calendar data on a Flight Deck server because no such server exists.

05 / Retention

Retention and deletion

Flight Deck retains Google OAuth tokens until you disconnect Google or reset local data. It retains cached Google Calendar data until a successful refresh replaces the applicable time window, you disconnect Google, or you reset local data. Flight Deck retains no Google user data on a developer-controlled server.

When a refresh fails, Flight Deck keeps the last successful local cache visible and marked stale.

Disconnecting Google or Outlook deletes that provider's OAuth tokens from Secret Service and removes its cached accounts and events immediately. It does not undo changes previously saved to the provider.

The in-app flow uses two activations: choose Reset local data, then choose Confirm reset. The terminal command calendarctl reset-local-data runs immediately when invoked.

Both paths delete all Flight Deck provider tokens, imported Google app credentials, cached events, provider health records, and local provider client-ID overrides. They preserve bundled public registration metadata and appearance settings. They do not delete or undo Google or Microsoft calendar data.

Uninstalling the plugin alone does not delete data. Run calendarctl reset-local-data first when complete local removal is wanted.

06 / This website

This website does not collect user data.

The site contains no JavaScript, analytics, cookies, tracking, forms, advertising, backend, or database. It loads its stylesheet and product image from relative paths on the same public site.

The Terms of Service describe the software license and provider boundaries.