[BUG] v1.0.45 --resume bug

Status Closed — not planned
Maintainer reply None cached
Activity 12 comments · opened Jul 9, 2025 · closed Jan 5, 2026

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

  1. Start a Claude session and note the session ID returned
  2. 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
``

  1. 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

  1. Initial session created normally (no resume flag)
  2. Session ID confirmed to exist in Claude's session storage
  3. Attempt to resume:
claude --print "Continue our previous discussion" --resume <existing-session-id> --output-format stream-json
  1. 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.

View original on GitHub ↗

12 Comments

foertel · 1 year ago

Why did you close this? It is still broken.

Also: why did you anonymize your uuids? They are not secret.

MiwiDots · 1 year ago

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 · 1 year ago

For me --continue and --resume both are broken. :-/

presmihaylov · 1 year ago

Yep, can confirm this is broken for me as well.

See this interaction:

$ claude -p --session-id 0f096bd6-56cd-4fc4-aaa2-331954a6d83e "hello"
Hello! I'm Claude Code, ready to help you with software engineering tasks. What would you like me to work on?

$ claude -p --resume b41abc4e-8995-4a03-af44-6bf03182bbad "what is 2+2"
4

$ claude -p --resume 0f096bd6-56cd-4fc4-aaa2-331954a6d83e "what did i jsut ask"
You asked "hello" - which was a greeting.

It obviously doesn't have memory of the 2+2 question

foertel · 1 year ago

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. :-/

presmihaylov · 1 year ago

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 · 1 year ago

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 · 12 months ago

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[bot] · 8 months ago

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[bot] · 7 months ago

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[bot] · 7 months ago

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.