Skip to content

Ingesting Claude Code Telemetry

Claude Code can report usage, cost, and tool activity over OpenTelemetry. Configured once in the Claude admin console, it applies to every developer in your organisation — no access to developer machines is needed — and the telemetry lands in SenseOn, where it is queryable in Hunt Lab.

ℹ Tell SenseOn before you configure this. Like other log sources, Claude Code telemetry ingestion is enabled per tenant on the SenseOn side. Contact your SenseOn representative or support@senseon.io before rolling this out, so your ingest endpoint is ready to receive it.

Before You Start

Requirement What it needs to be
Plan Claude for Teams, or Claude for Enterprise
Your role Owner or Primary Owner. Admin is not sufficient
Model provider The Anthropic API directly. Not Amazon Bedrock, Google Cloud, Microsoft Foundry, or a custom ANTHROPIC_BASE_URL
Ingest host <code-name>-logs.senseon.io, provided by SenseOn
Network Outbound TCP 4318 from developer machines, and access to api.anthropic.com

⚠ Telemetry leaves over port 4318, not 443, and many corporate firewalls block it by default. Confirm that first, or developers will configure this successfully and send nothing.

⚠ If you already deploy Claude Code policy to devices: console settings outrank device settings, and Claude Code uses the highest source that supplies any policy rather than merging them. Turning the console configuration on can stop your existing device policy applying at all. Move those keys into the console configuration at the same time.

Configure It

  1. Open the managed settings page. Sign in to the Claude console as an Owner and go to Admin Settings > Claude Code > Managed settings. Being redirected elsewhere means your account is not an Owner.
  2. Enter the configuration exactly as below, replacing <code-name> with the value SenseOn provides. These seven variables are all you need, and none of them is a secret.

    {
      "env": {
        "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
        "OTEL_METRICS_EXPORTER": "otlp",
        "OTEL_LOGS_EXPORTER": "otlp",
        "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
        "OTEL_EXPORTER_OTLP_ENDPOINT": "https://<code-name>-logs.senseon.io:4318",
        "OTEL_METRIC_EXPORT_INTERVAL": "300000",
        "OTEL_LOGS_EXPORT_INTERVAL": "300000"
      }
    }
    

    If 4318 is blocked, change the protocol to grpc and the port to 4317. Change both together.

  3. Save. Developers receive the change when they next start Claude Code, or within an hour on a session already running.

  4. Warn your developers about the prompt. The first time Claude Code applies these settings, each developer sees a security dialog naming the endpoint and must accept it. If they decline, Claude Code exits. A note in advance costs less than the support tickets.

💡 Anyone already sending Claude Code telemetry to a collector of their own will find it silently redirected here, so it is worth telling them too.

Confirm It Is Working

  1. Check the policy landed. Run /status in Claude Code and read the Setting sources line. It should read Enterprise managed settings (remote). Anything else means the console delivered nothing, so confirm you saved and restart.
  2. Check Claude Code is emitting. This prints metrics to the terminal, bypassing the network, so output here proves any remaining problem is transport rather than configuration:

    CLAUDE_CODE_ENABLE_TELEMETRY=1 OTEL_METRICS_EXPORTER=console claude -p hi
    
  3. Check it arrives. Restart Claude Code and use it normally. Exports are batched into one every five minutes, so leave it around ten minutes before looking for your data in Hunt Lab.

ℹ Claude Code does not warn anyone when it cannot reach a collector, and carries on working normally. That is why step 2 matters: it separates "not sending" from "sending into a blocked port", which otherwise look identical.

What Is Sent

Data Sent
Usage metrics: sessions, lines of code changed, commits, pull requests, token and cost usage, active time, accept or reject decisions on edits Yes
Event records: that a prompt happened, that a tool ran, that an API call succeeded or failed Yes
Named metadata: which skill, plugin or subagent ran, which MCP server was reached and whether it connected, and the category of a tool failure Yes — each lands in its own column, queryable in Hunt Lab
Identity: signed-in email address, organisation UUID, an anonymous per-install ID, session ID Yes
Prompt text, Claude's replies, tool parameters, tool input and output, raw API bodies, and tool error messages No — redacted before leaving the machine, unless you set OTEL_LOG_TOOL_DETAILS=1 (see Other Settings), which sends tool parameters, tool input arguments, and full tool error messages

ℹ Names arrive as placeholders, off by default. The skill, plugin, subagent and MCP server names are redacted to fixed placeholders such as custom_skill and third-party unless you set OTEL_LOG_TOOL_DETAILS=1. With that setting left off, the detail beside each name — the skill source, plugin scope, subagent source, whether an MCP server connected, and which category a tool failure fell into — stays specific, so you can query the shape of activity without turning names on. Turning OTEL_LOG_TOOL_DETAILS on does more than reveal names, though: see Other Settings before enabling it.

Other Settings

Claude Code exposes further telemetry variables, documented in the Claude Code monitoring guide. If you add any of them, tell SenseOn which, so we can make sure your tenant handles what you send.

One is worth calling out. OTEL_LOG_TOOL_DETAILS is off by default (confirmed against the Claude Code monitoring guide). Setting it to 1 in the same managed configuration turns the redacted skill, plugin, subagent and MCP server names into their real values, so a query can name exactly which skill or which server was involved rather than a placeholder — but it is not limited to names. It also switches a failed tool call from a category such as Error:ENOENT to the tool's full error message, and starts sending each tool call's parameters (for example the Bash command that ran, or the arguments passed to an MCP tool) as structured fields. Prompt text and Claude's replies stay redacted regardless, since those are controlled by separate variables (OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES) that this configuration does not set — but tool parameters and error detail are not, so read the monitoring guide before enabling OTEL_LOG_TOOL_DETAILS if your tools might see file paths, command text, or other content you don't want to leave the machine.

Need Help?

Contact SenseOn support at support@senseon.io with your organisation name, your collector code name, and — if telemetry is not arriving — the output of the terminal check above.