Chron: fünf Updates für prüfbare AI-Audit-Trails
Der local-first Logger Chron speichert AI-Interaktionen so, dass Entwickler nachvollziehen können, was aufgezeichnet wurde und was ein Verifikationsergebnis aussagt. Die neuesten Updates sollen Inspektion und Wiederherstellung der Aufzeichnungen verbessern.
Ein KI-Tool, das auf einen Prompt antwortet, und ein gespeicherter Audit-Eintrag sind zwei verschiedene Ereignisse.
Diese Unterscheidung hat unsere aktuelle Arbeit an Chron gepraegt, einem local-first Logger fuer KI-Interaktionen. Wir moechten, dass Entwickler:innen pruefen koennen, was aufgezeichnet wurde, verstehen, was ein Verifikationsergebnis aussagt, und ihre Belege wiederherstellen koennen, wenn etwas schiefgeht.
Hier sind fuenf Funktionen, die in den letzten Releases umgesetzt wurden und in Chron 0.1.64 verfuegbar sind.
MCP-Logging haengt davon ab, dass der Client ein Tool aufruft. Anweisungen koennen diesen Aufruf anfordern, aber sie koennen ihn nicht erzwingen.
chron run zieht eine andere Grenze. Es zeichnet die kontrollierte Standardeingabe, Standardausgabe und Standardfehlerausgabe des Kindprozesses in einem lokalen Journal auf und macht die zugehoerigen Eintraege dauerhaft, bevor Eingaben weitergeleitet oder Ausgaben freigegeben werden. Schlaegt die Aufzeichnung fehl, stoppt die Weiterleitung und Freigabe, statt ohne Eintrag stillschweigend fortzufahren.
npm install -g chron-mcp@0.1.64 chron run -- node -e "console.log('hello from chron')" chron history chron verify --journal Enter fullscreen mode Exit fullscreen mode Der Wrapper versucht zudem, den Lauf in die Datenbank zu projizieren. Schlaegt die Projektion unabhaengig von der Aufzeichnung fehl, ist chron project der Weg fuer einen erneuten Versuch.
Die Grenze ist wichtig: Abgedeckt sind die vom Wrapper kontrollierten Streams. Es zwingt niemanden, den Wrapper zu verwenden, oder zeichnet alles auf, was ein Client ueber Dateien, Unterprozesse oder Netzwerkaufrufe tut. Laeufe, die mit verringerter Verzeichnis-Dauerhaftigkeit aufgezeichnet wurden, erhalten nicht die vollstaendige enforced:wrapper-Klassifizierung.
Ein Logger sollte einen Wiederherstellungspfad haben, bevor er einen destruktiven Befehl bekommt.
Chron erstellt jetzt SQLite-Snapshots mit VACUUM INTO, zusammen mit einem separaten Manifest, das den Snapshot beschreibt. Die Wiederherstellung prueft die Datei-Pruefsumme, die Datenbankintegritaet und die aufgezeichneten Belegketten, bevor die wiederhergestellte Kopie installiert wird. Recovery-Tests ueben die Verifikation, ohne die Live-Datenbank zu ersetzen.
Bestaetigtes Aufraeumen erfordert ein explizites Backup-Ziel und verweigert das Loeschen, wenn dieses Backup fehlschlaegt.
Backups und signierte Exporte bleiben unterschiedliche Werkzeuge: Das eine stellt eine Datenbank wieder her, das andere ermoeglicht es, ein portables Belegbuendel zu verifizieren. Das Backup-Manifest ist nicht signiert, daher ist seine aufgezeichnete Erstellungszeit nicht unabhaengig belegt.
chron reconcile vergleicht lokale Claude Code-Transkripteintraege mit den geprueften Chron-Belegen. Es ist rein lesend: Es importiert, fuegt nicht zusammen und stuft die Herkunft einer Sitzung nicht stillschweigend auf.
Der Streaming-Reader kann grosse Transkriptdateien pruefen, ohne die gesamte Datei im Arbeitsspeicher zu halten. Der Vergleich bleibt eine Stichprobe von bis zu 200 Nachrichten pro Transkript und berichtet ueber seinen geprueften Umfang und seine Grenzen.
Ein nicht zugeordneter Eintrag bedeutet, dass innerhalb dieses Vergleichs keine Entsprechung gefunden wurde. Er ist kein Beweis, dass jemand das Logging umgangen hat, und der Entsprechungsanteil ist kein Mass fuer die Vollstaendigkeit der Aufzeichnung.
Chron unterstuetzt einen vom Bediener ausgeloesten OTLP/HTTP JSON-Trace-Export fuer Sitzungen und Nachrichten. Konversationsinhalte sind standardmaessig ausgeschlossen.
Der nuetzliche Teil liegt darin, Ergebnisse zu unterscheiden. Ein Collector, der einen Export ablehnt, ist nicht dasselbe wie eine Verbindung, die vor der Zustellung fehlschlaegt. Eine Anfrage, die ein Collector entgegennimmt, aber nie beantwortet, hat ein unbestimmtes Ergebnis.
chron otel receipts legt den aufgezeichneten Zustellstatus offen, statt diese Faelle zu einem Erfolgshaeckchen zusammenzufassen. Dies ist manueller Trace-Export, keine automatische Telemetrie sowie kein Metrik- oder Log-Export. Eine Collector-Antwort ist kein Beweis fuer dauerhafte Speicherung.
Bei Deployments, die MCP ueber HTTP nutzen, verlangt Chron 0.1.64 eine Authentifizierung und bindet sich standardmaessig an den Loopback. Host und Origin werden validiert, und eine Bindung ausserhalb des Loopbacks erfordert eine explizite Konfiguration.
Der stdio-Pfad bleibt getrennt und benoetigt keinen HTTP-API-Schluessel.
Das sind konkrete Kontrollen, keine pauschale Sicherheitsaussage. Die Haertung der Abhaengigkeiten laeuft weiter und wird getrennt von der Feature-Arbeit geplant.
Der rote Faden ist, die Aussage nah am Beleg zu halten.
Eine Journal-Kette kann interne Konsistenz belegen; eine nicht verankerte Kette ist kein Beweis, dass niemand sie veraendert hat. Ein erfolgreicher Pakettest belegt nicht, dass jeder KI-Client Chron aufrufen wird. Ein lokaler Eintrag belegt nicht, dass jede Interaktion aufgezeichnet wurde.
Unser neuester Regressionstest fuer publizierte Pakete bestand 44 Release-Pruefungen und neun Streaming-Pruefungen. Die echte Abnahme mit authentifizierten Clients bleibt ein separates, unabgeschlossenes Testfeld, das diese Zahlen nicht abdecken.
Chron ist auf npm verfuegbar, mit Quellcode und Dokumentation auf GitHub.
An Teams, die KI-Entwicklerwerkzeuge einsetzen: Welche Luecke ist heute die groesste: verlaessliche Aufzeichnung, das Erkennen fehlender Eintraege oder die unabhaengige Verifikation der bereits vorhandenen Belege?
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
An AI tool answering a prompt and an audit record being saved are two different events.
That distinction has shaped our recent work on Chron, a local-first logger for AI interactions. We want developers to inspect what was recorded, understand what a verification result establishes, and recover their evidence when something goes wrong.
Here are five capabilities shipped across recent releases, available in Chron 0.1.64.
MCP logging depends on the client calling a tool. Instructions can request that call, but they cannot make it inevitable.
chron run introduces a different boundary. It records the child's controlled stdin, stdout and stderr in a local journal and makes the covering records durable before forwarding input or releasing output. If capture fails, it stops forwarding and releasing rather than quietly continuing without a record.
npm install -g chron-mcp@0.1.64 chron run -- node -e "console.log('hello from chron')" chron history chron verify --journal Enter fullscreen mode Exit fullscreen mode The wrapper also attempts to project the run into the database. If projection fails independently of capture, chron project is the retry path.
The limit matters: this covers streams controlled by the wrapper. It does not force anyone to use the wrapper or capture everything a client does through files, subprocesses or network calls. Runs recorded with reduced directory durability do not receive the full enforced:wrapper classification.
A logger should have a recovery path before it has a destructive command.
Chron now takes SQLite snapshots using VACUUM INTO, with a separate manifest describing the snapshot. Restore checks the file digest, database integrity and recorded evidence chains before installing the restored copy. Recovery drills exercise verification without replacing the live database.
Confirmed pruning requires an explicit backup destination and refuses to delete if that backup fails.
Backups and signed exports remain different tools: one restores a database; the other lets someone verify a portable evidence bundle. The backup manifest is unsigned, so its recorded creation time is not independently attested.
chron reconcile compares local Claude Code transcript records with inspected Chron evidence. It is read-only: it does not import, merge or silently upgrade the provenance of a session.
The streaming reader can inspect large transcript files without retaining the whole file in memory. The comparison remains sampled, up to 200 messages per transcript, and reports its inspected scope and limits.
An unmatched record means no correspondence was found within that comparison. It is not proof that someone bypassed logging, and the correspondence fraction is not a capture-completeness score.
Chron supports operator-initiated OTLP/HTTP JSON trace export for sessions and messages. Conversation content is excluded by default.
The useful part is distinguishing outcomes. A collector refusing an export is not the same as a connection failing before delivery. A request received by a collector that never answers has an uncertain outcome.
chron otel receipts exposes the recorded delivery state rather than flattening those cases into a success tick. This is manual trace export, not automatic telemetry, metrics or log export. A collector response is not proof of permanent retention.
For deployments using MCP over HTTP, Chron 0.1.64 requires authentication and binds to loopback by default. It validates Host and Origin, and non-loopback binding requires explicit configuration.
The stdio path remains separate and does not require an HTTP API key.
These are specific controls, not a blanket security claim. Dependency hardening is ongoing and is being scoped separately from feature work.
The common thread is keeping the claim close to the evidence.
A journal chain can establish internal consistency; an unanchored chain is not proof that nobody rewrote it. A successful package test does not establish that every AI client will invoke Chron. A local record does not establish that every interaction was captured.
Our latest published-package regression passed 44 release checks and nine streaming checks. Real authenticated client acceptance remains a separate, unfinished test leg, not something those numbers establish.
Chron is available on npm, with source and documentation on GitHub.
For teams using AI developer tools: which gap is hardest today: dependable capture, identifying missing records, or independently verifying the evidence you already have?