Skip to content

[BUG] v1.0.45 --resume bug #3188

Closed as not planned
Closed as not planned

Description

@MiwiDots

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:
    claude --print "follow-up message" --resume <previous-session-id> --output-format stream-json --verbose
  3. 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.

Activity

  1. foertel commented on Jul 14, 2025

    @foertel

    Why did you close this? It is still broken.

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

  2. MiwiDots commented on Jul 15, 2025

    @MiwiDots
    Author

    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.

  3. foertel commented on Jul 15, 2025

    @foertel

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

  4. presmihaylov commented on Jul 19, 2025

    @presmihaylov

    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

  5. foertel commented on Jul 21, 2025

    @foertel

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

  6. iamgajendra commented on Jul 26, 2025

    @iamgajendra
  7. presmihaylov commented on Jul 28, 2025

    @presmihaylov

    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)

  8. foertel commented on Jul 28, 2025

    @foertel

    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?

  9. xunjianxiang commented on Sep 3, 2025

    @xunjianxiang

    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.

  10. github-actions commented on Dec 6, 2025

    @github-actions

    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.

  11. github-actions commented on Jan 5, 2026

    @github-actions

    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.

  12. github-actions commented on Jan 12, 2026

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

  13. locked as resolved and limited conversation to collaborators on Jan 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coreautocloseIssue will be closed automaticallybugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions