[BUG] Resuming a conversation by session ID broken in print mode
Environment
- Platform (select one):
- [X] 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
claude -p "describe this project in 2 sentences" --output-format json- Grab the session id that was output
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
Thanks for the report. We have fix and should have it out tomorrow.
@igorkofman the fix seems to create a new session each time instead of continuing with the previous session. Is this behavior intentional?
No, it should resume conversations correctly. Please let us know if it's not working (with exact repro and claude code version)
@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
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 ...
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
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.
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.
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.