Privacy Policy

Information we collect

Read-only conversation archives store the project, conversation and optional Task identifiers, original Task and conversation titles, ending identifier, archiving member and time, seal time and last original message identifier. Minimal image appearance records keep the original message and attachment identifiers, filename, type, size and appearance time, without object keys or signed URLs. These records are removed with their original messages under the existing 180-day retention; archiving does not renew it. Reusing an image creates a private unsent reference with its original upload time, a separate draft staging time and source conversation/message identifiers. It shares the same stored object and project quota. The browser tab remembers these draft attachment receipts until sent or removed; the server removes unsent references after a day, while the original file expiry can come earlier. Worktree image reads also retain the identifier of their member-requested fetch, so saved images can be read after worktree cleanup. Automatic expiry or owner-reviewed attachment cleanup may make archived images unavailable; object reclamation follows metadata deletion.

Conversation ending requests retain only project, member, Task or discussion and captured thread identifiers, action and revision, cancellation deadline, status, retry clocks, computer and worker claims, and bounded cleanup counts and errors. An archive can be cancelled for 60 seconds before cleanup starts. Terminal request metadata is removed after 30 days; original chat and image retention is unchanged. Permanently deleting a discussion removes its chat, sent and unsent attachments and archive records. Shared attachment bytes remain while referenced elsewhere. Computers delete only native AI sessions with local ownership receipts; shared or unproven histories remain. Offline cleanup waits for reconnection and offers a member retry when automatic attempts stop.

Exploration notes: closing an eligible Task creates a content-free receipt with project/member/closing identifiers, a one-way Task-name digest and timestamps. Only choosing a reason saves the Task name, reason and optional note, readable by this project’s members and authorized assistant. Closing a Task does not automatically declare a rejection or a lasting preference. Authors can remove their saved content in Exploration notes; the consumed content-free receipt remains to prevent a delayed retry from recreating it. These receipts and notes are deleted when the author leaves the project or their account or the project is deleted. Full conversations are not retained by this feature.

When asked to organize the conversation list, the assistant applies it at once for the member who asked: it creates groups, puts tasks and discussions in them, and retitles conversations whose title no person gave. That member can undo it for about a minute; for that undo we keep, for at most an hour, each placed item's previous section, the sections it created, and each renamed conversation's previous title and who chose it. After that hour we keep only that an organize happened, for whom, when and how many items it changed, for 14 days, so the project advisor does not offer another tidy-up too soon. The advisor may offer one as an ordinary suggestion. Its check is given counts of the list (how many conversations, groups and ungrouped items) and, as in any of its checks, can read the conversations themselves; nothing changes until a member presses it. Archiving discussions is never done this way: the assistant proposes it on a card that a member confirms a second time, because an archive cannot be undone.

Project operation history stores a sequence number, database time, actor kind, identifier and name snapshot, requesting member snapshot when applicable, entry channel, operation identifier, event kind, subject type and identifier, and structured before/after metadata. Imported history is labelled with its source and key. It contains no conversation bodies, instructions, Pulse prompt text, credentials or local paths. These records remain until the project is deleted, even after the subject or machine is deleted. Account deletion clears that account's actor and requesting-member name snapshots; opaque identifiers remain as project history. You can request account deletion using the privacy contact below.

When these project operations are available, a current member can change a Task's title at an exact revision, including filing its title after settlement, or set or clear only its short description while it remains open for work. The assistant may edit only the exact active Task bound to its issuing instruction; its title, description, brief and links are otherwise preserved. When Task ending operations are available, the assistant can propose Merge into mainline or permanent deletion for an exact Task revision; permanent deletion removes the Task. A current member must confirm the reviewed Task, branch and deletion consequences; the ACK starts the existing ending workflow and does not prove a PR merged or files were deleted. When a member explicitly asks to archive the active Task in their conversation, the assistant can start the same one-minute cancellable archive as the panel, without another confirmation card. Chat and images remain read-only under their original retention and quota. Cleanup waits until the cancellation window ends and all running replies finish; other running work prevents the request. Archive does not resume the old conversation or extend its retention. Daily-task creation, time changes, pause, resume and deletion proposed by the assistant require human confirmation of the exact instruction and target; personal tasks remain creator-or-owner managed, while current members may manage adopted project-machine tasks. Retrying a failed build or abandoning a candidate also requires human confirmation of the reviewed candidate and build; a full rebuild of an uploaded binary receives a fresh build number, while upload-only retry keeps the saved binary and number. Stop uses a separate request budget and queues a mechanical stop for the conversation's current computer; an ACK confirms that the request was queued, not that the running task has already stopped. Current membership, machine and credential authority are rechecked, including when reading a historical ACK.

Task summaries show existing Task descriptions, long explanations and imported notes. Members may edit only the short description while the Task remains open for work; the other content is preserved. This view creates no additional summary or notes record.

When preview-merge operations are available, only the member who initiated the preview edit may confirm the reviewed child and fixed parent tasks. The assistant can propose this action but performs no merge before confirmation. Confirmation adopts the requesting turn or queues a fresh verification if that turn has ended; configured checks and a build must pass before the existing integration protocol merges into the fixed parent branch. A started or queued receipt is not proof that Git has merged. The child and parent titles are retained only with the source-message review; permanent history records the operation, fixed parent identifier and started or queued status without the preview comment or images.

When strongly confirmed operations are available, the assistant can propose publishing an exact Web build as the project's public game on minigrove.games with the listing the owner saved, inviting an email address as an ordinary member, uploading a Web build to the project's connected itch.io page, changing a Google Play staged rollout, or promoting a release candidate (its tag, release branch and Play production release with any release notes). It cannot perform any of them. Only a project owner may confirm or decline publishing the game; any current member may confirm or decline an invitation or the other operations. Members can also invite ordinary members from the Members page; only owners can invite owners or manage existing invitations. Each needs a strong confirmation: on the web, a second press in a dialog that restates what will happen; in the mobile app, Face ID or the phone's passcode. The press rechecks the reviewed listing, address or build, so an owner who edits the listing after the proposal must ask for a new one. MiniGrove emails an invitation made this way just as it does one sent from the Members page.

When content and layout operations are available, the assistant may replace the title, short description and brief together only on its instruction's active Task. A canvas edit preserves the brief. Moving a Task and its subtree or creating an unstarted Idea requires a current member to confirm the reviewed titles, parent and order. A move changes layout only; a new Idea creates only a database Task. Neither changes an execution base nor starts a branch, worktree or instruction. Proposal review content also includes parent and neighbour titles, order choice and descendant count, under the same source-message retention.

Shared operation retry receipts store the project, an opaque principal namespace, operation identifier and version, a request digest, target identifier, optional revision and status, and creation and replay-expiry times. They contain no raw request or message bodies, names or credentials. The ACK window is 30 days; expired identifiers cannot execute again. These content-free receipts remain until project deletion.

Provider-operation reservations store a sequence number, project, opaque principal namespace, operation identifier and version, request and target digests, subject type and identifier, effect kind, reservation state, creation, expiry and update times, next pointer-repair time and pointer-repair attempt count, and optional proposal, requesting-member, source-message, source-computer and confirming-member identifiers. They contain no operation arguments, message bodies, names or credentials. An unfinished Web reservation expires after 10 minutes; recovery repairs the current published pointer without applying the abandoned request. Pointer repair retries up to 8 times before requesting operator repair. These content-free reservation identities remain until project deletion.

RC assignments retain the project, opaque principal namespace and operation identifier, planned candidate identifier, version and reserved number, exact commit and source Task or branch, repository and installation identifiers, connection time, and attempt, ref-observation and creation times. Numbers are never reused after refusal or expiry. These public ref metadata and opaque identities remain until project deletion; they contain no message body, name or credential. Recovery inspects only an attempted fixed tag and never creates or moves a tag, candidate, build or ACK for an abandoned request.

Confirmation proposals keep their operation, version, request and proposal identifiers, normalized operation arguments and reviewed target fields, including source PR titles or commit descriptions, Task titles, branch names, a public game's title and description, an invited member's email address, release notes, cleanup-target counts and ending choices, on the source message. An instruction can retain at most 16 proposals. Unconfirmed proposals expire after 10 minutes and cannot execute after expiry. Decline clears their pending arguments and review content; a sweep scheduled every 30 seconds also clears expired unconfirmed input. The remaining content-free identity and refusal marker stay until project deletion. Proposal content otherwise follows its source conversation retention and disappears with that message.

Voice dictation

When enabled for your account, voice dictation sends your recording to OpenAI for transcription, including when the AI destination switch is off. MiniGrove handles audio in memory and does not store recordings. For composer dictation, the transcript stays in your draft (in the browser, or saved on your device by the MiniGrove app) until you send it. Holding and releasing the preview quick-feedback button sends the transcript directly to that preview’s AI conversation, without the existing chat draft or attachments. 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.

Project ChatGPT subscriptions

Where subscription connections are enabled, a project member can connect one ChatGPT account for all current and future project members and enabled project tasks to use. Members share that account's allowance; MiniGrove does not automatically switch to API billing when it fails or runs out.

We store the project, computer and bot identifiers, selected mode, connection generation, connecting user, authorization state, current computer boot observations, timestamps and bounded error codes. A device verification code is encrypted and visible only to the connecting current member for up to 5 minutes. Expiry prevents disclosure; the encrypted code is removed on the next connection observation or change, or when the project is deleted. Connection metadata is retained until project deletion.

Provider tokens remain in the project's computer, not in MiniGrove's model-key database or chat. Project members can execute code on that computer and may read its local credentials. Disconnect refuses new subscription tasks immediately and requests local credential cleanup; an offline computer must return before cleanup is confirmed. Native conversation files remain until the computer is destroyed. Disconnecting does not cancel the ChatGPT paid plan or claim provider-wide token revocation. Removing the connecting member prevents further subscription work and requests cleanup when the computer next checks in.

Your own Claude subscription

Where it is enabled, the owner of a project with no other members can run its cloud AI on their own Claude Pro or Max subscription. It stays theirs alone: while it is connected, nobody can be invited to or join the project. The same connection record as above holds it, plus which subscription sign-ins the computer supports and when a reported limit resets. The Claude sign-in link the computer produces is encrypted and visible only to the connecting owner for up to 15 minutes. The code you paste back is encrypted and readable by that computer for up to 10 minutes. Expiry stops it being handed out; the encrypted code is removed when the computer next reports or checks in after that, when the connection changes, or when the project is deleted. The code works once and only with a secret that never leaves the computer.

Your Claude sign-in stays on the project's cloud computer, not in MiniGrove. Code running on that computer, including an AI misled by content it reads, could read the saved sign-in, which works for your whole Claude account. Disconnecting signs the computer out of Claude and deletes its saved login and its Claude conversation files; an offline computer must return before that is confirmed. It does not cancel your Claude plan. Claude's limits are not shown or shared with anyone else, and running out never switches to MiniGrove credits or API billing by itself.

Cloud machine model keys

For participating cloud projects, we retain the event identifier and the owner’s event capacity choice with the cloud project receipt. Members can see the selected capacity and adjustment status; the change is recorded in project history. This choice grants no AI allowance and expires with the event. Work already running may finish.

An operator may configure event capacity automatically, including for solo projects. The cloud project receipt records enrollment with an ordinary fallback, and project history identifies the system as the actor. Historical owner choices remain. Automatic capacity grants no model allowance; it ends with event eligibility, and running work may finish.

Cloud project trials: we retain the selected image release and launch-attempt metadata to recover preparation safely. For historical trials and operator quantity exceptions, MiniGrove can automatically create a project-specific OpenRouter key with a one-time spending allowance. Ordinary account trials reuse the account key described below. A server-only management credential creates, configures and disables these trial keys; it is never sent to a project computer. We keep a trial receipt containing the account, trial slot, preparation, project and cloud-computer identifiers, the initial game idea and any engine, target-platform or technical preferences included with it, allowance, provider key name and hash, encrypted key and last four characters, allowed models, guardrail identifier, cloud region and image, an encrypted registration grant while preparing, progress and error codes, remaining allowance and its check time, power state and wake-request time, retry count, and creation, update, retry, key-attempt and key-disable times. The encrypted trial key is moved to the project's model-key record during setup; the registration copy is cleared after enrollment. Trial history prevents repeated allowances after project deletion, except for accounts approved to create additional trial projects. While preparation is running, we also keep an optional display name you choose for MiniGrove. It is applied to the cloud computer and becomes visible to project members; the temporary copy is cleared when preparation is ready, cancelled or deleted. For explicitly submitted first discussions or tasks, we also keep the selected mode, submitted idea and advanced settings, an opaque submission identifier, separate discussion or production authorization times, first conversation, computer identity and instruction identifiers, and a bounded automatic-send recovery code. Your initial idea is shown only to you until it is queued into the project conversation. Creating a project with its name only prepares the space. On the preparation page, Discuss first is selected by default. Explicitly saving a nonempty idea authorizes its discussion after setup and model access are ready; choosing Start building before saving authorizes production instead. Unsaved form drafts stay in this browser tab session, scoped to your account and preparation receipt, until the accepted form is viewed or the tab session ends. Previously authorized tasks keep their original consent; historical drafts still require confirmation. Cancellation and project deletion clear the server’s private draft. Historical project-key trials disable their managed provider key before confirming cleanup unless their original key is retained as the account trial key. During deletion we may keep the encrypted project key in its trial receipt until it is adopted or disabled. Ordinary account-key trials retain their account key when a project or preparation is removed. A lost cloud launch response retains a recovery receipt until the resource can be reconciled. Trial history is retained until account deletion is requested and provider cleanup has been confirmed.

