claude-code - 💡(How to fix) Fix [FEATURE] expose session ID to external tools inspecting a running claude process

Preflight Checklist

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

Problem Statement

CLAUDE_CODE_SESSION_ID is already set in Bash tool subprocesses and hooks as of v2.1.132 (see #56879). That covers code running under a claude session.

It does not cover external tools that need to inspect a running claude process from outside. The session ID is not in argv, not in the main process env (ps eww -p <pid> on a running claude shows only CLAUDE_CODE_NO_FLICKER and CLAUDE_CODE_SSE_PORT), not in lsof (the session .jsonl is opened, written, and closed per event), and not reverse-resolvable from the .jsonl records (no pid or tty field).

This blocks tmux-resurrect-style session-restore tooling from mapping a specific process to its specific session when multiple panes run claude in the same cwd. All such tooling currently falls back to "newest .jsonl in cwd by mtime", which collapses parallel sessions into one on restore.

Proposed Solution

Either is enough:

1. Set CLAUDE_CODE_SESSION_ID=<uuid> in the main claude process environment at startup, alongside the existing CLAUDE_CODE_NO_FLICKER and CLAUDE_CODE_SSE_PORT. Externally readable via ps eww -p <pid> (macOS) or /proc/<pid>/environ (Linux). Reuses the variable name already established in subprocess env.
2. Write ~/.claude/runtime/<pid>.json with {"sessionId": "<uuid>", "cwd": "...", "startedAt": "<iso8601>"} at startup, remove on exit. Discoverable by tools that can't inspect process env.

Alternative Solutions

• lsof -p <pid>: claude doesn't keep the .jsonl open between writes. No persistent file handle to detect.
• Parse .jsonl records: no pid or tty field to backward-resolve a process to a session.
• Existing subprocess env (CLAUDE_CODE_SESSION_ID in Bash tool subprocesses): only accessible from inside the running session, not externally.
• --session-id <uuid> at launch: only useful if the external tool controls the launch. tmux-resurrect observes existing processes and can't change how they were started.
• SessionStart hook writing a sidecar file: user-side workaround, requires per-user hook installation. Acceptable as a stopgap, not a long-term solution.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

1. Three tmux panes, each running claude in the same project directory (backend, frontend, scratch conversation).
2. Kill tmux server (system reboot, accidental kill).
3. Restore tmux with tmux-resurrect.
4. Without externally-discoverable session IDs, all three panes resume the most recently modified session in that cwd. The other two conversations are lost.
5. With either proposed mechanism, tmux-resurrect reads CLAUDE_CODE_SESSION_ID (or the runtime file) per pane at save time, persists it, and emits claude --resume <uuid> per pane at restore time. Each pane resumes its own session.

Additional Context

Related:

• #59216 (open): exposes CLAUDE_SESSION_ID to hooks and tool subprocesses. Same underlying need, different scope (in-session vs external).
• #56879 (closed): documents that CLAUDE_CODE_SESSION_ID already exists in Bash tool subprocess env as of v2.1.132. Same variable name should be reused for the main process env.
• tmux-plugins/tmux-resurrect#571 and tmux-plugins/tmux-resurrect#558: community PRs that hit this wall.

The session UUID is already computed internally and used to name the .jsonl on disk. Surfacing it as a main-process env var or runtime file requires no new concept, only exposure of an existing value through an additional channel.