Configuration

Diffgazer keeps its configuration global by default. Settings, secrets, trust, and versioned provider configurations each live in their own files under ~/.diffgazer, and a tiny per-project file records the repository's identity. Think of the global directory as your account-level defaults, with the per-project file pinning a stable id for the repo you are reviewing.

The active configuration and selected exact model are global for this Diffgazer installation. Activating them through the API still requires trust for the project making the request, but the selection is not stored per project.

Set DIFFGAZER_HOME to move the global directory somewhere other than ~/.diffgazer. Diffgazer writes every config file with 0600 permissions.

Moving a repository

When you move or rename a repository directory, Diffgazer treats it as a move rather than a new project: the .diffgazer/project.json keeps its projectId and its repoRoot is updated to the new location, and your saved review history follows automatically. Trust stays gated, so the first request from the new path returns a trust prompt and you re-confirm trust once.

Each saved provider setup is a configuration with:

• configurationId — stable identifier for the record.
• revision — monotonic version used for optimistic updates.
• executionFingerprint — immutable identity for the admitted product tuple, credential reference, endpoint, and exact model.

Client-safe summaries expose readiness, notices, remediation, and available actions. They never expose literal secrets, environment values, auth paths, account identifiers, or raw diagnostics.

The local API exposes six generic actions on POST /api/config/actions:

Every action returns a client-safe summary. A configuration becomes ready only after its product-specific admission checks pass, including structured-output conformance, required usage when applicable, and an accepted product notice. Reviews do not wait for ready: a configuration whose only open item is structured-output conformance can start a review, and the review itself verifies it. An unaccepted notice is different: readiness reports acknowledgement-required and the review is refused until the notice is accepted, whether or not conformance was ever checked.

Setup always ends in an observable ready, unsupported, or skipped state.

Hosted API products

For Google Gemini, Z.AI, OpenRouter, DeepSeek, Qwen International, Moonshot Open Platform, MiniMax International, Ollama Cloud, and OpenCode Zen:

1. create a configuration for the product.
2. update it with either a stored literal credential or an environment reference. The reference carries no name: the server binds the canonical variable for that product, for example GOOGLE_API_KEY for Google Gemini.
3. Bind the allowed endpoint.
4. select an exact discovered model ID.
5. Optionally test (Verify in the UI) to check structured-output conformance up front. Skipping it leaves readiness at conformance-pending, which still selects and starts reviews; the first review verifies conformance and records the result, and the UI shows the last verification beside the configuration.

On OpenAI-compatible products Diffgazer sends a per-model reasoning control with the request where the model is known to honour it — thinking off (reasoning_effort: "none") for Qwen Flash and DeepSeek V4 Flash on OpenCode Zen, lowest effort (reasoning_effort: "low") for GLM-5.3-Flash on OpenCode Zen and Z.AI, whose thinking cannot be switched off — so a thinking-by-default model answers inside the dispatch budget instead of reasoning past it. It is not configurable.

Hosted examples never embed literal secrets. Use an environment reference or the setup UI's write-only credential field instead.

• Exact model only. Aliases, latest, and routing selectors are rejected.

• Conformance. Readiness reports ready only once schema-valid review output has been observed for the exact configured tuple. test (Verify) is the optional way to observe it early; otherwise the first review observes it. Until then readiness is conformance-pending, shown as Not verified, and the configuration can still be selected and reviewed. A recorded conformance failure fast-fails later reviews on that exact tuple until the tuple changes.

• Consent. Diffgazer asks once, globally, for the provider consent below and records it as settings.providerConsent. It is asked in the setup wizard, or — when the wizard was skipped — just in time, as a Provider data notice dialog the first time you take an action that would send repository content or store the credentials to do so: Configure or Update configuration (the notice opens before the credentials dialog), Select configuration, Verify, or starting a review. Accept and continue records the consent and runs the action; Not now (or Esc) cancels only that action, and Provider Details keeps a Consent required to run reviews · Review line that reopens the notice. Once accepted it is never asked again; the settings hub shows a read-only Provider data notice row with the acceptance date. Each configuration record still carries the acknowledgement of its product's current notice (noticeId, noticeVersion, acceptedAt): once the global consent is on record the Web and Ink UIs send that acknowledgement automatically when they create or update a configuration, and only ask again when readiness reports acknowledgement-required — a product whose notice materially changed (a new notice version), or a record upgraded without an acceptance. API callers send the acknowledgement themselves on create or update. An unacknowledged record reports acknowledgement-required before any conformance verdict and reviews on it are refused with 503 SETUP_REQUIRED.

  Info:

  Diffgazer sends repository content (diffs, files you include) to the provider you configure, using your own credentials, and stores nothing remotely. Billing, rate limits, retention and training terms are that provider's — see each provider's notice.

• Skipped live probes. When a live check is intentionally skipped, readiness stays non-ready with remediation code enable-live-probe. A skipped probe never enables a product.

These are the fields in the settings config. Anything you do not set falls back to the default in the table.

secretsStorage decides where literal credentials live when you choose stored secrets instead of an environment reference. With file, credentials are written to separate 0600 files under your Diffgazer home. With keyring, Diffgazer uses your operating system credential store. Environment references store only the variable name.

Either way, credentials stay local to your machine. For hosted reference names, see Environment variables.

Trust is granted per project, not globally. Each trust record names the project, when you trusted it, and capabilities such as readFiles. runCommands is forced to false because command execution is not supported yet. See Privacy and security.

• Providers: the canonical support matrix and per-product contracts.
• Environment variables: hosted credential reference names.
• Local API reference: the six configuration actions and review receipts.