Preflight Checklist
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:
- 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.
- 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
- Three tmux panes, each running
claude in the same project directory (backend, frontend, scratch conversation).
- Kill tmux server (system reboot, accidental kill).
- Restore tmux with tmux-resurrect.
- Without externally-discoverable session IDs, all three panes resume the most recently modified session in that cwd. The other two conversations are lost.
- 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:
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.
Preflight Checklist
Problem Statement
CLAUDE_CODE_SESSION_IDis 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
claudeprocess from outside. The session ID is not in argv, not in the main process env (ps eww -p <pid>on a runningclaudeshows onlyCLAUDE_CODE_NO_FLICKERandCLAUDE_CODE_SSE_PORT), not inlsof(the session.jsonlis opened, written, and closed per event), and not reverse-resolvable from the.jsonlrecords (nopidorttyfield).This blocks tmux-resurrect-style session-restore tooling from mapping a specific process to its specific session when multiple panes run
claudein the same cwd. All such tooling currently falls back to "newest.jsonlin cwd by mtime", which collapses parallel sessions into one on restore.Proposed Solution
Either is enough:
CLAUDE_CODE_SESSION_ID=<uuid>in the mainclaudeprocess environment at startup, alongside the existingCLAUDE_CODE_NO_FLICKERandCLAUDE_CODE_SSE_PORT. Externally readable viaps eww -p <pid>(macOS) or/proc/<pid>/environ(Linux). Reuses the variable name already established in subprocess env.~/.claude/runtime/<pid>.jsonwith{"sessionId": "<uuid>", "cwd": "...", "startedAt": "<iso8601>"}at startup, remove on exit. Discoverable by tools that can't inspect process env.Alternative Solutions
lsof -p <pid>:claudedoesn't keep the.jsonlopen between writes. No persistent file handle to detect..jsonlrecords: nopidorttyfield to backward-resolve a process to a session.CLAUDE_CODE_SESSION_IDin 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.SessionStarthook 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
claudein the same project directory (backend, frontend, scratch conversation).CLAUDE_CODE_SESSION_ID(or the runtime file) per pane at save time, persists it, and emitsclaude --resume <uuid>per pane at restore time. Each pane resumes its own session.Additional Context
Related:
CLAUDE_SESSION_IDto hooks and tool subprocesses. Same underlying need, different scope (in-session vs external).CLAUDE_CODE_SESSION_IDalready exists in Bash tool subprocess env as of v2.1.132. Same variable name should be reused for the main process env.The session UUID is already computed internally and used to name the
.jsonlon 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.