Add attribution of CLI harness/source when spawning the Elastic CLI

[vigneshshanmugam]

Summary

Currently, our telemetry and reporting mechanisms only capture user-agent (UA) and custom HTTP header (x-elastic-client-meta) information, which attributes all invocations to elastic-cli regardless of which agent or external harness (e.g., Claude, Cursor, Ramen, Opencode) spawned the CLI process. This results in a loss of visibility and proper attribution in BI and telemetry reporting.

Problem

When the CLI is invoked by external tools, the headers are overwritten by the CLI, making all requests appear as if invoked directly by elastic-cli.

Proposed Solution

• Investigate if CLI invocations can detect and attribute their harness/source (such as Cursor, Claude, Ramen, Opencode, etc).
• Potential approach: Examine specific environment variables (e.g., CURSOR_AGENT, CLAUDECODE) or use CLI flags to infer and annotate the source of the invocation.
• Ensure this information is captured in the telemetry data sent by the CLI (including UA and/or x-elastic-client-meta).
• Consider how similar attribution can be handled on the Kibana API side if applicable.

Acceptance Criteria

• CLI can detect and distinguish which harness/agent spawned it, when possible.
• Attribution information is sent via telemetry (UA, custom headers, etc).
• Documentation describes how attributions are determined and examples for known agents/harnesses.

Context

Attribution is crucial for unified skills, telemetry, and BI reporting. See internal discussion for more details.

View original Slack conversation

[JoshMock]

I'd be in favor of checking env vars; convincing an agent to explicitly set a CLI flag reporting its harness feels more brittle and vulnerable to hallucination.