Account cloud trials: eligible accounts can successfully create up to 5 trial projects over their lifetime, with only one trial project or preparation at a time. All ordinary trials share the account’s remaining trial allowance; deletion, cancellation and key replacement never issue it again. We retain the original creation identifier, shared billing-account identifier, successful-ready time, whether historical success is verified, final key usage, settlement time and a digest of settlement evidence until account deletion and confirmed provider cleanup. Eligible historical project keys can remain under the account, each retaining its original allowance and lifetime usage meter without final settlement. Historical keys that cannot be retained still need verified final costs before their allowance is transferred. Existing historical grants keep their actual unspent value, including larger or additional grants; existing projects are not automatically removed. The account trial initialization time and trial credit grants remain with the billing account after project deletion. New ordinary trials reuse an account provider key; accounts with multiple retained historical keys keep each key’s original budget separate. For each retained key we store its original credit-source identifier, original provider limit, encrypted credential, hash, last four characters, and creation-attempt, revocation and next-usage-check times. Converted credit reserved to a retained key cannot also fund another key. We retain the encrypted account trial key, its hash and last four characters, and creation-attempt, revocation and next-usage-check times. Its lifetime usage meter survives project deletion. Deleting a project cleans up its computer but does not revoke the account key; someone who retained that delivered key can still spend the account’s remaining trial allowance. Account deletion requires confirmed key revocation.

Cloud projects under a plan: where billing is available, the owner of a paying account can create further cloud projects billed to that account. We keep the same receipt for each, marked as a plan project rather than a trial: it carries no trial allowance, its provider key is created with no spending allowance of its own, and the key's limit then follows the account's plan allowance. The account covers the project from the moment it is ready. Counting how many of the account's projects are active (holding a cloud computer) reads these receipts and stores nothing more.

When a project runs on a MiniGrove cloud machine, its agent calls AI models through an OpenRouter key issued for that project by the organization funding its model use. We store that key encrypted, with its last four characters, the model identifiers it may use, who stored it and when, and when a cloud machine last fetched it. The key is sent only to the MiniGrove cloud machine running that project, while that machine is live, when it starts the project's agent. Project members can read the key through the agent on that machine, because the agent can run commands there. The model identifiers, never the key, are listed to project members in the conversation's model menu.

To push to the project's repository and open its pull requests, the cloud machine asks MiniGrove for a GitHub token limited to that one repository, with read and write access to its contents and pull requests. GitHub makes it expire within an hour. We do not store it; while it lasts, project members can read it through the agent in the same way.

The agent's model requests, including prompts and project code, go from the cloud machine to OpenRouter and the model provider it routes to; they do not pass through MiniGrove, and we do not store or log them. For operator-supplied keys outside automatic trials, spending limits and usage for the key are kept by the funder in its own OpenRouter account. Deleting the project deletes the stored key at once; the key itself stays usable at OpenRouter until the funder disables it.

Your own OpenRouter key: a project member can pay for a cloud project's AI with their own OpenRouter key instead of MiniGrove credits or the project's key. We check it with OpenRouter, then store it encrypted with its last four characters, the model identifiers chosen for it, which member set it and when, and when the project's cloud computer last fetched it. It is sent only to that project's live cloud computer when it starts the project's agent, and project members can read it through the agent there. Project members see its last four characters and who set it. MiniGrove's model allowlist and data-retention settings do not apply to it; its spending limits and usage stay in the setter's own OpenRouter account. Switching sources keeps the key and model configuration encrypted but inactive until a member explicitly uses it again; allowance exhaustion never activates it automatically. Project members can remove the saved key separately. The member who set it leaving or being removed from the project, or deleting their account, and deleting the project delete both active and saved keys. The key itself stays usable at OpenRouter until its owner disables it there.

Custom API services: project members can also save public HTTPS API Base URLs, their endpoint-specific routing identifiers and model lists beside OpenRouter, including any member-configured thinking effort choices per model. These choices are shared with project members, delivered with the service configuration and retained or deleted with it; they do not certify that the provider honors the requested effort. We store each Key encrypted, its last four characters, which member set it and when, and the configured API Base URL. Verification sends only a small synthetic streaming tool request to the first model, which may incur a provider charge; other entered models are not tested. No project prompt or code is used for verification, and provider response bodies are not logged. API services are shared by the project's members and enabled tasks; their Keys are delivered together only to that project's live cloud computer after it announces support. Prompts and project code then go directly from that computer to the service selected for the model, under that service's terms and retention policy. Members can see the service addresses and model lists, Key hints and setters, and can read Keys by executing code on the project computer. Members can remove individual services or all API Keys, or retain all services inactive when changing funding. Each Key is deleted if its setter leaves or deletes their account; project deletion removes all Keys. If the primary Key is retired, other members' retained Keys remain inactive until explicit reactivation. These removals do not revoke a Key at its provider.

Per-turn AI usage: when a project's cloud computer reports what an AI instruction paid with MiniGrove credits or a project member's own OpenRouter key used, we store the model identifier, the input, cached-input, output and reasoning token counts, who was paying at the time, the cost we estimated from OpenRouter's public prices, and which member's share of the allowance that cost was added to, with how much of it went there and how much an earlier allowance period already holds. It contains no prompt or output. Project members see recent usage on the project's AI credits page, and members who choose to see each turn's cost under its reply. It is deleted with the instruction it belongs to.

Tool-work statistics: when a machine running Codex reports how much tool work an AI instruction did, we store the model identifier, the reported software version, the count of tool steps, the step limit and whether it was reached, the turn and compaction counts, the elapsed time and the number of tool starts per fixed category, with when it was stored and last changed. It contains no prompt, output, file path or tool input, operators read it in aggregate, and it is deleted with the instruction it belongs to.

