Skip to content

Conversation

@SteffenDE
Copy link
Contributor

This is a proof of concept for two new methods: "session/resume" and "session/fork". The idea is to be able to continue an existing chat using Claude's resume and forkSession functionalities, without the need to stream all the existing conversation history (which prevents us from having session/load with the Claude Agent SDK).

For now, I implemented this as extension methods, but I could see it fit into the core protocol as optional agent capabilities. The methods accept the same parameters as session/new and also return the same response format. The only extra parameter that is required is the "claudeSessionId" for resume, but it could also be called "resumeSessionToken". Fork would assume that there's already a running ACP session, so for fork one needs to pass the ACP sessionId.

The extra ID / token is required because Claude internally has its own session ID that is independent from the ACP ID (it is only created when sending the first message). Currently, there's a special extension notification called "claude/sessionId", that send a mapping { sessionId, claudeSessionId }. Again, for a proper implementation, this could be called resumeSessionToken instead.

Let me know what you think!

This is a proof of concept for two new methods: "session/resume" and
"session/fork". The idea is to be able to continue an existing chat
using Claude's resume and forkSession functionalities, without the need
to stream all the existing conversation history (which prevents us from
having session/load with the Claude Agent SDK).

For now, I implemented this as extension methods, but I could see it
fit into the core protocol as optional agent capabilities. The methods
accept the same parameters as session/new and also return the same
response format. The only extra parameter that is required is the
"claudeSessionId", but it could also be called "resumeSessionToken".

It is required because Claude internally has its own session ID that is
independent from the ACP ID (it is only created when sending the first
message). Currently, there's a special extension notification called
"claude/sessionId", that send a mapping `{ sessionId, claudeSessionId }`.
Again, for a proper implementation, this could be called `resumeSessionToken`
instead.
@cla-bot cla-bot bot added the cla-signed label Nov 5, 2025
@benbrandt
Copy link
Member

@SteffenDE thanks for testing this out. It would actually be helpful if you could write up your new method designs as an RFD: https://agentclientprotocol.com/rfds/about

These features have been discussed a but between multiple groups, so it would be helpful to centralize the conversation there. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants