OpenClaw Logfire

Pydantic Logfire observability — OTEL GenAI traces, tool call spans, token metrics, distributed tracing

This package appears to do exactly what it claims: export OpenClaw spans/metrics to Pydantic Logfire. Before installing, consider: 1) Trust the destination — traces (even redacted) leave your host to logfire-api.pydantic.dev/eu. 2) Review or test the redaction logic (src/util.ts) if you have high-sensitivity data; pattern-based redaction can miss custom secrets. If unsure, disable captureToolInput or enable stricter redaction in config. 3) Use the EU region option if you need data residency. 4) Treat LOGFIRE_TOKEN like any write key: create a token with minimum scope, rotate it, and avoid embedding it in repos. 5) Deploy to a staging instance first to confirm no unexpected data is emitted. If you want, I can scan the specific util.ts and otel.ts functions for the exact redaction patterns and any other data-exfil patterns.

Type: OpenClaw Skill Name: openclaw-logfire Version: 0.1.2 The skill bundle is an OpenTelemetry (OTEL) plugin for Logfire observability, designed to trace agent lifecycle, tool calls, and metrics. It reads `LOGFIRE_TOKEN` and sends data to legitimate Logfire endpoints (`logfire-us.pydantic.dev`, `logfire-eu.pydantic.dev`). The `src/util.ts` file includes a `redactSecrets` function, which is a positive security feature. However, the `src/context/propagation.ts` file contains `injectTraceContext` which modifies shell commands (e.g., `curl`, `wget`) by appending `traceparent` headers to their arguments. While intended for legitimate distributed tracing, modifying shell command arguments programmatically introduces a vulnerability risk (e.g., shell injection) if the original command or the injected headers are not perfectly sanitized or handled by the shell, even if the headers themselves are structured OTEL data. This capability, despite its benign intent, elevates the classification to 'suspicious' due to the inherent risk of command modification.