Privacy and trace context

Continue an upstream WebSocket trace

An authenticated Gateway WebSocket client can attach a W3C traceparent to each request frame:

{  "type": "req",  "id": "eval-item-42",  "method": "agent",  "params": {},  "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"}

The Gateway creates a child request context that preserves the upstream trace ID and sampling flags. Agent, harness, model-call, provider, tool-execution, and exec spans created inside the request remain on that trace, including spans recorded after their parent run has already finished. This allows a local experiment runner to create one Langfuse/OpenTelemetry trace per dataset item and correlate the corresponding OpenClaw execution.

Trace context is request-scoped, not connection-scoped. On a long-lived WebSocket, generate or inject the appropriate traceparent independently for every RPC. Concurrent requests remain isolated even when their work interleaves.

The field is accepted only after the existing Gateway authentication handshake and does not affect authentication or method authorization. A traceparent on the initial connect frame is ignored. Missing or syntactically malformed values within the 128-character field limit silently fall back to a fresh request trace; longer values make the request frame invalid. tracestate and baggage are not accepted by the Gateway WebSocket protocol.

Privacy and content capture

Raw model/tool content is not exported by default. Spans carry bounded identifiers (channel, provider, model, error category, hash-only request ids, tool source, tool owner, skill name/source) and never include prompt text, response text, tool inputs, tool outputs, skill file paths, or session keys. Values that look like scoped agent session keys (for example starting with agent:) are replaced with unknown on low-cardinality attributes. OTLP log records keep severity, logger, code location, trusted trace context, and sanitized attributes by default; the raw log message body is exported only when diagnostics.otel.captureContent is true. Talk metrics export only bounded event metadata (mode, transport, provider, event type) - no transcripts, audio payloads, session ids, turn ids, call ids, room ids, or handoff tokens.

When diagnostics-otel tracing is active, outbound model requests may include a W3C traceparent header from the actual exporter-owned model-call span. Diagnostic trace IDs and span IDs only correlate events to that span; they are not used as outbound OTel identities. If the exporter cannot resolve a real span context, OpenClaw omits the header instead of naming an unexported parent. Existing caller-supplied traceparent headers are removed or replaced, so plugins or custom provider options cannot spoof cross-service trace ancestry.

Set diagnostics.otel.captureContent to true only when your collector and retention policy are approved for prompt, response, tool, and tool-definition text. This enables bounded, redacted input messages, output messages, tool inputs, tool outputs, tool definitions, and OTLP log bodies. System prompts remain excluded. Provider-internal thinking and redacted_thinking payloads are also excluded: compatibility attributes retain only a redacted structural marker, while GenAI message attributes omit those parts.

toolInputs/toolOutputs content is captured for the built-in agent runtime's tool executions (openclaw.content.tool_input and gen_ai.tool.call.arguments on completed/error spans; openclaw.content.tool_output and gen_ai.tool.call.result on completed spans). The openclaw.content.* names remain the stable OpenClaw attribute names; the gen_ai.tool.call.* copies mirror them for semconv-native viewers. External harness tool calls (Codex, Claude CLI) emit tool.execution.* spans without content payloads. Captured content travels on a trusted, listener-only channel and is never placed on the public diagnostic event bus.