[BUG] Resuming sessions doesn't work in non-interactive mode (Claude Code SDK)
Status Fixed / completed
Maintainer reply ✓ Yes — blois
Activity 7 comments · opened Jul 19, 2025 · closed Aug 4, 2025
💡 Likely answer: A maintainer (blois, collaborator)
responded on this thread — see the highlighted reply below.
I'm running in MacOS and run the following commands:
$ 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 0f096bd6-56cd-4fc4-aaa2-331954a6d83e "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.
Notice how claude is not aware of my previous conversations in this session. It seems that --resume doesn't work at all in non-interactive mode.
This prevents a lot of potential SDK integrations from being built.
7 Comments
@presmihaylov
This prevents a lot of potential SDK integrations from being built.
This is what I see:
I think this is the expected behavior, what do you think?
Hey @hesreallyhim apologies, I actually messed up my example because the second UUID is different, but the issue is still legit - here is me reproducing it:
<img width="998" height="251" alt="Image" src="https://github.com/user-attachments/assets/ccfb4ae8-3a63-4afe-845a-7ac3d4b6d79d" />
Snippet version:
And here is the example working when I'm not using session IDs, instead just continuing last conversation:
<img width="586" height="320" alt="Image" src="https://github.com/user-attachments/assets/965a5308-130e-4c46-b379-28ad6fbd2f96" />
Snippet:
it's just the weird way that sessions work in p-mode... you should examine
~/.claude/projects/if you're curious... and also get the output in json to see more (--output-format json)... every message is assigned a new session ID, but if it's a "continuation"/resume, the entire conversation from the previous log file where the whole chat is stored will be copied into the new file. That's why it suggests on the doc site to store the session ID somewhere, e.g. see here. Sessions are kind of "virtual" in p-mode, they should probably be clearer about this.I'm afraid this still doesn't work :/
<img width="762" height="320" alt="Image" src="https://github.com/user-attachments/assets/10b2cb43-4da2-466f-888b-77b71ee2455d" />
OK. so. The "What did I just ask?" thing is annoying cuz it doesn't interpret it the way you mean (like what did I ask before the current exchange lol). But look at the code and see what you're doing... You capture the session ID from line 1 and then resume it. OK nice. Then in the third line, you use the session ID in session.txt... but you didn't update it. The session ID output of the line 2 response is _different_. You're "resuming" from line 1 again. You would need to capture the new session ID each time and resume with THAT. They should really really probably give a more complete example, but you might write a helper function that receives the json payload, (a) captures the session ID (which like I said changes every turn); (b) prints the response. But please take a moment and use "-p --output-format json" and then keep doing that with"--continue" and you'll see that each response has a different session ID but it's the "same convo".
So that make sense?
That's not an elegant solution and I haven't tried it, but you can give that a go if you want. Anyway, you can figure this all out if you study the conversation flow with "--continue" and the full json output.
There was a recent issue where the user input was mistakenly being lost from resumed sessions. This should be fixed now.
Example:
Followed by:
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.