Privacy Policy

Information we collect

Voice dictation

When enabled for your account, voice dictation sends your recording to OpenAI for transcription, including when “Send to AI” is off. MiniGrove handles audio in memory and does not store recordings. The transcript stays in your browser draft until you send it; sent text follows the ordinary shared conversation policy. OpenAI processes audio under its own API data policies.

Dictation accounting stores your account and attempt identifiers, UTC billing month, rounded duration, model, price rate, reserved cost, outcome and timestamps (including a concurrency lease). It contains no recording or transcript. Attempts expire after 90 days; monthly usage counters expire 90 days after the month ends. Hourly cleanup removes them on its next successful pass; outages can delay deletion. Account deletion removes personal accounting immediately; aggregate service spending totals contain no account identifier and remain until expiry. Uncertain requests may still count toward usage.

Dictation failure logs contain the attempt identifier, a general failure category, the provider HTTP status and a validated provider request identifier when available, without recordings, transcripts or raw provider error messages.

Your browser may remember that you acknowledged the voice disclosure, keyed by account and disclosure version. This preference contains no recording or transcript and can be removed by clearing site data.

Activity Center enrollment

Activity Center is enabled by default for new and existing accounts. You can turn it off in account settings. We store your user identifier, enrollment identifier and start time. Only enrolled accounts receive personal activity handoffs. New completions and mentions are collected from that start time; following one retained execution explicitly can also collect its earlier result.

Personal activity handoffs

Personal activity handoffs store the source and project identifiers, recipient, enrollment and membership identifiers, actor, delivery reason, outcome, timestamps, read state, and an excerpt of up to 240 characters. While enrolled, your own executions are collected automatically. Explicit activity follows record the executions or Cards you choose to follow; you can remove them from My follows. These records are independent of email notification preferences.

Turning off Activity Center restores the original homepage and removes your enrollment, personal handoffs and follows. Original project content is unaffected. If immediate cleanup fails, or a handoff commits concurrently with opt-out, the copy is immediately inaccessible and removed on the next successful hourly cleanup. Enabling again starts a new enrollment; previous personal handoffs and follows do not return.

Activity excerpts become unavailable after 30 days. Background cleanup runs hourly and removes expired copies on its next successful pass; outages can delay physical deletion. Original command transcripts remain subject to their 30-day retention. Leaving a project immediately removes access to its activity and deletes its follows. Deleting the project, source Card or machine immediately removes activity access. Deletion also clears associated activity copies; a copy committed concurrently with deletion is removed by the hourly cleanup on its next successful pass.

Account and authentication information

• Your name, email address, profile image, and email-verification status.
• Password credentials stored as one-way hashes. We do not store your plaintext password.
• Browser-session records, including session identifiers, expiration times, IP addresses, and user-agent information.
• Verification, password-reset, OAuth state, authorization-code, and PKCE records needed to complete or secure authentication flows.
• MiniGrove API-token metadata, such as a token hash and prefix, scope, creation and expiration times, revocation status, and last-used time. The complete token is returned to the client once and is not stored by the Service.

Account-owned MiniHug machines

In My machines, you can see your machine IDs and last-seen times, rename active machines, and revoke a machine credential. Revoked records remain in your account history. Revocation does not uninstall MiniHug or delete files on your computer.

• When you connect MiniHug, we store opaque machine and installation identifiers, the account that owns the machine, the name you give it, and its platform and architecture. We also store the signed MiniHug service and Kit release versions and digests, an installation identity hash, the promoted capability snapshot digest, versioned capability contracts, and bounded capability sets used to decide whether the machine may safely accept work.
• Machine credential and continuity metadata includes a one-way machine-token hash, a display-only credential prefix, a one-way receipt-store identity hash, a one-way supervisor-boot identity hash, token, execution-eligibility, Kit-inventory, and account-purge generations, and account-purge state. The Service does not store the complete machine token in the ordinary machine record.
• Bounded machine-registration replay receipts store the enrollment grant, account, installation, machine and generation identifiers; request, response and encryption-context digests; key-provider metadata; and creation, expiration and key-destruction times. For the enrollment grant’s server-enforced lifetime (at most 10 minutes), the receipt also holds an envelope-encrypted exact response containing the machine token so a lost HTTP response can be replayed safely. At the database expiration time the Service immediately refuses to decrypt or replay it. Revoking or superseding the grant, revoking the machine, disconnecting a sign-in provider, or resetting the account password clears the ciphertext and wrapped data key in that operation. Expired material is cleared by a background cleanup that runs at startup and every minute, normally on its next successful pass; an outage or cleanup failure can delay physical removal, and the Service retries it. The remaining hash-only audit receipt is deleted within 30 days.
• Presence metadata includes the status sequence and payload digest, accepting-work and health state, last-seen time, and creation, update, and revocation times. MiniGrove derives presence only from accepted machine status heartbeats. We never store its hostname, workspace root, absolute filesystem paths, provider account details, local logs, or local receipt contents.
• Per-digest signed Kit installation evidence includes artifact and catalog digests, a one-way install-root identity hash, verified token and Kit-inventory generations, availability or retiring state, and verification and last-seen times. The install-root value is an opaque identity, never the path or file contents.

Service-upgrade recovery metadata

When process execution fencing is enabled, we keep a machine protocol version and adoption time, plus one current process record per bot. The process record holds project, owner, bot, machine and installation identifiers; token, machine eligibility, runtime fence and activation generations; supervisor-boot and receipt-store identity hashes; credential-store contract; worker-boot hash, process generation and binding time. A replacement overwrites the current process record. Neither record contains an instruction or local file contents. The protocol record is removed with its machine; the process record is removed with its bot or project. Revocation does not erase either record.

When managed command execution fencing is enabled, each claimed instruction, file operation, image share, stop or session restart retains execution identity metadata: its command type and command, project, owner, bot, machine and installation identifiers; token, machine eligibility, runtime fence and activation generations; one-way supervisor-boot and receipt-store identity hashes; credential-store contract; the claiming worker's boot hash and process generation; and creation time. This adds no copy of the instruction or local files. The metadata is removed with its command under the conversation retention and deletion rules, not when a service upgrades or its credentials change.

