[BUG] claude_code.active_time.total not emitted in --print mode on 2.1.119

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The claude_code.active_time.total OpenTelemetry metric is not emitted in claude --print (non-interactive) mode on Claude Code 2.1.119, despite other claude_code.* metrics emitting correctly from the same process and pipeline.

Across 5 independent claude --print sessions running the same prompt with OTEL_METRICS_EXPORTER=console and OTEL_METRIC_EXPORT_INTERVAL=1000, every session emitted hundreds of records for the three other documented claude_code.* metrics, and zero records for claude_code.active_time.total:

| Run | session.count | token.usage | cost.usage | active_time.total |
|---|---:|---:|---:|---:|
| 1 | 39 | 38 | 38 | 0 |
| 2 | 46 | 45 | 45 | 0 |
| 3 | 41 | 41 | 41 | 0 |
| 4 | 44 | 43 | 43 | 0 |
| 5 | 37 | 36 | 36 | 0 |
| Total | 207 | 203 | 203 | 0 |

The union of metric names observed across the 5 sessions was exactly three: claude_code.session.count, claude_code.token.usage, claude_code.cost.usage. claude_code.active_time.total never appeared. The type: "user" / type: "cli" attribute distribution was zero across all 5 sessions (an active-time record with type: "cli" was the documented expected output for CLI-side tool execution and AI response generation).

The cadence is consistent with OTEL_METRIC_EXPORT_INTERVAL=1000ms sampling each cumulative counter once per export window. Per-run counts in the 37–46 range over a ~3-minute wall-clock session reflect the active export windows that fell between session start and shutdown; the remainder is process startup/initialization and inter-tool model latency outside any active counter-emission window.

Sample size

N=5 independent claude --print sessions, all run on the same machine with the same prompt and the same ~/.claude/settings.json configuration. The pattern was identical in every run: zero active_time.total records, hundreds of sibling-metric records — 613 sibling records total across the 5 sessions, with no active_time line item in any of them.

Why this is not the same as #46338

Issue #46338 reported that non-interactive -p mode emitted no OpenTelemetry output at all on 2.1.100. In this repro on 2.1.119, OpenTelemetry export is demonstrably working in non-interactive mode: 613 records emitted across three other claude_code.* metrics over 5 independent sessions.

The failure is metric-specific: claude_code.active_time.total emits zero records even though sibling metrics emit on the expected interval.

Relationship to #16525

Issue #16525 reported that active_time was missing for some sessions while cost and token metrics worked. That issue was closed as a duplicate of #13803, which received a fix in v2.0.70. This report does not assert anything about whether the v2.0.70 fix was complete — only that on 2.1.119 in non-interactive mode the symptom is reproducible across 5/5 sessions, which is adjacent enough to flag for triage.

What Should Happen?

Per the official monitoring documentation at https://code.claude.com/docs/en/monitoring-usage (section "Active time counter"):

Tracks actual time spent actively using Claude Code, excluding idle time. This metric is incremented during user interactions (typing, reading responses) and during CLI processing (tool execution, AI response generation). Attributes: - type: "user" for keyboard interactions, "cli" for tool execution and AI responses

Each repro session contained substantial CLI processing (multiple tool executions plus AI response generation across ~3 wall-clock minutes), so a non-trivial number of type: "cli" records should have been emitted. Zero were observed in any of the 5 captured sessions, including the process-shutdown window and any final flush.

If active_time.total is intentionally unsupported in --print / -p mode, the documentation should state that limitation explicitly.

Error Messages/Logs

Sample emitted record from one of the sessions, showing other metrics export correctly with full attribute payload (de-identified):


{
  descriptor: {
    name: "claude_code.session.count",
    type: "COUNTER",
    description: "Count of CLI sessions started",
    unit: "",
    valueType: 1,
    advice: {},
  },
  dataPointType: 3,
  dataPoints: [
    {
      attributes: {
        "user.id": "<redacted-sha256-hash>",
        "session.id": "<redacted-uuid-v4>",
        "app.version": "2.1.119",
        "organization.id": "<redacted-org-uuid>",
        "user.email": "<redacted-email>",
        "user.account_uuid": "<redacted-account-uuid>",
        "user.account_id": "<redacted-account-id>",
        "terminal.type": "mingw64",
        "start_type": "fresh",
      },
      startTime: [ <redacted-epoch-seconds>, <ns> ],
      endTime: [ <redacted-epoch-seconds>, <ns> ],
      value: 1,
    }
  ],
}


No comparable record was observed for `claude_code.active_time.total` in any of the 5 sessions, including the final flush after `claude -p` returned.

Steps to Reproduce

In a fresh shell (Windows 11, Git Bash / mingw64):

1. Configure ~/.claude/settings.json env block with the console exporter only, to keep the repro self-contained and free of any dependency on a running OTLP collector:

