Privacy policy

Effective 2026-08-17. Updated 2026-10-20. Mossbear is in private beta.

The entity that operates Mossbear is being formed and is not yet named here. The practices below describe what the software actually does today, which does not depend on that filing — but if you need a named data controller before entrusting anything to it, ask before signing up.

What Mossbear syncs

Enumerated rather than summarised, because a summary of this list was wrong once: the CLI’s npm page said it synced “only action metadata” until 2026-08-22, and classes 4 and 5 below are why that was false. The list follows what the CLI can put on the wire, category by category.

1. Account information — who you are and which workspace you belong to.
2. Action metadata — the type of each tool call, a one-line summary, and the file paths touched.
3. Rule-file manifests — which guide files a repo has on disk, as paths and content hashes. Never their contents.
4. Content you choose to upload. Linking guidance sends the selected guide files, including supported files belonging to a selected skill. Context you capture also syncs. Two paths upload without a separate command. The first: in a repo subscribed to a document bundle, mossbear complete at the end of a session pushes back any subscribed document you edited locally, as a new version, even with --no-actions. It blocks push-back when another session has logged recent activity in that checkout, or the bundle does not allow the repo to write. By default, conflicting server edits are left for you to resolve. Documents you have not edited are not sent. The second is controlled by the repo config, not by a prompt: if the config has a published block that declares paths, the CLI uploads those paths automatically from the repo’s published branch (published.branch, default main) whenever a session hook sees that branch has moved. It sends the branch’s committed contents, never your working copy or the branch you have checked out, and it never fetches: it reads only what your clone already has. Other sync uploads are unaffected. Without a published block that declares paths nothing is published this way, and only the declared paths are sent.
5. Redacted excerpts of your session’s turns. A prose-redacted, length-capped excerpt of the user and assistant turns in a session reaches the server, where it is shown as evidence beside a verdict. The CLI does not derive guide suggestions from your transcript. The server uses these excerpts in one way besides grading: when a guide keeps failing in your sessions, it sends the guide’s text and the grader’s reasons for those failures to a model, to draft a finding about what goes wrong in it. It also reviews each of your skills once per version, with no session evidence: it sends the skill’s text, measurements of its files (line counts, links between them), the MCP tool names its files mention, and the names and descriptions of your other skills to a model, to draft findings against Mossbear’s skill-authoring rubric. The server also drafts from how your agents use a skill, and that draft reads no excerpt: when sessions that loaded a skill never open one of its reference files, or open it after nearly every load, it sends the skill’s SKILL.md, the paths of the skill’s files, and counts of loads, sessions and reads for each reference. No reference’s text and no session content is sent. When drafting from your corrections, the server also sends the grader’s notes on where an agent’s closing summary contradicted its recorded actions, with that summary’s quoted words and any replies you wrote under those notes. A draft is a finding: a comment on that guide that says what goes wrong and carries no replacement text. It changes nothing, and reaches no agent, until you hand it to your agent, which writes the fix, and you can stop drafting in Settings → Privacy and data. This is the most sensitive class on the list, which is why it is named rather than folded into “metadata”.
6. Evaluation verdicts and session metadata — the grading results and the sessions they belong to.
7. Token counts and session usage, read from your transcripts locally, including how many tokens each skill cost to load (skill name, model and counts, no content).
8. Where your session ended — when a session closes, the commit SHA and branch the checkout stood on, never the code, a diff or a commit message. Absent outside a git repo.
9. Your agent’s closing summary — when a session closes, the prose of the agent’s final message, redacted the same way as the excerpts in class 5. Absent when narration is switched off for the repo or the agent said nothing.
10. CLI connection state — your CLI version, which agent sessions have finished, and whether a sync came from a session hook rather than a typed command.
11. Legacy feedback submissions, from older CLI releases only — a CLI release that predates retiring command-derived workflow uploads still sends a short signal describing a repeated command, with a type, confidence and count. The server accepts these and discards them without storing them. Current releases send none. This entry stays until the field leaves the sync request.

What stays local

Full raw transcript files stay on your machine during session sync. Mossbear reads them locally to produce the redacted excerpts and session usage data described above. It excludes tool-result bodies and removes fenced and indented code blocks from those excerpts. Code or diff text written outside those blocks can remain in an excerpt after redaction.

The CLI holds no model credentials and produces no verdict of its own. Grading runs on the server, from the list above. You can also inspect the sync disclosure in the product at Settings → What syncs.

Run mossbear narration off in a repository to stop preparing new transcript excerpts, user turns and closing summaries there. Pending user turns from that repository are discarded, and switching collection back on does not restore them. Older queued turns without repository identity are discarded before delivery. An upload already started cannot be recalled. Update the CLI before relying on queued-turn deletion. This does not delete content already synced to your account, and action metadata and selected content uploads are unaffected.

What we don’t do with your data

We do not sell your data, and we do not share it for advertising or cross-context behavioral profiling. The service providers below process it to run Mossbear, under contract and for nothing else; nobody else receives it.

The data is yours, not ours — a property of how Mossbear is built more than a promise it makes. Your guides and documents are ordinary files on your own machine, and everything the account holds you can export or delete yourself, without asking us.

Service providers

• Fly.io hosts the application and database infrastructure.
• Cloudflare stores the nightly database backups, encrypted before they leave our servers with a key that is never kept on them.
• OpenRouter and OpenAI may process guide and evaluation context, including when drafting findings about a guide.
• Resend sends transactional email.
• PostHog provides product analytics and error tracking.
• GitHub provides OAuth login if you choose to sign in with it.

Model processing through OpenRouter

For model requests through OpenRouter, including grading and drafting, Mossbear requires endpoints with no-training and zero-data-retention policies. These restrictions also apply to fallback endpoints. If no eligible endpoint is available, the request fails rather than dropping the restrictions.

Our OpenRouter account requires zero-data-retention routing for every model group. Training, public prompt publishing, and the data-use discount are disabled. Prompt and response logging is disabled, and observability does not export their content. These settings and synthetic grading and drafting requests were checked on October 5, 2026.

These protections concern model processing through OpenRouter. They do not delete the evidence, guidance or generated findings stored in your Mossbear account; the retention and deletion terms below still apply. Direct OpenAI-compatible connections are outside this OpenRouter policy.

OpenRouter retains usage metadata, such as token counts and costs. Its zero-data-retention policy also permits temporary in-memory prompt caching. Zero data retention does not mean that no temporary copy exists during processing.

Analytics

Website and product analytics are cookieless and anonymous by default. Website analytics measure page views, traffic sources, load performance, signup clicks, and install-command copies. Website identity stays in memory and is not carried between full page loads. Website tracking excludes session replay and automatic click or form capture. We remove query strings and fragments from URL fields sent with analytics events. Persistent, identified analytics run only after you opt in. Server-side error reporting runs regardless, to keep the service working — it records what failed, not what you were writing.

Retention and your rights

We keep account and product data while your account is active or as needed for security, operations, and legal obligations. You can export your data as a JSON download from Settings → Export my data, or permanently delete your account and all its data from Settings → Delete account. Both are self-serve and take effect immediately — you do not have to ask us. Deleted data also sits in our encrypted nightly backups until they expire, so it is fully gone from those within 30 days.

If you are in the EU, UK, or California, you have further rights — access, correction, portability, objection, and complaint to your local regulator. The export and delete controls above already satisfy access, portability, and erasure. For anything else, contact us.

Contact

Beta testers were invited directly — reply on the channel you were invited through and it reaches a person, usually the same day. A published privacy address goes here when the operating entity is named.