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, not443, 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
- 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.
-
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
4318is blocked, change the protocol togrpcand the port to4317. Change both together. -
Save. Developers receive the change when they next start Claude Code, or within an hour on a session already running.
- 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
- Check the policy landed. Run
/statusin Claude Code and read the Setting sources line. It should readEnterprise managed settings (remote). Anything else means the console delivered nothing, so confirm you saved and restart. -
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 -
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_skillandthird-partyunless you setOTEL_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. TurningOTEL_LOG_TOOL_DETAILSon 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.