Network Disclosure

Always

Settings → Updates has two switches, and they are independent:

• Check for updates automatically. Off means the app never asks about new versions on its own; the "Check for Updates" button still works whenever you want it. It is on by default, because an app holding recordings you can't afford to lose is one where a silently un-updatable install is its own risk — but it is your call, not ours.
• Send anonymous usage data. On by default. Off means the request carries nothing but the request itself. It is what tells us how many installs are active.

With update checks off and usage data on, the daily request still happens — it goes to updates.samuraiscribe.com/ping, carries the same handful of fields, and fetches no release. Turning off update checks usually means "stop telling me about new versions", not "stop counting me", and we would rather honour each switch than guess that one implies the other. Turn both off and the app makes no background request at all, apart from the licence check below if you have activated Pro, once the three core models above are on disk.

A check that fails — or that reaches only GitHub, because updates.samuraiscribe.com did not answer — is tried again an hour later rather than the next day, for as long as the app is open: an outage would otherwise look like every install stopping at once.

The five fields are the whole of it, with one flag: pressing Check for Updates in Settings sends them marked forced=1, so that pressing the button is not counted as another day's use. Install week is the calendar week you first ran the app, which every install from that week shares — it tells us whether people stay, not who you are. The tier is one of three values — free, trial or pro — and says only which of the three you are on today: pro means a paid licence, which your licence check already tells us, and trial means the ten days of Pro that new installs of versions 0.61 to 0.64 started with (none starts since 0.65, so it only appears until such a trial ends). It carries no dates. Activation is a single number — 0 if you haven't transcribed anything yet, 1 once you have a transcript, 2 once you also have a summary — so we can tell a download that never worked from one that did. It never goes back down, and it says nothing about what is in your meetings, how many you have, or when you recorded them.

Here is the whole daily request from a free install on a Mac, first run in week 43 of 2026, that has a transcript and a summary:

GET https://updates.samuraiscribe.com/latest?v=0.64.1&os=macos&tier=free&install_week=2026-W43&activation=2
Accept: application/vnd.github.v3+json
User-Agent: SamuraiScribe-UpdateChecker/1.0

Those two headers are the app's own; the rest are the ones every web request carries, such as Host. On Windows, os reads windows. With usage data off it is the same address with nothing after /latest. On the beta channel the path is /list, and with update checks off it is /ping. If updates.samuraiscribe.com does not answer, the check goes to api.github.com instead, with none of the fields.

The licence check is how a Pro licence stays valid. It runs only if you have activated a licence — on the free tier there is nothing to check, so it never happens at all. Precisely: on app launch, but only if the last check was more than 12 hours ago, plus every 24–48 hours if you leave the app running. Launching the app repeatedly in a day does not repeat the check.

It carries no information about your meetings. It also isn't only a check on you: the app keeps working offline for 30 days between successful checks, and each successful check resets that window, so it's what stops a paid licence lapsing while you're travelling or offline.

The update check exists so we can tell how many installs are working. GitHub reports how many people downloaded the app; this reports how many still run it. The gap between those two numbers is our onboarding failure rate, and it is the only thing we measure. No per-install identifier is sent, ever — there is no id, no cookie, no device fingerprint, and nothing that could be used to follow one install from one day to the next.

