verify

A command that checks whether a signed JSON record of a completed command run is still authentic. It verifies the digital signature and reports the signer's public-key fingerprint.

In plain words
What is it for?
Use it to check receipts created by `crabbox run --attest`, such as records showing that tests were run.
Why use it?
It helps reviewers detect whether someone edited the recorded result after it was signed, while rejecting unreadable or ambiguous records.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/openclaw/crabbox/verify
Clone the repo
git clone --depth 1 https://github.com/openclaw/crabbox
Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 771 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.00771
Opus 5 $0.00000 $0.00385
Sonnet 5 $0.00000 $0.00154
Haiku 4.5 $0.00000 $0.00077

Measured 2d ago against content hash a30cc9c03a08, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

verify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

docs/commands/verify.md · 75 lines

How it starts

The opening of the file, as written. The whole thing — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.

verify

crabbox verify checks a signed run receipt produced by crabbox run --attest. It recomputes the receipt's canonical bytes, verifies the embedded Ed25519 signature, and prints the signer's public key fingerprint, so a reviewer can confirm a pasted receipt has not been edited after the run once they have matched the fingerprint through a trusted channel.

crabbox run --attest receipt.json -- go test ./...
crabbox verify receipt.json

On success it prints one line and exits 0:

PASS receipt.json signer=sha256:6a5f... trust=self-signed

If any signed field was modified after signing, it prints a failure line and exits 1:

FAIL receipt.json signer=sha256:6a5f... trust=self-signed: signature mismatch

A receipt that cannot be checked at all (unreadable file, invalid JSON, duplicate JSON keys, a missing or malformed public_key or signature) exits 2 with an error on stderr. Duplicate keys are rejected outright because JSON parsers disagree on which duplicate wins, which would let an edited receipt show one value to a reader while the signature still verifies against another.

Receipt format

Schema v1 is the existing successful-run format. It is a flat JSON object. schema_version, generated_at, provider, command, exit_code, command_ms, and public_key are always present; lease_id, slug, run_id, actions_url, and log_sha256 appear when the run produced them. log_sha256 is the SHA-256 of the combined stdout and stderr stream as observed by the client during SSH-backed runs.

The signature covers the canonical encoding of every field except signature itself: the object is re-marshaled as compact JSON with lexicographically sorted keys, and the Ed25519 signature is computed over those bytes. Because public_key is inside the signed payload, swapping in a different key also fails verification.

Schema v2 terminal receipts are emitted for non-zero local runs and stored by the coordinator for brokered terminal runs. They additionally bind the run, lease, slug, raw command digest, final exit code, sync/command/total timing, timestamps, retained log hash, truncation state, full observed stream hash, and signer fingerprint. Their signature input is a fixed length-prefixed field sequence shared by the Go CLI and Worker verifier. Command display text is bounded; unusually long displays are replaced by a marker containing the exact raw-argument digest.

Read the full file on GitHub · 75 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 75 lines · 0 tokens per session scan A a30cc9c03a08

Subscribe to this mod's changes

verify is a command published in the GitHub repository openclaw/crabbox (1,343 stars, last pushed 2d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 771 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.