Skip to content

Fix WebSocket connection in dev mode (bun run dev)#7

Open
alimaazamat wants to merge 3 commits into
Fallomai:mainfrom
alimaazamat:fix-dev-websocket-proxy
Open

Fix WebSocket connection in dev mode (bun run dev)#7
alimaazamat wants to merge 3 commits into
Fallomai:mainfrom
alimaazamat:fix-dev-websocket-proxy

Conversation

@alimaazamat

@alimaazamat alimaazamat commented Jun 15, 2026

Copy link
Copy Markdown

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-server openui command, which works fine).

Root cause

In dev, the frontend runs on Vite (6969) and proxies to the Bun backend (6968). The HTTP /api proxy works, but the /ws proxy does not: Vite forwards the upgrade and Bun accepts it (the backend logs [ws] Connected), but Vite's underlying http-proxy cannot relay Bun.serve's 101 Switching Protocols response back to the browser. The socket never opens and the connection silently times out.

This is a known incompatibility between Vite's http-proxy and Bun.serve WebSockets — 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 via VITE_BACKEND_PORT (defaults to 6968). Production/single-server mode is unchanged: there the backend serves the built client itself, so window.location.host already points at the backend.
  • client/vite.config.ts — remove the non-functional /ws proxy entry (with a comment explaining why). The /api proxy 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 dev running:

  1. Created a session via the (proxied) /api.
  2. Opened the terminal WebSocket directly to the backend with a browser Origin: http://localhost:6969 header.
  3. Result: ws OPEN and command output received ✓.

Terminals now work in dev mode without falling back to single-server/production mode.

Notes


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.

  • Bug Fixes
    • In client/src/components/Terminal.tsx, in dev connect directly to ${protocol}//${window.location.hostname}:${<VITE_BACKEND_PORT|6968>}/ws where protocol mirrors the page; production reuses the current host and protocol.
    • In client/vite.config.ts, remove the non-functional /ws proxy (keep /api), since Vite’s http-proxy can’t relay Bun.serve’s upgrade response.

Written for commit 9076c4b. Summary will update on new commits.

Review in cubic

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).
@changeset-bot

changeset-bot Bot commented Jun 15, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 9076c4b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 2 files

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread client/src/components/Terminal.tsx Outdated
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>

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 1 file (changes from recent commits).

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread client/src/components/Terminal.tsx
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant