Read-only by design: how Shipnote treats your code

Connecting a tool to your Git provider is a real trust decision. So let’s be precise about what Shipnote can and can’t do with that access, because the answer is deliberately boring.

Read-only, always

Shipnote never requests write access. It cannot push commits, open pull requests, change settings or delete anything. We ask you to create a fine-grained, read-only token scoped to just the repos you want to announce, and that’s all the access that exists. There is no “write” code path to worry about, because there’s no write permission to begin with.

We don’t read your source code

To write a release note, Shipnote needs to know what changed, not how it’s implemented. So it reads commit messages, pull-request titles and tags. It does not fetch, store or send your source files to the AI. Your actual code never leaves your repository.

What we store, and where

Access tokens are encrypted at rest. We keep the metadata needed to generate and show your announcements, versions, the change summaries, and the copy you generate, and nothing else about your codebase. Disconnect a provider and Shipnote can no longer read a thing.

Boring on purpose

Great security tooling is unremarkable: least privilege, no surprising powers, nothing sensitive held that doesn’t need to be. Shipnote reads the story of your changes and writes it up for your users. That’s the whole job, and the boundaries are the point.