`verify-audit-log`

Check that workspace audit log files have not been altered. The command replays the SHA-256 hash chain every line carries, across any set of files, and reports each entry whose signature does not match.

It works on local copies of the files. It takes no --server and no --token, and never contacts a workspace. For how the files are written and what the chain proves, see Audit logs.

Syntax

Usage: curiosity-cli verify-audit-log <files|folders|wildcard>... [--strict] [--json]

curiosity-cli verify-audit-log ./audit
curiosity-cli verify-audit-log ./audit/2026-09-*.jsonl --strict
curiosity-cli verify-audit-log ./audit --json > verification.json

Arguments and options

Argument / option	Description
`<inputs>`	Audit log files, folders, or a wildcard in the file name. A folder contributes its `.jsonl` files and its `audit*.log` configuration logs.
`--strict`	Also fail when a file's first entry cannot be verified: the file does not start with a server start entry, and the file written before it was not given.
`--json`	Print the report as JSON instead of text.

Exit code	Meaning
`0`	Every entry matches its recomputed signature.
`1`	At least one entry was altered, removed or reordered, or a line could not be parsed. With `--strict`, also an unverifiable first entry.
`2`	The command could not run, for example because no file was found.

Example output

VALID      2026-09-23_audit_logs_000.jsonl  (1842 entries)
           line 1: server start on 'ws-1' at 2026-09-23 08:00:00.000Z
TAMPERED   2026-09-24_audit_logs_000.jsonl  (977 entries)
           chained from 2026-09-23_audit_logs_000.jsonl
           line 212: The entry's signature does not match the recomputed hash chain value - an entry was altered, removed or reordered.
           line 604: server start on 'ws-1' at 2026-09-24 14:12:09.417Z

1 of 2 file(s) failed verification.

Each file is reported with:

chained from: the file whose last entry this file's first entry was verified against.
server start: a start entry ('k':'-1'), with the host name and time. A server writes one each time it starts, and it begins a new chain. Several of them in one day means the server restarted.
not verifiable: an entry with nothing before it to check against. It is trusted as the starting point, and everything after it is still checked.
The first 100 invalid entries, each with its line number and reason.

How files are chained

The command groups files by stream, which is the part of the name between the date and the sequence number: audit_logs, audit_config_logs, or a replica's audit_logs_replica-<uid>. It checks each stream in date and sequence order, and each file continues the chain from the last entry of the file before it.

So to verify a file's first entries, pass the file written before it too. Passing the whole folder does that. A file checked alone is reported as VALID (first entry unanchored): every entry after the first is still verified.

When an entry does not chain from the previous file, the message says so. The usual cause is a missing file in between.

Examples

Verify an archive every night and keep the report:

curiosity-cli verify-audit-log /mnt/archive/curiosity-audit --strict --json \
  > "/mnt/archive/reports/audit-$(date +%F).json" \
  || echo "Audit log verification failed" | mail -s "Curiosity audit" security@example.com

Verify one day plus the file before it:

curiosity-cli verify-audit-log ./audit/2026-09-23_audit_logs_003.jsonl ./audit/2026-09-24_audit_logs_*.jsonl

convert-audit-log: export the same files to CSV or JSON. --verify runs this check first.
Audit logs: where the files are, what an entry contains, and what the chain does and does not prove.