[BUG] session-meta records 'Unknown skill' error as first_prompt, polluting /insights telemetry

Summary

When a slash command fails with Unknown skill: X (for example, invoking a plugin command before /reload-plugins, or hitting a regression like #42073), Claude Code writes a session-meta record where the first_prompt field is literally set to the error string. The session is otherwise empty (zero tokens, zero tool calls, zero duration), and both user_message_timestamps entries are identical to the millisecond, indicating the error was captured back as a user input on top of the actual input.

Evidence

Local reproduction on a 2026 Claude Code install. File ~/.claude/usage-data/session-meta/0315a816-3a6d-448b-835d-fcfbcd22001d.json:

{
  "session_id": "0315a816-3a6d-448b-835d-fcfbcd22001d",
  "user_message_count": 2,
  "assistant_message_count": 0,
  "tool_counts": {},
  "input_tokens": 0,
  "output_tokens": 0,
  "first_prompt": "Unknown skill: plugin",
  "user_message_timestamps": [
    "2026-04-02T22:23:21.606Z",
    "2026-04-02T22:23:21.606Z"
  ]
}

Verified count on this machine:

$ ls ~/.claude/usage-data/session-meta/*.json | xargs grep -l '"first_prompt": "Unknown skill' | wc -l
35

35 such polluted records exist locally. The duplicate millisecond timestamps are the signal that two writes happened in the same millisecond. One was the real user input, the second was the agent re-ingesting its own error echo.

Expected behavior

When a slash command fails with Unknown skill, the failure should be recorded as an error event (or the session-meta first_prompt should still reflect the user's actual intended input). Error strings from the agent should not be recorded as if the user typed them.

Actual behavior

first_prompt is overwritten with the error string. /insights and any third-party insights consumer (ccusage, ClaudeUsageTracker, phuryn/claude-usage) see "Unknown skill: plugin" as the user's first prompt. Real user intent is erased.

Impact

1. /insights aggregation is polluted. "Unknown skill" appears as a visible first prompt in session lists and rollups.
2. Obscures root cause. The underlying problem (failed slash command) is hidden behind a telemetry artifact that looks like the user typed gibberish.
3. Privacy adjacent. Errors from local plugin state leak into the persisted usage log with no scrubbing option.
4. Combines with related pain. When slash commands fail, the user's real message gets swallowed (related to #32591 pattern) while the error gets recorded. Double erasure.

Why existing issues do not cover this

Searched these angles, none match:

• session-meta first_prompt returns only #34857 (non-atomic write corruption) and #32227 (EBUSY on Windows). Different mechanism.
• usage-data session-meta same two issues plus unrelated insights display bugs.
• insights first_prompt error captured, stderr captured as first_prompt, session-meta error prompt captured, insights telemetry Unknown skill first_prompt, insights Unknown skill pollutes all return zero results.
• Reviewed #34857, #32227, #27426, #24039, #28341. All about write races, Windows EBUSY, facet generation. None capture the error as prompt behavior.

Related but distinct:

• #42073 (commands regression in 2.1.89) triggers the Unknown skill path.
• #44756 (skills silently fail in --print mode) another trigger.
• #32591 swallows user messages after slash command fail.
• None describe the telemetry side of the bug.

Request

1. Stop writing error strings into the first_prompt field of session-meta.
2. Preserve the user's real first prompt even when the session terminates on a slash command error.
3. If error telemetry is wanted, record it in a separate session_errors field rather than overwriting user input.
4. Document the session-meta schema so third-party insights consumers know what to expect.

Suggested labels: bug, area:cost, data-loss