RFD: Resume existing sessions #234
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,100 @@ | ||
| --- | ||
| title: "Resuming of existing sessions" | ||
| --- | ||
|
|
||
| Author(s): [@josevalim](https://github.com/josevalim) | ||
|
|
||
| ## Elevator pitch | ||
|
|
||
| > What are you proposing to change? | ||
| We propose adding the ability to resume existing sessions. This is similar to session/load, | ||
| except it does not return previous messages. | ||
|
|
||
| ## Status quo | ||
|
|
||
| > How do things work today and what problems does this cause? Why would we change things? | ||
| While the spec provides a "session/load" command, most coding agents do not implement it. | ||
| This means that, once you close your editor, browser, etc, you can't resume the conversation. | ||
|
|
||
| An obvious answer to this question would be to implement "session/load" for existing coding | ||
| agents. For example, `claude-code-acp` could intercept all messages, write them to disk, | ||
| and emulate "session/load". We considered contributing this when we realized that, we already | ||
| store all messages in our own application, independent from ACP, given we want to provide | ||
| users to navigate or share old chats even if the coding agent is removed. And if we were to use | ||
|
Member
There was a problem hiding this comment. This is an interesting point. I know there is some work by other teams as well of putting a layer between the agent and the client (a proxy or something similar) that could store these events across agents. You'd still need to deal with persistence, but this could potentially be abstracted across agents and also allow for replay across multiple clients (i.e. I want to kick a session off on my computer and then load/interact with it on my phone). I think the use case you have is definitely valid, I just wonder who is best suited to own the state. I'm biased towards the agent (or something sitting in front of the agent) but I am open to changing my mind on this. (cc @nikomatsakis if you have thoughts) |
||
| "session/load", we would likely just discard them anyway. | ||
|
|
||
| In those cases, the ability to resume a session is beneficial because: | ||
|
|
||
| * it is exactly what we need | ||
| * it is more straight-forward to implement for both clients and servers | ||
|
Member
There was a problem hiding this comment. It is more straightforward, assuming the client doesn't have the responsibility to also implement storing all conversations. One reason this causes some issues is if you have a session on the client that got deleted on the agent, are you actually able to resume it? Would we instead have some way to "seed" a conversation from the client, passing the ACP messages through and the agent picks it up from there? I think if we move more data ownership to the client, we may need to think about allowing for that sort of data flow. But if the client accepts resuming without a previous history (maybe only showing the title and/or summary available from a list method) it is certainly easy to implement. |
||
|
|
||
| ## What we propose to do about it | ||
|
|
||
| > What are you proposing to improve the situation? | ||
| Two possible options: | ||
|
|
||
| * Add a "session/resume" command | ||
| * Add an option to "session/load" which allows us to continue even if | ||
|
Member
There was a problem hiding this comment. This second option would basically change the language from "The Agent MUST replay the entire conversation to the Client" to "The Agent SHOULD replay the entire conversation to the Client" Which obviously from the implementation side isn't that different in that a list of 0 events is processed the same as a list of X events. But obviously the UX concerns are quite different. |
||
| it doesn't return the previous conversation | ||
|
|
||
| In the rest of the document, I will refer to the solution as "session/resume", | ||
| but it implies any of the solutions above. | ||
|
|
||
| ## Shiny future | ||
|
|
||
| > How will things will play out once this feature exists? | ||
| We will be able to resume existing conversations, providing a better user experience. | ||
|
|
||
| ## Implementation details and plan | ||
|
|
||
| > Tell me more about your implementation. What is your detailed implementation plan? | ||
| <!-- | ||
| Use this section to add details that were not covered in the "What we propose to do about it" section and also include an implementation plan with phases. | ||
|
|
||
| Note: This section is OPTIONAL and NOT RECOMMENDED when RFDs are first opened. It can distract from the discussion of the problem. | ||
| --> | ||
|
|
||
| ## Frequently asked questions | ||
|
|
||
| > What questions have arisen over the course of authoring this document or during subsequent discussions? | ||
|
|
||
| <!-- | ||
| Keep this section up-to-date as discussion proceeds. The goal is to capture major points that came up on a PR or in a discussion forum -- and if they reoccur, to point people to the FAQ so that we can start the dialog from a more informed place. | ||
| --> | ||
|
|
||
| ### What alternative approaches did you consider, and why did you settle on this one? | ||
|
|
||
| The biggest question is if it makes sense to support both "session/load" and | ||
| "session/resume". However, I do wonder: how portable "session/load" is in practice? | ||
|
|
||
| When we start a new session over ACP, we introduce custom MCP tools and configuration. | ||
| This means that, while we could use "session/load" to load our own chats and chats | ||
|
Member
There was a problem hiding this comment. Yeah I guess the issue here is that we allow you to load a session with a different cwd and mcp servers, which indeed was maybe a mistake here reflecting on it. |
||
| not started by us, I presume loading third-party chats would lead to a flawed user | ||
| experience, as our tools would not be available. And depending on the ACP implementation, | ||
| not even the capabilities would be respected. | ||
|
Member
There was a problem hiding this comment. I'm not sure why capabilities wouldn't be respected? Can you elaborate here? |
||
|
|
||
| Therefore, I see functionality such as "session/load" and "session/list" being | ||
| useful for those who want to provide a different interface for coding agents, without | ||
| injecting custom functionality. Outside of that, the other benefit of "session/load" | ||
| is that we could rely on the coding agent's own storage, but unfortunately that does | ||
| not seem to be exposed at the moment. So if we have to emulate "session/load" at the | ||
|
Member
There was a problem hiding this comment. I would say from the agents where we apply adapters this is try, it isn't exposed. |
||
| ACP layer, we may know have chats stored in the coding agent, in ACP, and in our | ||
| applications. | ||
|
|
||
| If we can trivially implement "session/load" across agents, then I don't believe this | ||
| RFD has weight. But assuming we don't, we may need to deal with these trade-offs: | ||
|
|
||
| * If "session/resume" exists, coding agents may avoid implementing "session/load", | ||
|
Member
There was a problem hiding this comment. It seems like a reasonable fallback. If an agent supports the others, it makes for a nicer experience, and then it is a matter of how much the client wants to handle fallbacks for resume I guess. |
||
| hurting those who want a "session/list" and "session/load" style functionality | ||
|
|
||
| * If "session/resume" does not exist, coding agents may still not implement "session/load" | ||
| anyway, and clients will be unable to resume conversations (this is where we are) | ||
|
|
||
| ## Revision history | ||
|
|
||
| <!-- If there have been major updates to this RFD, you can include the git revisions and a summary of the changes. --> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering what was the intent to have
session/loadif main coding agents don't support it.If it is indeed the case that
session/loadis not the correct abstraction for the time being, should ACP drop it entirely in favor of thesession/resumethat is more aligned with current coding agent capabilities?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to both actually. As laid out
resumeis lighter weight, but it comes with tradeoffs that the client has to either store the entire previous conversation, or the user is left without the history of what happened before.The goal of
loadwas that the Agent could be in charge of persistence, but obviously this takes some more work on the Agent side.We haven't gotten to pulling our zed agent out into it's own process, but when we do this would be how we would handle loading the session, we'd do it from the agent not the client side, which is where the original design came from.