[BUG] Session ID has unexpected values for SessionStart:resume hooks
Status Fixed / completed
Maintainer reply ✓ Yes — dicksontsai
Activity 7 comments · opened Sep 19, 2025 · closed Oct 31, 2025
💡 Likely answer: A maintainer (dicksontsai, collaborator)
responded on this thread — see the highlighted reply below.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The Session ID and transcript path provided via JSON in Session Start when source = resume is wrong/random. Making it impossible to check the jsonl file at that time. This was NOT an issue a few days ago.
What Should Happen?
Sessionstart hooks should get the correct session id. All other hooks (including statusline hooks) get the correct session id.
Error Messages/Logs
Steps to Reproduce
Setup a hook that prints the session ID on session start. Then test different startups. Cold start, resume(or --continue), clear. The bug is obvious when you actually NEED the session id information.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
I dont know. The most recent previous version I would guess.
Claude Code Version
1.0.119
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
_No response_
7 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
The referenced reports are not the same problem. in 119 Sessionstart gets a COMPLETELY NEW AND UNIQUE SessionID that is NEVER USED ANYWHERE ELSE. No Jsonl file is created from it. This is not the previous sessions session id. This is effectively a randomly generated UUID that is never used in previous or new sessions EVER.
3 new releases since reporting this bug. Still not fixed? It can't be THAT hard to fix this. Come on guys.
Another day another release. AND THIS IS STILL NOT FIXED.
I track sessions in a database and I also track resume chains and I can confirm I just started noticing a problem recently, maybe with the 2.x series.
I did some testing and realized that this only happens to me when I resume from within another session using the slash command. It works as expected when I resume from the cli args with
claude --resume.I can't say for sure if it has always been a problem or not, I used to always resume with the flag and for some reason I recently started using the slash command on occasion. It is possible that it was always broken and my behavior has just changed. I can't say for sure either way.
I never use "continue" so I can't comment on that.
Should be fixed in the next version release. I'll close this issue after it comes out.
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.