[FEATURE] Pass CLAUDE_CODE_SESSION_ID to plugin MCP server subprocess env (stdio)

Analysis

The ask is straightforward: add CLAUDE_CODE_SESSION_ID=<current-session-id> to the environment variables passed to plugin stdio MCP servers at spawn time, alongside the already-existing CLAUDE_PLUGIN_ROOT, CLAUDE_PLUGIN_DATA, and CLAUDE_PROJECT_DIR.

Current state

| Env var | Bash tool | Plugin MCP stdio |
|---------|:---------:|:----------------:|
| CLAUDE_CODE_SESSION_ID | Yes (v2.1.132, #25642) | No |
| CLAUDE_PLUGIN_ROOT | N/A | Yes |
| CLAUDE_PLUGIN_DATA | N/A | Yes |
| CLAUDE_PROJECT_DIR | N/A | Yes |

The session ID is already tracked in the host process — it just isn't forwarded to the MCP server's environment block. This is a single-line addition in the env-var assembly code for plugin MCP server spawn.

Why it's needed

Plugin MCP servers that manage per-session state (routing, sidecars, channel servers) need a reliable session identifier. Current workarounds (hook files, PID keying) all race or break under concurrency and session-resume.

No user-side workaround

The env vars are set at spawn time in closed-source CLI code. There's no way for a user to inject CLAUDE_CODE_SESSION_ID into the MCP server environment today.

Bot-closure was premature — empirically still not fixed in v2.1.152

This issue was auto-closed by ant-github-proxy[bot] on 2026-05-27 as part of a 430-issue mass-closure sweep that day, with no maintainer comment and no linked code-PR (only docs PR #61754, which is still open and only documents the gap). Reopening with empirical evidence the env var is still missing in the latest public build (2.1.152).

Primary-source probe (2026-05-27)

Modified bd-cadence-channel (a plugin Bun stdio MCP server) to expose a debug endpoint dumping its process.env. Ran two probe stages against Claude Code v2.1.152 (latest available via claude install latest):

Stage 1 — env-inheritance check. Spawned a session via wt.exe → claude.exe with --session-id 2b2a0d9c-873d-480a-8c08-4c0811a476f1. The /env-debug response showed CLAUDE_CODE_SESSION_ID: 50feefa3-86ca-4c87-81c4-12eb45463bdd — but that value was the launching shell's own session uuid, not the spawned session's. The env var was inherited from the parent shell, not injected by claude.exe.

Stage 2 — clean-env probe. Re-spawned with CLAUDE_CODE_SESSION_ID stripped from the parent env before launch. Fresh sid 87e5d950-a018-4a2b-b231-454ee20e84f9. /env-debug returned:

{
  "CLAUDE_CODE_SESSION_ID": null,
  "BD_CADENCE_INSTANCE_ID": null,
  "CLAUDE_PLUGIN_ROOT":   "<path>",
  "CLAUDE_PLUGIN_DATA":   "<path>",
  "CLAUDE_PROJECT_DIR":   "<path>"
}

CLAUDE_PLUGIN_ROOT / CLAUDE_PLUGIN_DATA / CLAUDE_PROJECT_DIR are injected as expected. CLAUDE_CODE_SESSION_ID is not.

What the binary shows

String-grep of the 2.1.152 launcher at ~/.local/bin/claude.exe (PE32+ 235MB self-contained bundle) finds exactly four occurrences of CLAUDE_CODE_SESSION_ID:

1. Allowlist L01 used by Bash-command bare-assignment permission gating (unrelated to MCP spawn).
2. Allowlist Bq$ used by the same gate.
3. The Bash-tool env-builder naH(H){let q={CLAUDECODE:"1",CLAUDE_CODE_SESSION_ID:H.sessionId};...} — shipped in v2.1.132 per #25642.
4. Host-internal process.env.CLAUDE_CODE_SESSION_ID = y8() self-assignment.

The two plugin MCP spawn env-blocks visible in the binary are:

let D = {
  CLAUDE_PLUGIN_ROOT: q.path,
  CLAUDE_PLUGIN_DATA: G8H(q.source),
  ...w.env || {}
};

let z = {
  CLAUDE_PLUGIN_ROOT: q.path,
  CLAUDE_PLUGIN_DATA: G8H(q.source),
  CLAUDE_PROJECT_DIR: r4(),
  ...A.env || {}
};

Neither references CLAUDE_CODE_SESSION_ID. The one-line addition that would close this is shape-identical to what's already done for the Bash tool — read the session id from the same host-side handle, drop it into the env object.

What the bot-closure actually was

ant-github-proxy[bot] closed 430 issues on 2026-05-27, breakdown {completed: 16, duplicate: 12, not_planned: 2} per gh api search/issues?q=repo:anthropics/claude-code+is:closed+closed:2026-05-27. The cohort spans unrelated issues (ConnectionRefused bugs, /context UX, voice-transcription quality). It's a mass-triage sweep, not a per-issue decision. state_reason: completed here means "closed by automation," not "implemented."

Why this still matters

Plugin MCP servers that manage per-session state (channel servers, sidecar routers, per-session caches) need a reliable session identifier. Workarounds we've tried — all eventually broken under concurrency or session-resume:

• SessionStart hook writes a sidecar → race on concurrent spawns
• PID-keyed handshake → launcher/runtime fork makes hook-PID ≠ MCP-PID
• Sibling-by-PPID lookup → PPID changes between hook invocations of the same session (empirically verified)

The pattern we landed in bd-cadence is an env-bridge: GUI sets BD_CADENCE_INSTANCE_ID=<uuid> on the spawn process env alongside --session-id <uuid>. claude.exe inherits and propagates, bun reads at startup. This works because the spawning GUI controls the env block — but it doesn't help any plugin that needs to handle sessions launched outside its own spawner (e.g. a claude --resume <sid> started manually by the operator). The first-party env injection would.

Filing a docs PR alongside this comment that adds the env-bridge pattern as a worked example under examples/ for plugin authors hitting the same wall today.

Could a maintainer reopen and route this to whoever owns the env-assembly code path? Happy to test against any pre-release build that includes the fix.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.