Last updated: 2026-05-18

Zhivra Privacy Policy

Last updated: 2026-05-18 (J-B / routing-improvement opt-in added)

This is the privacy policy for Zhivra in its current state (pre-launch / early access). It describes what the extension does today. Before a public marketplace release we will revise this document — in particular, a future managed-cloud tier will introduce optional server-side features (covered below) that do not exist yet.

Zhivra is a VS Code extension that routes each of your requests to the best-suited “agent persona” (a model + system prompt + tool set) and runs an AI coding agent on your behalf. Here’s where your data goes — and, more importantly, where it doesn’t.

Where your data goes (and where it doesn’t)

Codebase indexing (off by default): if you turn on the optional “codebase indexing” feature, snippets of your code are sent to whichever embedding provider you configure (OpenAI, Ollama, Gemini, Mistral, Bedrock, OpenRouter, Vercel) and stored in whichever vector database you point it at (a local Qdrant by default). Nothing is indexed or sent until you enable it and supply that configuration.

Files Zhivra writes on your machine

Zhivra keeps some data locally on your own device — nothing here is uploaded anywhere unless you explicitly choose to share it (see the next section):

When the agent runs a shell command whose output is large, the full output is written to a file under your VS Code global-storage task directory (tasks/<id>/command-output/cmd-*.txt) so it can be referenced later. That file is removed when the task is reset and does not survive uninstalling the extension. If a command you run prints a secret (e.g. cat .env), that secret will be in that file until the task is cleared.

Contributing anonymous telemetry (opt-in)

To make the auto-router better, Zhivra can upload a small, anonymous stream of behavioral data. This is off by default. The first time the routing/outcome logging is enabled, Zhivra shows a one-time prompt asking whether you want to contribute; you can also flip it any time via the zhivra.telemetry.uploadEnabled setting. Until you say yes, nothing is uploaded.

What is uploaded, if you opt in:

What is never uploaded: your prompts, your code, file contents, API requests or responses, file paths, your username, IP-derived data, or anything we could use to identify you. The uploaded payload is the same anonymous, scalar-only schema as the local CSV logs — minus the prompt prefix and the reasoning text.

Where it goes: a Supabase Postgres database hosted in the United States (us-east-1). The write key the extension carries can only append events of the allowed types — it cannot read anything back. Self-hosters can point the extension at their own Supabase via zhivra.telemetry.uploadEndpoint.

Turning it off: set zhivra.telemetry.uploadEnabled to false. Already-uploaded events stay where they are; nothing further is sent.

Routing-improvement uploads (opt-in, off by default)

This is a separate channel from anonymous telemetry above. Anonymous telemetry tells our auto-router what happened (which persona was picked, did you accept it). Routing-improvement uploads add the request and the answer so a third-party judge LLM can grade quality. We split it out as its own setting because it’s a meaningfully larger privacy surface — and because plenty of users will reasonably want the first channel but not the second.

It is controlled by the zhivra.routingImprovement.enabled setting and is off by default. You can also flip it via the Zhivra: Configure Routing Improvement Consent command. We may also ask you once, via a one-click prompt, if you already have anonymous telemetry on. If you say “Not now,” we re-ask at most once, 30 days later, and then never again — no dark patterns.

What is uploaded, if you opt in (per routed turn):

What is still not uploaded: file contents the agent read or wrote, the text of diffs the agent applied, command output, API keys, your name, email, IP, or any device identifier. The boundary on tool output content is the same in both channels — only the metadata changes.

Where it goes: the same Zhivra-operated Supabase Postgres database in the United States (us-east-1). From there, every routed turn is forwarded to a third-party LLM provider so a judge can score it. Which provider depends on which persona ran — we apply a family-separation rule (a Claude judge never scores a Claude persona’s output, and so on):

These are the providers’ policies, not promises we can enforce. If a provider changes posture, we will update this section and docs/contributing-routing-data.md.

How to opt out: set zhivra.routingImprovement.enabled to false. From the next turn onward, no prompt or response content is uploaded. Already-uploaded data stays unless you also run Zhivra: Delete My Telemetry (next paragraph).

How to delete what you’ve already contributed: the Zhivra: Delete My Telemetry command cascades a deletion of your anonymous install id’s rows across the Zhivra-controlled tables. Specifically, in this order:

  1. Storage objects — zip blobs from any diagnostic reports you’ve sent are removed from our Supabase Storage bucket.
  2. diagnostic_reports — metadata rows for those diagnostic reports.
  3. judge_scores — every quality / routing-fit / tool-fit score the judge LLM produced for your turns.
  4. telemetry_events — every dogfood routing decision + every behavioral signal (accept / reject / re-ask / frustration / etc.) we have for you.
  5. upload_attempts — the rate-limit log for your diagnostic uploads.
  6. consent_grants — your consent row is marked withdrawn (granted = false) rather than deleted immediately. A daily reaper job sweeps withdrawn rows after 30 days, at which point the row itself is gone. The 30-day delay exists so we can prove to ourselves (in an audit) that the withdrawal was processed, not lost.

