Claude Code is running bash commands on your infrastructure. Here’s how to watch it.

I’ve been staring at Claude Code telemetry for the past few weeks, and I keep noticing the same thing: most teams drop it into their environment, say “it’s amazing,” and have absolutely no idea what it’s actually doing at the system level.

That’s fine for a personal dev tool. It’s not fine when you’ve rolled it out to 50 engineers.

What Claude Code actually emits

Claude Code ships with native OpenTelemetry support. Two environment variables and they’re exporting:

The endpoint URL comes from creating an OTLP/HTTP source under Manage Data, then Collection, then Hosted Collectors in Sumo Logic. Once the source is created, it gives you a unique ingest URL. Point your env vars at that URL, and you’re done. No collector required. No SDK. No wrapper. What starts flowing: metrics every 60 seconds, events every five.

The metrics are the boring part (but you still want them)

Token usage by user, by model, by type (input/output/cache). Cost per session in USD. Sessions started. Lines of code added and removed. Commits created. PRs created. Time spent actively interacting vs. time Claude is processing.

This is your ROI dashboard. It answers the question your VP of Engineering is going to ask in three months: “We’re paying for this. Is anyone actually using it?”

Segment by user.account_uuid and organization.id. Build a Sumo Logic dashboard. Move on.

The events are the interesting part

This is what’s worth paying attention to.

Every time Claude runs a tool, you get a claude_code.tool_result event. That event contains the tool name, execution time, success or failure, and for Bash: the full bash_command that ran.

Every file path touched. Every git command. Every script invoked. Logged, structured, searchable.

Every time a user submits a prompt, you get a claude_code.user_prompt event — prompt length by default, full content if you flip OTEL_LOG_USER_PROMPTS=1. Every API call gets its own claude_code.api_request event with model, cost, latency, and token counts.

The thing that ties all of this together: prompt.id. A UUID on every event linking back to the original prompt that triggered it. One filter in Sumo Logic Log Search, and you can reconstruct the full execution chain: what the user asked, what API calls it made, what tools it ran, all in order.

More than a log, that’s an audit trail.

The field nobody’s looking at

decision_source.

Every tool execution records how the permission decision was made: config, hook, user_permanent, user_temporary, user_abort, user_reject.

user_permanent means the user clicked “always allow.” Once. For that tool. Forever.

Pull that field in Sumo Logic and look at your distribution. If most of your tool decisions are user_permanent, your engineers have effectively pre-authorized Claude to do whatever it wants with whatever tools it touches. They did it once, months ago, and forgot about it. That’s not a security crisis. But it is something you should know, and right now you probably don’t.

What to actually build in Sumo Logic

Here are three dashboards worth setting up in Sumo Logic:

• Usage and cost: Token consumption by user and model over time. Cost per session. Active time vs. idle time. This is the thing finance will eventually ask for.
• Tool execution: Which tools are running, how often, success rate, and average duration. Filter to the Bash tool and look at the command patterns. You’ll learn things about how your engineers are actually using the tool vs. how you thought they were.
• Session reconstruction: A saved search filtered by prompt.id with fields for event.name, event.timestamp, tool_name, bash_command, cost_usd. If something goes wrong and a wrong file is deleted, or there’s an unexpected API call or a mysterious commit, this is how you figure out what happened.

One thing to get right before you go wide

The tool_parameters field can contain secrets. If engineers run bash commands that include tokens, passwords, or API keys inline, those values land in your logs.

Configure a Sumo Logic field extraction rule to mask or drop tool_parameters before ingestion if that’s a concern for your environment. Don’t wait until after you’ve shipped it to 50 people.

Final thoughts

Claude Code is useful. That’s established. But useful and observable aren’t the same things. And in an engineering org, unobservable tooling has a way of creating surprises at the worst possible time.

Wire it up. You probably won’t regret knowing.

See what you can do with our 30-day free trial.