English · Türkçe · Deutsch · 简体中文 · Español · Français

Ask another provider. Get a clear second opinion.

Xerify is a shell-first, open-source tool for bounded cross-provider questions and verification. It can use provider CLIs already authenticated on your machine, direct APIs, or an explicitly configured executable. The same core and schemas power the CLI, library, local STDIO MCP server, and Streamable HTTP MCP server.

Xerify is built and maintained by Verhex, with community contributions, and distributed under the MIT License. It is the cross-provider verification layer of Deckent, the Verhex agentic operating system, released here as a standalone tool — Xerify runs on its own and has no dependency on Deckent.

Xerify provides a second opinion, not formal proof or guaranteed truth. Provider output is untrusted data and is never executed.

Release status: 0.2.0 is an early public release, distributed on npm as xverify-cli. Public CI is green on Ubuntu, macOS, and Windows with Node 20/24, including external install and MCP Inspector smoke; the same check, clean-install smoke, and release audit also pass on WSL2 with Node 24. The invocation-provider identity contract has live Cursor/OpenAI proof in both directions. The published 0.1.0 tarball reached the registry outside the release workflow and therefore carries no npm provenance attestation; 0.1.1 and later releases are published by the workflow, which requests one. Public schemas, JSON envelopes and exit codes are stable; the provider surface is still small and the API may grow.

Install

Install from npm:

npm install --global xverify-cli@latest
xerify --help
xerify --json health
xerify init

From a source checkout:

npm ci
npm run check
npm link
xerify --help
xerify init

Node.js 20 or newer is required. Node.js 24 is the primary development lane. For a project-local install after publication, use npm install --save-dev xverify-cli@latest and invoke its xerify binary with npx xerify. A guarded postinstall initializes .xerify/ for a declared direct local dependency or an explicit root --save-dev/--save-prod install. Global, nested transitive, no-save, and npx installs do not write into the current project; run xerify init explicitly in those cases. Set XERIFY_SKIP_AUTO_INIT=1 to opt out. See the documented npm hoisting limitation before using Xerify as another package's dependency. See installation and upgrades for project-local, global, npx, lifecycle, upgrade, removal, and clean-install verification instructions. The documentation index links the complete English reference and all localized consumer guides. Documentation is served from the repository and is not installed with the package, so the npm artifact stays small; read it at https://github.com/VerhexIO/xerify/blob/main/docs/README.md.

Quick start

Ask an open-ended question. Piped input becomes bounded context:

git diff --cached | xerify ask \
  --to anthropic:MODEL_ID \
  --question "What is the highest-risk issue in this change?"

Verify a concrete claim with a different invocation provider:

git diff --cached | xerify --json verify \
  --from openai:AUTHOR_MODEL \
  --to anthropic:VERIFIER_MODEL \
  --claim "This change closes the race without introducing a regression"

--from and --to identify the service that performs or performed the invocation. Cursor Agent is always cursor, regardless of whether its exact model ID names GPT, Claude, Gemini, Grok, Composer, or another model. Direct Codex/OpenAI is openai; direct Claude/Anthropic is anthropic. Same-provider verification fails before a model call.

This measures channel/control-plane diversity, not model-lineage independence. For example, openai:gpt-x → cursor:gpt-x is admitted but may share the same upstream model and blind spots.

Only the target adapter is called. --from declares who authored the existing artifact, so both OpenAI → Anthropic and Anthropic → OpenAI work without introducing an author-orchestration layer.

Live provider calls can consume subscription quota or incur API charges. Setup commands are non-billable:

xerify --json doctor
xerify --json health
xerify --json providers list
xerify --json providers probe --all --timeout 5000

The worked verification examples include research, game-production, website, analytics, outbound-data, and Xerify dogfood cases. Each page shows the bounded evidence, exact command, observed normalized result, and exit decision; docs/examples/index.jsonl is the compact machine-readable catalog.

Commands

xerify ask
xerify verify
xerify health
xerify doctor
xerify providers list
xerify providers probe
xerify config show
xerify config validate
xerify mcp stdio
xerify mcp http
xerify request
xerify init
xerify runs list
xerify runs show 1
xerify runs search "race condition"   # searches the archive
xerify runs archive 1
xerify runs restore 1
xerify runs delete 1 --yes

Global --json, --timeout, and --log options may appear before or after a subcommand. JSON mode writes one undecorated envelope to stdout. Important verification exits are 0 confirmed, 10 refuted, and 11 unclear; transport and schema failures have separate typed exits. See the complete CLI reference and JSON contract.

xerify request is a bounded adapter-debug escape hatch. Even when its envelope uses operation: "verify", it does not enforce author provenance, provider separation, verdict parsing, or verification exit semantics.

Providers

The default config exposes the official codex and claude CLI adapters. Additional built-ins are the invocation-provider-pinned Cursor agent adapter, openai-api, anthropic-api, openai-compatible, and a shell-free generic command adapter.

Direct API keys should be read from named environment variables. A literal apiKey is supported as an explicit fallback for basic local setups. Literal keys and complete configured endpoint URLs are redacted from CLI diagnostics; files containing either must be owner-only on POSIX. Remote compatible endpoints without explicit key configuration report authentication as unknown rather than auth-free. Usage and cost are reported only when the provider supplies them. See provider adapters and project configuration.

Configuration

Project-local npm installation runs a guarded, non-overwriting init; xerify init is the explicit idempotent fallback. Configuration lives at .xerify/xverify-config.json; secret-safe audit metadata goes to .xerify/logs/audit.jsonl and is ignored by the generated .xerify/.gitignore. Each ask/verify also gets a sequential, content-addressed record under .xerify/runs/; archived records move to .xerify/archive/. Initialization adds .xerify/ to the project root .gitignore, .npmignore, and .dockerignore without replacing existing content. The config itself is also ignored because it may contain an optional literal API key. User configuration uses the platform-native config directory with the same xverify-config.json filename. Precedence is flags, environment, project file, user file, then defaults.

