Proof of concept: session/resume and session/fork - #145
Closed
SteffenDE wants to merge 1 commit into
Closed
Conversation
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.
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! |
KUKUShuang
pushed a commit
to KUKUShuang/claude-code-acp
that referenced
this pull request
Feb 11, 2026
agentclientprotocol#145) Bumps the cargo group with 1 update in the / directory: [bytes](https://github.com/tokio-rs/bytes). Updates `bytes` from 1.11.0 to 1.11.1 - [Release notes](https://github.com/tokio-rs/bytes/releases) - [Changelog](https://github.com/tokio-rs/bytes/blob/master/CHANGELOG.md) - [Commits](tokio-rs/bytes@v1.11.0...v1.11.1) --- updated-dependencies: - dependency-name: bytes dependency-version: 1.11.1 dependency-type: indirect dependency-group: cargo ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 calledresumeSessionTokeninstead.Let me know what you think!