0.3.0 — renamed to dsh-embedded-browser, tools published lazily, an on-demand Sidebar tab

This release renames the plugin. Updating from dsh-browser-panel means changing every name it used — and moving a directory of data.

What breaks

All at once, on purpose, so that the package, the tools and the routes finally agree with each other:

	0.2.0	0.3.0
package	dsh-browser-panel	dsh-embedded-browser
tools	browser_panel_*	browser_embedded_*
routes	/api/dsh-browser-panel/*	/api/dsh-embedded-browser/*
profile	$DSH_HOME/browser-panel/profile	$DSH_HOME/embedded-browser/profile

The profile directory is data, not a string. Move it before the first start of 0.3.0, or the browser comes up with an empty profile and every site asks you to log in again:

# no Chrome may be running on it
mv ~/.dsh/browser-panel ~/.dsh/embedded-browser

Alternatively point profileDir at the old directory and keep it where it is.

Two surfaces also disappear: the per-session conversation.view tab and the host-wide overview panel are gone, replaced by an on-demand tab in the right Sidebar.

What changed, and why

The ten tools are published lazily. A tool schema is paid for on every request whether or not the turn touches a browser; a skill's catalog entry is two lines, and its body is read only when the model decides to read it. browser_embedded_* now appears only after the entry skill browser-use has been invoked — a successful skill call, a /browser-use gesture, or a past invocation found in a live session's log when the plugin loads. That third path is the one that matters: a gate that only listens for future events stays shut forever after a plugin reload, because the invocation that opened it is in the past (upstream Tencent/BrowserSkill#269 is exactly that failure, and it is why the reference implementation turned its own gate off). lazyTools: false restores the old behaviour.

Measured on the development host, read from the session log's request/header — the tool list as the model actually received it:

	tools	schema bytes
0.2.0, registered at load	73	72,541
0.3.0, gate closed	63	67,958
0.3.0, after browser-use	73	72,732

A session that never browses therefore sends about 4,774 bytes (~1.2k tokens) less on every request.

The UI is an on-demand right-Sidebar tab. One registered tab type plus a watcher that opens it when the session on screen gets a browser, or when a new hand-over request arrives. Nothing is pinned per session, so a session that never browses shows nothing at all. The tab opens its stream from tab.visible rather than from mounting: a docked body stays mounted while its tab is inactive, and a hidden tab holding a socket would keep stealing the browser's foreground and spending bandwidth nobody is looking at.

Client services are now awaited, not sampled. The Sidebar tab silently failed to register in the first build of 0.3.0: ctx.get('sidebarRightTabs') is undefined during apply(), because the client half really is activated before the Sidebar provides its services (the boot graph's order is not the activation order). Every Sidebar-facing surface was skipped, the host stayed perfectly healthy, and the only witness was one line in the browser console. ctx.inject waits for the declaration instead — the rule the host half already followed for webServer/connection.

Upgrading

1. Move the profile directory if you want to keep your logins (above).
2. In your profile, replace the dsh-browser-panel bundle/dependency entry with dsh-embedded-browser, then re-install.
3. Install the browser-use skill, or set lazyTools: false. Without either, the tools are never published.
4. Rename any tool call you make by hand: browser_panel_* → browser_embedded_*.

How this was verified

• npm test: 22 checks for the lazy gate (a fake context; no host, no browser — including the composition-order and reload cases) and 43 for the core (real Chrome).
• The gate end to end on a live host, read from the session log's tool list: 73 → 63 tools with the gate closed, 73 again after invoking the skill, with all ten browser_embedded_* names present.
• Routes: /api/dsh-embedded-browser/health answers 200 with the Web UI's own authentication cookie and 401 without it (the gateway fence, which is why the old prefix answers 404 only when authenticated).
• The browser itself, on both channels: the BrowserSkill plugin's browser_* tools against a real user browser, and this plugin's browser_embedded_* tools against the Chrome inside the container — navigate, read back page structure, and the right-Sidebar tab observed opening by itself.
• The rename's data step: the 0.2.0 profile directory was moved, and the logins came with it.