No way to access session ID from within a running session

[overseers-desk]

Problem

There is no way for a running Claude Code session to know its own session ID. This makes it impossible for automation (hooks, commit trailers, logging) to reference the current session without asking the user to manually copy-paste the ID.

The session ID is only revealed after the session ends, in the "Resume this session with: claude --resume <uuid>" line. By then it's too late for anything inside the session to use it.

Use case

Our CLAUDE.md instructs Claude to include a Session-Id: git trailer in commits. Currently, Claude has to ask the user for the session ID on every first commit — a poor experience. We want a wrapper or alias that makes the session ID available automatically.

What we tried

1. --session-id <uuid> flag (pre-set the ID)

Result: does not control the local session ID in interactive mode.

• In -p (print/non-interactive) mode, --session-id correctly controls the persistence ID — the .jsonl file is named with the injected UUID, and session_id in JSON output matches.
• In interactive mode, --session-id sets a separate API/telemetry ID, but the CLI generates its own internal UUID for local persistence. The --resume line shows a different ID than the one injected.

$ CLAUDE_SESSION_ID=$(uuidgen) claude --session-id "$CLAUDE_SESSION_ID"
# Inside session, $CLAUDE_SESSION_ID = 669f77f5-...
# But "Resume this session with" shows: 9ecddef3-...
# Persistence file: 9ecddef3-....jsonl (not 669f77f5)

This means --session-id is usable as a synthetic tag for commit trailers, but it is not the actual session ID. This is confusing — the flag name implies it sets the session identity.

2. -p mode bootstrap + --resume (two-phase approach)

Result: works for the prompt case, but requires a throwaway first message for the no-prompt case.

Since -p mode respects --session-id for persistence, we can:

1. claude -p "$prompt" --session-id "$UUID" --output-format json → captures answer, persists session
2. claude --resume "$UUID" → continues interactively

This works but adds complexity and doesn't handle the common case of starting a fresh interactive session without a prompt.

3. Capture resume line via expect (PTY automation)

Result: the resume line is never written to the PTY.

We tried spawning claude in expect's PTY, sending /exit, and capturing the "Resume this session with" output. Multiple approaches were tested:

• expect alone: /exit is received (autocomplete menu shows "Exit the REPL"), session exits cleanly (exit code 0, .jsonl file created), but no resume line appears in the PTY output.
• script -c wrapping expect: same result — Script done. appears but no resume line.
• screen with stuff command injection: same result.
• strace -f -e write: confirmed zero write() syscalls containing "Resume" — the code never even attempts to print the line.

Root cause (from binary analysis)

The resume-line printing function (HF8 in the minified source) has this guard:

if (process.stdout.isTTY && CT() && !lk())

The process.stdout.isTTY check, or one of the other conditions (CT(), !lk()), evaluates to false under expect/script/screen PTYs. This is surprising because these are real PTYs — isatty(1) returns true on the slave fd. The conditions may involve terminal feature detection (DA1/XTVERSION query responses), TERM_PROGRAM, or other environment checks.

4. Filesystem approach (newest .jsonl file)

Result: works reliably.

After claude exits, the newest .jsonl file in ~/.claude/projects/<project-dir>/ is the session that was just created. Its filename (minus .jsonl) is the real session ID, and it is resumable:

BEFORE=$(ls -t ~/.claude/projects/$PROJECT/*.jsonl | head -1)
# ... start and exit claude via expect ...
AFTER=$(ls -t ~/.claude/projects/$PROJECT/*.jsonl | head -1)
SID=$(basename "$AFTER" .jsonl)
claude --resume "$SID"  # works

This is our current workaround but it's fragile (race conditions with concurrent sessions, requires deriving the project directory path encoding).

Feature request

Any of the following would solve this cleanly:

1. Environment variable: Set CLAUDE_SESSION_ID (or similar) in the session's environment so tools, hooks, and the AI itself can read it. This was requested in [Feature Request] Expose Session Metadata via Environment Variables and API #17188.

2. Make --session-id actually control the local session ID in interactive mode (not just -p mode). Currently the flag's behavior is inconsistent between modes.

3. Print the resume line in PTY environments: The current guard that suppresses it under expect/script/screen PTYs prevents legitimate automation. If isatty(1) is true, the resume line should be printed.

4. A command or API to query the session ID: e.g., claude session-id that prints the current session's ID, or a /session-id slash command.

Environment

• Claude Code v2.1.92
• Linux x86_64
• Binary: ELF (compiled/SEA)

[overseers-desk]

Update: hooks already provide the session ID

After filing, we discovered that the hooks system already passes session_id in the JSON input to every hook event. This means a SessionStart hook can capture it:

{
  "hooks": {
    "SessionStart": [{
      "type": "command",
      "command": "echo CLAUDE_SESSION_ID=$(cat | jq -r .session_id) >> \"$CLAUDE_ENV_FILE\""
    }]
  }
}

This would make $CLAUDE_SESSION_ID available for the rest of the session — no wrapper script or expect automation needed.

However, this is a workaround that requires every user to configure a hook. The feature request still stands: the session ID should be natively accessible (via env var or command) without requiring hook setup. The inconsistent --session-id behavior between -p and interactive mode is also still a bug worth fixing.

[github-actions]

Found 3 possible duplicate issues:

1. Feature: Expose session ID as $CLAUDE_SESSION_ID environment variable #25642
2. [FEATURE] Printout Session ID While Session Still Active #39739
3. Feature request: Expose session_id to the conversation context #38390

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[github-actions]

This issue has been automatically closed as a duplicate of #25642.

If this is incorrect, please re-open this issue or create a new one.

🤖 Generated with Claude Code

[github-actions]

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.