Merge AI usage: the same figures, stored the same way, for the AI a Merge runs in its own stages (its checkpoint, review and pull-request steps, and a fast Merge's conflict step and risk check), when the computer running them reports it. It is attributed to the member who started the Merge, contains no prompt or output, appears in the same recent usage, and is deleted with that Merge's record.

Background tidy-up: where a fast Merge is on, after a Merge lands MiniGrove reviews and tests it in the background, on the computer that ran the Task, and lands what it fixes through its own pull request as MiniGrove. For each Merge we store the Task and conversation identifiers, which computer ran it, who started it, the Task's title, the pull request number, the commits it landed, which AI provider ran it, whether MiniGrove started it itself, how many runs stopped or were overtaken by a moved main before finishing it, when a member last asked to check it again, and when its notification was sent. For each run we store the computer, the repository, the default branch and its commit, status, failure code and message, the commit, branch and pull request it opened and when that pull request began waiting to merge, and its AI-written one-line headline, test result and failing test names. We also store which computer last asked for tidy-up work, and when. Each problem it reports is stored as a one-line summary in the members' language with up to five file paths and a test name, never file contents or conversation text, with whether it was fixed, who accepted leaving it unfixed and when, and when its notification was sent. A candidate the server started from the queue records when it was queued and how many Merges were still being checked. The AI it used is stored as Merge AI usage is, per Merge, on the share of the member who started that Merge. That computer also keeps a small record of each fast Merge, with its identifiers, commits, changed file paths and AI session, never file contents or conversation text; it goes when the check settles, or once it is stale. Forking a conversation for its retrospective happens only on that computer: the conversation itself is not sent to MiniGrove, and a Task or conversation deleted first is not used. What its AI writes while it works is stored as text and shown to the project's members, where that computer reports it: the review and its fixes, and a retrospective per Merge, which may quote that Merge's conversation. A retrospective's text is deleted with its conversation, and the rest with its run. These records are deleted 90 days after they settle.

A fast Merge's pull request description is written by the AI from the Task's conversation, then checked for credentials and personal data. We store it with the Merge's record, and it is visible to whoever can see the pull request on GitHub.

Fast Merge is off until a project owner turns it on in project settings. We store who turned it on and when, and delete that when it is turned off.

Queued candidates: when a member makes a release candidate while MiniGrove is still checking recently merged work, we store who asked, the version, how they asked, the repository it was for, when, its status, attempts and any failure code, and the candidate it became. MiniGrove then creates it in that member's name, from main as it is then. These records are deleted 90 days after they settle.

Parking a cloud project: where parking is available, when a project's owner parks it, or when it has had no AI instruction for 14 days, we release its cloud machine and keep its data volume as an encrypted snapshot in the same cloud region. We keep that snapshot's identifier and when it was taken and completed, when the project was parked and when it was last woken, a relaunch counter, when parking was asked for, the time of the project's latest AI instruction, and whether old snapshots are waiting to be deleted. Conversations, Tasks, members and published games are not affected. A snapshot is deleted within about an hour once the project has been woken onto a new cloud machine or the park was abandoned, and with the project when it is deleted.

A cloud preparation that stops with no project: when a cloud trial's preparation cannot continue and no project was created, we stop its cloud machine. If it has not been recovered 7 days later, we cancel the preparation and delete that machine and its disks, just as if you had cancelled it yourself; its GitHub repository is kept. If any cloud machine keeps running with no project, we email our operators its identifiers, and keep digests of the operator addresses we alerted on the machine's record.

Member shares of an AI allowance: when a project's AI spends a plan's or a trial's allowance, we add each instruction's estimated cost to a running total for the member who issued it, for that allowance period, with when the total was started and last changed. Schedules have one shared total, and so do instructions whose issuer had already left. It contains no prompt or output. Every member of the projects the allowance covers sees each member's share as a percentage, and nothing more. When a member deletes their account, their total stays without their identity so the team's figures still add up. It is deleted with the allowance period it belongs to, which is kept with the billing account, or with the project for a historical project-scoped trial. Shared account trial totals remain with the account after project deletion.

The allowance wall: when a cloud project's AI allowance is used up, we record that a member was shown the options to continue, once per member per allowance period, and which option a member pressed (upgrade, buy a top-up pack, connect a ChatGPT subscription, or wait for the reset). When the allowance is running low we likewise record, once per member per period, that a member was reminded and whether they dismissed the reminder. When a plan's cloud computer hours are running low we record the same, once per member per billing period, and when a member presses upgrade on that reminder; these are kept apart from the allowance's. We store the project, the member, the project's plan at the time, the allowance or billing period and when it happened. It contains no message content and is visible only to MiniGrove operators, who use it to see which options people choose. It is deleted with the project, and the member's identity is removed from it when their account is deleted.

Billing and credits

Billing and credits: paid plans and credit packs are sold by Paddle.com as Merchant of Record. Paddle collects your name, email address, billing address, payment method and tax information and processes the payment under its own terms and privacy policy; MiniGrove never receives your card or bank details. Billing accounts: when you start a checkout we keep a billing account linked to your MiniGrove account, with Paddle's customer identifier and whether a chargeback is open. We store which of your projects the plan funds and who chose them; for each subscription its plan, its status, currency, current billing period, any scheduled cancellation or pause, the number of paid seats, a plan or seat change you asked for at the next renewal (with when you asked and when it applies) and when Paddle last changed it; and each checkout you start, with its plan, or its pack and the amount you chose, currency, Paddle transaction identifier, state, who started it and the project it was started from. We keep Paddle's payment notifications for 90 days after processing them, reduced to identifiers, statuses, prices, quantities, amounts and billing periods; names, email and postal addresses and payment details in them are discarded before storage. We record each refund or chargeback Paddle approves and how much credit it removed. For a plan's cloud computer hours we keep, per billing account and billing period, the seconds your plan's cloud machines ran, whoever paid for the project's AI.

Add-ons: for each project an add-on is bought for, we store which add-on it holds, which subscription pays for it, when you asked for it, when Paddle confirmed it is billed and, if you scheduled its removal or the project was deleted, the renewal it ends at. It is deleted once Paddle no longer bills it, or with its subscription.

Own compute from before paid plans: if a cloud project began paying for its AI with its own OpenRouter key or a ChatGPT subscription during its trial, while that did not yet need a paid plan, its model-access record keeps when it began, so the project may keep doing so. The record is removed when a plan covers the project, and deleted with the project.

Free trial terms: we record once when the free trial's current terms took effect. A trial that was already running then keeps the terms it started under, and its record notes when it was marked so. For a trial's cloud computer hours we keep, per billing account, the seconds its cloud machines ran during the trial, whoever paid for the project's AI.

Credit records: for each source of AI credit on a cloud project (its trial, a plan's allowance for one billing period, a pack, or a grant by the MiniGrove operator) we store its amount, how much has been spent and revoked and why, when it starts and expires, the payment or operator it came from, an operator's note, and for a top-up the amount paid for it. We also keep spending records: each time we read a project key's usage, how much was spent since the previous read, which credit paid for it and any amount no credit covered; and, per key, how much of the project key's spending has been recorded and the spending limit last set on it. These records hold amounts and identifiers, never message content. Spending records are kept for 400 days, including after their project is deleted; a project's own credit records (historical project-scoped trials and any operator grant to it) are deleted with the project, while shared account trial grants are retained with the account. A billing account and its records are deleted when account deletion is requested and processed, after any live subscription has been cancelled.

Release candidates and store releases

When a project member marks a Task's version or the default branch's latest commit as a release candidate, or promotes a candidate to a release, we store its version and candidate number, status, the exact Git commit, the source Task's identifier and title (or the default branch's name), the branch the marked commit was on, the tag and release branch names, release notes, and who marked, promoted or abandoned it and when. MiniGrove's GitHub App creates the tag, and at promotion the release branch, in the project's connected repository; it never moves or deletes an existing tag or branch. Release candidates, their build jobs and platform settings are visible to project members and are deleted with the project; tags and branches stay in the repository.

Release preparation: when you ask the advisor to prepare a release, we remember its work conversation, explicit audit status, reporting instruction, reviewed Task and commit, and update time. Project members can see this progress and the ordinary work conversation. The advisor can inspect and fix the project in that work Task, asks you about unresolved choices, and leads to candidate creation; it does not automatically publish a release. These progress records are deleted when the project is deleted.

Release platforms: a project owner can enable a store platform or the project's hosted web address, set a store app's package name and choose a build computer attached to the project. We store those settings with who changed them and when, the latest store check (whether the app was found, whether the project's Play access was accepted, the highest build number the store reported, and the store's message), and a project build counter. For each platform build we store its status, a bounded failure code and message, stage, attempt count and lease times, the target computer, the member who requested it, the package name and build number, whether the binary reached the store, for a web build the hosted web release it uploaded, and its production rollout status and fraction. A build computer reports the project's detected game engine and web build type, its Node.js version, npm availability and whether Godot and its export templates are installed or the app can prepare them itself, and which Unity editor versions it has and whether each supports Android, iOS or WebGL; we keep its latest build toolchain report. We also retain the latest Web candidate’s source commit, its detected engine/build type and which build recipes the reporting app could recognize, separately from the main checkout.

itch.io publishing: we store the encrypted upload key, its authorizing owner, itch.io username and game identifier, destination, selected upload computer and connection time, and the fixed code and time of the upload computer's last failure to install butler itself, cleared when the connection changes or a later automatic install succeeds. The key may access other games and is sent once per upload attempt to the selected computer, never to AI or back to a browser. We record the Web build, destination, requesting member, computer, upload status and attempts, last credential delivery time, fixed failure code, confirmed itch.io build identifier and completion time. Project members can read destination and upload status; only owners can replace or remove the connection. Removing the connection deletes the saved key immediately; leaving the project, account deletion or losing owner status also deletes the owner's saved key. Publication history remains until project deletion. Removal does not revoke the key on itch.io or recover copies received by computers; revoke it in itch.io settings if a computer should lose access. Uploaded files are sent directly from storage to the computer and then to itch.io; game-page visibility and browser-play settings remain under your control on itch.io.

Store credentials: a project owner can give MiniGrove Google Play access, either by authorizing with their own Google account or by storing a Google Play service account key, and can store an Android upload keystore with its alias and passwords. We store them encrypted under a key held in a managed key service, with metadata shown to project members: the authorizing Google account's or the service account's email address, the key alias, a SHA-256 fingerprint and size of the keystore file, who stored it and when. Authorizing with Google stores a Google refresh token and your Google account identifier, and records which member authorized it; Google Play access through it covers every app your Play Console account can manage, not only this project's. That authorization belongs to the owner who gave it and is deleted when they leave or are removed from the project, stop being an owner, or delete their account; except after account deletion, MiniGrove then also asks Google to revoke it once no project still uses that Google account, and you can revoke it yourself in your Google Account's third-party access settings. Only one kind of Play access is kept: storing one deletes the other. Play access never leaves MiniGrove: we use it to call Google Play and give a build computer only a Google access token that expires within an hour; anyone who can run commands on that computer during a build may be able to use that token until it expires. The upload keystore is sent only to the build computer that has claimed a build, once per build attempt, and each delivery is logged with the computer's name, the build and the time; project members can see this credential delivery log. Anyone who can run commands on that computer may be able to read the keystore while the build runs. Removing a credential or deleting the project deletes it at once; a computer that received the keystore may keep a copy, so replace the upload key in Play Console if a build computer should no longer have it.

iOS configuration: a project owner can connect an App Store Connect Team API key. We encrypt its private key in the same managed key service and store its Key ID, Issuer ID, size, and who stored it and when. The private key stays on the server and is never sent to a build computer or an AI. A Team key can access every app in its Apple team; selecting this project's app does not narrow that authorization. We store the selected bundle identifier and TestFlight group identifier, the App's Apple identifier and name, available group identifiers, names and whether they are internal, and whether signing resources were accessible at the latest check. The computer's environment report also includes its operating system, Unity iOS module availability and selected Xcode version. Project members can see the selected configuration and checks; only owners can discover the team's other apps or change credentials. iOS automatic builds and uploads are not yet connected. Deleting the connection or project deletes our stored private key immediately; it does not revoke the key at Apple. An owner can revoke it in App Store Connect.

Store status for AI tasks: an agent working in the project can ask MiniGrove for its apps' current status in App Store Connect and Google Play: whether the App is found, its newest App Store version and that version's state, and each Play track's releases with their version codes, status and rollout fraction. MiniGrove reads it at that moment with the project's stored store access and keeps none of it; this read never changes store state and the agent never receives the key, the Play access or a token. Separately, the agent can propose promotion and rollout changes for a member to confirm strongly. An agent's browser is not signed in to App Store Connect or the Play Console: it is pointed to this read instead.

Release configuration for AI tasks: an instruction's issuing member can ask the assistant to read enabled release platforms, application identifiers, designated build computers, whether store access and an upload key are saved, cached readiness and blockers, TestFlight group identifiers and names, and first-bundle status. Returned information is sent to the AI model running the instruction; account emails, key identifiers, credential contents and store-provided prose are excluded. On an explicit request from a current project owner, the assistant can change ordinary platform settings, with a check against the settings it read. Account connections and keys remain owner-controlled; publication and release promotion retain their separate confirmations.

Signed Android candidate bundles: we store the build and attempt, package name, build number, file size and SHA-256 digest, storage key, readiness and expiry. Current project members can download the saved AAB through a short-lived link, or retry only the Google Play upload using the same binary and build number. Bundles become unavailable 24 hours after storage is reserved; hourly cleanup deletes expired files on its next successful pass. Project deletion removes the records and attempts to delete the files; a cleanup failure is logged and may leave files in storage. We retain the current Google Play upload error stage, HTTP status and original response text up to 16,000 characters, with credentials removed and truncation indicated, plus the Play edit identifier used for recovery. These diagnostics are visible to project members; retrying clears the current failure, and deleting the project deletes the records.

Windows desktop builds: we store the project, build and attempt, exact Git commit, Windows x64 target, private archive storage key, byte count, SHA-256 and MD5 digests, executable name, file manifest with sizes and hashes, upload deadline, readiness and expiry. We also keep whether the build computer has its matching Windows export template. Current project members can download the archive through a short-lived private link. Each archive and its unpacked content are limited to 1 GiB, with a separate 10 GiB desktop archive limit per project. Downloads expire 30 days after verified completion; hourly cleanup deletes expired files on its next successful pass and retains failed deletion keys for retry. Incomplete upload reservations expire after their upload window and landing margin. Windows playtest receipts store the member's account, the exact archive identity and digest, and the confirmation time; a member can remove their own confirmation. A candidate's playtest receipts are also deleted when it is abandoned or replaced, or when its Windows build is retried. Hourly cleanup deletes expired playtest receipts on its next pass, even if deleting the archive's files fails. Leaving the project or deleting the member's account or project also removes their receipts. Building an archive does not create a playtest receipt. Project deletion waits for open archive upload windows, removes the files before the records, and keeps the project if file cleanup fails. Desktop archives count under App bundles on the storage page. This version does not upload desktop games to Steam.

Windows trial packages: before a Task merges, a member or the AI can have the project's build computer build a Windows x64 package of the Task branch's pushed commit. We store the Task, branch and exact Git commit, the member who asked and the reply it was asked from, the computer, status, failure code and message, stage, attempt and lease times, and for the archive the same fields as a Windows desktop build. Current project members can download it through a short-lived private link while the Task is open. A newer package replaces the previous one, which stays downloadable until the newer one is built and is then deleted on the next hourly pass. When the Task merges, is archived or is deleted, downloads stop at once and hourly cleanup deletes the files on its next successful pass; otherwise trial packages expire 30 days after verified completion. They share the project's 10 GiB desktop archive limit, have no playtest receipts, and are never released or uploaded anywhere.

Mac release candidates: Godot standard / GDScript projects can export a Universal macOS archive from the candidate's exact Git commit. We store the build and attempt, source commit, macOS Universal target, storage key, sizes, SHA-256 and MD5 digests, entrypoint and file manifest, upload deadline, readiness and expiry. The computer reports its matching Mac export template and an ad-hoc signed export; the server verifies storage size and MD5, but does not verify Apple notarization or execution on a Mac. Only current project members can obtain five-minute private download links; already issued links may remain usable for five minutes. Mac candidates share the desktop limits of 1 GiB per archive and its unpacked content and 10 GiB per project, and expire 30 days after verified completion. Members can save or remove their own results for each running architecture: member account, exact build/attempt/archive digest, macOS version, pass or problem, optional note and update time. Export never creates a playtest result. Apple Silicon and Intel results remain separate, and another member's report does not verify your own Mac. Reports are hidden when the archive expires and deleted by hourly cleanup even if storage is unavailable; retrying the build or ending the candidate by abandonment or replacement removes them immediately. Member, account, project or archive deletion also removes the reports. Hourly cleanup removes expired files on its next successful pass, retaining failed keys for retry. Mac candidates count under App bundles on the storage page. Developer ID signing, notarization and Mac App Store submission are not included.

Mac trial imports: when asked by a current member, the AI can upload an existing Mac ZIP directly to private build storage, without rebuilding or attaching it to chat. We store the project and source instruction, importing member, filename, reported source commit and optional source snapshot digest, architectures and signing, storage key, byte count, SHA-256 and MD5, readiness and deadlines. Local paths are not stored. Each ZIP is limited to 1 GiB and shares the project's 10 GiB desktop archive limit; at most 100 retained imports are allowed per project. Storage verifies size and MD5; source, SHA-256 and signing are importer-provided, and import does not verify notarization or Mac execution. Only current members can obtain five-minute private download links. Downloads expire 30 days after completion; the importer or owner can withdraw an import, stopping new links and deleting its playtest reports immediately. Already issued links may remain usable for five minutes. Members can save or delete their own playtest result, Mac version, running architecture, optional note and report time for those exact bytes; another member's report is not their own verification. Expiry hides reports immediately and hourly cleanup deletes them even if storage is unavailable. Project deletion removes reports, revokes new downloads and expires imports; import records survive for cleanup until file deletion succeeds, without the importing member's account identifier. Hourly cleanup deletes expired bytes after the upload window and bounded transfer margin, retaining failed keys for retry. Mac imports count under App bundles on the storage page. These imports are not release candidates.

Mainline web builds: a member, or the AI on a member's instruction, can have the project's build computer build a web version of the default branch's latest commit, and can stop that build. We store the branch, exact Git commit and tree, the member who asked, the computer, status, failure code and message, stage, attempt, request and finish times, and the hosted build it made, until the project is deleted.

First release of a new app: Google Play cannot see an app until its first bundle is uploaded by hand, so a project owner can have MiniGrove create the project's Android upload key and have the build computer build and sign the app's first bundle without uploading it. A key MiniGrove creates holds no personal data, is stored like any store credential and never sent to a browser; the page shows that MiniGrove created it and its certificate's SHA-256 fingerprint. For the build we store its status, failure code and message, stage, attempt and lease times, the computer, the member who asked for it, the package name, version and build number, the Git commit, and the bundle's size and SHA-256 digest. The bundle itself is kept in MiniGrove's file storage, not in the database, and only the project's owners can download it, through a link that works for a few minutes, for 24 hours after it is built. After that, or once it is replaced or fails, the hourly cleanup deletes the file on its next successful pass (an outage can delay it). Project deletion removes the records and attempts to delete the files; a cleanup failure is logged and may leave files in storage. The build record remains until the project is deleted.

Activity Center enrollment

Activity Center is always on for every account and cannot be turned off; it also holds the read state of your @ mentions in projects. We store your user identifier, enrollment identifier and start time. New completions and mentions are collected from that start time; following one retained execution explicitly can also collect its earlier result. Accounts that had turned it off were enrolled again on 24 September 2026, collecting from that moment on; handoffs from before they turned it off were already removed and do not return.

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 Tasks you choose to follow; you can remove them from My follows. These records are independent of email notification preferences.

When an agent turn you started or follow waits for a member to approve a tool call, you receive a handoff whose excerpt is that request's one-line summary. When the turn has no current human issuer (a scheduled or chat-gateway task, or one whose issuer left the project), the project's owners receive it instead. It stays until the request is answered, withdrawn or its turn ends, for up to one year, and then follows the 30-day activity retention below.

When you choose Save for later on a message, you receive a handoff that names that message and whether you saved its text or its reply, with a one-line excerpt of the part you saved. Only you can see it. It stays unread until you open it from notifications or mark it read; while it is unread you can take it back from the message, which deletes it. Once read it stays among your read notifications and follows the 30-day activity retention below. Deleting the message before its own retention ends removes it. If its conversation ends or can no longer be opened, only the excerpt remains visible.

When a teammate leaves a note in a conversation where you have already sent a message, to the AI or to the team, you receive a handoff naming that note and its author, with an excerpt of up to 240 characters. Only notes members type themselves are included: not a note the assistant sends for someone, a scheduled notice or a chat-group line. A note that @mentions you arrives as that mention instead. Whether you have sent a message there (in MiniGrove itself: not a message relayed from a linked chat group, nor a setting such as a model switch) is read from the retained conversation, so it lapses with the 180-day message retention, and leaving and rejoining the project starts it over. Deleting the note before its own retention ends removes the handoff; otherwise it follows the 30-day activity retention below.

When a teammate puts an emoji reaction on a message you wrote yourself, a note or an instruction you sent to the AI, you receive one handoff for that message, naming the teammate who reacted most recently, with an excerpt of up to 240 characters of your message. Who else reacted and with which emoji are read from the reactions themselves when you look, not copied into the handoff. Only messages you typed in MiniGrove count: not a note the assistant sent for you, a scheduled task, a message relayed from a linked chat group, or a setting such as a model switch. Your own reactions, reactions on the AI's reply and reactions from a linked chat group do not create one. When every teammate takes their reaction back, the handoff is deleted, read or not. Once you have read it, a reaction from a teammate who had not reacted before makes it unread again. Deleting the message before its own retention ends removes the handoff; otherwise it follows the activity retention below, counted from the latest reaction that raised it.

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 180-day retention. Leaving a project immediately removes access to its activity and deletes its follows. Deleting the project, source Task 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.

Mobile notification devices store an installation identifier, your account and member bearer identifiers, Expo push token, whether the device is an iPhone or an Android phone, binding time and expiry, and whether the installed app can show teammates' notes (a note another member leaves in a conversation you spoke in) and sign-in requests, which decides whether these are pushed to it and counted on its icon. You enable these notifications in the mobile app; disable them there to remove its device binding. Signing out or revoking its member bearer also removes the binding. Devices expire after 90 days without renewal and are removed on the next successful hourly cleanup. Mobile push delivery records store device and personal activity identifiers, source timestamp, creation time, state, retry count, next retry time, provider receipt and a bounded error code, without an additional message copy. They are deleted with the activity or device, or after 7 days on the next successful hourly cleanup. Expo and Apple (iPhone) or Google (Android) process the device token, a notification preview containing the notification type, execution outcome, mention or note author name and task title when available, and for a sign-in request the website it is for, the unread notification count for the app icon badge, and account, activity, project and conversation identifiers to deliver alerts. Preview language uses your account interface language, with English when automatic or unset; conversation text is fetched after you open the app using your current member permissions. An alert already delivered to the phone cannot be recalled by revoking access.

Account and authentication information

On supported mobile servers, you can create a conversation, save an Idea or start a task from the Conversations tab. Creating or starting an Idea uses your registered phone key to sign the exact form and a single-use challenge; the challenge stores the action, identifiers and a content hash, never the title or description. Draft forms and unconfirmed requests stay in the app account cache until sent or removed with sign-out or project access loss.

When phone Stop is available, your registered device key signs the exact project, conversation and request identifier. Its single-use challenge stores identifiers and a content hash. The shared operation receipt keeps the queued stop identifier so retries cannot queue it twice; a queued receipt does not mean cancellation has finished. This press leaves ordinary bearer operation grants unchanged.

When mobile previews are available, the app reads fixed build versions inside its Preview tab. Its sign-in bearer stays in native app code; the hosted preview receives only a separate encrypted read credential, valid for at most 8 hours. Each file request rechecks that sign-in's expiry and revocation, current project membership and current project address. Signing out or losing access stops later reads; content already delivered can remain on the device.

When a hosted phone preview confirms audio support, you can mute its sound. The control forwards a sound setting inside that view; it sends no AI instruction and creates no server record.

When phone preview annotations are available, your registered device key signs the exact selected build, area, two screenshot identifiers, title, comment and automatic merge-back choice. Annotation drawings stay on the device until submission; the two PNG images become ordinary project attachments under the same retention as preview feedback on the web. The existing preview-edit record stores that feedback and its task and merge receipts; drawing paths and labels have no separate database record. The challenge stores only identifiers and a hash, and a hosted page or ordinary bearer alone cannot commission the task.

Mobile send receipts store your account and project identifiers, an opaque request identifier, a content hash, the accepted message identifier and creation time. The same receipts prevent MCP Task creation from opening twice. They contain no additional message text and remain until the account or project is deleted, so retrying an expired message cannot execute it again.

For the mobile app's MiniGrove tab we store, per project, which discussion it opens for you: your account, project membership and conversation identifiers and when that last changed. The discussion itself is an ordinary conversation every project member can see; this record is removed when you leave the project, delete your account or the project is deleted, and it stops pointing anywhere once that conversation is ended or expires.

If you let the mobile app confirm chat cards, we store, per sign-in, that phone's confirmation keys: the public half of the App Attest key Apple certified as the MiniGrove app's, the public half of a key that signs only after Face ID or your passcode, Apple's signature counter, an installation identifier, an optional device name, and when it was registered and last used. No private key, face or fingerprint data leaves the phone. Single-use confirmation challenges are stored only as a hash and deleted an hour after they lapse. Each answer you give from the phone keeps a receipt (the card, your answer, which phone, and the response you were sent) so that a retry cannot answer twice; receipts are deleted 30 days after the answer. Signing out of or revoking that sign-in, removing the phone in the app's settings, or deleting your account deletes its keys.

If you register an Android phone to confirm chat cards, we store, per sign-in, the public halves of the keys that phone's secure hardware made for the MiniGrove app: one that signs each answer and, when the phone has a fingerprint or another strong biometric, one that signs only after it. Google's certificates for those keys are checked when the phone registers and are not kept; we keep only the app package they name. To check whether Google Play vouches for the app on that phone, we send the phone's Play Integrity token to Google, which returns its verdict; we keep only whether it was checked, unavailable (with Play's error code) or not checked and why. We also store an installation identifier, an optional device name, and when it was registered and last used. A phone with an unlocked bootloader or modified system software cannot register. No private key or fingerprint data leaves the phone. Challenges, answer receipts and deletion work as they do for an iPhone.

