add separate resumeToken for session/resume #279
Conversation
| > Tell me more about your implementation. What is your detailed implementation plan? | ||
| We propose to add a new "session/resume" method. Agents must declare this option is | ||
| available by including `sessionCapabilities: { resume : {} }` in its capabilities. |
There was a problem hiding this comment.
I already used the new sessionCapabilities proposed by session/list. Happy to change that to a top level key.
| token received to continue the chat from where they left off. | ||
|
|
||
| Agents may only support resuming chats in some cases. Therefore, an agent may not send a `resumeToken`, | ||
| even if it declares the capability. |
There was a problem hiding this comment.
The nice thing about using a token is that it would allow for us to have multiple resume points in the conversation i.e. for forking
But I guess this is somewhat different in that resume kind of always assumes resuming from whatever point the agent decides correct? Like the last message?
So, I guess in general i like the idea.. but I also feel like we are applying a band-aid at the protocol level for lack of support from the Claude Code SDK...
Because I guess what isn't clear to me is you would get this session/update shortly after starting the conversation and then it is somewhat unclear where you are actually resuming from...
And should this resume token be somehow returned by the session/list endpoint, if supported?
There was a problem hiding this comment.
But I guess this is somewhat different in that resume kind of always assumes resuming from whatever point the agent decides correct? Like the last message?
Yes. I'd also say the main difference between resume and fork (with message id) is that fork assumes an already running session, while resume does not.
but I also feel like we are applying a band-aid at the protocol level for lack of support from the Claude Code SDK...
It would be nice if we don't need it, yes. The token approach feels very flexible though and as long as we document that resuming should always resume from the most recent interaction, I think we're good. "Resuming" from a different point in time is something I'd only consider for fork.
The "getting it shortly after starting the conversation" is somewhat similar to agent modes though, since those also don't change most of the time.
And should this resume token be somehow returned by the session/list endpoint, if supported?
I'd say so, yes!
There was a problem hiding this comment.
So the resume token is just an indication that this session is now resumable?
vs just being able to call resume on a session?
There was a problem hiding this comment.
Like i guess, if it is always from the most recent interaction, why wouldn't I just ask to resume a given session?
2 participants
To make implementing resume easy for Claude Code, I'm proposing session/resume to use a separate
resumeToken.Because of the way the Claude SDK works,
claude-code-acponly gets the internal Claude Session ID after sending the first prompt. Therefore the ACPsessionIdis completely separate from Claude's session id. Without this,claude-code-acpwould need to keep a separate session mapping somewhere on disk to implement resuming.