[BUG] v1.0.45 --resume bug
Summary
Claude CLI v1.0.45 ignores the --resume flag and creates new sessions instead of resuming existing ones, causing loss of conversation history.
Environment
- Claude CLI Version: 1.0.45 (Claude Code)
- Platform: macOS
- Output Format: stream-json
Bug Description
When passing the --resume <session-id> flag to Claude CLI, it ignores the session ID and creates a new session instead of resuming the existing one. This results in:
- Loss of conversation context
- Inability to continue previous conversations
- New session IDs generated for every command
- Breaking session-based applications
Steps to Reproduce
- Start a Claude session and note the session ID returned
- Send a follow-up message attempting to resume that session:
``bash``
claude --print "follow-up message" --resume <previous-session-id> --output-format stream-json --verbose
- Observe the response - Claude returns a completely new session ID instead of resuming
Expected Behavior
When using --resume <session-id>, Claude should:
- Load the existing session context
- Continue the conversation with full history
- Return the same session ID in the response
- Maintain conversation continuity
Actual Behavior
Claude CLI:
- Ignores the provided session ID
- Creates a brand new session
- Returns a different session ID
- Loses all conversation context
Reproducible Test Cases
Test Case 1: Simple Resume Attempt
Command sent:
claude --print "Hello, please help me with a task" --resume 12345678-abcd-efgh-ijkl-123456789012 --output-format stream-json --verbose
Response received:
{
"type": "system",
"subtype": "init",
"session_id": "87654321-wxyz-uvwx-stuv-987654321098",
"model": "claude-opus-4-20250514"
}
Note: Requested resume of session 12345678-abcd-efgh-ijkl-123456789012 but got new session 87654321-wxyz-uvwx-stuv-987654321098
Test Case 2: Multiple Resume Attempts - Same Session
First attempt:
claude --print "First message" --resume aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee --output-format stream-json
Returns: "session_id": "11111111-2222-3333-4444-555555555555"
Second attempt (same resume ID):
claude --print "Second message" --resume aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee --output-format stream-json
Returns: "session_id": "66666666-7777-8888-9999-000000000000"
Both attempts create new sessions instead of resuming the requested one.
Test Case 3: Resume After Session Exists
- Initial session created normally (no resume flag)
- Session ID confirmed to exist in Claude's session storage
- Attempt to resume:
claude --print "Continue our previous discussion" --resume <existing-session-id> --output-format stream-json
- Result: New session created, previous context lost
Pattern Analysis
- The bug occurs 100% of the time
- Affects all session IDs (valid UUID format)
- Independent of message content
- Independent of tool configuration
- Occurs in both interactive and non-interactive modes
Impact
This bug makes it impossible to:
- Build stateful applications using Claude CLI
- Maintain conversation context across multiple API calls
- Implement multi-turn conversations programmatically
- Create chat interfaces that preserve history
- Resume interrupted sessions
Expected Response Format
When resume works correctly, the response should maintain the session:
{
"type": "system",
"subtype": "init",
"session_id": "12345678-abcd-efgh-ijkl-123456789012", // Same as --resume parameter
"model": "claude-opus-4-20250514"
}
Severity
High - This completely breaks session management functionality, making it impossible to build applications that require conversation continuity.
12 Comments
Why did you close this? It is still broken.
Also: why did you anonymize your uuids? They are not secret.
I was not sure if that really is a bug coz -resume vs -continue solved it for me. While i agree it looks still broken. If you want we can reopen it.
For me
--continueand--resumeboth are broken. :-/Yep, can confirm this is broken for me as well.
See this interaction:
It obviously doesn't have memory of the 2+2 question
You put your 2+2 question into a complete different session id. 🙈 It is not visible from your example why it should be in the 6d83e context.
Here it is stated, that it is supposed to work like this. New session id for every message in a multi-turn conversation. :-/
https://github.com/anthropics/claude-code/issues/2778#issuecomment-3117855658
Thank you folks, I think I understood the gotcha - the session ID resets everytime you invoke claude. I wouldn't say devexp is the best but definitely doable 🤷
This ticket can be closed now (but I don't have permission to do it)
Most bugs are somehow doable. But maaaaybe instead of everyone of us fixing around this, they could just fix it. :) So why not leave this open?
Hi everyone, any progress?
We already have a specified session ID, so why isn't it just using it instead of creating a new session?
At least we should give the user the choice.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
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.