Why is best-effort telemetry a compliance problem and not just an ops problem?

Because the events you most need for an audit or incident reconstruction are generated right before a failure, which is also when a process is most likely to crash. In-memory batching loses exactly that window. EU AI Act Article 12 requires records that are durable and traceable across the system's lifetime, so a pipeline that silently drops events on a crash does not meet the requirement no matter how much data it collects when everything is healthy.

How does MeshAI for Claude Code guarantee no events are lost?

It uses the outbox pattern. Every hook event is appended to a local write-ahead log and fsynced to disk before anything else happens, and only then does a separate daemon publish it. Daemon crash, out-of-memory, or network outage cannot lose an acknowledged event because it is already on disk; only disk failure can. Span ids are minted once at hook time and deduplicated on ingest, so replay after a crash records the event exactly once.

Does the connector send my source code to MeshAI?

No, not by default. Content filtering is default-deny: tool inputs and outputs, including code and file contents, are dropped unless you explicitly allow a specific field for a specific tool. Structural metadata such as tool name, timing, and token counts always flows. Allowed content is scrubbed of secrets before it leaves, and the write-ahead log is owner-only local state.

What does it cost and how do I install it?

The connector is open source under Apache-2.0 and free to install with pip install meshai-claude-code. It runs on macOS, Linux, and WSL. You need a MeshAI account to receive the telemetry. Source and configuration are at github.com/meshailabs-org/meshai-claude-code.

← Back to Blog

eu-ai-actarticle-12ai-agentsobservabilityclaude-codeopen-source

Your Agent Telemetry Loses Data on a Crash. For EU AI Act Records, That Is the Whole Problem.

Henrique Veiga Curi2026-07-067 min read

Most telemetry for AI agents is best-effort. The agent emits an event, an in-memory queue batches it, and a background exporter ships it when it gets around to it. If the process crashes, the machine runs out of memory, or the network drops while events sit in that queue, they are gone. For a dashboard, that is an acceptable trade. For a regulatory record, it is a failure at exactly the moment the record matters most.

EU AI Act Article 12 requires high-risk AI systems to automatically record events across the system's lifetime, and to keep those records traceable and appropriate to the risk. A record that silently disappears when a process dies does not meet that bar. The gap is not that teams collect the wrong data. It is that the collection itself is not durable, and almost nobody checks whether it is.

We built the fix as an open-source connector for Claude Code, and we proved it by pointing it at ourselves. You can install it today:

pip install meshai-claude-code

Observability durability and compliance durability are different requirements

An observability pipeline is allowed to drop data. Sampling is a feature. If one span in ten thousand never lands, no dashboard is wrong in a way anyone notices. The standard OpenTelemetry setup reflects this: a batch span processor holds events in memory and flushes them on an interval. Fast, cheap, and lossy by design.

A compliance record has the opposite requirement. The events you most need are the ones generated right before something went wrong, which is also exactly when a process is most likely to crash. Best-effort telemetry loses data precisely in the window that an auditor, an incident review, or an Article 26 reconstruction cares about. The reliability math is unforgiving here. A twenty-step agent chain running at 95 percent per-step reliability completes end to end only about 36 percent of the time, and every failure is a moment where in-memory events vanish.

So durable record-keeping is not a stricter version of observability. It is a different property, and you cannot bolt it on after the fact by turning up a sampling rate.

Write to disk first, publish second

MeshAI for Claude Code uses the outbox pattern, borrowed from databases that cannot afford to lose a write. When Claude Code fires a hook, before anything else happens, the event is appended to a local write-ahead log and fsynced to disk. Only after the event is durably on disk does a separate daemon read the log and publish it to MeshAI over OpenTelemetry.

The ordering is the whole point. The daemon is a publisher of a durable log, not the source of truth. If the daemon crashes, the machine loses power, or the network is down for an hour, the events are already on disk and get published when the daemon comes back. The only thing that can lose an acknowledged event is disk failure itself. On macOS the connector uses a full-platter flush rather than the ordinary fsync that the operating system is allowed to buffer, because on a compliance record "probably written" is not written.

Each event is framed with a checksum so a process killed mid-write is detected and healed on the next read rather than corrupting the log. Every event carries a span id minted once, at hook time. Delivery is at-least-once, and the MeshAI ingest side deduplicates on that span id, so a crash-and-replay produces the record exactly once. Not approximately once. Once.

There is an optional compliance mode that inverts the failure posture: if the event cannot be durably recorded, Claude Code is blocked from proceeding. No evidence, no action. That is a strong setting, off by default, for teams whose obligation is that strict.

What leaves your machine, and what never does

Durability is worthless if the price is leaking source code or secrets into a telemetry backend. The connector is default-deny on content. Structural metadata always flows: which tool ran, when, how many tokens it used, the shape of the session. The actual contents of a tool call, the code, the file bodies, the command output, are dropped unless you explicitly allow a specific field for a specific tool.

When you do allow content, it passes through a secret-redaction pass first, which catches API keys, tokens, private key blocks, and their homoglyph and base64-wrapped variants, and fails closed if a pattern check ever times out. The write-ahead log itself is owner-only local state. The default posture is that your code stays on your machine and only the evidence of what happened leaves it.

We instrumented the Claude Code that builds MeshAI

The cleanest way to trust a record-keeping tool is to watch it record something real. MeshAI's first instrumented agent is the Claude Code instance we use to build MeshAI itself. It is installed, the hooks are live, and the telemetry from those coding sessions flows into our own control plane: agents auto-discovered, token usage and cost attributed per session, governance evaluated against policy.

We also verified the property that matters. We replayed a completed session's events a second time, the way a crashed daemon would on restart, and confirmed the usage landed exactly once rather than double-counting. The durability guarantee is not a claim in a README. It is something we exercise against production every day we ship.

Install it

The connector is Apache-2.0 licensed and on PyPI. It runs on macOS, Linux, and WSL.

pip install meshai-claude-code

Then log in with your MeshAI API key and run the install command, which registers the hooks in your Claude Code settings with a backup and a clean uninstall path. Source, configuration, and the filtering rules are at github.com/meshailabs-org/meshai-claude-code.

If you are running AI coding agents inside a high-risk process and you need the record to survive the crash, that is the problem this was built for. See how the four pillars fit together on the features page, or start on the pricing page.