[FEATURE] Expose tool_use_id (and optionally W3C Baggage) as environment variables in Bash tool shell processes

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code calls an MCP server tool, the server receives the tool_use_id via the _meta field in the request, providing a deterministic correlation key back to the specific tool invocation. Bash tool shell processes have no equivalent. The subprocess has no way to know which tool_use_id spawned it.

This matters for observability. We are build tooling to propagate context to processes spawned in the shell environment. Without the tool_use_id available in the shell environment, the only options are fragile post-hoc heuristics such as: command string matching, PID-based correlation, filesystem signaling. All of which are inherently racy and lossy.

Proposed Solution

Set CLAUDE_TOOL_USE_ID as an environment variable in the shell process that Claude Code spawns for each Bash tool invocation.

Alternative Solutions

W3C Baggage env var: Claude Code could set also set BAGGAGE environment variable per the W3C Baggage specification, carrying the tool_use_id as baggage members:

BAGGAGE=tool_use_id=toolu_01D8GH7gMk...,session_id=abc-123

or alternatively set TRACEPARENT as an env variable, although Claude Code would need to provide a mechanism to inject this per session or turn in the first place.

This would align with the convention of using W3C propagation headers as environment variables for non-HTTP contexts. A dedicated CLAUDE_TOOL_USE_ID env var is simpler and easily discoverable. However, canonical variables like TRACEPARENT and BAGGAGE would be nice long term solutions and align well with other feature request like: https://github.com/anthropics/claude-code/issues/31039.

Workarounds exist but are complex. Options include writing context to temp files, having downstream CLIs instantiate their own trace context and reconciling after the fact using command string matching or process liveness checks.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Imagine a CLI that talks to a backend API. Claude Code runs mycli deploy --service orders via the Bash tool. The CLI makes HTTP requests to a provisioning API, which in turn calls downstream services. We want an unbroken trace from the Claude Code tool execution → CLI → HTTP request → backend.

1. Claude Code runs mycli deploy --service orders via the Bash tool (tool_use_id: toolu_01ABC...)
2. The shell process spawns with CLAUDE_TOOL_USE_ID=toolu_01ABC... in its environment
3. mycli reads $CLAUDE_TOOL_USE_ID, creates a root span referencing it, and propagates that trace context via traceparent headers on its outgoing HTTP requests to the provisioning API
4. The provisioning API continues the trace as usual — the full chain from Claude Code tool call → CLI → API → downstream services is connected
5. When something fails three services deep, an engineer can trace it all the way back to the specific Claude Code tool call that started the chain

Without the env var, the trace breaks at the boundary between Claude Code and the CLI. The CLI has no parent context to propagate, so its HTTP requests start a new disconnected trace.

I recognize that this is a custom way of propagating context. However, in lieu of first class support for OTEL context propagation in Claude Code, the existence of the tool_use_id in the environment is a low cost way to unblock our goal here.

Additional Context

Relation to #31039: That issue requests TRACEPARENT support — reading an existing W3C trace context so Claude Code's own telemetry joins a parent trace. That is inbound context (environment → Claude Code). This request is outbound context (Claude Code → subprocesses). Both are valuable and complementary: TRACEPARENT gives Claude Code a parent span to attach to; CLAUDE_TOOL_USE_ID gives downstream CLIs a key to attach back to a specific tool call.

MCP precedent: Claude Code already sets _meta.tool_use_id on every MCP tool call. Extending this to Bash processes via an env var is a small, consistent change that closes the gap between the two execution contexts.