What Hawkeye stores, what it never stores, and how to get it all back or gone.

Hawkeye takes privileged actions on machines you own — running commands, moving files, driving a signed-in desktop. A product like that has to be unusually specific about what it keeps, so this page lists the actual database tables rather than a category like "usage data".

What is stored, where it lives, and who else touches it

The control plane runs as a Cloudflare Worker over a single Cloudflare D1 (SQLite) database, an R2 bucket for objects, and short-lived KV counters. The table below is rendered from the product's own data registry (worker/src/panel/dataregistry.ts), not written by hand: every class names the real tables, prefixes or files it lives in, and a release check fails if the code grows a table or a processor this page does not carry.

What is NOT stored

• No credential for reaching your machines ever enters the database. The key the Worker presents to a machine is a Worker secret, held by the operator of the deployment. It is not a database row, it is not returned by any API, and it does not travel to a browser, to an agent, or into a model's context.
• Your agent channel history is not ours. Agent-to-agent messages live in a SQLite file on your own machine, next to the daemon. The panel reads them live, over your machine's own outbound tunnel, and keeps no copy. Delete that file and the history is gone — there is nothing on our side to also delete. The honest cost of that design: when the machine sleeps, the history is unavailable, and the product says "offline" rather than pretending it is empty.
• No advertising trackers, and no cross-site tracking. This is checkable rather than promised, so here is the exact shape of it. Every page ships under a default-src 'none' Content-Security-Policy with all styles inline, and connect-src 'self' — the page cannot call anywhere but back here. One host is named as an exception in script-src-elem: static.cloudflareinsights.com, Cloudflare's own Web Analytics beacon, which their edge can inject at the zone level outside this application's control. It is switched off today — read the page source and you will find no beacon, and no other off-site script could load even if one were added by mistake. We name it because you can read that header yourself, and finding an analytics host in a policy we told you to trust would be worse than saying so here.
• No advertising, and no sale or sharing of personal data. There is no business here that would want it.
• Command output and file contents are not archived. When you run something on a machine, the result passes through the Worker to your screen to answer that request. The audit row records that you ran it and where, not the payload.

Error reporting — the one thing that leaves for a reason

There is no product analytics, no attribution and no campaign pixel. There is operational error reporting, and it is a real processor rather than a figure of speech, so it is stated exactly:

• Error and performance telemetry — when the control plane throws, the exception and its stack are sent to Sentry with the request method, the URL it happened on and the response status; timings are sent for a 10% sample of requests. Request bodies are switched off in the SDK, the user identity and IP are not attached, and the URL is stripped of any bearer credential before it leaves. Processed by Cloudflare and Sentry. Retention: Not decided yet: how long Sentry keeps an error event for this project — set in the Sentry organisation, not in this repository, and not recorded here. deleting your org does not reach Sentry. An error event already sent expires under Sentry's own retention, whatever that is set to.
• Operator logs — the console stream an operator reads to diagnose a failure: the method and path of a request that 500'd and the stack that caused it. Both wrangler configs enable Workers observability, so Cloudflare keeps that stream. Processed by Cloudflare. Retention: Not decided yet: how long Cloudflare keeps Workers Logs for this account. The product does not set the period and has not recorded it. deleting your org does not reach the log stream; entries age out under Cloudflare's retention.

Distinguishing the two matters more than the word "telemetry" does: service telemetry exists so an operator finds out that the product broke before you have to tell them. Nothing above measures what you looked at or builds a profile of you.

Where it lives

On Cloudflare: Workers for the code, D1 for the database, R2 for objects, KV for counters, and the platform's own log stream for the operator's console. Requests traverse Cloudflare's global network, and Cloudflare processes them as our infrastructure provider under its own terms. Your machines are yours — Hawkeye never dials in to them; they dial out.

Getting your data out

You can export a full copy of your org's rows — self-serve, no request needed: sign in and use /account/export on the /account page. What the file contains, and what it deliberately does not, comes from the same registry as the table above:

• In the file — Your account, Your organisation, Paired apps and runtimes, Invitations and access requests, Your machines, People you can route work to, Notification destinations, Notifications, The org stop switch and its record, The audit trail, The activity feed, Hosted cloud coding workspaces, Outbound control connections from your machines, Approval requests and their answers, Lead agent commands and autonomy settings, Geographic provenance rules for file transfers and vault access, Agent specs, conversations and workflows, Harness rules and templates, Hawkeye's memory of your conversations, Remote desktop grants and frames, House model usage and cost, Model call log, Which of your machines answers chat with its own CLI, Saved terminal grid layouts, Notepad posts and shared files, Files attached to a Hawkeye chat message, Links between organisations, Billing events, Receipts on your own machine.
• Deliberately withheld — Retired organisation identifier, Sign-ins, Credential verifiers, GitHub installation change fence, Cloud resource cleanup journal, Secrets you seal into the vault, Third-party connectors you connect (Google Drive, Slack, GitHub, Notion, Linear, ...), Files moved between machines, Browser-rendering jobs, Rate and budget counters, Deployment state. A session id is a live login and a credential verifier is the lock itself; a file that contained either would be a credential you then email to yourself.
• Not ours to hand over — Platform-refuse confirmation code, Global refusal break-glass recovery code, Which OAuth app this deployment uses per connector, Error and performance telemetry, Operator logs. These sit with a processor under its own retention, and are named here rather than left out.