``json
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "console",
"OTEL_LOGS_EXPORTER": "console",
"OTEL_METRICS_INCLUDE_SESSION_ID": "true",
"OTEL_METRICS_INCLUDE_VERSION": "true",
"OTEL_METRIC_EXPORT_INTERVAL": "1000"
}
}
``

1. From any code repository (the prompt below assumes a project with a top-level markdown file, a docs/ subdirectory, and recursively-nested config files — substitute equivalents for your repo), run a claude --print session designed to exercise multiple tool calls and AI response generation:

``bash
claude -p "Comprehensive analysis task. Step 1: Read the project README or any top-level markdown file and summarize the key rules or guidelines. Step 2: List the markdown files in any docs/ subdirectory and identify the most recently modified one. Step 3: Read that file and summarize it in two sentences. Step 4: Count how many configuration files (e.g., .yaml, .json, .tf, .toml) exist recursively under the project root. Step 5: Final reflection: identify which document you read is most foundational. Take your time and use multiple tool calls deliberately." > "/tmp/claude-otel-repro.log" 2>&1
``

1. Inspect the captured console-exporter output:

```bash
echo "=== unique metric names + counts ==="
grep -oE 'name: "claude_code\.[a-z_.]+"' "/tmp/claude-otel-repro.log" | sort | uniq -c | sort -rn

echo "=== active_time records ==="
grep -c "active_time" "/tmp/claude-otel-repro.log"

echo "=== type attribute distribution ==="
grep -oE 'type: "(user|cli)"' "/tmp/claude-otel-repro.log" | sort | uniq -c
```

(The type: regex is anchored to the values "user" and "cli", so it will not false-match terminal.type: "mingw64".)

Expected: non-trivial counts for claude_code.active_time.total and at least type: "cli" records.

Observed (representative run from N=5 on 2.1.119):

=== unique metric names + counts ===
     46 name: "claude_code.session.count"
     45 name: "claude_code.token.usage"
     45 name: "claude_code.cost.usage"

=== active_time records ===
0

=== type attribute distribution ===
(empty)

Repeating this 5 times produced the same shape every time: zero active_time.total records, hundreds of sibling records.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.119 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

claude_code.active_time.total is the documented signal for active Claude Code time, covering both user interaction time and CLI processing time. If type="cli" records are not emitted in non-interactive sessions, that signal can't be used to measure elapsed AI-assisted work in scripted or automation-heavy Claude Code workflows; consumers fall back to wall-clock duration, external timing wrappers, or model-estimated effort instead.

Even if the partial-emission concern from #16525 is interactive-mode-only, this non-interactive repro consistently produces zero active_time.total records while other metrics emit correctly across 5/5 sessions, which suggests a separate code path worth checking against the v2.0.70 fix.

Reviewer environment notes

• The repro uses claude --print because it is fully scriptable and produces repeatable captured output. Interactive TTY mode has not been validated here because Claude Code's terminal UI does not appear to be reliably captured by standard PowerShell mechanisms (Tee-Object, Start-Transcript). A reliable interactive-mode repro likely requires PTY/terminal-emulation capture or a real OpenTelemetry collector receiving the OTLP stream directly. Happy to provide an interactive-mode repro if Anthropic can recommend a preferred capture method.
• The 5 sessions were started concurrently as separate claude -p processes, each writing to its own logfile, with distinct session.id values. They share no in-process state; running them concurrently versus sequentially is not expected to affect this metric class, and the per-run shape is identical.
• The single-record sample above shows start_type: "fresh" and a complete attribute payload, demonstrating the SDK is functional and configured correctly — the absence is metric-specific, not pipeline-wide.
• Each captured log spans the full claude -p lifecycle including process shutdown, so a final-flush-only emission of active_time.total would have been visible if it occurred.
• All collected logs are local-only and have been de-identified before inclusion in this report.

Is this a regression?

Issue #13803 reported active_time working through 2.0.64 and broken from 2.0.65 onward; a fix shipped in 2.0.70. Whether that fix covered the non-interactive --print path is not clear from the resolution comment. The symptom is now reproducible across at least two consecutive minor versions (originally observed on 2.1.118, then 5/5 on 2.1.119), which suggests it is not a transient regression in a single point release. Without bisecting between 2.0.70 and 2.1.119, I can't say whether this is a regression, an incomplete prior fix, or an intentional-but-undocumented limitation of active_time.total in non-interactive mode.

Claude Model

Claude Opus 4.7 (1M context); model identifier claude-opus-4-7[1m]. Default effort level (xhigh).

Last Working Version

Unknown for non-interactive mode specifically.

Claude Code Version

2.1.119 (also reproduces on 2.1.118).

Terminal/Shell

Repro launched from Git Bash for Windows (mingw64).

## 2.1.138

- Internal fixes