If you click a download button on this website, that link passes through updates.samuraiscribe.com before redirecting to GitHub, which records the platform and which link you came from, plus the country Cloudflare sees for any web request. If you arrived through one of our tagged links (?ref=…), the page also sends one landing record per browser tab, with the tag, your operating system and that country. Both record two facts about the request itself, so that crawlers and email scanners can be counted apart from people: whether it came from a page on this site (your browser's own Sec-Fetch-Site header), and whether it looks automated — a headless browser, a declared bot or link previewer, or a cloud server. That second one is kept as a single word; the browser details and network it was worked out from are not stored. These are one-off website requests, not something the app does.

The four addresses on this page that are ours — updates., models., hub. and support.samuraiscribe.com — run on Cloudflare Workers, with Cloudflare's Workers Logs switched on for all four. Cloudflare records each request to them — its method and full address (for the update check, that includes the usage fields above), with the details Cloudflare attaches to every request it serves — and keeps the record for up to seven days, for finding out why something broke.

Only if you turn them on

The downloader never runs or checks for updates by itself: yt-dlp is started with --no-update, and its JavaScript runtime with its own update check disabled. The "once a day" check above only happens because you pressed Import.

The "What's New" window shown after an update makes no request of its own: those notes were already downloaded alongside the update itself. Only opening the full release history from Settings fetches anything.

Calendar data is fetched to your machine and cached there. The Mac Calendar connection (macOS) makes no request of its own: it reads the calendars macOS already has, and whatever syncs them (iCloud, Google, Exchange) is macOS's doing. Calendar data is never sent to us, and its event titles, attendees and accounts are kept out of the logs. Refresh tokens and ICS URLs are encrypted with a key tied to this computer and kept in your OS keychain, with an encrypted copy in the app's own data folder; never in your vault.

Reporting a bug, and testimonials

Settings → Support → Report a bug opens a form. Nothing is sent until you press Send report. It then goes to support.samuraiscribe.com, which files it as an issue in Samurai Scribe's private GitHub repository, read only by the developer. What you typed and your reply address are in the issue itself. The troubleshooting file below waits in Cloudflare's storage until the report is looked at, then moves onto the issue; one that is never looked at is deleted after 30 days.

What goes with a report travels as one troubleshooting file. See what's included saves that exact file and shows it to you before you decide; Send then uploads those same bytes. Logs record what the app did, and personal details are taken out of them: as they are written, meeting titles, people's names, calendar event titles and accounts, email addresses and the names of your files are replaced by placeholders such as <meeting 3f2a91c0, 31 chars>, and a meeting's folder in a path by the same; as the troubleshooting file is built, your home folder, user name and your name in a device's name ("…'s AirPods") go too. The file's first page, report.txt, says how many of each were taken out. Logs written before version 0.63.0, which named these things, are deleted when 0.63.0 first starts and never included. Meeting text is written to a separate file per meeting, which goes only with the meeting you pick, as it is. The file is kept with the issue it belongs to and deleted if you ask at support@samuraiscribe.com — except a meeting's text, which is read to find the problem, then deleted, and never kept with the issue.

If sending does not work, the form offers Save and email instead: the file is saved and shown to you, and a draft opens in your own mail app. Nothing then leaves your computer until you send that email. Licensed users can send a testimonial from the same place; it is quoted on this site only if you tick the box allowing it.

Contributing recordings

Settings → Support → Contribute recordings (or Contribute… with meetings selected in the sidebar) opens a form for sending meetings to help test and improve transcription and speaker detection. Nothing is sent until you tick that everyone who speaks in them agreed, and press Send. The meetings then go to support.samuraiscribe.com in pieces and are kept there, in storage only the developer can read; an issue in Samurai Scribe's private GitHub repository says that they arrived, with nothing from them in it.

The logs and setup travel as one file, support.zip, beside the meetings — the same troubleshooting file a bug report sends, without any meeting's text. They are read when the recordings are added to the test set, to explain how a take came out (a slow processor, audio the live transcript dropped, echo), and then deleted: they are never kept with the recordings. The setup describes the computer you send from, which may not be the one that recorded every meeting.

The app builds the package on this computer first; See what's included shows you its folder before you send. The recordings are kept to test future versions of the app — they become part of the recordings each change is measured against — and are deleted if you ask at support@samuraiscribe.com. Your reply address is used for replying and nothing else. A send you stop, or one that fails, deletes whatever had arrived; one left unfinished (the app quit mid-send, say) is deleted by the intake, your address with it, two days after it started.

AI apps you connect

Settings → AI Apps shows how to connect Claude Code, Claude Desktop, Codex, Gemini CLI or Cursor to your meetings. Connecting one makes no network request from Samurai Scribe: the app you connected starts a small helper on this computer (Samurai Scribe Helper --mcp), which reads your meetings, notes and upcoming calendar meetings from the running app over 127.0.0.1 and hands them to that app.

What happens next is that app's business, not ours. Claude Desktop, Claude Code, Codex, Gemini CLI and Cursor send what they read to their own AI service, under their own privacy terms — so a meeting an AI app reads leaves your computer through that app, the same as if you pasted it in yourself. Nothing is read until you ask the app something, and an app you never connect can read nothing: the helper needs a key that changes every time Samurai Scribe starts and that only your user account can read. Folder rules in Settings decide what a connected app can see and change.

Connections you add (beta)

Skills → Connections lets the assistant and your skills use another service's tools — Linear, Notion, Jira and Confluence, Todoist, monday.com, ClickUp, Attio, or an address you enter yourself. Each is that service's own MCP server, run by the service; nothing is downloaded or installed. Until you connect one, nothing here makes a request.

A connection is offered to a chat only when you add it to that chat, when a skill you run needs it, or when you switch on "offer in every chat" for it. An automation running a skill by itself (Pro) can use a tool that changes something only if you set that tool to Allow in automatic runs; otherwise the call waits for you. What you send to a service is then held under that service's terms. Sign-in tokens are kept in your operating system's keychain, sealed to this computer, and sent only to their own service.

Email is not a connection. When the assistant drafts an email, the draft stays in the app until you click Open in Mail or Open in Gmail: the first hands it to your own mail app, the second opens Gmail's compose page in your browser with it filled in. You send it from there, if you do. Samurai Scribe never connects to your mailbox and sends nothing itself.

A cloud model — only if you choose one

Every writing task in Samurai Scribe — meeting summaries and the skills a processing profile runs, dictation polish, and the assistant — runs on a model on this computer by default: the built-in model, your own Ollama, or LM Studio. Nothing it reads leaves your computer.

Ollama is on this computer unless you have pointed OLLAMA_HOST at another one. Then what an Ollama model works on goes to that computer, over your network, and the app treats Ollama as it treats a cloud provider: it is marked as one, choosing it for a task first says what that task will send, and it is sent images only with "Let cloud models read images" on.

You can choose a cloud model for any of them instead — Anthropic, OpenAI, Google Gemini, OpenRouter, or an address you enter yourself, which must use https unless it is on this computer or your own network, as set out below (Settings → AI Models; a cloud model is marked as one everywhere it is shown, and the first time you pick one the app tells you what will be sent and to whom). Then what that task works on goes to that provider, and nowhere else, using the API key you gave, under that provider's terms. Your audio never does: transcription always runs on this computer.

A skill one of your automations runs by itself (after meetings, on a schedule, or before calendar meetings) uses the assistant's model, so with a cloud model chosen its instructions and what it reads go to that provider too. A skill run before a calendar meeting — by itself, or by you choosing that meeting — is also given the meeting's title and time, the names and email addresses of the people invited, its organizer, and the first 1,500 characters of its calendar description.

A question you ask the assistant about a meeting while it is being recorded (Pro) carries what was said most recently and your notes for that meeting so far, as text from the subtitles. With a cloud model chosen for the assistant, those go to its provider with your question — when you ask, and never otherwise. If you turn on Keep running notes during meetings (Settings → Meetings, off by default), the assistant's model is also given the meeting's subtitles every few minutes while it records; with a cloud model chosen, those go to its provider as the meeting goes. Your audio still does not leave your computer.

Images in a meeting — attached to it, pasted into its notes, or inside an attached deck, document or PDF — are read on this computer, by the built-in model, your own Ollama or LM Studio. With a cloud model chosen for summaries, only the text read out of them goes with the documents above, and the images themselves stay on your computer — unless you turn on "Let cloud models read images" (Settings → AI Models, off by default, and it asks first). Then the summary model's provider is sent each image once, to read it.

A picture's reading stays on this computer, deleted 30 days after it was made, and never syncs with the vault. Read again and Read with… (on a picture's chip, in a chat, or in Files) read it on request. Read again sends it only where a summary would. Read with… a cloud model, while "Let cloud models read images" is off, asks first and sends that picture alone.

