Skip to content

Privacy and security

How Diffgazer handles source, credentials, and provider requests.

Diffgazer runs an embedded local server and reviews your code on your own machine. Your source and credentials never reach a Diffgazer-hosted relay. Your code leaves only when you ask for a review: at that point the diff and the prompt built around it go to the admitted product you configured, under that product's policy.

Server-only boundaries

Several sensitive concerns stay on the server and never appear in Web, Ink, or CLI client payloads:

  • Provider secrets and credential material — literal provider keys, provider tokens, environment values, and auth file paths stay in server-side storage. Client-safe summaries expose only configuration identity, readiness, notices, and generic actions. The one credential the browser does hold is the per-run shutdown token described below: it authorizes the local API and nothing else, and it never reaches a provider.
  • Admission evidence and diagnostics — raw provider errors, account identifiers, executable paths, and probe envelopes are normalized or redacted before any client-visible copy is produced.
  • Budget and execution leases — spend limits, lease revocation, and cancellation drain run only in the embedded server and review pipeline.
  • Review receipts — terminal outcomes, usage normalization, and execution fingerprints are assembled server-side and projected through safe presentation copy.

Diffgazer does not fall back to another product or treat HTTP compatibility as authorization when admission fails.

Localhost binding and the host allowlist

The embedded server only answers requests that came from your own machine. Before any route runs, it reads the Host header and checks it against a fixed allowlist of localhost, 127.0.0.1, and ::1. A request with any other host gets 403 Forbidden.

Combined with the server binding to 127.0.0.1 when it starts, there is no public interface for someone on your network to reach the API.

CSRF protection on writes

For any state-changing method (POST, PUT, PATCH, or DELETE), the server inspects the request Origin. If an origin is present and it is not a localhost origin, the request is rejected with 403.

Hardening headers

Every response carries X-Frame-Options: DENY, X-Content-Type-Options: nosniff, a restrictive Permissions-Policy, and Referrer-Policy: no-referrer.

The shutdown token

The server protects its API with a per-run secret. Every API request, except /api/health and OPTIONS preflight, must present the token in the x-diffgazer-shutdown-token header. Packaged builds always require it.

This token is deliberately client-held: the browser app receives it so it can call the local API at all. It is scoped to this run's localhost server, is not a provider credential, and grants no access to stored secrets.

Where secrets are stored

You choose where secrets live. Diffgazer offers your operating system keyring wherever the platform supports it — the server refuses to save that choice when the keyring is unavailable — and file storage everywhere. Until you pick the keyring, secrets go to files: literal credentials in separate 0600 files under your Diffgazer home. Environment references store only the variable name.

Every product may use either method.

The trust gate

Reading your repository is not automatic. Routes that touch repository files require an explicit readFiles grant for the exact repository root you are working in.

What leaves the machine

Two kinds of request cross the network boundary: model-catalog requests during setup, and the review request itself. Neither passes through a Diffgazer-hosted relay.

The review request, when you ask for one

When you run a review, Diffgazer uses the admitted configuration and exact model you selected and sends the review prompt directly to that product's endpoint. Your diff and prompt go to your provider under your account and that product's documented terms.

Ollama Cloud is a hosted product that sends review content to ollama.com; it is not a local transport.

Model-catalog requests, during setup

Before any review, opening the model picker for a catalog-backed hosted product can make Diffgazer fetch a current model list. None of these requests carry code; exactly one kind carries a credential:

  • Keyless, for every catalog-backed product. For Google Gemini, Z.AI, DeepSeek, Qwen International, Moonshot Open Platform, MiniMax International, OpenCode Zen, Ollama Cloud, and OpenRouter, Diffgazer may read the public models.dev catalog at https://models.dev/api.json. The catalog is cached for an hour and then revalidated with the ETag models.dev returned, so an unchanged catalog costs one small conditional request. That request carries no key.
  • Keyless public model lists. OpenRouter's list at https://openrouter.ai/api/v1/models and Ollama Cloud's list at https://ollama.com/v1/models answer without a credential, so Diffgazer reads them without one — even when you have saved a key for that product. Each list is cached for five minutes.
  • Your key, only to its own product. For a saved Z.AI, DeepSeek, Qwen International, Moonshot Open Platform, MiniMax International, or OpenCode Zen configuration that has a credential, Diffgazer asks that configuration's own endpoint for its model list ({endpoint}/models) using that configuration's own credential. A credential is sent only to the endpoint of the configuration it belongs to, plus — for OpenCode Zen alone, whose two endpoints share one key — that same product's other endpoint, and there only to read its model list so the picker can say which pool serves a model. A credential never goes to models.dev, never to a public list, never to another product's endpoint. Google Gemini's list lives at {endpoint}/openai/models on its endpoint's OpenAI-compatible layer, on the same terms. Each list is cached for five minutes per configuration.

If a live list cannot be fetched or is unusable, the picker silently falls back to the models.dev catalog. DIFFGAZER_OFFLINE skips every live request — models.dev and provider lists alike — and serves cached or bundled data.

Info:

Note: A provider may use what you send according to its own terms. Diffgazer keeps your code local up to the moment you send a review, but it cannot control provider-side handling. Before the first send it asks you once — in the setup wizard, or as a Provider data notice dialog the first time you configure a provider, select or verify a configuration, or start a review — to accept that repository content goes to the provider you configure, using your own credentials, that Diffgazer stores nothing remotely, and that billing, rate limits, retention and training terms are that provider's; each product's own notice is shown alongside, and a product whose notice materially changes asks again. Declining cancels only that action; the accepted notice stays readable from Settings. Choose a product whose notice you are comfortable with.

Related