Bohdan Triapitsyn
a5aa32446d
The preview panel worked by proxying a dev server through OpenChamber's own origin and rewriting the HTML that came back. Anything the rewriter did not anticipate broke, and pages that refuse to be embedded never loaded at all. This deletes the proxy (-1604 lines and its tests) and merges the preview and browser panels into one surface backed by a real Chromium view. What the panel is now - A `<webview>` in its own session partition: logins and cookies persist, hot reload works because nothing is rewritten, DevTools are one click away. - Annotation: pick one element, drag a region, or draw freehand, write a note, and it reaches chat with a screenshot of the visible page with the marks on it. - Toolbar: hard reload, page zoom, device sizes, a light/dark switch that applies to the page rather than the app, and cookie/cache clearing scoped to the panel alone. - Several pages at once, each tab showing the page's own favicon, and an address bar that suggests pages already visited in this project. - Dev servers are listed from what is actually listening on the machine, checked against what a project announced, so a server is offered no matter how it was started. One that is still starting is waited for instead of failing. Remote dev servers The desktop app binds a local port and pipes raw bytes to the OpenChamber host over the existing authenticated connection, so the page keeps its own origin at the root of its own host. The reachable set is exactly what discovery reports and is re-checked per connection, so an authenticated client cannot dial arbitrary local services on the host. Links and redirects to another loopback port stay on the machine that served the page. A tunnel that cannot be opened is reported; it is never replaced by the plain loopback URL, which would answer from the user's own machine under a remote address. Agent control Browser actions are a separate `openchamber_web` tool: open, snapshot, click, type, scroll, inspect computed styles, resize between mobile/tablet/desktop, and capture a screenshot into `.openchamber/screenshots/` in the project. The existing `openchamber` tool keeps sessions, worktrees and scheduled tasks. Each has its own setting in the new Settings -> General -> OpenChamber Tools section, and the plugin is not injected at all when both are off. Capability belongs to the connected client, not to configuration: a client declares on its event stream that it can drive a page, which only a Chromium host does. Exactly one client performs each request — it claims the request before acting, and the first claim wins — because deciding by whose result arrives first would be too late for a click that already happened. No client listening is answered immediately with an explanation rather than a timeout. Runtime boundaries Web tabs get a plain iframe that can display a page but not inspect one. The VS Code extension no longer offers the surface at all, since nothing that makes the panel worth having works there. Mobile is unaffected. Native boundary Camera, microphone, location and device-picker requests from panel pages are denied — Electron grants them by default when no handler is set, and the panel loads whatever address the user types. Page capture, appearance emulation and storage clearing verify that their target belongs to the panel's own session instead of trusting a web-contents id from the renderer. Persisted state Stored `preview` tabs migrate to `browser` (v13 -> v14). Context panel tab limits are now per surface, so filling one surface no longer evicts another's tabs. Address history is stored per project and per runtime. Documentation `preview.mdx` and `desktop-browser.mdx` rewritten across all locales, the agent tool settings path corrected, new `DOCUMENTATION.md` for the browser-control broker and the dev tunnel, and the `ui-api-decoupling` skill updated where it still described the deleted proxy.
3.2 KiB
3.2 KiB
Dev Server Tunnel
Purpose
This module carries raw TCP bytes between a desktop client and a dev server running on the OpenChamber host, so a remote dev server can be opened in the browser panel without anything being rewritten.
The page is served from a real origin at the root of its own host. That is the whole design: absolute URLs resolve, cookies scope correctly, HMR sockets connect, and developer tools behave as they do locally. No HTML, header, or URL is inspected or modified, which is what the previous rewriting proxy did and what made it fragile per framework.
Boundaries
runtime.jsis the host end: it accepts the WebSocket upgrade at/api/dev-tunnel, authenticates it, opens a TCP socket to the requested local port, and pipes the two together.client.jsis the local end: it binds a loopback listener on the user's machine and pipes each accepted connection through one WebSocket. It lives in this package because it needs a WebSocket client the package already depends on; the desktop shell drives it over IPC.- Port discovery is not owned here.
runtime.jsis given the reachable set by the same dev-server discovery the user's own list is built from. - The browser panel decides when to tunnel; this module never chooses a target.
packages/ui/src/lib/browser/devTunnel.tsowns that decision, including for navigations the page starts itself: a tunnelled page that sends the view to another loopback port means a port on the host, not on the user's machine.
Invariants
- The reachable set is exactly what dev-server discovery offers the user, never "any loopback port". Without that restriction an authenticated client could dial arbitrary local services on the host — databases, admin panels, the OpenCode API — through this socket.
- Authentication depends on whether the caller is a browser, and this is
deliberate rather than a relaxation:
- With an
Originheader the request came from a browser context, and the usual origin allowlist applies unchanged. That check is a CSRF defence: a hostile page can make a browser open a WebSocket carrying ambient cookies, and the origin is what exposes it. - With no
Originthe request must carry client-token auth. A browser cannot reach this path — the WebSocket API always sends an origin and never lets a page set anAuthorizationheader — so this case is the desktop shell.
- With an
- Concurrency is capped per host, not per page, because one page load opens many sockets.
- A connection that cannot be established fails the socket rather than holding it open; a stalled connect is bounded by an explicit timeout, and so is the WebSocket handshake. While it is pending the local socket is paused and its buffered bytes are capped, so a local process writing into a stalled handshake cannot grow the desktop app's memory.
- A tunnel that cannot be opened is reported to the panel, never replaced by the plain loopback URL. On a remote instance that substitution would change which machine answers and show local content under a remote address.
- Closing either end closes the other. A half-open pipe would leave the page waiting on bytes that will never arrive.