Telemetry (OTLP export)

Speedwave can send the in-container Claude Code session’s OpenTelemetry (OTLP) data to a collector you choose. Telemetry is off by default: nothing exports until you turn it on in Settings → Telemetry. The section is currently gated behind Beta features, so turn the beta toggle on first to see it; the organization-managed enforcement described below applies regardless of the beta toggle.

Turn it on

1. Open Settings → Telemetry and flip the master toggle.
2. Set the collector endpoint, for example https://collector.example.com:4318.
3. Click Test connection to check the collector is reachable from this host before you rely on it.
4. Pick the protocol: gRPC, HTTP protobuf, or HTTP JSON.
5. Turn on Metrics and/or Logs export, whichever signals you want.
6. Optionally set auth headers (for example Authorization=Bearer <token>). The field is masked once saved. Speedwave never displays a saved header value back to you, only whether one is set.
7. Optionally set resource attributes to tag exported data, and Include account UUID if you want that attribute on your metrics.

Metric interval and Logs interval control how often each signal exports, in milliseconds.

Privacy gates for content

Metrics and logs on their own carry counts and events, not conversation content. Four separate checkboxes control whether the exported logs also include that content, and each one is off by default:

Gate	Includes
Log user prompts	The text you send to Claude
Log assistant responses	Claude’s replies
Log tool details	Tool commands and parameters Claude runs
Log raw API bodies	Raw request and response bodies to the model provider

Turning any of these on requires an explicit confirmation, because it sends conversation and code content to your collector. Export Logs also has to be on for these to have any effect: the gates control content inside the log export, they are not a separate export path.

This leaves your machine

With a privacy gate on, prompts, responses, tool details, or raw API bodies go to whatever collector endpoint you configured. Point it at infrastructure you trust before enabling any of them.

Organization enforcement (MDM)

An administrator can force or lock any subset of these settings by deploying a managed-config.json to a machine-wide, admin-only location:

• macOS: /Library/Application Support/Speedwave/managed-config.json
• Windows: <ProgramData>\Speedwave\managed-config.json, resolved through Windows’ own known-folder API rather than the %ProgramData% environment variable, so a spoofed variable cannot hide the policy from Speedwave.

Presence is the lock: any field the file sets becomes read-only in Settings, shown with a lock icon and “managed by your organization.” Omit a field and the user keeps control of it. A missing file is a no-op; a malformed file, or a policy Speedwave cannot resolve, is caught once at startup and stops the app from launching with an “Organization policy error” rather than silently ignoring or partially applying the policy. Setting enabled: false in the managed file is a kill-switch: the whole Telemetry section collapses to a locked banner reading “Managed by your organization, telemetry cannot be changed here,” with no editable controls.

Claude console policy does not apply here

If you administer Claude Team or Enterprise, a telemetry policy set in Claude’s own Admin Settings does not reach Claude Code inside Speedwave. Sessions run behind Speedwave’s local proxy, so ANTHROPIC_BASE_URL is never the default and Anthropic’s server-managed settings are bypassed. Use Speedwave’s managed-config.json instead.

Speedwave re-forces locked values at the process level too: any user-set environment variable for a locked field is stripped and replaced with the managed value before the container starts, so a locked setting stays locked even if something else in the environment tries to override it.

For the full list of config keys Speedwave writes elsewhere, see Configuration keys and Environment variables. For what data leaves your machine in general, see Data and privacy.