• Project creation preparation: we store your chosen name, request identifier, whether you marked it as not a game (which decides the Kit tool packs it starts with), explicitly selected computer identifier, GitHub account and installation identity, repository name and result, authorization purpose, nonce digest and expiry, and preparation timestamps. Automatic creation, when enabled, uses the same GitHub App as project access. Administration write permits creation and management of repositories; Contents write permits file access. Choosing All repositories covers existing and future repositories, not only the new project. The App authorization remains until you revoke it in GitHub settings. We use a callback-only user token to create your private repository and confirm access, revoke that single token without deleting the authorization, and do not store user tokens or refresh tokens. A failed token cleanup pauses preparation for retry; GitHub may retain that token until cleanup or provider expiry. Later creation returns through GitHub to confirm your account and may require login again. You can remove a preparation record before creation starts or after its result is confirmed; GitHub files remain. Removal clears the name, selected computer and GitHub metadata, and resets the not-a-game choice, while retaining an account-linked request identifier and timestamps for abuse limits and duplicate prevention until account deletion. Uncertain creation results retain their receipt for recovery. Linked records follow project setup retention.
• 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. Tokens may grant the existing member API or a specific set of project operations; operation grants do not include the member API or machine enrollment. Current membership and operation permissions are checked again when an operation executes or its receipt is read.

Authorized platform operators can read project-level usage counts, member-activity times, runtime health, the step, status codes and timing of unfinished Task endings with their computer's last connection, and attributable platform costs for operations. This does not grant access to project conversations, files or Task titles; Support access remains controlled by the member grant.

Account-owned computers (MiniGrove Desktop)

Operator image upgrade records include the authorizing account, batch and request identifiers, the exact verified image release, provider instance and disk observations, the original runtime and power state, maintenance progress and failure codes, backup and root-replacement identifiers, independent maintenance command receipts and output digests, and receipts of an operator deleting a retained backup or old system disk (which account, when, and which copies). Trusted image operators can also read project identifiers and names, cloud lifecycle and power state, and whether a cloud project holds an active slot; this read-only projection does not grant project membership. The verification script is fixed system-maintenance code; these records contain no project files or cloud credentials. We also retain when a machine first entered image maintenance as machine-owned backup-cleanup evidence. Machine observations and target receipts are removed with their cloud-machine record; batch records are removed with the authorizing account. Active maintenance must be settled before those records or their parent account can be removed. Recovery disks and backups remain until separately reviewed cleanup or project deletion; a cleanup review date alone does not delete them.

In My computers, 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 MiniGrove Desktop or delete files on your computer.

• When you connect a computer with MiniGrove Desktop, 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 MiniGrove Desktop 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. We also store whether its name uses the localized default or a name chosen by a user.
• 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.
• When MiniGrove runs a cloud machine for a project, we also keep its cloud-machine record: an opaque cloud-machine identifier, the project it serves, the cloud provider, the provider’s instance, data-volume and network-group identifiers, its region and availability zone, the machine image version, its machine type (while it moves to another type, the type it ran as before; and when its last move to another type failed, that type, when and why), its lifecycle state, the account machine it enrolled as, the account it was created for, and its last-active, creation and update times. When we ask a cloud machine to update its signed service software, automatically or because a project member asked, the record also keeps the identifier of that update request, the signed release it targets, when it was requested, when it may next be offered and when it was last handed to the machine, and the last update outcome the machine reported, with the request it answered and when. It also keeps when the machine last checked for updates. For operator-authorized recovery, it keeps an exact signed runtime hold and the latest scoped maintenance request and result: opaque machine, bot and thread identifiers, installation and token generations, supervisor boot hash, request time, inspection fingerprints, filesystem identity numbers, and a bounded outcome. This contains no local paths, journal bodies, prompts or credentials and is deleted with the cloud-machine record. The record also keeps the latest numeric data-disk observation: instance and volume identifiers, region, block and filesystem byte counts, usable and available bytes, the system disk's usable, used and available bytes, and measurement and receipt times. It contains no file paths, file contents or credentials and is deleted with the cloud-machine record. Who asked for an update is written to our server logs, not to this record. A one-time registration grant lets that machine connect without a browser: we store only a one-way grant hash, the cloud machine it belongs to, the short-lived enrollment token it was last exchanged for, and its creation, expiration (at most 60 minutes), use and revocation times. A grant stops working once its machine registers, when it expires, when a newer grant replaces it, or when your API tokens are revoked. Grant records are deleted with their cloud-machine record, which is deleted once the cloud machine is destroyed.
• A cloud machine’s data volume holds the project’s working copies and the full records of its agent conversations. A project owner can ask support to delete a cloud project. Deletion first stops the project: its agent stops taking instructions, its cloud machine is revoked, and its stored model key is deleted. It then destroys the machine’s instance, data volume and network group at the cloud provider, deletes the project’s published web builds, and deletes the project with everything MiniGrove stores for it. The project’s GitHub repository is not deleted. We keep a deletion record: the project, cloud-machine, account-machine and provider instance identifiers, the account that asked for the deletion, the last four characters of the model key, its progress state and when each step happened. It holds no project content, and it names the requesting account until that account is deleted.
• To account for what running cloud machines costs, and to count how long a paid plan's cloud machines ran, we keep power records: when each cloud machine was launched, started, stopped or destroyed and the machine type it ran as, with its cloud-machine and project identifiers. They hold no project content, name or key, and are kept after the project is deleted so its month still adds up.
• We also keep each cloud machine's update history for 90 days: every update request (whether MiniGrove made it automatically, an operator asked or a project member asked, but not which member), every time it was handed to the machine, every outcome the machine reported and every withdrawal, each with the opaque cloud-machine and request identifiers, the signed release it targeted and the time. It holds no project content, name or account, and is kept until it is 90 days old even after the cloud machine is destroyed.
• We also keep the reason each cloud machine stayed on or was started for 45 days: what kept it from sleeping (the kind of work under way, a recent command, a pending update) and what kind of request woke it (a project member, a command, a schedule, but not which member), with the opaque cloud-machine and project identifiers and the times, and no content; this is kept until it is 45 days old even after the cloud machine is destroyed.
• 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.
• A computer's disk report holds only opaque identifiers, what kind of folder each entry is (such as a Unity cache or a Task workspace), its size, the project bot and Task cleanup target it belongs to, whether a Task workspace has changes that are not committed or not pushed and how many days it has been idle, its disks' free and total space, and what the computer cleaned automatically. It never holds a path, file name or file contents. We keep only the latest report, the maintenance kinds the computer announced and when it last asked, a pending request to check again, and the owner's automatic-cleanup setting. The record is deleted with the computer's record.
• When a computer's owner confirms a disk cleanup, we keep the request: the computer, its installation and credential generation, the report it was chosen from, each selected item's opaque identifier, fingerprint, kind and size, who confirmed it and when, when the computer claimed it with a one-way hash of its supervisor boot, and what it reported for each item and in total, and when. It never holds a path or file name. These records are kept until the computer's record is deleted, a revoked computer's included.
• 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.

Homepage appearance: your light or dark choice is kept in a browser cookie for up to 180 days, without changing your account or workspace settings. Choose System in the homepage appearance menu to remove this preference.

Interface language preference: we store your explicit choice (English, Simplified Chinese, or follow browser) on your account and in a browser cookie for up to 365 days. This is separate from your email language. You can change it through the interface language control. Following the browser uses its language preferences, not your IP location.

Built-in instructions MiniGrove writes for the AI on your behalf, such as a roadmap, release preparation or a Merge fix, use your interface language. When one is written later without your browser (a scheduled run, or a Task that finishes opening after you press) and your interface follows the browser, it uses your email language, or Simplified Chinese if neither is set. Project members and the project's computer see these instructions like any other you send.

MCP connections store the application's self-reported name and registered callback addresses, your account and selected project identifiers, allowed actions, resource audience, creation, authorization, expiry and revocation times, and one-way hashes of authorization codes and refresh credentials. Selected project content is sent to the AI client you connect. Access tokens last at most 60 minutes; refreshing cannot extend a connection beyond 30 days. Revocation prevents further access and refresh, but does not stop accepted instructions. Expired access tokens and grants, including their project selections, code and refresh records, are physically removed by an hourly sweep 7 days after expiry. Client registrations unused for 90 days are removed once they have no retained grants. You can see and revoke connections even when new connections are disabled. AI client connections

Each MCP consent also keeps a non-exported authorization checkpoint in the existing API-token store until 7 days after the connection expires. Account credential revocation invalidates it even in a previous server version. Its raw credential is never returned to a client.