Hermetic automation may point XERIFY_USER_CONFIG_PATH at a dedicated file without changing the process home directory.

{
  "$schema": "https://raw.githubusercontent.com/VerhexIO/xerify/main/schemas/config.schema.json",
  "providers": {
    "openaiApi": {
      "kind": "openai-api",
      "apiKeyEnvironment": "OPENAI_API_KEY"
    },
    "cursor": {
      "kind": "cursor",
      "provider": "cursor",
      "executable": "agent"
    },
    "localVerifier": {
      "kind": "command",
      "provider": "independent-lab",
      "executable": "/absolute/path/to/verifier",
      "args": ["--model", "{model}", "--operation", "{operation}"],
      "authKind": "local",
      "structuredOutput": true
    }
  },
  "limits": {
    "timeoutMs": 120000,
    "maxInputBytes": 1048576,
    "maxOutputBytes": 1048576
  },
  "history": {
    "enabled": true,
    "directory": ".xerify/runs",
    "archiveDirectory": ".xerify/archive",
    "captureInput": "full",
    "captureOutput": "normalized",
    "sequencePadding": 6
  },
  "logPath": ".xerify/logs/audit.jsonl"
}

The transparent default stores the claim/question, supplied context, SHA-256 evidence manifest, normalized Xerify result, lifecycle events, and final exit outcome locally. It never stores raw transport output or credentials. Sensitive projects can select captureInput: "metadata" or "none", and captureOutput: "metadata" or "none". runs show does not print evidence content unless --include-evidence is explicit. One runs/HEAD.json preserves monotonic IDs without a per-run reservation tree; archive/index.jsonl lets humans and agents find archived verification heads without scanning every record. See local run history.

Only {model} and {operation} are expanded for a command adapter. Xerify invokes an executable plus argument array with shell: false and sends prompt/context through stdin.

A command adapter runs in a private empty directory, not in your project, so every path in executable and args must be absolute. A relative path such as ./tools/verifier.mjs resolves against that private directory and the process fails to start. The failure now quotes the interpreter, which names the directory it actually looked in:

{
  "code": "PROVIDER_FAILURE",
  "providerMessage": "Error: Cannot find module '/tmp/xerify-command-rBJrxX/tools/verifier.mjs'"
}

Every live ask or verify request must name an exact model in --to provider:model; configuration does not silently choose or guess a model.

Exact IDs come from the provider, not from Xerify, and only Cursor exposes a listing command:

Adapter	Where the exact model ID comes from
cursor	agent models
codex	your Codex account and CLI version; codex --help shows --model, and the CLI names the model it rejected
claude	your Anthropic account and CLI version; claude --help shows --model
openai-api, anthropic-api, openai-compatible	the provider's own model list for your key

When a provider rejects a model, its own sentence is reported back under providerMessage, which is usually the fastest way to learn what it will accept.

For Cursor, configure one cursor adapter and use --to cursor:EXACT_MODEL_ID. Exact model IDs are opaque Cursor catalog identifiers; Xerify does not reinterpret their upstream vendor. auto fails before a call because it cannot produce deterministic model provenance. Use agent models to choose an exact ID. Token values never belong in .xerify/xverify-config.json unless the user explicitly accepts local secret-file custody. Prefer environment-variable names; literal apiKey is a fallback and is never printed. The full precedence, permission, environment, and user-path rules are in configuration.

MCP

For local hosts:

A global install puts xerify on PATH:

{
  "mcpServers": {
    "xerify": {
      "command": "xerify",
      "args": ["mcp", "stdio"]
    }
  }
}

A project-local install does not. Point the host at the entry point directly — this also skips the npx indirection, so the server starts faster:

{
  "mcpServers": {
    "xerify": {
      "command": "node",
      "args": ["./node_modules/xverify-cli/dist/cli/entry.js", "mcp", "stdio"]
    }
  }
}

The server exposes xerify_ask, xerify_verify, and xerify_capabilities. SDK v2 modern (2026-07-28) and legacy negotiation are served from one factory and are exercised by a pinned Inspector smoke.

Streamable HTTP binds to 127.0.0.1:8787 by default:

xerify mcp http --host 127.0.0.1 --port 8787

The endpoint is http://127.0.0.1:8787/mcp; the root path returns 404. The command prints the full URL on startup, so read it from there rather than assembling it by hand.

A non-loopback bind requires both --allow-public and a bearer token supplied through --token-env. See MCP operation and security.

Contributing and compatibility

npm run check
npm run smoke:mcp
npm run assets:logo

Normal tests are hermetic and never require a provider account. Source contributions follow the contribution guide; the public runtime, host, schema, and provider support boundary is documented in compatibility. Injection defenses and residual boundaries are documented in SECURITY.md; prompt instructions reduce risk but cannot make any LLM prompt-injection-proof.

Who makes Xerify

Xerify is designed, built, and maintained by Verhex.

It originates in Deckent, the Verhex agentic operating system, where asking a second provider to check a claim is one of the capabilities the orchestrator depends on. Xerify is that capability in standalone, open-source form: it installs on its own, needs no Deckent, and carries no dependency on it.

Only Xerify is covered by the MIT License in this repository. Deckent is a separate Verhex product and is not licensed here.

Security and license

Read SECURITY.md before reporting a vulnerability or operating the HTTP server. Subscription, direct API, Cursor, CLI, and MCP combinations are mapped in provider and access channels. Xerify is distributed under the MIT License; third-party notices are in THIRD_PARTY_NOTICES.md.