-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Add app-server transport layer with websocket support #10693
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2cd76800f6
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let outgoing_message = | ||
| OutgoingMessage::Request(request.request_with_id(outgoing_message_id.clone())); | ||
| if let Err(err) = self.sender.send(outgoing_message).await { | ||
| if let Err(err) = self | ||
| .sender | ||
| .send(OutgoingEnvelope::Broadcast { | ||
| message: outgoing_message, | ||
| }) |
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.
Route server requests to the originating connection
With websocket support, send_request_with_id now broadcasts server-initiated requests (approvals, user input, auth refresh) to all initialized connections, and the first response wins while other responses are dropped. This means a second client can receive and approve/deny a command or tool call that was triggered by a different client, causing cross-connection data leakage and incorrect approvals. These requests should be targeted to the connection that initiated the action (e.g., carry a ConnectionId through the request flow) instead of broadcasting.
Useful? React with 👍 / 👎.
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.
this is intentional - all connected clients are eligible to receive / reply to requests from server->client
JaviSoto
left a comment
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.
Not super familiar with the code, so someone else should take a look. It looks good to me overall. I particularly like the --listen stdio://|ws://IP:PORT API! 🙏
Lazy question: are the changes to the app-server messages you made backwards compatible? Just wanna make sure that existing clients don't break
|
@JaviSoto this doesn't change any of the app-server messages yet - just allows multiple connections and broadcast + response routing semantics |
owenlin0
left a comment
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.
looks like a good start to me, but curious what @jif-oai thinks about how multi-client should work with experimental
owenlin0
left a comment
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.
approving to unblock, i think the experimental thing we can figure out as a followup
Testing