MCP instruction provenance stores only the command, connection and client identifiers, plus the opening command identifier that links a new Task to its first execution. It survives connection removal and is deleted with its conversation command under normal transcript retention. Instructions and output use the existing conversation storage; immutable send receipts retain their existing retry guarantees. When Task creation is enabled, a separately authorized connection can create a Task from the project default branch and start its first instruction automatically after preparation. Existing send permission does not grant direct Task creation through the client. Instructions sent to existing tasks can still ask the project AI to create child tasks or hand off work. Automatic child Tasks and handoffs retain the same delegated source.

Projects, collaboration, and uploaded content

• Screenshot annotations: unfinished marks, freehand drawings, arrows, text labels and sampled colors stay in the current browser tab. Pressing Add to draft uploads the screenshot images as ordinary conversation attachments and adds notes and color references to the message draft. Sending shares these images and references with project members under the normal conversation and attachment retention rules. Drawing paths, text label positions and color samples have no separate database records.
• Suggested replies: the main AI may provide one short follow-up, stored with its source message and deleted under the same conversation retention policy. Only the member who started that turn receives the recommendation. Accepting it fills an empty draft; it never sends or confirms an action. Acceptance and dismissal stay on the device.
• Interactive reply extensions: in projects with a compatible online computer, a separate fresh AI request receives the completed reply's final message, a short part of the member's instruction and opaque references to its existing attachments or suggestions. It uses that reply's Provider and model with tools disabled. Organizing uses the project’s current AI payment method in addition to the original reply. We store the source identifiers and fingerprint, original model and model-access generation, bounded input and structured extension, queue/attempt status, worker/lease identity, error code and timestamps. Project members can read the extension. Unsubmitted answers stay in the current browser tab. In the web app, clicking an option sends that choice directly to AI as a reply to the source message; check feedback requires its explicit send button. Custom answers use the ordinary chat composer. Older clients may fill an editable draft instead. These replies grant no operation authority. Stopping an attempt ends its pending generation and preserves completed extensions and already-incurred use. Extensions and their attempts are physically deleted with their source message under the conversation retention policy, or with their project. We do not copy attachment names or expired operation inputs into an extension's references.
• Sandbox cards: the AI may present an answer or a supplementary page as sandboxed HTML. We store that page in our web build storage, and its title, size, fingerprint, presentation role, project and source message in our database. Members who can read the message open the card at a short-lived signed address; it runs isolated from MiniGrove, with no network access. Picks made in a card stay in the current browser tab, and a draft it fills is sent only if you send it. Once their source message is deleted, under the conversation retention policy or by a member, the next cleanup pass physically deletes the card and its page; cards are also deleted with their project.
• Interactive reply attempt usage: separately from the original turn, we store each attempt's identifiers, Provider/model, original payer and model-access generation, token and estimated-cost accounting reservations, reported token counts, estimated cost when available, member-share identifiers and amounts, receipt fingerprint and report/creation times. Missing usage retains its reservation rather than counting as free. This includes subscription and operator-key attempts in the independent usage records; only MiniGrove-funded attempts have a share of its allowance. Usage is deleted with the source message. A worker readiness record contains the computer identifier, boot fingerprint and last-seen time and is deleted with that computer.
• Interactive reply usage totals: we keep project and UTC day, admitted attempt count, reserved or settled token totals, and known estimated-money totals for accounting compatibility. These totals impose no additional organizing limit. They contain no person, source message, model or content. Background cleanup removes old day rows once they leave the 3-UTC-date window; deleting the project removes them too.
• Project names and identifiers, who created each project, whether its tree is private or public, its hosted-web hostname label, and its default machine selection. We store the member-confirmed game name separately from the project name until project deletion. Members can read and replace it; it is used in release preparation and the owner's publish form, and becomes public only through the owner's publication. We store project creation and update times, membership roles, activity times, and invitation records. Each project initially receives an ordinary shared Saved Prompt. Owners can edit or delete it with other shared templates. A legacy opening research prompt column and its migrated template identifier are retained for compatibility until a later release or project deletion; its migrated copy follows Saved Prompt retention. Invitations include the recipient's email address and the inviter, status, role, and timestamps. 在付费套餐覆盖的项目里，我们还记录每位成员是否按套餐的成员规则加入、是否占着项目的不付费名额、是否已停用以及各自的时间，并记录最近一次提醒成员使用将要结束的时间。停用的成员记录会保留，直到成员离开、被移出或项目删除。
• Search-tree tasks 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 task 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 tasks created in or imported into MiniGrove, including the stable task identifier and complete task object, plus searchable projections of the task title, its optional description, and its task 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 task or the database, and creation, update, orphaning, resolution, and withdrawal times.
• Retired project Task identifiers excluded by a reviewed database-authority migration decision, a legacy Discard accepted by an older release, a completed ending-workflow Delete, or an empty provisional Task retired when its branch is attached to the idea 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 Task cannot inherit an old link, comment, or receipt address. The reservation does not store the excluded Task body.
• Task-to-conversation bindings that record which project task 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.
• Task Provider-switch replay receipts, including a stable request identifier, project, Task 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.
• Task resolution requests, including an opaque resolution identifier, Task and project identifiers, the requested action (Withdraw, Keep, or Kill), whether the request archives the Task as a record without a verdict, the reason required for Kill and any reason retained for a legacy Keep, an actor type, identifier, and display-name snapshot, the expected Task 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.
• Task ending workflows, including an opaque ending identifier; project and Task identifiers; the Merge, Rejection, or Purge action and whether it archives the Task (Merge & Archive or Archive) or reopens it after a Merge; automatic PR merge authorization, including automatic Kit updates that archive the Task, and whether it keeps the Task open or executes Delete after verified landing; the linked Merge ending for a Delete continuation and when PR merge was authorized for execution; status, stage, and generation; actor type, identifier, and display-name snapshot; original lifecycle and frozen Task 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. Delete confirmation is recorded when you authorize deletion, before the computer freezes and checks its targets; older requests may ask for confirmation after that check. For Rejection, this can include the rejection category, draft reason, and confirmation time. For Archive, this is the member's optional reason for leaving work unmerged; when one is given it is also published to the project's decision ledger in the connected repository. 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. When the member also asks for the Merge to start again after that AI turn, we store the automatic-merge status, the reason it was skipped, the automatically started ending link, and when it settled. If a pull request conflicts with the default branch, MiniGrove may cancel that Merge itself and start it again once; we then store when the conflict was detected beside the same automatic-merge fields, and on the Merge it starts, a link to the Merge it replaced. Where MiniGrove's automatic recovery is enabled, if a stage of a Merge was interrupted before it finished, MiniGrove may likewise cancel that Merge itself, keeping its work, and start it again once; we then store when it cancelled the interrupted Merge beside the same automatic-merge fields, on the Merge it starts, a link to the interrupted Merge, and whether a Merge paused before this recovery existed was opted into it. We also store whether a Merge's checkpoint included its review, when a Merge was granted the fast landing step, whether it landed that way, and when MiniGrove began opening its PR. So that every ending keeps moving, we also store when it entered its current stage, when MiniGrove last checked it and when it will check next, and when operators were last told it had gone unchecked.
• Queued Merge requests: when a member confirms Merge or Merge & Delete while the Task still has work running or queued, we store the project and Task identifiers, the requesting user identifier, whether the Task stays open or is deleted after landing, the request status (waiting, starting, started, withdrawn or skipped) and the reason it was skipped, the ending it started, and when it was requested, settled and last updated. MiniGrove starts that Merge as the requesting member once the Task's conversations are idle, or skips it after 24 hours. One request is kept per Task: a new request replaces a settled one, and the request is deleted with the Task or the requesting account. AI instructions a member sends while a Merge freezes the Task are stored as ordinary queued requests and are not sent to the computer until the freeze is released.
• Structured Task-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 Task-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; whether capability binding waits for the first claim; the process-boot hash that offered automatic Delete recovery, when prepared; 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; the fast Merge's current land sub-step (syncing, resolving a conflict, the risk check or pushing), when its computer reports one; 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. When a computer restarts during the AI review and the review is run once more, the receipt also keeps the interrupted attempt's one-way task and report fingerprints and its exact response, so that attempt's lost response can still be replayed. A blocked stage may add a bounded refusal reason identifier, supplied by the member's machine or by the server's own verification step (such as which Merge check failed), 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. A blocked review or checkpoint may also add a short AI-written summary of what must be fixed: one headline of up to 120 characters and up to 5 must-fix lines of up to 160 characters each, with the count of any further must-fix findings. It is written by the AI on the member's machine, stored in the task receipt, and shown to project members only while that ending is paused; it is kept for as long as the ending record is and removed with it. It is shown as the AI's own words and never used to decide anything. Apart from that summary, 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.
• For Delete on compatible computers, we separately record the authorized origin head and each cleanup target’s actual local head, plus the named authorization to accept it. A different local head does not expand the deletion scope. A consented Delete paused before cleanup may receive one new mechanical freeze generation after all target computers negotiate support; the original task reports remain unchanged. During an active Task-ending workflow, the compatible executing project bot may receive the exact Task 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 Task'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, Task and project identifiers, Keep or Kill conclusion, decision source, any MiniGrove-captured reason, actor type, identifier, and display-name snapshot, observed origin head, Task 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 Delete receipts that survive Task deletion, including the project, retired Task, 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; completion time; and, for Merge & Delete, the completed Merge identifier, generation, and original executing computer identifier, so that computer can release its prior freeze after deletion. Ordinary Task 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 Task. The receipt contains no Task 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, Task 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 Task head and local branch diverge, the bounded local-only commit hashes and subject lines, Task, 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; when local cleanup failed after the origin branch was removed, the time a member asked the owning machine to retry, the identifier of the conversation close command that carried the request and which member asked, and, if a member then finished the Withdraw without removing the local folder, a keep-the-folder fingerprint, which member chose it and when (the worktree folder and local branch then stay on that computer, and MiniGrove does not ask it to remove them); 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, Task and project identifiers, exact native-session provider, source key and opaque cleanup-target hash, acknowledging bot identifier, retained Task 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 Task 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. For remote recovery we also store an opaque directory recovery fingerprint, whether that computer can delete the directory, the member's choice (keep or delete), which member made it, and the check, authorization and retention times. When a member chooses to keep the files, they stay in a recovery directory on the original computer and require separate cleanup; completing Task deletion does not delete those retained files. When a member chooses deletion, the original computer deletes that directory and everything in it. When local cleanup keeps failing, its computer was removed from the project, or it has been offline for days, every current project member can choose to stop waiting for that computer: the Task deletion then completes without that computer's cleanup receipt, we store which member chose this and when, and that computer's working folder and any programs the Task started there may remain and require separate cleanup. During failed deletion, including the initial worktree removal and automatic continuation, we store an opaque cleanup inspection fingerprint. The cleanup lock diagnostics contain a bounded category, up to 8 blocking programs, each with its process ID and either a fixed application label or its process name (the program's file name, without its folder or arguments), a partial-coverage flag, and request/check times, visible to project members. They contain no file paths, command lines or machine-wide process list and are cleared when the recovery target or choice changes, files are retained, or local cleanup completes. When the computer supports force termination, every current project member can explicitly authorize ending the listed blocking programs, including on another member's computer. Unsaved work may be lost. We store opaque process identities, the confirming member, request and claim times, and the bounded execution result. These records are cleared with the same recovery transitions described above. Consent expires after 2 minutes; the computer rechecks process identity and file or directory use before acting. We also keep 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 Task and session bindings are gone. These server records contain no local filesystem path or repository URL and remain with the project after the Task and its active session bindings are deleted, so an offline machine can converge without recreating the Task; deleting the project removes them. In projects that have enabled Task-ending workflows, new Delete requests use one confirmation, followed by freezing and verification before cleanup. Projects that have not enabled those workflows still offer the leaf-only immediate-delete request: after confirmation, Task and server session records are deleted before external cleanup. That path rechecks current project membership and refuses a Task already owned by an ending workflow. Status, bot receipt, and background cleanup consumers remain available so accepted requests can finish.
• Queued AI requests store the combined prompt, contributions, sender, request fingerprint, order, predecessor or exact current-turn target, editing and execution status, version and timestamps. Project members can read these requests; the sender or a project owner can edit, cancel or reorder a request before preparation starts. Edited-away contribution text is removed, while content-free retry receipts remain. Queue records follow conversation retention and are physically deleted with the source message or project. Requests for a later turn pause after 24 hours until confirmed; undelivered current-turn messages follow the ordinary delivery timeout. A queue upgrade reminder stores only your dismissal time and is deleted with project membership. Unsaved queue edits stay in this browser's local storage until saved or discarded. Only the same member's attended composer inputs combine. Other members and automated work keep separate requests. An owner editing another member's request cannot reuse that member's kept website sign-ins.
• 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. A question you type without a selection (Side questions) is stored the same way with an empty quotation and a question marker; its source is the conversation's latest settled AI reply, so it is deleted with that reply, and only a machine that announces the question ability answers it. A selection from a Task ending stage's output (Merge) is marked as a detached explanation: the machine also receives that stage output as context and starts a fresh provider session instead of forking, so it works while the ending runs and after the Task closes. Explanations do not run project actions or create Git worktrees. A parallel-context marker records that a supported machine may fork AI history while the main task runs, without holding its execution lock or sharing cancellation; follow-ups continue the private snapshot. Older active jobs keep their original exclusion until they settle. On machines that support concurrent explanations, separate selections can generate at the same time within the machine’s request limit; stopping one explanation does not stop the others. 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, announced abilities 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 task, optionally attach a native session, and initialize a newly created provisional Task's title, optional description, summary, and parent position. Registered project bots may read that shared title, description, 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 task — 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 task or is only a discussion, because that decides what a project’s machine is asked to do with what you write there, and stores legacy discussion-end timestamps. Legacy End requests hide a discussion from every member’s list and old conversation link without immediately deleting its messages or native AI history; those older markers do not record who ended it or why. Current member controls distinguish Archive from Permanently delete. Archive keeps chat and images read-only and allows cancellation for 60 seconds before cleanup. Permanently deleting a discussion removes its chat, attachments and archive, and queues owned native AI session cleanup. Saved decisions and Tasks remain. The initial research Saved Prompt defaults to an ordinary discussion. Owners may edit its content and launch mode or delete it like any shared template. Each sent opening is retained with its conversation; editing or deleting a template does not rewrite existing conversations or expand 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. Task and decision suggestions are stored for member confirmation; saving an Idea does not start an agent. Only open-and-start, or a member asking the assistant to create a Task, 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 Task-link editing is available, a bot running a live instruction may read and update only that conversation's bound Task links, using a revision check. When Task creation is available, a live instruction in a work conversation or a discussion may also create a Task under a specified parent and start a separate task on the same machine from the project default branch, in the issuing member's name. In a discussion the assistant is told to do so only when a member asks, and the discussion itself stays read-only with no Task of its own. System discussions (the roadmap's daily update and project advice) cannot use this capability. This does not deploy a build, change the project's main address, or edit repository Task JSON.
• When Task cleanup is available, an AI executing a current member's live instruction in a work or discussion conversation may discard explicitly selected other leaf Tasks, 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 Task, 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.
• On compatible computers with shell access enabled, the assistant can allocate task-owned temporary directories, extra branches, worktrees in other repositories, and background processes. Delete stops those owned processes and verifies removal of the allocated resources before it reports success; failed cleanup is retried. A private inventory stays on that computer until cleanup is acknowledged. It contains local allocation and repository identities, generated branch names and operation hashes, without saved command arguments or environments; the Service receives only its existing cleanup status. Resources created separately through shell commands and shared caches are not automatically included.
• 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 task tree, a bounded window of recent project activity, the conversations you yourself can list, one of those conversation's messages and AI replies, a task's comments, and a search of MiniGrove's copy of the project's decision ledger (the lines already committed to its repository, described below). These reads are performed for the member whose instruction is running and are limited to what that member could already open in MiniGrove. Messages members send to the team with the AI destination switch off are included too — as are messages mirrored from a bound Telegram or Feishu group, including from people with no MiniGrove account, schedule notices, and the assistant's own team notes — marked as team notes: the bot reads them as context and never runs them, and like everything else it reads they are given to the AI model running the instruction. Those conversation and Task context reads add no account email address, repository URL or local path.
• When project history, current project state or conversation search is available to the project's assistant, it may use those reads while answering an instruction. A human instruction reads only what its issuing member can open; an instruction explicitly issued by a project machine uses that machine member's project access. Returned information is sent to the AI model running the instruction. Current state includes project names and identifiers, registered computers and their registrants, member names, account identifiers, roles, email addresses and membership dates, visibility and default computer settings, and canon metadata when available. Only an instruction issued by a current project owner can return invitation recipient email addresses, roles, inviter names, creation, expiry and settlement dates, and pending or recently settled status. History returns the structured operation metadata described above; conversation search includes messages, AI replies and labelled team notes from readable conversations. Results include links to the corresponding project pages. These reads do not return credentials, model keys, machine-owner files or operator data.
• 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, the default-branch commit where the Kit manifest was found missing, any synchronization error, and the exact project structural branch exclusion list that should not create Tasks. 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 Task panel can show which decisions mention a Task without a machine being online. The copy covers every line of the ledger file and of its archive files. Each copied line holds the whole line as written (its identifier, type, date, what was decided and why, the alternatives considered, the outcome, which Tasks or project it applies to, which earlier decisions it replaces, and the files it links to), the file and line number it was read from, a hash of the line, and the commit the copy was read at. For each ledger file MiniGrove also keeps its path, Git blob identifier, size, line count and when it was read, so a file that has not changed is not downloaded again. It is a copy and never the record: a file's lines are replaced wholesale each time that file is 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, repository-selection 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, the Kit tool packs the new project starts with, bounded setup state, when the setup last made progress, error metadata, and a one-way hash of the single-use GitHub return nonce. Historical list-removal timestamps are retained for compatibility; previously hidden failures are visible again for cleanup. Permanent deletion removes the setup after the requested resource cleanup is confirmed. They do not store local workspace paths, provider credentials, or repository contents. Project setup deletion requests store the owner, opaque project and setup references, GitHub deletion choice, hashed creation request identities, the original setup date, progress, retry metadata and timestamps. Until cleanup finishes they also store the project name and exact GitHub installation, repository and owner identifiers. Completion deletes that name and GitHub metadata, retaining a content-free cleanup receipt that prevents deleted requests from recreating a project or resetting creation limits. Account deletion removes these cleanup receipts. Dedicated cloud computers and working files, published web versions and project records are deleted after cleanup is confirmed; GitHub repositories are deleted only when explicitly chosen. Local file cleanup requires confirmation from the computer. For a failed setup on an unavailable computer, the owner may instead reauthenticate and explicitly authorize online-only deletion. Its receipt records the unverified local disposition, execution fence and credential expiry timestamps; it does not claim that local files or processes were removed.

  Online cleanup starts immediately after confirmation. If you keep the GitHub repository, previously issued access may remain valid for up to 60 minutes.

