Does Claude Code have built-in logging?

Claude Code writes a session transcript, and it exposes hooks that fire on every tool call. The transcript is not designed as an audit record and is not tamper-evident. Hooks are the mechanism you use to record tool calls yourself.

What does monitoring Claude Code cost in latency?

A PreToolUse and PostToolUse hook pair costs about 124ms per tool call, measured, median. On a 100-call session that is roughly twelve seconds. Most of that is Python interpreter startup rather than the recording itself.

Do I need a server to monitor Claude Code?

No. A hook can append to a local file. Hosted observability platforms give you dashboards and evals in exchange for running a deployment. For a VM, Langfuse self-hosting recommends at least 4 cores and 16 GiB of memory, with 100 GiB of storage.

Can I prove the log was not edited afterwards?

Only if the log is built for it. A plain log file can be edited freely. A hash-chained file makes an edit, a deletion or a reorder detectable, and signing the head catches a chain that was rebuilt from scratch.

How to Monitor Claude Code: Logging, Telemetry and Observability Options

Your agent said it worked. The tool returned a success code. The thing you asked for never happened, and there is no record to contradict it.

That is the failure mode worth monitoring for. It is not a crash. Crashes are easy: you get a stack trace and a red line in the terminal. The expensive failure is the confident one, where a run reports success and the work was not done, and you find out days later.

This page covers the three ways people monitor Claude Code, what each one actually gives you, and where each one stops.

What “monitoring Claude Code” means in practice

Claude Code writes a session transcript. It is useful for reading back a conversation. It was not designed as an operational record, it is not structured for querying, and nothing about it resists editing.

The mechanism built for this job is hooks. Claude Code fires a hook on tool-call events, and passes the tool name, its input and its response to your command on stdin. Two events matter for monitoring:

PreToolUse fires before the tool runs. This is the decision: what the agent was about to do.
PostToolUse fires after. This is the outcome: what the tool returned.

Recording only the outcome tells you what happened. Recording both tells you what was authorised before it ran, which is a different and stronger claim.

The three options

	Hosted platform	Self-hosted platform	Local file
Examples	Braintrust, LangSmith, Langfuse Cloud	Langfuse, Arize Phoenix	a hook that appends to disk
Dashboards and evals	Yes, and they are good	Yes	No
Infrastructure	None, it is their problem	Langfuse recommends 4+ cores, 16 GiB, 100 GiB on a VM	None
Your data leaves the machine	Yes	No	No
Detects the record being edited	No	No	Only if the format is built for it

Be clear about the trade. If you want dashboards, traces, evaluation runs and a team UI, use an observability platform. They are mature, they are good at it, and a file will not compete on features. That comparison is not close and pretending otherwise wastes your time.

The reason people look past them is usually one of two things. Either the deployment is more than the problem is worth, or the data cannot leave the building.

Monitoring with a hook, concretely

hsm hook --install prints a snippet for ~/.claude/settings.json. It does not edit your settings. You paste it.

pip install homestead-memory     # needs Python 3.10+
hsm hook --install               # prints the PreToolUse + PostToolUse entries
hsm watch                        # see what your agent actually did

Every tool call is appended to a plain JSONL file on your disk. hsm watch reads it back in order, showing the decision and the outcome as separate records.

If you want to see it before installing anything, hsm watch --demo runs the whole loop in a temporary directory and cleans up after itself.

The part a plain log file cannot do

A log file is a claim about the past that anyone with write access can revise. If the question is “what did my agent do”, a plain log answers it. If the question is “can I show someone what my agent did, and can they believe it”, a plain log does not.

Each record in the ledger carries the hash of the record before it. Editing a record, deleting one, or reordering two breaks every hash after it, and the break is reported at the exact index. That is tamper-evident, not tamper-proof: it does not stop an edit, it makes one detectable.

Hash chaining alone has a hole, and it is worth naming. Someone who rewrites every record can recompute every hash and produce a file that is internally perfect. hsm checkpoint signs the head with a key, which is what catches that. Everything appended after your last checkpoint is not yet covered, so re-checkpoint regularly.

What it costs

About 124ms per tool call, measured, median, both hook phases combined. On a session with 100 tool calls that is roughly twelve seconds.

Most of that is Python interpreter startup rather than the recording work. It is disclosed here because it is the most likely reason to uninstall, and finding out on your own machine is worse than reading it first.

What this does not cover

Claude Code only. Cursor and Codex use different mechanisms and are not supported.
It records what the harness reported. If a tool lies about what it did, the ledger faithfully records a hash-chained lie. It is a record of reported actions, not independent observation.
The signing key sits on the same machine as the log. Anyone who can rewrite the file can usually read the key. Publishing a signed checkpoint somewhere else is the answer to that, and hsm checkpoint --export prints one line for the purpose.

Free, MIT licensed, no account and no server: github.com/fuckbigtech-ai/homestead-memory