[BUG] Resuming a conversation by session ID broken in print mode

[swerner]

Environment

• Platform (select one):
  • Anthropic API
  • AWS Bedrock
  • Google Vertex AI
  • Other:
• Claude CLI version: 1.0.19 (Claude Code)
• Operating System: macOS 145.5
• Terminal: Ghostty

Bug Description

When attempting to resume a session by session ID in print mode like:
claude -p -r {session_id} "{prompt}"

I get an error of:
"No conversation found with session ID: {session_id}"

When running the command not in print mode like this it resumes the session correctly:
claude -r {session_id}

I would expect session ID to be usable regardless of the -p flag usage or not.

Steps to Reproduce

1. claude -p "describe this project in 2 sentences" --output-format json
2. Grab the session id that was output
3. claude -p -r {session_id} "expand on that a bit" --output-format json

Expected Behavior

The previous session to continue further and output another blob of json

Actual Behavior

output of: No conversation found with session ID: {session_id}

Additional Context

It resumes the session just fine if I leave the -p flag off

[igorkofman]

Thanks for the report. We have fix and should have it out tomorrow.

[viper151]

@igorkofman the fix seems to create a new session each time instead of continuing with the previous session. Is this behavior intentional?

[igorkofman]

No, it should resume conversations correctly. Please let us know if it's not working (with exact repro and claude code version)

[viper151]

@igorkofman it does resume the conversation but creates a new session jsonl as well (a copy of the first one). Shall I open a new issue for that?

So here is what I'm doing on 1.0.31 (Claude Code)

Starting a session
claude -p hi --output-format json
{"type":"result","subtype":"success","is_error":false,"duration_ms":2662,"duration_api_ms":2585,"num_turns":1,"result":"Hi! How can I help you today?","session_id":"8075bc20-afcs-439f-b281-1376e5785784","total_cost_usd":0.015174149999999999,"usage":{"input_tokens":3,"cache_creation_input_tokens":3191,"cache_read_input_tokens":10013,"output_tokens":13,"server_tool_use":{"web_search_requests":0}}}
Resumming the session gives a different session ID.

claude -p -r 8075bc20-afcs-439f-b281-1376e5785784 hi2 --output-format json

{"type":"result","subtype":"success","is_error":false,"duration_ms":1956,"duration_api_ms":2729,"num_turns":3,"result":"Hello! What would you like to work on?","session_id":"e3ea25de-dva3-lk9x-a2gj-65e5274542d1","total_cost_usd":0.00438195,"usage":{"input_tokens":3,"cache_creation_input_tokens":17,"cache_read_input_tokens":13204,"output_tokens":16,"server_tool_use":{"web_search_requests":0}}}

The session jsonl of the second session ID contains the contents of both the first session ID and the new content. The first session ID jsonl contains only the contents of the first output

[foertel]

Why is this closed? It is still broken in 1.0.51.

@viper151 the new jsonl is not a real copy, right? for me all the messages uuids are changed. so it is a completely new jsonl with the same content. but no way to track what is what ...

[viper151]

Why is this closed? It is still broken in 1.0.51.

@viper151 the new jsonl is not a real copy, right? for me all the messages uuids are changed. so it is a completely new jsonl with the same content. but no way to track what is what ...

Correct it is the exact same content only with different session ID

[foertel]

Correct it is the exact same content only with different session ID

And different message / parent ids. :-/ That makes it really hard to find the same message over the multiple jsonl files.

[viper151]

From my tests I found a shared ID.
You can take the last assistant message uuid of the initial and compare it to the leafuid on the second one which is in the summary of the second one
That would give you an indication that this is a continuation of the first one.