• Managed project runtime authority stores the lasting relationship between a provisioned project, the account that owns its selected computer (the project's creator), its active project agent, signed Kit identity, execution generations, and versioned execution-policy contracts, including whether the project is owner-only or runs on a computer MiniGrove created for that project alone, where every member may instruct it. 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 task 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 automatic machine membership began, and, for an agent created by managed project setup, the account-owned computer 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 MiniGrove Desktop 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 Task-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. Separately, it stores the skill inventory it most recently reported: the name, kind, declared description and argument hint of every skill and slash command a conversation on that machine can invoke, including the machine owner's user-level, plugin and AI-provider built-in ones, which AI providers can run each, and when it reported that inventory. Every member of the project can see this inventory. It does not include prompt bodies or local paths, and it is deleted when the machine is revoked. It also stores the Kit version the project's files on that machine carry, the newest Kit version that machine can install for the project, and when it reported them. As with API tokens, the complete credential is shown once and is not stored by the Service. Each registered computer automatically becomes a machine member: it can read project deployments and run project schedules after its registrant leaves, until the computer is revoked or its owner's account is deleted.
• 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, 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. Work conversations and discussions started on the panel, or adopted from before the binding, get a status card in the bound group showing their title, computer and status; their earlier history is not posted there. Ending a discussion stops new messages from entering MiniGrove; messages already in Feishu remain there even after MiniGrove's retained records expire. 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.
• From the project task board, members can start a Task using its stored description. MiniGrove saves that opening instruction with the existing conversation launch receipt, releases it only after the workspace is confirmed, and uses the ordinary instruction queue. Board columns are derived from existing Tasks, conversations, response requests, and merge evidence; they do not store another acceptance or completion status. 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), machine-reported failure reasons (a reason code, disk-space byte counts, the hostname of the model API service that refused a request or could not be reached, or the id of the model it refused), 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. To show the unread dot on your Tasks on every device, we store how far you have read each Task's conversation: one timestamp per Task, visible to nobody else, deleted when you leave the project or when the Task or the project is deleted. 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 Task opening. Until that Task opens, project members see the opening task in the new conversation, and still see it there if the Task fails to open. 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. When preview feedback is enabled, Preview-edit requests retain your comment, selection coordinates and viewport size, capture time, source release, fixed parent task/branch and child conversation, automatic integration choice, whether the subtask publishes a web build before merging back, request digest and progress, exact commit and check digests, bound session identities, integration task receipts, whether the parent task was asked for its check and build configuration (and why not, if it was not, or why the subtask's recheck after it was not queued) and child/parent release identifiers. They are shared with project members and expire with the opening command. Any project member may remove a request whose opening command failed or expired before its child conversation opened; that deletes the request and that conversation's messages and screenshot records at once, and the stored screenshot files right after (if that fails, the storage cleanup deletes them later). An unfinished integration retains its request and associated commands until its remote-write outcome is reconciled, so expiry cannot release a live repository-write hold. After reconciliation the normal command expiry applies. Deleting the project removes these records. The two screenshot attachments follow the normal image retention period; the opening request holds them until its first task starts. No second permanent image copy, page DOM, storage or URL query/fragment is saved for this feature. 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 asked to run it, though an assistant reading the conversation sees it as context. An agent may also propose new tasks alongside its output — a name, an optional description, an opening brief, where it would hang in the tree, and, when it judges that an open task already covers that work, which task and why — and we record which of those a member chose to open and when, any edited name, description or brief, and the task 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 task that was written down earlier, we record which task it was opened for, so the work attaches to that task 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. These conversations are shared: every member of that project sees all of them, and the returned output is whatever the machine printed. Command-bound Task-link replay receipts store the command and operation identifiers, a one-way request digest, the acknowledged Task 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. For scoped approval we also record the canonical checkout-relative file target or the complete scrubbed command display and a one-way digest of the original command, the checkout-start execution context, duration, file/directory or exact-command/all-commands rule, saved grant identifier and whether the call was automatically allowed. Saved permission grants record the project, computer, authorizing membership, optional conversation/Task, file-write or command-execution rule and creation time. Project members can inspect and delete grants in AI 授权; revoked grants are physically deleted, while prior call receipts retain their audit fields until their command is deleted. Grants expire with the authorizing membership or deleted computer/project; conversation grants are also deleted with their Task. Inactive grants remain removable in AI 授权. A grant cannot enable a tool disabled by the computer owner. Sent notes and mentions follow the same retention and removal rules as other conversation messages. Command-bound Task creation receipts store command and operation identifiers, a one-way request digest, the new Task and conversation identifiers, the first task prompt, startup state, setup and started command identifiers, and receipt time. The instruction that created them shows project members each new Task's title, parent task and startup state, with a way into its conversation. That conversation shows project members the first task prompt while it waits to be sent, and keeps showing it if startup fails. They are removed when either their source or setup command is swept under the conversation retention policy; removing a receipt does not remove its Task. Members may also sort a project's conversation list into named groups; we store each group's name, its order, who created it and when, and which top-level task or discussion sits in which group. Groups are shared with every member of the project, forget their creator when that account is deleted, and are deleted with the project; a task's or discussion's place in a group is deleted with that task or discussion, and deleting a group returns its items to the list without changing any conversation. For each conversation title we also record whether a member, the AI or its first message chose it, so tidying the list never renames a title a member gave. For each task we also keep when each of the agent's messages began, the kind of step the agent was last on (a category such as building, running tests or playing in a browser, never the command it ran) and when that step began, which is shown only while the task runs, and the plan the agent states for the task, if it states one. We also keep fixed-version check scopes and fingerprints, a retained preview label and evidence-file identifier, an optional work budget and a saved-work checkpoint fingerprint. All of these are shared with project members like the output itself and deleted with the message. When a member records a decision, the agent that proposed it may also name open conversations it matters to, and how much it may affect them. Conversations the member has asked to be told automatically receive it at once, as an ordinary message from that member recording which recorded decision it told the conversation, who recorded it and in which conversation; the other named conversations wait for the member directing them to choose, and a teammate's conversation is never told without that teammate. We store which of these happened on the source message, for as long as the message is kept. We also store which conversations a member asked to be told about another conversation's decisions automatically, with who asked and when, until they turn it off or the project is deleted. An agent may also propose a handoff: one message and some of the conversation's files, for one or more other Tasks. It is sent at once, as the member whose message the agent was answering; each Task then receives an ordinary message from that member in its current conversation (or, for an idea, in the conversation it opens). After 10 such automatic handoffs in a row, when that member is no longer in the project, or when that member's handoffs in the last few minutes have reached the same limit a member pressing them has, it waits until a member reviews, edits and presses it, and a press starts the count again; a Task it could not reach waits the same way. We store the proposed text, Task and file identifiers, and for each Task which message and conversation it was sent as, in whose name and when, or who dismissed it and when. Each delivered message records where it was handed off from, the other Tasks the same send reached, and how many automatic handoffs in a row led to it. The files are copied into each receiving conversation and expire on the original file's clock; deleting one copy does not delete the others. While an offer waits we keep why: the number of automatic handoffs that led to the wait, or that no member stood behind the turn, the limit had been reached, or the send failed. Any member can turn on autonomous collaboration (unlimited automatic handoffs) for a project, for a set time or until a member ends it; while they are open, neither the count nor the limit above stops an automatic handoff, and AI credit keeps being used. For that we store who opened them, when, and until when. Ending them deletes that record at once, and a timed opening that ran out is deleted 24 hours after it ended; the project's history keeps who opened or ended them and when, as it does for other settings, and goes with the project.
• 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: MiniGrove Desktop 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, MiniGrove Desktop keeps retrying the cleanup. The image bytes are not uploaded unless a member opens that image’s line in the conversation; 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.
• Project advice is on by default. We store the project's enabled/paused preference, who changed it and when. This preference remains until the project is deleted, including when its computer or owner changes. We also store the selected owner and computer, enablement and optional end time, progress cursor, next eligibility scan, inspection status, and failure category; this execution binding remains until its project, account or computer is deleted. Suggestions, their evidence and reviewed commit, considered-by/time with the member's optional reason and short note, the suggestion's shared discussion, replies and each member's read/later state are shared with current project members except that read/later state is personal. Discussion links start its ordinary read-only discussion on the selected computer, issued by the member who opened it, or reopens the one already started: project members see these discussions in the conversation list, it follows the conversation-retention period, and the suggestion is added to each instruction sent to the computer in it. Choosing Start work creates and starts one ordinary work Task as the accepting member, using the suggestion as context. We store its thread, computer and opening-command identifiers with the suggestion so retries reopen the same work, even after completion; removing that work does not erase this receipt. Feature records are deleted with the source or inspection conversation, or with the project. Underlying AI execution history, including context copies, follows its own conversation-retention period described above. Default checks select a current project owner's computer and use its current AI account and allowance. Registration alone starts no AI or wake; only new progress, or the selected computer's disk being nearly full with nothing left to clean automatically, can start a check. A check started by a full disk also stores, from that computer's latest disk report, the computer's name, its free and total space, when it was checked, what it cleaned automatically that day, and up to five of the project's Tasks with their titles, sizes, idle days and whether they hold uncommitted or unpushed changes; project members see this with the suggestion, and it is deleted with it. No external message or work Task is created automatically. Checkup repair Tasks run only after a current member selects findings and accepts automatic merging and closing. We retain that member, the exact report snapshot and selected findings including their evidence and paths, the planning instruction, independent repair groups and their instructions, ordinary Task and command identifiers, exact workspace identities, progress and failure categories, check digests and the verified merged commits and pull request. They are shared with current project members. The repairs use ordinary AI capacity and funding. After verified landing, closing deletes their conversations, attachments, workspaces and branches; the repair summary and evidence remain for 180 days after the batch settles. A paused batch stops automatic processing after 7 days and keeps its ordinary Tasks. Deleting the project removes these records. Project checkups run only when a member starts one. We store who started it, the default-branch commit it began from, its status and failure category, the report's summary and coverage, and each finding with its evidence, repository paths and suggested step, plus who marked a finding as opened as a Card, considered or not taken, and when. These records are shared with current project members and are deleted with the checkup conversation or with the project; a Card opened from a finding is an ordinary Card. Repository health is measured without AI by the project's checkup computer, from the default branch. We store the latest measurement: the commit it read, when, which computer measured it, sizes, counts, image dimensions, audio lengths and import settings, the engine project folders it found, and the repository-relative paths of the files behind each finding (at most six per finding, or six groups of four copies for duplicated files, plus the file that refers to a missing one), never file contents. We also store when that computer last asked whether to measure and was asked to, when one of its reports could not be stored, a member's pending request to check again with who made it and when, and each shared answer to a finding (opened as a Card or left for now) with who gave it and when. When a member starts a project checkup, a short summary of these findings, without the names of credential-like files, is part of its instruction to the AI. These records are shared with current project members and are deleted with the project; a Card opened from a finding is an ordinary Card. Project members can add, replace and remove project-shared API keys. Project-shared API keys are encrypted with managed KMS. We keep their reference name, service, purpose, version, who saved them and when, a save-retry identifier and keyed fingerprint, and delivery/cleanup records naming the project, command, worker and process generation. The server and consuming task process can access plaintext. Current and future project members can use these keys through project programs and may obtain them through code execution. Values are not sent as chat messages or model inputs. Removing a key deletes its encrypted value immediately and blocks further delivery; offline cleanup remains pending until the computer confirms owned process exit. Removal does not revoke the key at its provider. Non-secret key metadata and delivery records remain until the project is deleted; requests and per-command support records follow conversation retention.
• When an agent asks to run a tool call that its machine will not run without a member's approval, we keep a tool-permission request: the tool's name, a one-line summary and a bounded detail of what it would do (for example the file it would write or the command it would run), whether it is waiting, allowed, denied or withdrawn, which member answered and when, when it was asked, and where it appeared in the reply. A request has no answer deadline: it waits for as long as its turn does. MiniGrove Desktop shows paths relative to the conversation's checkout and replaces its other local directories and credential-shaped text before sending. A tool-permission request is removed with its command under the conversation retention policy. For scoped approval we also record the canonical checkout-relative file target or the complete scrubbed command display and a one-way digest of the original command, the checkout-start execution context, duration, file/directory or exact-command/all-commands rule, saved grant identifier and whether the call was automatically allowed. Saved permission grants record the project, computer, authorizing membership, optional conversation/Task, file-write or command-execution rule and creation time. Project members can inspect and delete grants in AI 授权; revoked grants are physically deleted, while prior call receipts retain their audit fields until their command is deleted. Grants expire with the authorizing membership or deleted computer/project; conversation grants are also deleted with their Task. Inactive grants remain removable in AI 授权. A grant cannot enable a tool disabled by the computer owner.
• When an agent needs you to sign in to a website, or to allow one submission on a website you signed in to, we keep a browser request: whether it asks for a sign-in or a submission, the site's domain, the page's address without its query or fragment, the agent's one-line reason, whether it is waiting, accepted, declined or withdrawn, when it was asked and answered, and where it appeared in the reply. Only the member who sent the instruction can see the request's live view of the page, use it or answer; other project members see only whom it is waiting for and which site. While a request waits, the newest picture of the page and, while you sign in, what you click and type are held only in our server's memory until that computer takes them; they are never written to our database or logs, and they are cleared within about a minute after the request ends, or when the server restarts. What you type goes straight to that computer's browser and is not saved. The AI never sees what you type into a password field, but text you leave in an ordinary field on the page, such as an email address, can be read by the AI when it reads the page afterwards. A browser request is removed with its command under the conversation retention policy, and its notification waits for an answer like a tool-permission request. If you finish signing in, we keep a website sign-in: the project, the computer, your account, the site's domain, when it was made and last used, and a key sealed by our key-management service. The computer keeps your signed-in browser state encrypted with that key; we never receive the state itself. We hand the key only to an open instruction you sent to that computer, any of your instructions there and not only the one you signed in for, so another member's instructions open the site signed out. While one of your instructions is open on that computer, anyone who can run programs on it could use the computer's own credentials to get the key, and so use or read your signed-in state. In a conversation other members have written in, their earlier messages stay in the AI's context after you sign in through it; to keep them out, have the AI sign in from a conversation only you have written in. With each instruction we also record whether its member typed it in MiniGrove's own message box, on the web or the phone app; only such an instruction can ask you to sign in or use your kept sign-in. A website sign-in does not expire from disuse: it is kept until you sign out of it in Settings, which deletes the key at once and leaves the computer's copy unreadable, until you leave the project, or until the project or the computer is deleted or revoked, which deletes it too. We record where each one came from: that computer's own browser, or your own browser or phone. When an agent opens a site with your kept sign-in and then has to ask you to sign in there again, the website has ended it: we record when, Settings shows that it needs reconnecting, and you get a notification naming only the site, on your phone too if you allowed that there. Signing in to that site again, or signing out of it, settles it. A sign-in request is also sent as a notification to the phones where you use the MiniGrove app and allowed it; the notification names only the website, never the agent's reason.
• You can also hand a website's sign-in to one of your project's computers yourself, from your own browser with the MiniGrove browser helper or from the MiniGrove app. The site's cookies and site storage, and nothing from any other website, are encrypted end to end to that computer's key in your browser or on your phone before they are sent; we store only that ciphertext, cannot read it, and give it only to that computer, which keeps it as a website sign-in like the ones above. We keep a record of each handoff: the project, the computer, your account, the site's domain, whether it came from the browser helper or the app, the sign-in request it answers, whether it is waiting, delivered, kept, failed, cancelled or expired, a fixed failure reason, the website sign-in it became, and when it was started, delivered and kept. The ciphertext is deleted as soon as the computer has kept the sign-in, when it fails, when you cancel, and at the latest 24 hours after you started the handoff: an expired handoff is refused at once, and a cleanup that runs every minute deletes its ciphertext, normally on its next pass (an outage can delay it). The record itself is deleted 7 days after the handoff expires. For this we keep each computer's import key: its public half and its identifier; the private half never leaves the computer. A phone's handoff is confirmed by that phone's confirmation keys described above, with a single-use challenge stored only as a hash. For the browser helper we store only one-way hashes of a pairing code, which works once and lapses after 5 minutes, and of the credential the helper receives for it, with when it was paired and last used. That credential can only send your own handoffs started on the website and read how they stand. Removing the helper in Settings, resetting your password or deleting your account deletes it.
• Machine-issued instructions record the machine issuer separately from human authors. Daily schedules a member creates for a conversation, or to open a new Task under a parent task each day: the instruction text sent each day, the time of day and time zone, which conversation or parent task and which machine it targets, who created it, whether members are notified, whether successful completion notices are sent, its optional end time, and its next due time. A configured end stops new scheduled runs; a run already admitted may finish afterwards. 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, skipped because the plan's cloud computer hours were used up or the project's own key or ChatGPT subscription needed a paid plan, skipped because the project was parked and its account had no free active project, or a Task that opened without starting), which conversation it opened, and the note it left, for 90 days; the Tasks, instructions and output it produced are ordinary Tasks and conversation messages under the retention above. When the connected computer's MiniGrove Desktop 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.
• When automatic Kit updates are available, they are on by default for every project with a repository and a project owner's computer that can run them (never a member's own computer by default). There is no project settings section or off switch; owners reach updates needing attention from their notifications. A project's Kit is updated only together with an update of its cloud computer that brings a newer Kit, never on its own, so a project on an owner's own computer is not updated automatically. Each such project has one system schedule (the computer it runs on, its daily time and zone, whether it is on, the owner it is recorded under, and its runs as above, including the Kit version each run was for and whether each run's merge started and why not). Each update opens a Task and a conversation that members are not shown, on that computer and as its machine member; a project owner can open that Task's ending, and its Task page, when the Merge or its cleanup needs them. When the update finishes, MiniGrove starts that Task's Merge & Archive on behalf of a project owner, which merges it into the default branch through a pull request. If one Kit version is tried as many times as allowed without landing, or an update's Merge stops and needs a person, each project owner gets one notification that records only that version. The instruction it sends, the AI's output and the Task are stored and deleted like any other Task and conversation messages under the retention above. Where MiniGrove's automatic cancellation is enabled, an update's Merge that stopped before any pull request merge was requested, and is still stopped 12 hours after its owners were told, is cancelled by MiniGrove itself: the Task's branch and work are kept, the owners' waiting notification for that stop is removed, and the update is tried again later. Where Kit updates run as a machine job instead, no Task or conversation is opened: only while a service update asks for the project's Kit, a project owner's computer runs the new Kit's update script in a separate copy of the default branch and sends MiniGrove the changed Kit files. MiniGrove's GitHub App commits them as MiniGrove, never as a member or a member's GitHub login, and pushes that commit straight to the default branch with no pull request and no one reviewing it, never by force and only while the branch has not moved since the update read it; if the repository's own rules refuse that push, nothing is changed, and MiniGrove pushes the same commit again, about once a day, for up to 7 days, so it lands once an owner lets MiniGrove's App bypass those rules. AI is asked only about Kit files this project has edited, through that computer's AI account and offered no tools, and decides each one without asking anyone; a file it cannot settle is left for /mg-kit-update. We do not keep the changed files. For each update we store the computer, the two Kit versions, the default branch and its commit, which AI provider settled conflicts, the per-file decisions and reasons the update reported, the commit, status, failure code and message, when its push was first refused, and timestamps, for as long as the project exists; for each owner's computer we store when it last asked for an update, and for each project when a service upgrade last asked for its Kit, and which service upgrade request last opened a fresh window of tries, and when. When the repository's rules first refuse a Kit version's push, each project owner gets one notification that records only that version and asks them to let MiniGrove's App bypass those rules; if one Kit version uses every try, or its push is still refused at the end of those days, each owner gets one more. A service upgrade also updates project Kits to at least its paired version and waits for the active workers to confirm adoption. We retain the upgrade retry identifier, the retry identifier on each Kit attempt, when the upgrade last asked for the project's Kit, and an opaque machine-boot hash that confirms Kit adoption. A Kit published on its own waits for the next service update.
• Files and images you attach to a tree-chat message, and files a machine produces in reply — their contents, filename, type and size, together with who uploaded each one, when, and which conversation it belonged to, plus an integrity fingerprint of each file that passes through MiniGrove's servers. A large file instead goes straight between your browser or the machine and MiniGrove's file storage, so it has no fingerprint. A file you send to the AI is also saved in that conversation's working folder on the computer that runs it, and is deleted with that folder. These are shared with the project the same way the conversation is, and they are deleted 180 days after they are attached, or sooner if the message that carries them is deleted. Messages are kept for 180 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 remaining temporary file attachments stop being reachable when that checkout is cleaned up; images fetched for the chat and retained by an archive remain under their original attachment retention period. 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.
• Task comments and their archive have been permanently removed. Historical comments, their mention records and associated notification copies are deleted during the removal rollout. Conversation messages and conversation mentions continue under the retention rules above.
• Historical Task likes, including the project, task, your account, and when you liked it, remain stored after the feature's retirement. New likes are no longer accepted, and counts and member lists are no longer displayed. You can permanently delete all your historical Task likes in Account settings, including likes on closed Tasks. Deleting a Task, your project membership, or the project also removes the corresponding likes. The Service continues to remove invalid historical likes on structural root Tasks.
• Conditional forwarding rules store their creator, explicit conversation or schedule scope, condition, selected Feishu group binding and authorization revisions. Conditional forwarding checks store source input and results, evidence, model identity, worker leases, usage and delivery receipts. Forwarding management receipts store command-bound request fingerprints and immutable responses. All project members can read these records; the creator or project owner can manage them. Checks expire after 24 hours. Source-message deletion physically removes copied input, evidence and delivery content; clearing settled records also removes these copies. Deleting a rule stops future checks and preserves source-bounded history until cleared or the source is removed. Feishu recipients can keep sent messages independently.
• Queued notification records for @mentions, including the recipient, the project, the conversation's title, the name of the person who mentioned you, and a short excerpt of the conversation 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, or whether you see what each AI turn cost. 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 computer whose MiniGrove Desktop 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 or explicitly ask the assistant to submit for you, including the message, type (bug, idea, or other), project identifier, and, for browser submissions, your browser's User-Agent string. Assistant submissions do not automatically attach conversations or files and do not store a browser User-Agent. 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. Screenshots you attach in the browser are the exception: they are emailed to the operator with the message and deleted from our servers once sent, or 30 days after you attach them if they cannot be sent. Public feature suggestions cannot carry screenshots.
• MiniGrove Support: when a member @mentions MiniGrove Support in a conversation, we open a support case recording the project, the conversation, who asked, which messages asked support, its status, which support person it is assigned to, timestamps and mail delivery attempts. The email to our support team names the project and links to the case; it does not copy the message. Without the member's permission, support sees only the messages that asked it and its own replies. If the member allows it, our support staff may enter the project for 7 days; asking again restarts the period, and any member can revoke it at once, which also stops what support queued and has not yet started. We store who allowed it, when, its expiry and any revocation. While allowed, support can view and operate the project like a member and run AI directly using the project’s current AI allowance, key or subscription. Support can also see and operate the closing of Tasks MiniGrove runs unshown, such as automatic Kit updates, as an owner can. If the member's permission named it, support can also add or replace the project's API Keys and choose its models and service, including pausing or resuming saved Keys; we store whether the permission named this. A Key support saves is recorded as supplied by the member who allowed support in, or by a project owner if that member has left, and is shared, delivered and deleted like any member's Key. We reject a message to or from support that looks like an API key, so that it does not stay in the conversation. Support cannot connect or disconnect a subscription, remove an API Key, invite people, change billing or other credentials, park the cloud computer, or publish to a store. Support's own messages are marked as support's, and a suggested AI instruction is stored with its state until a member allows or declines it; allowing sends it as that member's own instruction. Support's messages are not forwarded to Telegram or Feishu groups. Each change support makes is listed to members with a fixed description, the support account and the time; what support only views is not recorded. Cases, grants and the change list are deleted with the project; support's messages, their support marks and suggestions, and which messages asked support follow the conversation retention policy.
• Public product suggestions: when you publish on the product roadmap, or choose Public feature suggestion in project feedback, your title, description and chosen public name are visible to everyone. We store the author account, timestamps, category, status, official response, optional feature link, moderation visibility, merge target, revision and an internal link to the original feedback. Private and historical feedback is never automatically published. Votes retain the account and suggestion but display only a count of distinct supporters. Comments display their text, chosen name and time; their account identifiers stay private. Following stores your chosen suggestions, time and last-read revision privately; updated suggestions display a New progress label for their followers. Team management records retain the action, operator identifier, status, explanation and time; private moderation explanations are not public. AI management requires a currently authorized platform operator. You can remove your own suggestions and comments, including hidden or merged contributions, from My public contributions; remove votes and follows on the board. Account deletion removes your suggestions, comments, votes and follows. Removing a suggestion also removes its votes, comments, follows, progress and merged suggestions. Otherwise these records remain until removed. The original private feedback follows its separate retention above. My public contributions.
• Product suggestion emails: new suggestions and comments submitted on the roadmap are forwarded to our support team with your account name and email as the reply address. Delivery records store only the suggestion or comment identifier, attempt count, next attempt time, completion time and a bounded error code; they do not copy content or contact details. Removing a comment or suggestion, or deleting its author account, removes the corresponding delivery records. Copies already emailed may remain in support correspondence. Public suggestions from project feedback use its existing email, without a second notification. Historical suggestions and comments are not emailed automatically.
• Suggestion reply notifications: the suggestion’s creator receives emails for other people’s new public comments and changed public team replies. These emails contain only public content and a discussion link, not another member’s private account name or email. We read the recipient’s current verified email address and email language when delivering. Delivery records store a source comment or response identifier, recipient account identifier, attempts, next attempt time, completion time and a bounded result code; they copy no message content or email address. Removing the source, suggestion or recipient account deletes these records. Historical content is not backfilled and authors do not receive notifications for their own messages. If a comment’s recipient is also the configured support inbox, its existing support notification provides the delivery. Email copies already delivered may remain in the recipient’s inbox.
• Feedback follow-up is visible only to authorized platform operators. We retain handling status, archive reason, operator assignment, internal notes, links to existing errors, support cases or roadmap items, operator identifiers and change times with the private feedback archive. These records are kept indefinitely unless the original feedback is removed. Linking a roadmap item does not publish private feedback, and feedback does not grant access to your project.
• Emails about your feedback: an operator may answer your feedback by email, from a reply address that brings your response back to that feedback. We keep each such email's text with the private feedback archive, including your responses, the address a response came from, its message identifier, its attachment count, whether it was an automatic reply, and its delivery state. We do not keep attachments here; our email provider Resend holds received mail under its own retention. Our answer goes to your current verified email address, which is not copied into the record. These emails are visible only to authorized platform operators and are kept indefinitely unless the original feedback is removed. Copies already emailed may remain in the correspondents' mailboxes. A record of the provider's identifier for each received email, with its processing state, is deleted about 30 days after processing.
• Anonymous Get Started feedback includes your helpfulness answer, optional comment, tutorial edition and language, and submission time. We do not attach an account, project, browser User-Agent or stored IP address to this report. It uses the same private feedback archive and is kept indefinitely. A short-lived signed cookie confirms a successful submission; a random form identifier prevents duplicate delivery. There is no contact address for a direct reply unless you choose to include one in your comment.
• Error reports a project's bot sends us when a command it was running fails, including when the cause is a model service or the network and the bot has told you so. 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

• Concurrent live reads store random lease identifiers, keyed one-way client digests and expiry times. Leases last up to 60 seconds without renewal; expired leases cannot be renewed. Expired lease records are physically removed by the next hourly cleanup.
• Shared rate limits store a keyed one-way digest of the policy and client identifier, accepted-request times and an expiry time. They do not store raw client identifiers or request content. Sliding windows last at most 24 hours; expired buckets are physically removed by the next hourly cleanup. Each sliding-window check discards accepted times outside its current window.
• 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. Container diagnostics include memory limits, usage, file-cache and kernel counters, and bounded process identifiers, parent identifiers, process categories and memory totals. Release-import diagnostics record stages, durations and artifact sizes. They do not record process command lines or environment variables. 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 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 task 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
• OpenRouter receives the model requests an agent on a MiniGrove cloud machine sends, including prompts and project code, and routes them to the model provider that serves the chosen model. It processes them under its own terms and the funder's account settings. OpenRouter privacy policy
• Paddle is the Merchant of Record for paid plans and credit packs. It collects your name, email address, billing address, payment method and tax information to process payments, calculate tax, issue invoices and handle refunds, and tells MiniGrove the identifiers, amounts and billing periods of your purchases. On the payment page, if you are signed in and already have a Paddle customer identifier, we send that identifier to Paddle Retain for payment recovery. We do not use your MiniGrove account identifier or email address to identify you to Retain. Paddle 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
• Google Play processes app binaries, release names and notes, and rollout settings when a project owner enables Android releases. MiniGrove calls Google Play with the project's Play access (an owner's Google authorization or a service account); the build computer uploads the app to Google directly, and the binary does not pass through MiniGrove. When an owner authorizes with Google, Google also receives the authorization request and tells MiniGrove the account's email address.
• 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 within the installation’s approved repository selection. When automatic creation is enabled, Administration write is also required; an All repositories installation covers existing and future repositories. Synchronization does not read or write repository Task JSON and does not read the project link; it reads only exact default-branch and branch/head facts. Task metadata, Task links, and conversation-driven Task names are stored in MiniGrove's database. A current project member may change a database Task's parent position (by dragging it in the tree or conversation list, 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 Task enters an ending workflow. The same member may also edit a Task's name and its description together from the tree canvas, but only while that Task is still open: once it is settled or in an ending workflow its description is part of what settled, and only the name stays editable. The parent position and the sibling order are the Task'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 Task 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. When a member's instruction asks the project's assistant what has happened, MiniGrove makes the same read for the commits the default branch has gained since a release candidate still under test and returns at most 10 of them to that member's assistant session, which sends them to its AI model provider; the same cache applies and nothing is stored durably. 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.

Unsent chat drafts are saved only in this browser, separately for each account, project, conversation and tab. They include text, selected mentions, the quoted reply and an unsent new conversation's identifier, kind and selected computer; attachments are not included. We do not receive this content until you send it. Up to 50 local snapshots per account and project can be restored for 7 days after their last edit. Expired snapshots are removed when that project is opened or its drafts are saved. Sending or erasing a draft removes its saved copy; different drafts in other tabs remain. Local drafts remain after sign-out and can also be removed by clearing this site's browser data. If browser storage is unavailable or full, drafts remain only in the open page.

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. Desktop sign-in handoffs store the requested local action, account identity, loopback return address, random state and hashes of one-use request, browser binding and exchange code. They expire after 5 minutes and are physically deleted on the next scheduled sweep. Google credentials, PKCE verifiers and raw exchange codes are not stored in these handoffs.
• 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 and uploaded search-tree content 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.
• 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, whether it was published as an early build (retired once a later build of the same instruction is published), and when. By default, every published release is accessible only to current project members, even when the project tree is public. Opening an internal 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. If your browser refuses that cookie and you allow the preview to use cookies when your browser asks, the same read credential is kept instead in an HttpOnly cookie on the deployment host that is not partitioned, and the host's confirmation page sets a cookie that holds no data, kept for 30 days. 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. Deleting the project deletes every one of its builds and its web address at once, files and records alike; while a build is still uploading, or when the files cannot be reached, the deletion is refused and the project is kept. If the files stop responding part-way, the project is kept with its builds taken down, and the files not yet deleted are deleted by the regular cleanup. 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.
• Task addresses for published web builds. A member may give one Task a lasting play address so its link keeps working as newer builds are published; MiniGrove stores which release that Task's address points at and when it last moved. The Task's identifier appears in that address, and Task identifiers are usually taken from the branch name they were created for, so anyone holding the link can read it. A Task address is not listed in search engines, is removed when the Task 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.
• Public game playtests. A current project owner can explicitly open one playable release to everyone, either by link or listed in the playground. We store the project and selected release, access and listing choice, game title, gameplay description, public creator name, supported device, stage, a screenshot file path inside the selected build, an optional creator question, and the last update time. When an owner asks AI to draft these display details, MiniGrove remembers that drafting conversation, the build it was asked about and the instruction whose report it holds, and stores the drafted game title, gameplay description, supported device, stage, screenshot file path, creator question and report time. The AI draft is shown only to project owners, is never published by itself, is replaced when drafting starts again, and is deleted with the project. These display details and the selected release label become public, together with every file in that selected build. Other builds, project Tasks, roadmap and repository access keep their existing permissions. Every anonymous file request checks the live public grant. Closing public playtest stops future anonymous reads and removes the game from the directory; copies already delivered cannot be recalled. The private editable display draft remains until the project is deleted. A selected public version is kept while its grant remains open; taking that release down closes its public grant and applies ordinary build cleanup. Deleting the project deletes its game display record and builds. We store Games access history with the actor account identifier, action, selected release label, moderation reason and creation time until project deletion. Operators can read game settings and reports, and pause public play with a creator-visible reason; this does not grant access to private project content. Moderation stores the project, pause time, reason, operator account identifier and update time until project deletion. Signed-in player reports store the project, reporter account identifier, problem category, declared input device, report text, resolution time and creation time. Game owners see report content without the reporter account identity; operators can read the reports. Reports remain until the author removes them through My reports, or until project or reporter account deletion; removal remains available after a game closes or a report is resolved. We do not store play statistics.
• Public game likes and comments. Liking a game needs no account: we keep a random browser cookie on the app, store only its digest with the game and the time, and show the total publicly. Clearing the cookie forgets which games that browser liked; it is not tied to your account. Rate limits read your network address and do not store it with the like. Commenting needs a signed-in account: we store your account identifier, the public name you choose, your comment text and its time. The name, text and date are public while the game is open. A comment is deleted when you remove it, or when the game's owner or an operator removes it, and with your account or the project. Closing or pausing the game hides comments without deleting them, and removal stays available to you at My comments. Likes are deleted with the project.
• Project roadmap site. When a project member asks a machine to design, edit or update the project's roadmap, MiniGrove stores the roadmap's files (its page, the plan and progress data it shows, and notes on their format) and, for each revision, a list of their relative file names, sizes and content hashes, which registered machine published it and the instruction it was published from, and when. It also remembers which conversation the roadmap was designed in and which conversation its daily update runs in. The roadmap is served at the project's web address and is accessible only to current project members, like internal web builds; it is not part of the project's repository and does not count toward the project's published builds. A daily update is a project schedule whose runs may change only the progress data. When a newer revision is published, files that only older revisions used are deleted by the regular cleanup; a revision's file list, sizes and timestamps stay on record so its revision number is never reused. Deleting the project deletes the roadmap's files and records with it.
• Hosted-tool save authorizations. When a member lets a tool published on a project's play address save files into a Task or message its agent, MiniGrove stores which member approved it, for which project, Task 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 180 days after the message was sent. The files attached to either are deleted 180 days after they are attached, or sooner if the message that carries them is deleted; the message text remains readable until its own 180-day retention ends. 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. Task-link replay receipts may outlive Task deletion but are removed when their command is swept under this 180-day conversation retention policy; at most 64 accepted link operations are retained per command. Current project owners can review and permanently clear selected older chat attachments from Storage while keeping conversation text. Unsent uploads stay private. Files in use or waiting for a task to start cannot be cleared there. After removal we stop issuing download links; previously issued links may stay valid until they expire. Shared stored bytes are reclaimed later after their last reference is removed.
• 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 Task-authority gate's startup cleanup deletes all legacy default-branch and feature-branch Task 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 Tasks 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.

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; messages still appear in the conversation.

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].