Summary

diagnostics.otel.captureContent.{inputMessages,outputMessages,toolInputs,toolOutputs} is documented but does nothing. The runtime emits only sanitized paramsSummary on the broadcast stream that bundled diagnostics-otel consumes — raw inputMessages, toolInput, and toolResult content never appear in OTel span attributes. Confirmed empirically against pre-bug traces from 2026-05-03 through 2026-05-04 with captureContent: {enabled: true, inputMessages: true, outputMessages: true, toolInputs: true, toolOutputs: true}: zero openclaw.content.* attributes on any span.

Environment

• OpenClaw 2026.5.3-1 (also confirmed on 2026.5.3 and earlier 5.2 releases)

Reproduction

openclaw config set diagnostics.otel.enabled true
openclaw config set diagnostics.otel.captureContent.enabled true
openclaw config set diagnostics.otel.captureContent.inputMessages true
openclaw config set diagnostics.otel.captureContent.outputMessages true
openclaw config set diagnostics.otel.captureContent.toolInputs true
openclaw config set diagnostics.otel.captureContent.toolOutputs true
openclaw gateway restart --wait 30s

openclaw agent --message 'hello' --agent main --to '+15555550100' --json

Observed

Spans reach the OTLP endpoint with openclaw.run, model_call, tool.execution names, but no openclaw.content.*, openclaw.input.*, or openclaw.output.* attributes are populated. Tool spans carry only paramsSummary (a hash + length, no actual values).

Expected

Per docs (/gateway/opentelemetry), captureContent: true should populate raw input/output content as span attributes (size-capped, optionally redacted).

Working approach (for reference)

We bypassed this by writing a separate plugin that subscribes to public hooks (api.on("before_tool_call", ...), api.on("llm_input", ...), etc.) — the hook arguments contain full unsanitized content because the runtime calls hook handlers with the real data, not the sanitized broadcast. Code: https://github.com/mjunaidca/tutorclaw/tree/main/plugins/tutorclaw-tracing

This works, but it means every operator who wants content visibility has to ship their own plugin. The bundled diagnostics-otel's configuration knob is the natural seam — it just doesn't work today.

Suggested fix

Either:

• (a) Wire captureContent.* flags through to actual content-emission paths so the documented config does what it claims; OR
• (b) Document captureContent as deprecated/no-op and point operators at the public-hook plugin pattern as the recommended approach.

Related

Related to #77390 (bundled-only origin gate) — even if captureContent worked, externally-installed diagnostics-otel couldn't receive the events to attach attributes to.