Merged
Conversation
An alternative to streamable HTTP (#6741) that simplifies bidirectional communication
jh-block
force-pushed
the
jhugo/acp-websocket
branch
from
bfe86e1 to
1206006
Compare
alexhancock
approved these changes
Feb 2, 2026
Collaborator
alexhancock
left a comment
alexhancock
left a comment
There was a problem hiding this comment.
good to get this in and then experiment with clients that use both transports!
| ) -> Poll<std::io::Result<usize>> { | ||
| self.buffer.extend_from_slice(buf); | ||
|
|
||
| while let Some(pos) = self.buffer.iter().position(|&b| b == b'\n') { |
Collaborator
There was a problem hiding this comment.
is there any way this could catch \n in content?
Collaborator
Author
There was a problem hiding this comment.
(this isn't new code, just extracted out of the http transport impl)
If the protocol client is well-behaved, the JSON-RPC messages should not contain any actual newline characters, and they're not valid within JSON strings (a newline within a string would be encoded as two characters: backslash followed by n).
If the protocol client somehow manages to fail at that, then we'd end up trying to parse an incomplete JSON documents and error out, which I think is fine
stebbins
pushed a commit
to stebbins/goose
that referenced
this pull request
Feb 4, 2026
Signed-off-by: Harrison <hcstebbins@gmail.com>
kuccello
pushed a commit
to kuccello/goose
that referenced
this pull request
Feb 7, 2026
Tyler-Hardin
pushed a commit
to Tyler-Hardin/goose
that referenced
this pull request
Feb 11, 2026
Tyler-Hardin
pushed a commit
to Tyler-Hardin/goose
that referenced
this pull request
Feb 11, 2026
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.
Adds WebSocket transport alongside the existing streamable HTTP transport for ACP, providing an alternative simpler implementation for bidirectional communication.
Protocol Details
Connection Model: A WebSocket connection maps one-to-one with an ACP session.
Message Format: JSON-RPC 2.0 (same as the streamable HTTP transport) over WebSocket text frames. All message types (requests, responses, notifications) share the same connection with native bidirectional support.
Lifecycle:
ws://host:port/acp. Session ID is returned in anAcp-Session-Idheader in the same way as for streamable HTTP.Implementation Choices
Shared Components: Extracted
ReceiverToAsyncReadandSenderToAsyncWriteadapters intoadapters.rs, enabling both HTTP and WebSocket transports to reuse the sameserve()protocol handler with consistent framing.Architecture:
TransportSessionmanages per-connection state for both http and ws transports: bidirectional mpsc channels and agent task handletokio::select!loop concurrently routes messages: client→agent and agent→clientServer Integration: Both transports are served by the same HTTP server via merged Axum routers, allowing clients to choose their preferred transport at will.