Bundled CLI silently drops inbound TRACEPARENT on 2nd+ invocation when ~/.claude/ has state from a prior run

Filing here in addition to anthropics/claude-agent-sdk-python#952 because the root cause appears to be CLI-side, not SDK-side. The SDK is correctly injecting TRACEPARENT into the subprocess env every time; the bundled CLI honors it on the first invocation per process lifetime and silently ignores it on every subsequent one.

TL;DR

For a long-running embedding process that invokes the bundled CLI multiple times (claude-agent-sdk-python in a server / worker, or claude -p in a loop), only the first invocation correctly nests claude_code.* spans under the caller's W3C trace context. From the second invocation onward:

• claude_code.interaction is not emitted at all
• claude_code.llm_request and claude_code.tool each emit with their own fresh trace_id, no parent
• The inbound TRACEPARENT (and explicit one in ClaudeAgentOptions.env) is silently dropped

Even the CLI's internal parent-child propagation (interaction → llm_request/tool) appears broken on subsequent invocations — children become roots of separate traces.

Trigger

~/.claude/ populated by a prior invocation (specifically ~/.claude.json with firstStartTime + migration flags). Wipe the dir between calls → next call nests correctly. Leave it → next call fragments. 100% reproducible.

Repro + Full Detail

See anthropics/claude-agent-sdk-python#952 for the Python reproducer, observed Langfuse trace shape, what's been verified on the SDK side (Python OTel context byte-identical between calls), and the HOME=/tmp/<uuid> workaround.

Asks

If the CLI is supposed to re-read TRACEPARENT and re-establish OTel context for every subprocess invocation regardless of ~/.claude/ state, the regression is in the "have I started before?" code path — likely the OTel SDK init or interaction-span construction. Happy to provide more diagnostics from the subprocess side if useful (couldn't capture stderr telemetry-related lines from the bundled CLI — the SDK's stderr callback never fired for any otel/trace/exporter/error keyword on either invocation).