After the cascade completes, your local install id and consent token are rotated; future turns from this machine are treated as a fresh install.

The delete cascade covers everything we store. It does not reach into the third-party LLM provider’s abuse-monitoring window described above — that data is held by Anthropic (7-day window), Google, or OpenAI under their own retention policies (the windows listed above) and we have no API to delete it. This is the documented gap; we’d rather state it honestly than imply we can wipe data we can’t.

Long version: see docs/contributing-routing-data.md for the plain-English explainer, the trade-off in one paragraph, and pointers into the source.

Verify Install command

Zhivra: Verify Install is a self-diagnostic command added in the pre-beta build. Run it from the Command Palette to see a quick report on whether your extension is configured correctly and whether your install id is registered with Zhivra’s telemetry server. It also runs automatically once 30 seconds after the first activation — only after you’ve already answered the routing- improvement consent dialog — with Yes / Not now / Don’t ask again choices. “Not now” suppresses the prompt for 7 days; “Don’t ask again” turns it off permanently. You can always invoke the command yourself afterwards.

What the command sends to Zhivra’s server: your anonymous install_id (the same UUID the rest of Channel-D uses) and the extension version. That is the entire request body. No prompts, no code, no settings, no behavioral data are sent — and the request is authenticated by the same publishable key any client carries, not by a per-install secret.

What comes back: aggregate counts only, for your install id — how many telemetry_events rows are recorded (today and all-time), whether a consent_grants row exists and its granted state, the shape of the consent token hash (sha256 / grandfather sentinel / null — never the hash itself), aggregate counts for judge_scores and diagnostic_reports, and the latest scored-at / received-at timestamps. The hash of your consent token never leaves the server.

What the rendered report shows: the response above + your local settings (telemetry.uploadEnabled, routingImprovement.enabled), the dogfood CSV path (rendered with your home dir as ~/ so screenshots don’t leak your username), the timestamp of the latest CSV write, and the count of pending-retention.json entries. Your install id is truncated to the first 8 characters before display.

Where it goes: the same Zhivra-operated Supabase project in us-east-1 that hosts the rest of Channel-D, at the new /functions/v1/verify-install Edge Function. Self-hosters can override via the zhivra.verifyInstall.endpoint setting. The endpoint is rate-limited to 10 calls per install id per hour (it reuses the upload_attempts table); a single rate-limit log row is inserted per call, no other writes happen.

How to opt out: don’t run the command, and pick “Don’t ask again” if the one-time prompt appears. The command never auto-fires after the first run.

Diagnostic reports — only if you choose to send one

If you hit a bug and want us to help, Zhivra has a Zhivra: Send Diagnostic Report command (Command Palette). Nothing uploads in the background. An upload only happens when you run that command and pick “Send to Zhivra” in the second dialog. This is one of three paths by which your data can reach Zhivra: the other two are the opt-in anonymous routing telemetry channel and the opt-in routing-improvement uploads channel — both off by default. Diagnostic reports aren’t on/off; they just run when you ask them to.

What the bundle contains:

What’s NOT in the bundle by default: your prompts, your code, the model’s completions, and the contents of any files the agent read or wrote — all replaced with [REDACTED — len=N] placeholders, keeping only structural metadata (timestamps, roles, tool names, token counts). The first dialog gives you three task-history options:

The second dialog then asks where to send it: Send to Zhivra (recommended), Save locally instead (you get a .zip you can email yourself), or Cancel.

Where it goes if you choose “Send to Zhivra”: a Zhivra-operated Supabase project hosted in the United States (us-east-1). Stored privately in Supabase Storage; access is restricted to Zhivra maintainers debugging the report.

How long it’s kept: 30 days, then auto-deleted by a scheduled job. We don’t keep copies elsewhere.

Reference code: after a successful upload you’ll see a code like ZD-XXXX-XXXX. Include it when you email us at support@zhivra.com — that’s how we find your bundle on the server. Without it we have no way to match a report to a person, by design.

How to opt out: don’t run the command. If you’ve already started it and changed your mind, pick Cancel in the second dialog (nothing is uploaded until you confirm). If you want the bundle for your own records but don’t want us to have it, pick Save locally instead — you can then email the zip to support@zhivra.com yourself, or attach it to a GitHub issue, on your terms.

What we do not do

Your controls

Security & changes

We take reasonable measures to protect data on your machine, but no system is perfectly secure. If this policy changes materially, we will surface a notice in the extension.

Contact

For privacy questions, open an issue on the Zhivra project repository.

By using Zhivra, you agree to this Privacy Policy.

Canonical source: PRIVACY.md in the Zhivra repository.