Getting it deleted

You can delete the org and its accounts yourself, through the two-step /account/delete (also on the /account page; it needs no sign-in to read). Deletion asks you to type the org's name back, so it cannot happen by a single mis-click, and it asks every reachable machine to purge its own receipts for that org. A member who is not an owner can close their own account from the same page; the remaining personal records are erased within 30 days. You can also ask by email, below.

Everything else in the table above is deleted when the org is deleted. These are the exceptions, each one for a stated reason:

• Retired organisation identifier — created atomically when the org is deleted and intentionally retained as a non-reusable namespace guard.
• Platform-refuse confirmation code — not org data and never swept by the org-deletion cascade in account.ts — it holds no org id, only a platform admin's own in-flight confirmation attempt.
• Global refusal break-glass recovery code — not org data and never swept by the org-deletion cascade in account.ts — it holds no org id, only a platform admin's own break-glass recovery material.
• The audit trail — your org's audit rows go with the org, but ONE deployment-level row survives it: a record, with no org id, that the deletion happened and who asked for it (worker/src/panel/account.ts:793). Keeping no evidence that we deleted something is not a record.
• GitHub installation change fence — not covered by org deletion — this is a deployment-level provider event fence with no org id, retained so deleting one tenant cannot reopen a stale consent callback.
• Which OAuth app this deployment uses per connector — not covered by org deletion — this is deployment-level configuration shared by every org, not one tenant's data.
• Cloud resource cleanup journal — it deliberately does not go with the organization row: already-authorized cleanup must finish after a controller restart, and the minimal final resource/cost/custody tombstone remains in the protected controller journal. No automatic purge period has been set.
• Remote desktop grants and frames — the grants, leases and handovers go with the org; frames and intents are keyed by machine, not by org, and are left to expire.
• Notepad posts and shared files — the rows go with the org. THE UPLOADED FILES DO NOT: the cascade deletes D1 rows only, so an object under the notepad prefix becomes unreachable rather than erased, and stays in the bucket until an operator removes it (worker/src/panel/account.ts:564).
• Files attached to a Hawkeye chat message — both halves are real: the D1 row is swept by the deletion cascade (worker/src/panel/account.ts's ORG_DELETE_PLAN) and the R2 object is enumerated and deleted in the same deletion, then the prefix is re-listed to confirm nothing remains (account.ts's collectOrgObjectKeys/ deleteOrgObjects).
• Files moved between machines — not touched by org deletion — the cascade deletes D1 rows only. The ticket that reaches an object expires; the object itself remains until it is deleted through the transfer API or by an operator.
• Billing events — our rows go with the org. What the payment provider keeps for its own accounting is theirs and outlives the deletion.
• Browser-rendering jobs — not covered by org deletion — these rows are keyed by job, not by org.
• Rate and budget counters — expires on its own; there is nothing to delete by hand.
• Deployment state — not tenant data, so org deletion does not touch it.
• Error and performance telemetry — deleting your org does not reach Sentry. An error event already sent expires under Sentry's own retention, whatever that is set to.
• Operator logs — deleting your org does not reach the log stream; entries age out under Cloudflare's retention.
• Receipts on your own machine — deleting the org asks every reachable machine to purge its receipts for that org, and reports per machine whether it answered (worker/src/panel/account.ts:793). A machine that is asleep is not purged, and the result says so rather than claiming it was.

If a self-serve route is not enough — an access request, or a question about something above — write to contact@transition2.ai and we aim to reply within 2 business days.

Sub-processors

Everyone outside this deployment that data can reach, why, and what actually gets to them. A processor marked not switched on for this deployment is wired in the code but has no credentials configured, so nothing reaches it today; it is listed anyway, because "we will tell you when we turn it on" is a promise a page cannot keep.

A new processor cannot be enabled without a registry entry: the release check reads every third-party hostname, every imported package and the deployed configuration out of the source, and fails when one of them is missing from the table above. That is the change-notice process, mechanised rather than promised.

Who is accountable, and where

The data controller is Transition 2 Consulting Inc. of Victoria, British Columbia, Canada V9B 4J5, operating under the laws of British Columbia, Canada. A privacy complaint that reaches the applicable regulator would go to the Office of the Privacy Commissioner of Canada. For export, deletion or access requests beyond the self-serve tools above, write to contact@transition2.ai — we aim to respond within 2 business days.

Retention

Stated exactly, not rounded up, per class, in the table above. The shape of it: sessions, tickets and counters carry their own expiry and are refused or dropped past it; everything else is kept until you delete the org. There is no automatic, time-based purge for the rest, and where nobody has set a period this page says so below rather than implying one.

This page describes the deployment you are reading it on. If you run Hawkeye yourself, you are the operator and these answers are yours to give.