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.
openchamber # Start on port 3000
openchamber --port 8080# Custom port
openchamber --lan --port 3000# Listen on LAN (0.0.0.0)
openchamber --ui-password secret # Password-protect UI
openchamber startup enable# Start at login as a native serviceOPENCHAMBER_UI_PASSWORD=secret openchamber startup enable# Save service password env
openchamber startup status # Show startup service status
openchamber startup disable # Remove startup service
openchamber tunnel help# Tunnel lifecycle commands
openchamber tunnel providers # Show provider capabilities
openchamber tunnel profile add --provider cloudflare --mode managed-remote --name prod-main --hostname app.example.com --token <token>
openchamber tunnel start --profile prod-main
openchamber tunnel start --provider cloudflare --mode quick --qr
openchamber tunnel start --provider cloudflare --mode managed-local --config ~/.cloudflared/config.yml
openchamber tunnel status --all # Show tunnel state across instances
openchamber tunnel stop --port 3000# Stop tunnel only (server stays running)
openchamber connect-url --port 3000# Add this server to OpenChamber Desktop
openchamber connect-url --server http://host:3000 --qr
openchamber connect-url --port 3000 --qr
openchamber logs # Follow latest instance logsOPENCODE_PORT=4096OPENCODE_SKIP_START=true openchamber # Connect to external OpenCode serverOPENCODE_HOST=https://myhost:4096 OPENCODE_SKIP_START=true openchamber # Connect via custom host/HTTPS
openchamber stop # Stop server
openchamber update # Update to latest version
startup enable snapshots your current environment into the native service so startup behaves like you launched openchamber from the same shell. This preserves provider tokens, PATH, SSH agent settings, and other CLI auth/config env vars. Use --no-env-snapshot for a minimal service env.
When OpenChamber launches the local OpenCode server, it also registers a native
openchamber agent tool for project, session, and scheduled-task orchestration.
The tool is not injected when connecting to an external OpenCode server.
Behavior settings can optionally inject a managed system-prompt optimizer on
the next OpenCode restart. It is disabled by default and is not available for
external OpenCode servers.
Tunnel behavior notes
One active tunnel per running OpenChamber instance (port).
Starting a different tunnel mode/provider on the same instance replaces the active tunnel.
Replacing or stopping a tunnel revokes existing connect links and invalidates remote tunnel sessions.
Connect links are one-time tokens; generating a new link revokes the previous unused link.
Connect other OpenChamber apps
Use connect-url when a web/API server should be added to OpenChamber Desktop or another OpenChamber app. If no server is running on the selected port, OpenChamber starts one first.
--api-only starts API routes without serving browser UI assets. --lan binds the server so other machines can reach it. --server is the address saved into the Desktop connection link. --ui-password protects browser access if UI routes are enabled elsewhere; the generated client token is what Desktop uses for API access.
This creates a remote client token and prints an openchamber://connect?... link. The link contains the server URL, token, label, and payload version. In OpenChamber Desktop, paste it in Settings -> Remote Instances -> Direct Instances -> Import Link to add that server as an Instance.
If the server was started with --lan or --host 0.0.0.0, connect-url automatically advertises a detected LAN IP instead of 127.0.0.1. Use --server <url> when you want to advertise a specific DNS name, Tailscale address, reverse proxy URL, or HTTPS endpoint.
If you are exposing the server beyond localhost, start it with a password:
Generating a client token does not automatically password-protect the hosted browser UI. --ui-password protects browser access; the client token lets another OpenChamber app connect to this server.
Full base URL of external server (overrides OPENCODE_PORT)
OPENCODE_PORT
Port of external server
OPENCODE_SKIP_START
Skip starting embedded OpenCode server
OPENCHAMBER_OPENCODE_HOSTNAME
Bind hostname for managed OpenCode server (default: 127.0.0.1, use 0.0.0.0 for LAN/remote access — trusted networks only). Invalid values are rejected with an error and fall back to loopback
OPENCHAMBER_HOST
Bind hostname for the OpenChamber web server (default: 127.0.0.1; use 0.0.0.0 for LAN/remote access — trusted networks only)
OPENCHAMBER_VERBOSE_REQUEST_LOGS
Set to true to log every HTTP request; disabled by default to keep user logs small
OPENCHAMBER_SKIP_API_COMPRESSION
Set to true to disable gzip compression for /api/* responses
OPENCHAMBER_COMPRESS_API
Set to true to force /api/* compression, or false to disable it. Desktop runtime disables API compression by default to reduce local sidecar CPU use
OPENCHAMBER_TERMINAL_SHELL
Preferred terminal shell executable used by the Auto setting before platform defaults
Security note: binding to 0.0.0.0 exposes the server on all network interfaces — use only on trusted networks and protect with firewall rules or --ui-password.
Managed-local path note: OPENCHAMBER_TUNNEL_CONFIG must use a container path under /home/openchamber/.... If the config file references credentials-file, ensure that JSON path is also mounted and reachable inside the container.
Data directory: mount data/ for persistent storage. Ensure permissions:
openchamber # Runs in background by default
openchamber stop # Stop background server
systemd service (VPN / LAN access)
Use --foreground to keep the CLI process alive so systemd (or any other process manager) can track and restart it. Combine with OPENCODE_HOST to connect to an OpenCode instance running as a separate service.
Why set PATH and SSH_AUTH_SOCK?
systemd user services start with a minimal environment — no shell profile is sourced.
Without an explicit PATH, OpenCode won't find tools installed via Homebrew, npm, or ~/.local/bin.
Without SSH_AUTH_SOCK, git operations over SSH (push, pull, clone) will fail.
%t expands to $XDG_RUNTIME_DIR (e.g. /run/user/1000), where most SSH agents write their socket.
--host 0.0.0.0 is required to listen on all interfaces (the default is 127.0.0.1). Use --host <ip> or OPENCHAMBER_HOST=<ip> to bind to a specific interface instead.
What makes the web version special
Remote access - Cloudflare tunnel with QR onboarding. Scan from your phone, start coding.