When service-upgrade recovery is enabled, we store machine and generation identifiers, request identifiers and hashes, candidate release identities and fingerprint hashes, and required Kit set identifiers, hashes, counts and ordered members. Recovery history also records origins, states, blocked reasons, predecessor and successor links, timestamps, and bounded exact recovery responses with their hashes. These responses contain release and inventory metadata, not machine credentials or local files. This history is retained while the owning machine record exists and is removed when that machine record or its account is deleted; revocation alone does not delete it.

Google and GitHub sign-in information

If you choose Google or GitHub sign-in, we receive information the provider makes available for authentication, such as your provider account identifier, name, email address, email-verification status, profile image, granted scopes, and OAuth tokens. GitHub sign-in may read your GitHub email addresses so it can identify a verified address. Provider tokens stored by MiniGrove are encrypted at rest.

Projects, collaboration, and uploaded content

• Project names and identifiers, who created each project, whether its tree is private or public, its hosted-web hostname label, its default machine selection, and whether Card ending workflows are enabled. For that setting, we also store when and which owner last changed it. We store project creation and update times, membership roles, activity times, and invitation records. We also store a project's custom opening research prompt. Owners can replace or reset it; project members can read and use it, but it is not part of the public tree. The current setting remains until replaced, reset, or the project is deleted. Invitations include the recipient's email address and the inviter, status, role, and timestamps.
• Search-tree cards and canon snapshots that you or your project's integrations uploaded before the database-authority cutover. During the frozen, gate-off migration window MiniGrove may temporarily retain complete legacy card objects, which are not limited to predefined fields. Once the cutover gate is enabled, the legacy canon snapshot API answers 410 and a startup cleanup removes those repository-card mirrors.
• Database-owned project cards created in or imported into MiniGrove, including the stable card identifier and complete card object, plus searchable projections of the card title, what it is betting on, and its card body. We also store its current and last associated origin branches and last observed branch head when available, any native session currently authorized to refresh that head, lifecycle (including closing and purging workflow states), metadata revision, whether its source was a legacy repository card or the database, and creation, update, orphaning, resolution, and withdrawal times.
• Retired project Card identifiers excluded by a reviewed database-authority migration decision, a legacy Discard accepted by an older release, a completed ending-workflow Discard, or an empty provisional Card retired when its branch is attached to the idea Card it was opened for, together with the reservation reason and when each identifier was reserved. MiniGrove keeps these project-local identifiers until the project is deleted so a new Card cannot inherit an old link, comment, or receipt address. The reservation does not store the excluded Card body.
• Card-to-conversation bindings that record which project card a native agent session belongs to, its session provider, a provider-scoped source key supplied as a device/native-session namespace or hash, an opaque local cleanup-target hash that does not contain a repository URL or filesystem path, an optional shared conversation thread, binding status, when it was bound, and when that session ended. These bindings do not add another copy of the conversation text.
• Card Provider-switch replay receipts, including a stable request identifier, project, Card and conversation identifiers, the previous and replacement session providers, provider-scoped source key, opaque cleanup-target hash, the previous and replacement opaque binding identifiers, receipt time, and when a later switch superseded the receipt. These receipts contain no conversation text, repository URL, or local filesystem path.
• Card resolution requests, including an opaque resolution identifier, Card and project identifiers, the requested action (Withdraw, Keep, or Kill), the reason required for Kill and any reason retained for a legacy Keep, an actor type, identifier, and display-name snapshot, the expected Card metadata revision, expected origin head and branch, the optional resolving-session provider, source key, and opaque cleanup-target hash, resolution status and last resolution error, and creation, update, and completion times.
• Card ending workflows, including an opaque ending identifier; project and Card identifiers; the Merge, Rejection, or Purge action; status, stage, and generation; actor type, identifier, and display-name snapshot; original lifecycle and frozen Card revision; branch and frozen head; executing machine, capability revision, and bridge protocol; requesting conversation and native-session identifiers; and an opaque cleanup-target hash. The workflow can also retain the frozen exact cleanup-target inventory, its one-way confirmation digest, and final confirmation time. For Rejection, this can include the rejection category, draft reason, and confirmation time. For Merge, this can include the pull-request repository, number, URL, head and base references, and submitted head; merge commit, verified work head, and landing-evidence kind. We also store the resulting resolution link, last error code and retryable state, when member action became necessary, and creation, update, cancellation, and completion times. If a member chooses to leave a frozen Merge ending and continue ordinary work with AI, we retain the pending AI instruction text, requesting user identifier, delivery status, queued command link when one is created, and request and settlement times. The instruction is not sent to the machine until its exact cancellation receipt has released the freeze.
• Structured Card-ending timeline events, including the linked ending and sequence; typed code, stage, and severity; actor type, identifier, and display-name snapshot; a member-visible summary; structured metadata; and event time. These events contain product progress and evidence selected by the server, not raw local command output.
• Generation-bound Card-ending machine task receipts, including the linked ending, generation and stage; the target ordinal and exact machine, native-session, provider, source-key, cleanup-target, capability-revision, and bridge-protocol snapshot; pending, leased, or completed status; a one-way task fingerprint; a stage-specific authorization object; an opaque lease token, expiry, owning process-boot hash and attempt count; a link to the conversation line that carries the stage's streamed output, when one exists; and creation, update and completion times. After a machine reports, the receipt also stores a one-way report fingerprint, typed outcome and evidence receipt, plus the exact bounded server response so a lost HTTP response can be replayed without repeating checkpoint, pull-request, cancellation, or cleanup work. A blocked stage may add a bounded machine-supplied refusal reason identifier, which is copied into the timeline event and shown to project members; it is a short identifier such as a missing capability name, limited to lowercase letters, digits and a few punctuation marks with no spaces, so it cannot carry a sentence, a slash-delimited path or a quoted command line. These receipts do not store raw local command output, file contents, absolute paths, provider account details, or conversation transcripts. Snapshot-free Discard and Reject receipts record that work has stopped and identify the managed cleanup target; they contain no file-content fingerprint or clean/dirty assessment. Older Discard and Reject snapshot receipts remain readable for recovery. A snapshot-free Reject Decision also records the authorization to discard the listed worktrees, including uncommitted files, after ledger publication.
• During an active Card-ending workflow, the compatible executing project bot may receive the exact Card branch and head, native-session provider and source key, opaque cleanup-target hash, an expected capability revision for semantic work or no catalog revision for mechanical cancellation, stage authorization, and a bounded lease. It may return only the typed freeze, checkpoint, review, pull-request, blocker, or cancellation evidence accepted for that stage; the Service does not accept an arbitrary client log as a workflow event. While it runs a checkpoint, review, or pull-request stage, the bot may also stream that stage's assistant output into the Card's conversation as a machine reply line of its own, opened in the name of the member who started the ending; that line is shared, retained, and deleted exactly like any other conversation line, and it is never read back as workflow evidence.
• Immutable Keep and Kill decisions, including their resolution link, opaque decision identifier, Card and project identifiers, Keep or Kill conclusion, decision source, any MiniGrove-captured reason, actor type, identifier, and display-name snapshot, observed origin head, Card revision, the frozen repository installation, repository, and default-branch publication target, any exact ledger entry object frozen for publication, a source-specific evidence object, and creation time. A checkpoint-backed Keep stores no duplicate MiniGrove reason or ledger entry; its rationale remains in the project knowledge ledger written by the checkpoint workflow. Withdraw intentionally creates no decision or ledger entry.
• Hidden minimal Discard receipts that survive Card deletion, including the project, retired Card, and ending identifiers; authorizing actor type, identifier, and display-name snapshot; a one-way digest of the exact purge inventory; cleanup-target count; database-purge generation; and completion time. Ordinary Card and tree APIs do not return these receipts. They remain until the project is deleted for idempotency, security audit, and to prevent an old address from being inherited by a new Card. The receipt contains no Card body, conversation text, file path, file contents, or Git/PR content.
• Ledger publication jobs, including the linked decision and project, pending, published, or failed status, attempt count and next-attempt time, last publication error, resulting Git commit and commit URL, publication time, and creation and update times.
• Remote branch-cleanup progress, including the resolution, Card and project, exact branch and expected head, session or server cleanup executor, the frozen repository installation, repository, and default-branch cleanup target when the server owns deletion, remote cleanup status, remote attempt count and next-attempt time, last cleanup error, and creation and update times. We also store per-session local cleanup results: the linked resolution, native session and project, opaque cleanup-target hash, pending, prepared, completed, or blocked status, preparation outcome and time, local outcome, bounded cleanup detail, a bounded machine-scrubbed failure description (the git subcommand, exit and first error line, with local paths and credentials removed by the machine before sending), opaque execution lease token and expiry, execution-attempt count, an optional member-authorized dirty-file fingerprint, file count, authorized checkout head and authorization time, the matching machine execution fingerprint, discarded-file count and execution time, or, when a local branch was ahead during Withdraw, a bounded list of pushed commit hashes and subject lines, the previous and pushed heads, direct-push time, Continue authorization and matching machine receipt, or Cancel request time; when the Card head and local branch diverge, the bounded local-only commit hashes and subject lines, Card, local and common ancestor heads, the member's abandonment authorization time and matching machine execution time; when local cleanup could not read its worktree, the member's worktree-removal authorization fingerprint and time and the matching machine removal receipt fingerprint and time; and creation, update, and completion times. The fingerprint is derived from the relative-path file listing already described above; it contains no file contents or local path. For up to 30 days after a machine acknowledges Cancel Withdraw, we retain a narrow cancellation replay receipt: the resolution, Card and project identifiers, exact native-session provider, source key and opaque cleanup-target hash, acknowledging bot identifier, retained Card lifecycle, and receipt time. This lets a lost HTTP response replay safely after the active resolution has been removed.
• Legacy force-purge requests and progress, including the removed Card identifier and title, requesting member, frozen branch and repository identity, remote deletion status, retry counts and errors, unverified-local-target count, timestamps, and a snapshot of any prior immutable Keep or Kill decision. We also retain force-purge local cleanup receipts containing the native-session provider and source key, opaque cleanup-target hash, optional conversation and owning-agent identifiers, retry/error state, and deleted-or-absent acknowledgement, plus force-purge conversation tombstones containing only the purge, project and conversation identifiers and creation time. A tombstone prevents delayed input from recreating a worktree after its Card and session bindings are gone. These server records contain no local filesystem path or repository URL and remain with the project after the Card and its active session bindings are deleted, so an offline machine can converge without recreating the Card; deleting the project removes them. Until the reviewed two-confirmation Card-ending purge replaces it, the Web interface may create a leaf-only immediate-delete request after rechecking current project membership and refusing a Card already owned by an ending workflow. Status, bot receipt, and background cleanup consumers remain available after that initiation surface retires so already accepted requests can finish.
• Personal explanations store your selected AI quotation, source-message identifier and integrity fingerprint, questions, answers, generation status and errors, timestamps, and request/worker lease identifiers. Only their creator can read them through the member interface; the owning project machine receives the quotation and question to generate an answer. When that machine supports explanations, it forks the current AI session and continues in a separate provider session, without adding these turns to the shared conversation. Explanations do not run project actions. The machine keeps separate native-session identifiers; provider-side history follows that provider's retention policy. Collapsing the pane does not delete explanations. You can reopen, continue, or delete them in the conversation's explanation workspace, including when the conversation is read-only. Server records are deleted when you delete an explanation, its source message is removed by normal retention/cleanup, or your project membership is removed. A worker readiness record stores the machine's current worker identifier, explanation protocol and last-seen time; revoking generation access prevents new work but does not erase readable history.
• Registered project bots and authorized project members may ask MiniGrove to associate an observed origin branch and exact head with its database card, optionally attach a native session, and initialize a newly created provisional Card's title, bet, summary, and parent position. Registered project bots may read that shared title, bet, and summary so an agent's first turn receives the work it was opened to do. This operation does not accept repository URLs, local paths, or conversation transcripts. A conversation in the panel is either one that opens a card — it gets a branch and a working checkout on a project machine — or a discussion, which opens none of those. MiniGrove stores whether it opens a card or is only a discussion, because that decides what a project’s machine is asked to do with what you write there, and stores when a member ended a discussion. Neither records who ended it or why. Ending a discussion removes it from every member's conversation list and prevents reopening it through its old conversation link; there is currently no restore action. Saved decisions and Cards remain. Ending does not immediately delete messages: they continue to follow the message retention and cleanup rules below. The I'm feeling good! (Project Pulse) button starts an ordinary discussion with the project's current opening research prompt (or the default task). Each sent opening is retained with its conversation; changing the setting does not rewrite existing conversations or expand the machine's discussion permissions. It uses a shared reading checkout on the selected machine, not a per-conversation worktree. Follow-up questions and public web research are allowed; external queries are sent to the selected AI provider's research services. Do not include private content in external queries. Discussion tools do not edit the shared reading checkout or publish builds. Card and decision suggestions are stored for member confirmation; saving an Idea does not start an agent. Only open-and-start creates a new work conversation.
• When conversation messaging is available, an AI running a live instruction may list project member IDs, names and roles and send an AI-labelled note with member mentions in its current conversation on the issuing member's behalf. Project schedules send as their independent machine member, without impersonating their creator. This works for work and discussion conversations and scheduled instructions. When cloud Card-link editing is available, a bot running a live instruction may read and update only that conversation's bound Card links, using a revision check. When Card creation is available, a live work instruction may also create a Card under a specified parent and start a separate task on the same machine from the project default branch, in the issuing member's name. Discussion commands cannot use this capability. This does not deploy a build, change the project's main address, or edit repository Card JSON.
• When Card cleanup is available, an AI executing a current member's live instruction in a work or discussion conversation may discard explicitly selected other leaf Cards, including in-progress work, their associated branches and worktrees, and uncommitted files. Cleanup uses the existing frozen target inventory and durable deletion receipts; the current conversation's Card, project root and default branch are protected. Stopping the instruction prevents new tool calls but does not reverse cleanup already authorized. Completion is reported only after local, remote and database cleanup finish.
• A project’s assistant may also propose a decision to record — what was decided, why, and the alternatives that lost. The proposal is stored with the conversation and nothing happens to it until a member reviews, edits and accepts it. Accepting one commits it to the project’s connected repository as a line in its decision ledger and a dated document, both carrying the name of the member who accepted it. That is a change to the repository, not only to MiniGrove, and it is public to everyone who can read the repository.
• While a project's bot is running an instruction you sent, it may read project context in order to answer you: the card tree, a bounded window of recent project activity, the conversations you yourself can list, one of those conversation's messages and AI replies, and a card's comments. These reads are performed for the member whose instruction is running and are limited to what that member could already open in MiniGrove, including the point at which they joined the project. A message you sent to your team without “send to AI” is never included in any of them, on any route, and so is never given to an AI model. These reads return no email address, no repository URL, and no local path.
• Canon metadata, including a Git commit identifier, revision count, uploader, and upload time.
• If a project owner connects a GitHub repository for automatic canon synchronization, the GitHub App installation and repository identifiers, repository owner and name, default branch, who linked it, link and sync times, the last synchronized commit, any synchronization error, and the exact project structural branch exclusion list that should not create Cards. MiniGrove uses a temporary GitHub user token to show the repository picker and does not store that token.
• For a connected project, MiniGrove also keeps a copy of the decision ledger already committed to that repository, so its Card panel can show which decisions mention a Card without a machine being online. Each copied line holds its identifier, type, date, what was decided and why, which Cards or project it applies to, which earlier decisions it replaces, the path of its document, and the commit the copy was read at. It is a copy and never the record: it is replaced wholesale on each read, so a line removed from the repository disappears from MiniGrove too, and it holds nothing that is not already in a file everyone with repository access can read.
• Account-level GitHub App connections store the GitHub account and installation identifiers, account login and type, selected-repository and Contents-permission snapshots, verification time, and suspension or revocation state. During connection, a temporary GitHub user token proves that the signed-in user can see the named App installation; it is never stored, and the connection is committed only after GitHub confirms its revocation. If GitHub cannot confirm revocation, the connection fails and GitHub may retain the token until its provider-managed expiry. MiniGrove does not store a GitHub user token or installation token in this connection record.
• Resumable project-setup drafts store the requested project name, the selected account-owned machine and its opaque capability generations, the GitHub installation and any selected numeric repository identifier, bounded setup state and error metadata, and a one-way hash of the single-use GitHub return nonce. They do not store local workspace paths, provider credentials, or repository contents.
• Managed project runtime authority stores the lasting relationship between a provisioned project, its sole owner, selected account-owned MiniHug machine, active project agent, signed Kit identity, execution generations, and versioned execution-policy contracts. It stores no local workspace path or raw machine, bot, GitHub, or provider credential.
• For non-default GitHub branches of a connected repository, the branch name, synchronized commit and time, internal synchronization ordering number and deletion status. Before the database-authority cutover this also included the search-tree card snapshot at that branch head. The startup cleanup removes that legacy JSON and recorded parent claims derived from it, while preserving computed Git parents and derived git state: how far the branch is ahead of or behind the default branch, whether its merge was detected or confirmed by a project member and which of those it was (never which member), its recorded or inferred parent branch, whether its pushes came only from automated accounts (a yes/no classification — never who pushed), and its terminal outcome (kept, killed, or abandoned). These rows power the execution-tree view and do not replace the default-branch canon.
• Minimal GitHub webhook delivery metadata needed to deduplicate and retry synchronization: the delivery and event identifiers, installation and repository identifiers, branch ref and resulting commit, a bot-or-not sender classification (never the sender's identity), attempt and processing times, and any error. MiniGrove does not retain the full webhook payload or unrelated changed-file paths.
• Self-reported machine labels collected by the retired live search-tree upload feature (before 2026-08-20; by default the first component of the computer's hostname). New uploads no longer exist, so no new labels are collected; previously collected labels remain stored until their retention window or a project owner's cleanup removes them.
• Agents that a project member registers so the project can send instructions to a machine they control, including the agent's name, who registered it, when independent machine membership was enabled, and, for an agent created by managed project setup, the account-owned MiniHug machine that activated it and its activation generation. We also store credential metadata such as a token hash and prefix, the bridge protocol capability it reports, the MiniHug version it reports, the time it last connected, an opaque process-boot hash and its last worker-poll time, the process instance that supplied the current capability catalog, and the exact Card-ending capability revision, readiness time, and process instance most recently proved by a strict worker poll, and the project command and skill names plus supported native control names, declared descriptions and argument hints it most recently reported, together with when it reported that catalog. That catalog does not include prompt bodies, local paths, or user-level plugins. As with API tokens, the complete credential is shown once and is not stored by the Service.
• If a project registers a Telegram gateway bot: its BotFather token (stored encrypted; displayed only as the bot's numeric prefix), the bot's Telegram username and webhook secret, which Telegram groups the project has bound and to which registered agent, the Telegram display name of whoever redeemed each binding and, on each mirrored message, the sender's Telegram display name, the topic-to-conversation identifier mapping, and content-free Telegram delivery identifiers kept briefly to de-duplicate webhook deliveries. Photos and files sent in a bound topic are stored as project attachments (subject to the attachment size limits and retention above), and files a project's agent or members produce in a conversation are delivered into the bound Telegram group. Files moved by the files panel are the exception and are never delivered to Telegram: an upload on its way to a machine's checkout, and a file fetched back for the panel to display, are transport for that panel rather than messages to the group, so only the one-line record of the operation relays. Messages from unbound chats and Telegram direct messages are not stored.
• If a project registers a Feishu or Lark gateway app: its Feishu or Lark app credentials (the app id, and the app secret, event encrypt key and verification token, stored encrypted), the app's bot identifier and display name, which platform it runs on and its request-URL secret, which Feishu groups the project has bound and their group names, the Feishu display name of whoever redeemed each binding and, on each mirrored message, the sender's Feishu display name, the thread-to-conversation identifier mapping including the root card the gateway posts in each thread, and content-free Feishu event identifiers kept briefly to de-duplicate event deliveries. Photos and files sent in a bound thread are stored as project attachments (subject to the attachment size limits and retention above), and files a project's agent or members produce in a conversation are delivered into its bound Feishu thread. Files moved by the files panel are the exception and are never delivered to Feishu, as for Telegram: only the one-line record of the operation relays. Conversations started on the panel, or adopted from before the binding, get a root card in the bound group showing their title, machine and status; their earlier history is not posted there. Messages from unbound groups, Feishu private chats, and messages in a bound group's main area that do not address the bot are not stored.
• Instructions members type in a project's tree chat, custom conversation titles members set, and the output an agent returns, including pre-agent Git preparation failure receipts and repair-and-continue source message links, Claude connection recovery status and its linked recovery task (never Claude credentials), reported execution model identifiers, Provider and thinking effort (deleted with the message), together with who sent each instruction, which project members it @mentioned in a conversation, which conversation it belonged to, and when. We also record when the database observes a command reaching its terminal state, so Activity Center enrollment does not depend on application-server clock differences. This timestamp is deleted with the command. Machine-reported model settings for each conversation, known model choices with their Provider, supported thinking efforts and defaults, and update times are shared with project members and removed when the machine or project is deleted. A message may quote the message it replies to — a one-line excerpt and the author's name, copied when the reply is sent and kept with the reply. Members may also put an emoji reaction on a message; we store which member reacted with which emoji, and remove it with the message. Members may pin a message to the top of a conversation; we store which message is pinned and who pinned it, forget the pinner when that account is deleted, and remove the pin with the message. A member may separately pin a conversation to the top of their own list; we store which conversations that one member pinned and when, we do not show it to anyone else, and we delete it with the account or the project. Saved Prompts store a name, body, discussion/work launch mode, ordering, revision and creation/update times. Personal templates belong to your account, are visible only to you and are deleted with your account; shared templates belong to the project and are editable by its owner and deleted with the project. You can edit or delete templates in the viewer's Common Prompts menu. The fixed project research entry can instead be edited or reset to its default. Starting a template creates a project-shared conversation; private template visibility does not make that conversation private. Each launch retains a one-way request digest and, for work, the authorized opening task with its command, so retries do not launch twice and work waits for confirmed Card opening. These receipts expire with their commands; editing or deleting a template does not rewrite sent conversation history. The browser retains an unconfirmed launch and its exact text in tab session storage until acknowledged or the tab closes. A message can also be addressed to your teammates rather than to the machine — a note. A note is stored, shared with the project and deleted exactly like an instruction; the difference is that no agent is ever given it. An agent may also propose new cards alongside its output — a name, what it is betting on, an opening brief, and where it would hang in the tree — and we record which of those a member chose to open and when, any edited name, bet or brief, and the card saved when they choose idea-only creation. When a member dismisses a suggestion or a proposed decision for the project, we record who dismissed it and when; restoring it deletes both. When a conversation is opened to continue another one's work, we also record the repository branch its checkout was cut from, so the tree can show that work under the work it came from. When a conversation is opened to start a card that was written down earlier, we record which card it was opened for, so the work attaches to that card instead of creating a second one. When a member asks the owning machine to restart only a conversation's AI session, we store a stable browser-generated session-restart request identifier with that command so an uncertain response can be retried without performing the restart twice. Like comments, these conversations are shared: every member of that project sees all of them, and the returned output is whatever the machine printed. Command-bound Card-link replay receipts store the command and operation identifiers, a one-way request digest, the acknowledged Card identifier, title, lifecycle, metadata revision, playable and document URLs, actual link changes, warnings, and receipt time. These receipts let an uncertain response be retried without overwriting a later edit; they contain no local filesystem path, file contents, or authentication credential. Command-bound message replay receipts store source command and operation identifiers, a one-way request digest, the message identifier and receipt time. They contain no second copy of message text and are removed with their source command under the conversation retention policy. Sent notes and mentions follow the same retention and removal rules as other conversation messages. Command-bound Card creation receipts store command and operation identifiers, a one-way request digest, the new Card and conversation identifiers, the first task prompt, startup state, setup and started command identifiers, and receipt time. They are removed when either their source or setup command is swept under the conversation retention policy; removing a receipt does not remove its Card.
• When an agent reports reading a local image, we keep structured image-read records: the image's basename or worktree-relative path, whether the read is in progress, ready, or failed, a bounded failure reason, whether it can be opened from the worktree or offered for explicit upload, and when that record was created or updated. For a worktree image this stores only its worktree-relative path. For an image that is not in the reported worktree listing, the owning machine sends a SHA-256 fingerprint, byte size, detected image type, and 24-hour sharing deadline, plus whether a member requested that exact image be shared. The local absolute path never leaves the owning machine: MiniHug keeps it in a private local reference that becomes unusable at the 24-hour deadline and removes it on the expiry timer or after a successful share. If a local storage failure delays physical removal, MiniHug keeps retrying the cleanup. The image bytes are not uploaded unless a member chooses “Upload this image” and confirms; that mechanical request carries the file path or image-read identifier it names and the staleness checks, and records which structured image read an explicitly shared image came from.
• Machine-issued instructions record the machine issuer separately from human authors. Daily schedules a member creates for a conversation, or to open a new Card under a parent Card each day: the instruction text sent each day, the time of day and time zone, which conversation or parent Card and which machine it targets, who created it, whether members are notified, and its next due time. We also store when a schedule was authorized for the project and who authorized it. Project schedules execute as the machine member after the creator leaves; legacy personal schedules retain creator authorization until adopted. Each schedule run keeps its outcome (done, failed, unclaimed, skipped because the machine was offline, or a Card that opened without starting), which conversation it opened, and the note it left, for 90 days; the Cards, instructions and output it produced are ordinary Cards and conversation messages under the retention above. When the connected MiniHug supports schedule reads, the assistant can read this project’s schedule configuration and recent run outcomes as the member whose instruction is running, or as the independent machine member executing a project schedule. These reads exclude team notes and cannot create or change schedules.
• Files and images you attach to a tree-chat message, and files a machine produces in reply — their contents, filename, type and size and integrity fingerprint, together with who uploaded each one, when, and which conversation it belonged to. These are shared with the project the same way the conversation is, and they are deleted 14 days after they are attached — sooner than the message that carries them, which is kept for 30 days; an attachment uploaded but never sent is deleted within a day.
• A file listing of that conversation's working checkout, reported by the machine that runs it: relative file paths with sizes, modification times and git status, the checkout's branch and last reported commit, how many files are uncommitted, whether it is live, not yet created, or already cleaned up, which conversation's checkout it describes, and when the machine last reported it. The listing holds names and metadata, never file contents. By default it collapses each Git-ignored directory to its name alone; a member can open one, which additionally records which Git-ignored directories are open and lists the names and sizes inside them until they are closed again. A file whose name identifies it as credentials is listed but never fetched. When a member uses the files panel, the operation is recorded as a conversation instruction carrying the file path or image-read identifier it names and the staleness checks the member confirmed, and any file content viewed or uploaded travels as an ordinary conversation attachment (above) — additionally, an uploaded file's staged copy stops being reachable as soon as the machine reports that operation finished, and any remaining file attachments stop being reachable the moment that checkout is cleaned up. In both cases the stored copy itself is reclaimed afterwards by a routine cleanup rather than at that instant, so it can persist for a period after it becomes unreachable. The listing itself is kept as a read-only record of what the conversation held.
• Comments you write on a project's cards, together with the card they were written on, who wrote them, when, and which project members were @mentioned on a card. Unlike uploaded cards, comment text is authored by you directly in the Service and is visible to every member of that project. Comments can be added or deleted while the Card is writable; once an ending workflow starts, the retained discussion becomes part of the read-only Card record until the project is deleted.
• Card likes you give, including the project, card, your account, and when you liked it. The aggregate like count may appear on a public read-only tree, but the list of members who liked a card is visible only to current members of that project. You can add or remove your like while the Card is writable; once an ending workflow starts, the retained reaction becomes part of the read-only Card record until the project is deleted. The structural root cannot be liked; if an earlier release stored a root like, the Service removes it.
• Queued notification records for @mentions, including the recipient, the project, the card name or the conversation's title, the name of the person who mentioned you, and a short excerpt of the comment or message. These are copied at the time the notification is queued so the email describes what happened then, and they are deleted 30 days after the notification is resolved.
• Your notification preferences, such as whether MiniGrove may email you when a project member @mentions you.
• Your product preferences — settings you choose about how MiniGrove behaves for you, such as whether a project's machine conversation starts out addressed to that project's bot or to your team. These are yours alone: they change what you see and what your own messages do, never what another member sees.
• Your agent profile — a role, a reply language, and working preferences you may write for the AI on a project's machine. Unlike your product preferences, this is written to be shown to others: it is sent beside your name on every instruction you send from a project's conversation panel, a bot running a MiniHug release that understands it passes it to the AI model as part of your message, and the member whose machine runs that bot can read it. MiniGrove does not display it to other members, though an AI reply written for you may reflect it. Every field is optional, and clearing them stops it travelling.
• Feedback you choose to send us from a project page, including the message you write, the type you pick (bug, idea, or other), the identifier of the project you sent it from, and your browser's User-Agent string. Feedback is forwarded to the person who operates this deployment, together with your name and email address so they can reply to you directly. Unlike @mention notifications, feedback is kept indefinitely — it is the record of what you reported, so it is not deleted on a schedule. If your account or the project you sent it from is deleted, the message and its User-Agent remain but are no longer linked to you or to that project.
• Error reports a project's bot sends us when a command it was running fails in a way it cannot explain to you. A report holds the error's name, code, message and stack trace with the machine's file paths and credentials removed by the bot before sending, a fingerprint of the error's shape, the identifiers of the project, bot, conversation and command it happened in, and the bot's software versions. It never holds the command you typed or the files in the conversation. Reports are forwarded to the person who operates this deployment, coalesced so one bug is reported once a day, and deleted 90 days after they arrive.

Do not put passwords, API keys, private keys, or personal information that your collaborators have not agreed to share in search-tree content.

Service and communication information

• Request information used to operate and protect the Service, including IP address, request method and path, response status, timing, and rate-limit activity. MiniGrove's application request logs do not include URL query strings. Runtime diagnostics record memory use, event-loop delay, connection counts, background-job timing, and bounded request counts by route. Polling diagnostics also record authenticated bot and project identifiers and client-reported worker fingerprints to investigate excessive traffic; these diagnostics do not record request bodies, credentials, or conversation content.
• Transactional-email information, including recipient address, message content, delivery status, and related metadata for account verification, password reset, invitations, security notices, @mention notifications, and feedback you send us (which is delivered to the operator of this deployment with your name and email address set as the reply address).
• Information you include when contacting us for support or exercising a privacy right.

How we collect information

We collect information:

• directly from you when you create an account or contact us;
• from the MiniGrove CLI and project integrations when you choose to log in, create or link a cloud project, or—before the database-authority cutover—push a legacy canon snapshot;
• from collaborators who invite you to a project; and
• from Google or GitHub when you choose a provider sign-in option, and from GitHub when a project owner installs the optional repository-sync App.

How we use information

• create and secure accounts and authenticate users;
• provide project membership, invitations, synchronization, and sharing;
• display project activity;
• show card likes, discussions, and conversations to a project's members;
• send transactional and security-related messages, and — unless you turn them off in your account settings — notify you by email when a project member @mentions you in a card discussion or in a conversation;
• prevent abuse, enforce rate limits, troubleshoot, and protect the Service;
• respond to support, privacy, and legal requests; and
• comply with law and enforce our agreements.

We do not sell personal information. We do not use the Service for targeted advertising or cross-context behavioral advertising, and we do not run third-party behavioral analytics on the Service.

Legal bases

Where applicable law requires a legal basis, we process information as needed to provide the Service you request and perform our agreement with you; for our legitimate interests in securing, maintaining, and improving the Service; to comply with legal obligations; and with consent where we specifically ask for it. You may withdraw consent when processing is based on consent, without affecting earlier processing.

Service providers and other disclosures

We use the following providers to operate the Service:

• Cloudflare provides edge networking and security and processes network information such as IP addresses and routing data. Cloudflare privacy policy
• Render hosts the application and PostgreSQL database in the United States. Render privacy policy
• Resend delivers transactional email and processes recipient addresses, message content, and delivery metadata. Resend privacy policy
• Google and GitHub process information under their own policies when you choose their sign-in services. Google privacy policy · GitHub privacy statement
• GitHub also processes repository and workflow data if a project owner installs the optional GitHub App. The App has read and write repository-content access for selected repositories. Synchronization does not read or write repository Card JSON and does not read the project link; it reads only exact default-branch and branch/head facts. Card metadata, Card links, and conversation-driven Card names are stored in MiniGrove's database. A current project member may change a database Card's parent position (by dragging it in the tree or choosing a parent in its panel), change where it sits among its siblings (by dragging it into the gap between two of them), and rename it from its panel, at any stage before the Card enters an ending workflow. The same member may also edit a Card's name and its bet together from the tree canvas, but only while that Card is still open: once it is settled or in an ending workflow its bet is part of what settled, and only the name stays editable. The parent position and the sibling order are the Card's place in the shared tree only; where a new conversation's work branch is cut from is chosen when that conversation is started. Neither act moves or rewrites a Git branch, worktree, or repository Card JSON. When a current project member opens branch divergence details, MiniGrove reads commit identifiers and titles, author names, dates, and the common Git ancestor for the exact heads shown; that response is returned only to that current project member and is not stored durably. A bounded in-process cache may retain it for up to five minutes, then physically removes it. For a Kill, and for a legacy Keep already in flight, MiniGrove appends one immutable decision object to .brain/ledger.jsonl on the default branch, then permits exact-head branch cleanup. A new checkpoint-backed Keep instead verifies the project knowledge ledger already written by that checkpoint and does not append a duplicate Keep rationale. When no active managed session owns cleanup, MiniGrove uses Git's expected-old-head protocol to delete only the frozen branch version; a changed head or repository connection blocks cleanup for review. Withdraw writes no ledger entry. It does not read or store the rest of the repository's source code.

We may also disclose information when required by law; to protect rights, safety, and the integrity of the Service; with your direction or consent; or as part of a merger, financing, acquisition, reorganization, or sale of assets, subject to appropriate protections.

Cookies and local credentials

The Service uses cookies that are necessary for browser sessions, form security, and OAuth state. It does not use advertising cookies. The Grove CLI stores its bearer token on your computer, normally at ~/.config/grove/credentials.json, with file permissions restricted to your user account. You can revoke that token with grove logout.

Retention

• Account, connected-provider, and active API-token records are kept while your account or connection remains active, unless a longer period is required for security or legal reasons.
• Browser sessions are deleted after they expire. Signing out removes the current session, and resetting a password revokes existing browser sessions and MiniGrove API tokens.
• Email-verification links expire after 24 hours, password-reset links after 1 hour, and social-sign-in state after approximately 10 minutes. Expired verification and state records are deleted by a regular cleanup process.
• Grove CLI authorization codes expire after 10 minutes and may be retained for up to 24 additional hours to detect replay. IP-based rate-limit entries are held in memory for no more than approximately 15 minutes.
• Project data, uploaded search-tree content, and card comments are kept until the project is deleted. Accepted invitation history is kept with the project. Other expired invitations are normally removed 30 days after expiration.
• While a Card is writable, a comment you delete is hidden from the thread immediately and its text stops being served; the record that a comment was there is kept so the discussion does not silently renumber around it. Starting an ending workflow freezes the retained discussion as part of the read-only Card record.
• Published web builds. When a project member asks their machine to publish a playable web version, MiniGrove stores the build's files and a manifest of their relative file names, sizes and content hashes, together with the release label, the project's web address label, which registered machine published it, the instruction it was published from, and when. Every published release is accessible only to current project members, even when the project tree is public. Opening a deployment requires sign-in. A host-only, HttpOnly cookie carries a project-scoped read credential; each file request checks the current login session and membership. Embedded previews use a separate partitioned, HttpOnly cookie scoped to the deployment host and embedding site. The browser also remembers your preview split width locally; it is not sent to the server. A release that is retired, replaced beyond the project's retention limit, or taken down has its files and manifest deleted within 7 days; the release label, sizes and timestamps stay on record so that an old link can never serve a different build. Resumable uploads also store temporary upload identifiers and part sizes until the release is purged. The manifest holds relative file names only — never absolute paths, hostnames, or file contents.
• Card addresses for published web builds. A member may give one Card a lasting play address so its link keeps working as newer builds are published; MiniGrove stores which release that Card's address points at and when it last moved. The Card's identifier appears in that address, and Card identifiers are usually taken from the branch name they were created for, so anyone holding the link can read it. A Card address is not listed in search engines, is removed when the Card is deleted or its release is taken down, and can be cleared at any time from the project's Web builds page, after which the address stops answering.
• Hosted-tool save authorizations. When a member lets a tool published on a project's play address save files into a Card or message its agent, MiniGrove stores which member approved it, for which project, Card and conversation, the tool's web address, the folder it may save into, if any, whether it may send messages to the conversation's agent, a one-way hash and short display prefix of the credential handed to the tool, and when it was created, last used, expires and was revoked. An authorization lasts at most 12 hours and ends early if its member leaves the project. Its record is deleted within an hour after it expires or is revoked, and a member can revoke it at any time from their tool authorizations page. Files a tool saves are handled exactly like files uploaded from a conversation's files panel, and a message a tool sends is kept like any other instruction.
• Tree-chat conversations — the instructions members type, the notes they address to each other, and the output a machine returns — are deleted 30 days after the message was sent. The files attached to either are kept for half as long: they are deleted 14 days after they are attached, so a message stays readable for a fortnight after its files are gone. Removing an attachment's record stops the file being served at that moment; the stored copy is reclaimed afterwards by a routine cleanup rather than at that instant, so it can persist for a period after it stops being reachable. A note is not kept longer than the conversation it was left in — but where a message @mentioned someone, the short excerpt copied into the queued notification follows the notification retention below, which runs from when that notification was sent rather than from the message. Card-link replay receipts may outlive Card deletion but are removed when their command is swept under this 30-day conversation retention policy; at most 64 accepted link operations are retained per command.
• Notification records are deleted 30 days after the notification is sent, suppressed, or abandoned.
• Processed GitHub webhook delivery metadata is deleted 30 days after processing. The Card-authority gate's startup cleanup deletes all legacy default-branch and feature-branch Card JSON mirrors, including mirrors in a quiet repository that sends no later webhook. A minimal ordering tombstone (branch name, deletion time and synchronization generation) is retained for at most 90 days so a delayed delivery cannot resurrect a ref. Disconnecting a repository removes its active project binding and feature-branch metadata; database-owned Cards remain project data until resolved, withdrawn, or the project is deleted.
• Application and infrastructure logs are retained for operational and security purposes for no more than 30 days under the hosting provider's current retention options.
• Deleted database records may remain in provider-managed recovery backups for up to 7 days before aging out.

We may retain limited information longer when reasonably necessary to comply with law, resolve disputes, prevent fraud or abuse, or enforce agreements. Service providers may retain operational records under their own documented retention schedules.

Deletion and your choices

Project owners can delete a project through its member-management page. Project deletion removes its memberships, invitations, live tree, and canon data from the active database.

To request access to, correction of, export of, or deletion of your account information, email [email protected]. We may need to verify your identity. Before deleting an account that owns projects, we may require you to delete those projects or transfer ownership so that collaborators are not locked out.

Content in a shared project may remain after a contributor deletes their account when the project is kept by other members. Where practical, the deleted account's direct identifier is detached from retained project content and invitation history.

This applies to card comments, and it is worth stating plainly because comment text is written by you rather than uploaded by a tool: when an account is deleted, the comments it wrote stay in the project and the author is detached, so they display without a name rather than disappearing. Deleting the text of a specific comment is a separate action available to its author and to project owners while that Card is writable. Once an ending workflow starts, the retained discussion is read-only. Deleting the project removes its comments outright.

You can turn off @mention emails at any time from your account settings. Doing so stops mention notifications you have not yet received as well as future ones; comments still appear on the card, and messages still appear in the conversation, in the project.

Depending on where you live, you may have rights to access, correct, delete, restrict, or object to processing; receive a portable copy; withdraw consent; appeal a response; or complain to a data-protection authority. We will not discriminate against you for exercising a privacy right.

Security

We use safeguards designed to protect information, including encrypted network transport, access controls, one-way credential and API-token hashes, encryption of stored provider OAuth tokens, request-size and rate limits, and security headers. No system can guarantee absolute security.

Children

The Service is a general-audience developer service and is not directed to children under 13. We do not knowingly collect personal information from children under 13, and we do not ask users for their date of birth. If you believe a child under 13 has provided personal information to the Service, contact us and we will investigate and delete it as required.

International transfers

The application and primary database are hosted in the United States, and Cloudflare operates a global network. If you use the Service from another country, your information may be transferred to and processed in the United States and other locations where our providers operate. Where required, we rely on legally recognized transfer mechanisms and provider contractual protections.

Changes to this policy

We may update this policy as the Service or legal requirements change. We will post the updated policy here with a new effective date and provide additional notice when required.

Contact

Questions, privacy requests, and security reports: [email protected].