Privacy Policy — Dispatch

Effective 2 September 2026. Supersedes the version of 31 August 2026. What changed: Dispatch now finds a meeting's document through your calendar rather than by searching your Drive, so it asks for one permission instead of two and no longer requests any access to Google Drive whatsoever. This page also now describes the calendar feed, which the earlier version did not mention.

Dispatch is an open-source plugin for Obsidian, published under the MIT licence by Kai Mysliwiec. This policy explains what data Dispatch touches, where that data goes, and what the developer can and cannot see.

The short version#

Dispatch has no server. There is no account to create, no backend to sign in to, and no service operated by the developer. Everything Dispatch does happens on your own computer, against files you already have. The developer receives no data from you of any kind — not your notes, not your Google data, not usage statistics, not crash reports.

What Dispatch is#

Dispatch renders your Obsidian notes as project boards and launches command-line AI coding agents from them. It reads and writes the markdown files in your own vault, and it runs programs you have configured on your own machine. It does not transmit your notes anywhere.

Google account data#

One optional feature connects to Google. When you use Dispatch's meeting-transcript import, a script running on your computer asks Google for permission to read the Google Doc that Gemini wrote for a meeting — and nothing else.

What we request, and why#

Scope	What it grants	Why Dispatch asks
`https://www.googleapis.com/auth/documents.readonly`	Read-only access to your Google Docs	To read the meeting document. This is the only permission Dispatch ever asks for

It is read-only, and it is the whole list. Dispatch requests no permission to modify, create or delete anything, and no access to your Google Drive at all — not drive.readonly, which would expose every file you own, and not the narrower Meet-files scope either. It cannot list, search or browse your Drive, because it never asks to.

Which document to fetch comes from your calendar, not from searching your Drive. If you have given Dispatch your calendar's secret iCal address for its Meetings view, each event in that feed already carries a link to its own Gemini document. So the normal path asks Google for one permission only — reading a document whose address it was handed.

Being straightforward about what that one scope covers, because it is broader than it sounds: Google grants document-reading permission per application, not per file, so documents.readonly technically covers all of your Google Docs, not only the meeting ones. Dispatch only ever requests the specific document your calendar pointed at, but the permission you grant is the wider one, and you should know that before granting it.

What the script does with it#

Fetches your calendar feed — see below — and finds the event for the meeting you named, by date. Google attaches each meeting's Gemini document to its own calendar event, so this is what identifies the document.
Asks the Google Docs API for that one document, by its id.
Writes it into a folder inside your own Obsidian vault as Markdown — the Gemini summary and, when the meeting was transcribed, the transcript that Google appends to it.

That is the entire flow. The content of your meetings is read from Google and written to your disk. It is not sent anywhere else, and no copy is retained outside your vault.

Your calendar feed#

The Meetings view can show upcoming events if you give Dispatch the secret iCal address of a Google Calendar (Settings → your calendar → Integrate calendar → Secret address in iCal format). It is optional, and Dispatch does nothing with calendars unless you provide it.

That address is itself a credential — anyone holding it can read that calendar — so it is stored with your other device settings, outside your vault, and never syncs. Dispatch fetches the feed read-only, directly from Google, and it is the transcript import's normal route to a document: the feed already names it, so nothing has to search your Drive. Nobody but you and Google sees the feed or its contents.

Where your credentials are stored#

Your OAuth client ID, client secret and refresh token are stored with Dispatch's other per-vault settings, in a plain file under ~/.dispatch/ on your own computer — outside your vault, so that they are never picked up by Obsidian Sync, Google Drive, git, or any other sync mechanism that might carry your vault to another machine or another person. Your calendar's secret address lives in the same file.

These credentials are transmitted only to Google's own endpoints, over HTTPS, to obtain and use an access token and to read the calendar feed. They are sent to no one else.

What the developer receives#

Nothing. The developer operates no server, collects no telemetry, and has no technical means of accessing your Google account, your Drive files, your meeting content or your vault.

Limited Use#

Concretely, and as a restatement of what the section above already describes: data obtained through these scopes is used solely to provide the meeting-import feature you invoked. It is not transferred to anyone, not used for advertising, not used to train any model, and not read by any human other than you.

Data Dispatch does not collect#

No analytics, telemetry or usage statistics.
No crash or error reporting.
No advertising identifiers, cookies or tracking of any kind.
No account, email address or personal profile.
No network requests at all, except the Google calls described above — your calendar feed and the meeting documents — and any made by the agent programs you yourself configure and launch.

Third parties#

Dispatch shares your data with no third party, because it sends your data to no one. The only external service it contacts is Google, on your instruction, using your own credentials.

Note that Dispatch launches command-line programs you configure — for example Claude Code or Codex. Those programs are not part of Dispatch and are governed by their own terms and privacy policies. What they send, and to whom, is between you and their providers.

Retention and deletion#

Because nothing is stored on a server, there is nothing for the developer to delete.

Downloaded meeting content stays in your vault until you delete the files.
Your stored credentials — the OAuth tokens and your calendar's secret address — stay in that vault's settings file under ~/.dispatch/ until you delete them. Clearing the calendar URL in Dispatch's settings removes it from the file.
Dispatch's access to your Google account can be revoked at any time at myaccount.google.com/permissions. Revoking takes effect immediately; the stored refresh token stops working, and Dispatch will report that re-authorisation is needed.

Deleting the plugin removes it entirely; the credential file is separate and should be deleted by hand if you want it gone.

Security#

Credentials are stored unencrypted in a file in your home directory, protected by your operating system's own file permissions and by whatever disk encryption you have enabled. This is the same posture as most command-line developer tooling. Anyone with access to your user account on your computer can read that file, so treat it as you would an SSH key.

Children#

Dispatch is a developer tool. It is not directed at children and collects no data from anyone.

Changes to this policy#

Changes are published on this page with a new effective date. Because Dispatch is open-source, every revision is visible in the project's public history.

Contact#

Kai Mysliwiec — kai@eightnine.de Project: github.com/kaimys/obsidian-dispatch