Repository navigation
Description
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:
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 --verboseResponse 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-jsonReturns: "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-jsonReturns: "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.
Activity
foertel commentedon Jul 14, 2025
Why did you close this? It is still broken.
Also: why did you anonymize your uuids? They are not secret.
MiwiDots commentedon Jul 15, 2025
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.
foertel commentedon Jul 15, 2025
For me
--continueand--resumeboth are broken. :-/presmihaylov commentedon Jul 19, 2025
Yep, can confirm this is broken for me as well.
See this interaction:
It obviously doesn't have memory of the 2+2 question
foertel commentedon Jul 21, 2025
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. :-/
iamgajendra commentedon Jul 26, 2025
#2778 (comment)
presmihaylov commentedon Jul 28, 2025
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)
foertel commentedon Jul 28, 2025
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?
xunjianxiang commentedon Sep 3, 2025
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.
github-actions commentedon Dec 6, 2025
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.
github-actions commentedon Jan 5, 2026
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.
github-actions commentedon Jan 12, 2026
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.