Claude Code runs tools on your machine, shell commands, file edits, network fetches. When the session ends, the terminal is gone and so is the record of what happened. Toolog captures every tool call, stores it in an embedded database on your machine, and gives you three views over the data: a forensic timeline, a permission and risk review, and the state of capture itself.

What toolog captures

Every tool call Claude Code makes gets recorded. The full shell command, the full file diff, who approved or refused each call, which rule evaluated it, and how long it took. The data stays on your machine in a SQLite database. There is no analytics, no crash reporting, no remote configuration, no account, and no update check. The update path is brew upgrade, and that is the only network interaction the application makes.

The application runs as a menu-bar app on macOS. It binds an OTLP receiver to 127.0.0.1 only, which means no traffic leaves the loopback interface. A CI test verifies this by running a full ingest and every query the UI issues, then asking the operating system which sockets the process holds. Any address that is not loopback fails the build. A second test proves the check can fail by opening a socket pointed off the machine and asserting the census sees it. The guarantee is a build failure when broken, not a promise in a readme.

Two ingestion lanes

Toolog uses two data sources because neither is complete alone. The first lane watches Claude Code's transcript files, which carry the full content of every tool call: the complete shell command, the complete file diff. These files are appended by Claude Code during the session and tailed by toolog through file system events.

The second lane receives OpenTelemetry logs over HTTP on localhost. The OTEL lane carries what transcripts never record: who approved or refused each call, which rule evaluated it, and how long the call took. OTEL also truncates tool inputs at 512 characters, which is why the transcript lane matters for full content.

The two lanes are joined on tool_use_id. Where they disagree, that is a finding rather than an inconsistency to paper over. A call only the transcript saw is a gap in collection. A call only OTEL saw had no transcript body written. This is how the tool demonstrates its own completeness instead of asserting it. Neither lane puts code on Claude Code's critical path. One is a read-only file watch. The other is a fire-and-forget export whose failure costs nothing.

The risk review

Twelve built-in rules evaluate each tool call against a set of security patterns. Rules that match get a severity level. The risk review shows the rules evaluated, worst first, with what each one looks for whether or not it matched. Rules are deterministic. A rule's severity is the same every time.

For tool calls that no rule matched, the local model provides a second opinion. Toolog links llama.cpp and does not ship with a downloader. You fetch the .gguf model yourself and point toolog at it. The model reads each unmatched tool call and produces a one-line summary of what it was doing, scored on a scale from one to five.

The model's scores are advisory and visibly separated from the rule-based severity in every view. The model is wrong sometimes. Measured on the owner's store, it scored a benign cargo test at two and needed its rubric spelled out before it called a raw device dangerous. That is why it is opt-in, advisory, and kept apart from the rules everywhere it appears. The one-line intent summary may be the half worth keeping even where the score is not.

What it does not do

Toolog does not capture decisions or latency for sessions that ran while it was not listening. Those sessions arrive through the transcript lane only, which has commands and results but no decision layer. The verify command reports exactly which sessions those are, rather than averaging across a gap as if it were not there.

Cost is captured and never shown. API request records are stored and counted, and nothing reports spend or tokens. This is a scope decision, not an omission. The database is a plain SQLite file on purpose, which lets you verify the claims in the privacy documentation without trusting the program. Encryption at rest was evaluated and declined in favor of FileVault, which already encrypts the entire disk.

Quitting from the menu bar stops capture, and that is intentional. Anything Claude Code runs while toolog is quit is recoverable by a later backfill, minus the decision layer. There is no update notification. If you downloaded the disk image directly, nothing tells you a new version exists. That is the cost of an application that makes no network calls.

Installation and what it changes

Toolog is installed through Homebrew or as a direct download. It is a universal macOS build signed with a Developer ID and notarized by Apple, so it opens without a Gatekeeper warning. The doctor command configures Claude Code's telemetry settings, merging rather than overwriting the existing configuration. It keeps a timestamped backup and refuses to run if a non-loopback OTEL endpoint is already configured.

The uninstall command restores the settings file from the backup taken before toolog first wrote to it. If you have edited the file since, it removes only toolog's own keys and explains why it did not restore the full file. Your recorded history is kept unless you add the delete-data flag.

For developers who want to know what Claude Code actually did on their machine, when, in which repository, and who approved it, toolog provides a local audit trail that never sends data anywhere. The database is yours. The binary is signed. The network is silent.