The side panel no longer brings its own browser tools into opencode. It is an
opencode client like the desktop app and TUI; agents drive the browser through
the `browse` MCP server (renamed from opencode-browser), and setup pairs the
extension with opencode instead of using a native messaging host.
Removed / replaced:
- The per-session browser attachment (session-browser, page, cdp, files,
profiling, analysis, diagnostics, preview): the panel no longer attaches
`browser.*` tools or writes instruction entries. Instead, each prompt sent
from the panel is preceded by a synthetic "Browser context" message
(resume: false) naming the page; a tab shared with agents comes with its
Chrome tab id. Sent only when the page or its sharing changed.
- The opencode plugin (site_scripts, browsing, browser.tabs.request) and its
relay-link: these are browse MCP tools now (site_scripts_*, browsing_*,
tabs_request), sent through the relay as `extension.request`
(POST /extension/request, 10-minute timeout for the user's answer).
tabs_request adopts the approved tab into the session.
- The native messaging host and service discovery: the extension keeps a list
of paired servers (background/servers.ts, chrome.storage.local). connect.html
redeems a one-time code from opencode's own pairing (POST /api/pair,
GET /auth/connect/:code -> 30-day token used as the password) and renews the
token a week before expiry. Loopback links pair right away; others ask.
Servers can also be added by hand with a code or the service password; the
directory menu switches, adds, and forgets servers.
- Permissions nativeMessaging, downloads, webNavigation.
Setup (cli/src/setup.ts):
- `install` writes the `browse` MCP entry (renaming the old one), removes the
old host and plugin, then runs `connect`.
- `connect` finds browsers/profiles with the extension (default browser
first; macOS-protected profiles are reported as unknown and asked about),
opens connect.html#server=&code= there via the browser's executable and
--profile-directory, opens the Web Store listing when missing, and prints
the link and code when headless (no TTY, SSH, no display, --no-open).
- The relay reports the extension's build in /extension/status; install
checks the build changed after asking for a reload, and says so (and skips
connect) when it didn't.
Fixed: the extension's runtime.reload closed its socket with code 1001,
which browsers reject (only 1000 or 3000-4999), so the reload threw and never
ran; every install since reported "Reloaded" while Helium kept the old
build. It closes with 1000 now.
Also: session_adopt / `session adopt --tab-id` adopt a tab by Chrome tab id;
"Share tab" above the composer lets agents use the current tab; agent guide
renamed to skills/browse; store listing and privacy policy updated.
Verified in the user's Helium: `connect --yes` detected Helium/Ryan (default),
Chrome unreadable (macOS privacy), Arc without the extension, opened the
connect page, which showed "Connected · This computer · 4102". Through the
browse MCP server: site_scripts_list, tabs_request (returned the tab id and
adopted it), session_adopt({ tabId }) (success, exclusivity error, unknown-tab
error). The synthetic message with metadata was accepted and stayed queued
(resume: false). A clean headless Chromium loads the build and the connect
page answers. Install now reports a stale reload instead of claiming success.
Typecheck (extension, cli), lint. Upstream relay suite: 871/888; the new
failures are the 9 MCP tests asserting the old server name.
Not yet verified: the panel UI (server menu, Share tab, composer flow).
- `bun run package` builds and writes release/opencode-browser-<version>.zip
without the manifest `key` (the store rejects it and assigns its own ID) and
without source maps. release/ is ignored.
- history, bookmarks, topSites, and sessions are now optional permissions,
requested from the panel's Allow click on an agent's browsing-data request,
so install shows fewer warnings and review sees them as user-initiated. A
session grant only counts while the browser permissions are held; revoking
them in browser settings makes the panel ask again.
- store/listing.md (listing copy, single purpose, permission justifications,
data disclosures) and store/privacy-policy.md (to host for the listing).
Verified: typecheck, lint, and `bun run package` produced a zip whose manifest
has no key and lists the four optional permissions. The Chrome permission
prompt on Allow was not exercised (headless can't answer it).
opencode Browser now connects to the local Browser Control relay
(ws://127.0.0.1:19989/extension, protocol 2) and runs its commands, so the
relay's CLI, MCP server, and Playwright execute drive tabs through this
extension instead of the separate Browser Control extension.
- debugger-hub.ts: one chrome.debugger attachment per tab shared by owners
(each opencode page and the relay); the tab detaches with its last owner.
cdp.ts now attaches through it instead of calling chrome.debugger directly.
- browser-control.ts: relay link ported from browser-control's background
(hello with a stored profile id, debugger/tab/group/badge/page-status/profile
and recording commands, events only for relay-owned tabs, reconnect with
backoff, /version probe to tell "not running" from "refused").
- Recording: offscreen document + tabCapture ported verbatim; frames encoded
with the relay's BCRD format.
- content.js (separate IIFE build): in-page status pill and "Your turn"
handoff card in opencode's style; restyles the relay's ghost cursor.
- Badge shows ON/RUN/WAIT for relay tabs, else the site-script count. The
toolbar still opens the panel; "Let Browser Control use this tab" moved to
the icon's context menu. First install opens welcome.html (placeholder).
- Manifest adds offscreen, tabCapture, activeTab, contextMenus and the
content script.
Verified: typecheck, build, and lint pass. Headless Chrome for Testing with an
isolated relay on port 19990: `browser-control status` reports the extension
connected (protocol 2, profile "opencode Browser"); `browser-control execute`
opened example.com, hovered a link, returned the title; the page showed the
status pill and the panel received the relay tab state.
The extension becomes "opencode Browser", the product that will also take over
Browser Control's extension, and the CLI command follows it.
Renamed:
- packages/open-extension -> packages/browser-extension (@opencode/browser-extension),
manifest name, panel copy, README, and agent-facing text.
- `opencode sidepanel` -> `opencode browser` (install/status/uninstall/host);
services/sidepanel.ts -> services/browser-extension.ts.
- Native host ai.opencode.sidepanel -> ai.opencode.browser; plugin id, file
(plugins/opencode-browser.ts), relay RPC (opencode-browser.relay), panel port,
session context keys, and cursor element id use "opencode-browser".
Install now:
- adds the Browser Control MCP server to opencode's global config (browser-control
on PATH, else npx @opencode-ai/browser-control), with
BROWSER_CONTROL_EXTENSION_ORIGINS so existing relays accept this extension;
skips it when a browser-control server is already configured;
- uses clack steps and, in a terminal, waits up to 3 minutes for the extension's
first connection; status also reports the Browser Control MCP server.
Verified: cli and extension typecheck, extension build, and root lint pass; in a
temp HOME/XDG, `opencode browser install` registered Helium, wrote the MCP entry
to opencode.json, started the service, and `status` reported all three.
Ryan Vogel