An address you enter yourself must start with https://, unless the server is on this computer or on your own network. Plain http:// is accepted for a private address (192.168.x.x, 10.x.x.x, 172.16–31.x.x, and 100.64–127.x.x, the range Tailscale hands out, which some internet and mobile providers also use), a link-local address (169.254.x.x, IPv6 fe80::) or an IPv6 unique-local one (fc00::–fdff::), or a name only a local network resolves (one ending in .local, .lan, .home.arpa or .internal, or a machine name with no dot). What is sent to such a server, and the key, crosses that network unencrypted. Settings says so under the address.

The address is checked once, when you save it, and then trusted on whatever network your computer joins. On a café, hotel or office Wi-Fi, the same address may be someone else's machine, and a summary run there, including one that runs by itself after a meeting, would send the meeting's text and the key to it. Before running meetings away from the server's network, switch to a model on this computer or a cloud provider over https://, or reach the server through Tailscale or https://. The same holds for Ollama or LM Studio on another computer. On macOS 15 and later, the first connection to a server on your network may ask for Local Network access.

Your API keys are stored in your operating system's keychain, sealed to this computer, and are sent only to their own provider.

Local only (never leaves your machine)

What runs without you asking

Three things, all listed above: the daily update check; the daily licence check, only if you have activated a Pro licence; and, each time the app starts while one is missing, the download of the three small models every transcription needs. The update check and its usage data can each be switched off in Settings → Updates; the licence check can't, but it only exists once you activate Pro. Between them the first two send the usage fields described above, and (if licensed) your licence key and this computer's activation id.

The ten-day Pro trial that versions 0.61 to 0.64 gave new installs sends nothing of its own, and none starts since 0.65. A trial's start and end dates are kept on this computer, beside the licence. The only trace of it anywhere else is the update check's tier reading trial while it runs — and only with usage data on.

Everything else is either a one-time action you trigger yourself (downloading a model, activating a licence, importing a link, sending a bug report or contributing recordings) or a feature you opted into: calendar sync; an automation running a skill by itself, or running meeting notes, with a cloud model chosen for the assistant; and an automation using a connection's tool you allowed in automatic runs. If you never connect a calendar, never activate a licence and keep the assistant on a model on this computer, the update check is the only request the app ever makes on its own, once the three core models are on disk.

Verifying this

The claim above is worth checking rather than trusting:

1. Open Little Snitch (macOS) or Wireshark, filtering on the app.
2. Record and process a full meeting, on local models.
3. Confirm nothing leaves the machine.

If you find a request that isn't on this page, that's a bug — please report it.