Fix WebSocket connection in dev mode (bun run dev)#7
Open
alimaazamat wants to merge 3 commits into
Open
Conversation
Vite's http-proxy cannot relay Bun.serve's WebSocket upgrade (101) response, so the /ws proxy silently times out and terminals never connect under `bun run dev` (broken since the initial commit). Connect the terminal WebSocket directly to the backend in dev instead of through the proxy, and remove the non-functional /ws proxy entry. Production/single-server mode is unchanged (the backend serves the client, so window.location.host already points at it). The backend port is configurable via VITE_BACKEND_PORT (defaults 6968).
|
There was a problem hiding this comment.
1 issue found across 2 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
In dev the client connects directly to the plain-HTTP Bun backend, which has no TLS listener. Deriving the WebSocket protocol from the page meant an HTTPS-served dev page produced a wss:// URL that failed the TLS handshake. Always use ws:// for the direct dev connection; production still mirrors the page protocol and reuses the current host. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Forcing ws:// would be blocked by the browser's mixed-content policy when the dev page is served over HTTPS. Mirror the page protocol instead: the default HTTP dev page still yields ws:// (works against the plain backend), while an HTTPS dev page yields wss:// so the browser does not block it. Co-authored-by: Copilot <223556219+Copilot@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
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.
Problem
When running the project with
bun run dev, agent terminals never connect — you can't type into them and no output appears. This affects anyone developing against the repo (as opposed to the published single-serveropenuicommand, which works fine).Root cause
In dev, the frontend runs on Vite (
6969) and proxies to the Bun backend (6968). The HTTP/apiproxy works, but the/wsproxy does not: Vite forwards the upgrade and Bun accepts it (the backend logs[ws] Connected), but Vite's underlyinghttp-proxycannot relayBun.serve's101 Switching Protocolsresponse back to the browser. The socket never opens and the connection silently times out.This is a known incompatibility between Vite's
http-proxyandBun.serveWebSockets — not specific to any agent.Fix
client/src/components/Terminal.tsx— in dev, connect the terminal WebSocket directly to the backend (window.location.hostname+ backend port) instead of through the Vite proxy. The backend port is configurable viaVITE_BACKEND_PORT(defaults to6968). Production/single-server mode is unchanged: there the backend serves the built client itself, sowindow.location.hostalready points at the backend.client/vite.config.ts— remove the non-functional/wsproxy entry (with a comment explaining why). The/apiproxy is untouched.The backend performs no Origin check on upgrade, so the cross-port WebSocket from the dev page is accepted.
Verification
With the fix and
bun run devrunning:/api.Origin: http://localhost:6969header.ws OPENand command output received ✓.Terminals now work in dev mode without falling back to single-server/production mode.
Notes
+10 / −5. No behavior change in production.Summary by cubic
Fixes terminal WebSocket connections in dev by bypassing Vite’s proxy and connecting directly to the Bun backend. In dev, mirror the page protocol (ws/wss) to satisfy browser mixed-content rules; production/single-server is unchanged.
client/src/components/Terminal.tsx, in dev connect directly to${protocol}//${window.location.hostname}:${<VITE_BACKEND_PORT|6968>}/wswhereprotocolmirrors the page; production reuses the current host and protocol.client/vite.config.ts, remove the non-functional/wsproxy (keep/api), since Vite’shttp-proxycan’t relayBun.serve’s upgrade response.Written for commit 9076c4b. Summary will update on new commits.