Closing a workbench page popped a centered confirm dialog that locked
the entire shell (busy gate) until answered. Developers who clicked the
tab's close button and immediately went for the connection list found
every button dead and reported the page as impossible to reopen. Debug
pages are stateless and rebuild on reopen, so the close now happens
immediately; destructive actions (delete connection, disconnect,
backend rebuild) keep their confirmations.
The dev host read manifest.json once at startup and froze that copy in
the Sidecar, while the backend watcher happily rebuilt the binary on any
source edit. Editing the manifest while the host ran — a routine version
bump during a release, for example — then made every restart compare the
fresh binary against the stale in-memory manifest and fail with "Sidecar
identity or protocol does not match manifest" until the whole dev host
was restarted.
Two layers of fixing: the project root now watches manifest.json and hot
swaps the in-memory copy (plus secret-key collection), and the sidecar
handshake re-reads the manifest from disk before declaring a mismatch, so
the check can no longer race the watcher. A genuinely disagreeing
manifest still fails the handshake.
Plugin workbenches run in a sandbox="allow-scripts" iframe with an opaque
origin, so every scripted clipboard path (async Clipboard API, offscreen
textarea + execCommand) is denied there — plugins could not copy share
links to the system clipboard. The bridge now exposes host.copy: the
workbench host reuses copyToClipboard (Tauri clipboard-manager on desktop,
Web Clipboard with a legacy fallback on web hosts), and the sandbox iframe
additionally gets allow="clipboard-write" so engines that honor the
delegation can write directly.
The dev host matches production: its debug page answers host.copy in the
top-level document and its plugin iframes carry the same allow attribute.
No new plugin permission is required, so old hosts keep installing new
plugins and old plugins simply never call the method.
Jinpy