The server section was only in the directory menu, which a conversation's
header replaces with its title menu, so servers could only be switched from a
new conversation. It is now a shared ServerMenu at the end of both menus
(switching starts over on the other server, since conversations belong to it).
Server rows used the default one-line item height for two lines of text; they
now use the directory rows' 44px two-line layout. The lists above shrink to
leave room for it; the History icon's menu, without a server section, keeps
its height.
Verified: typecheck, lint, build; the extension reloaded into the new build
in the user's Helium (relay reports the new build id).
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).
Bot checks (deviceandbrowserinfo.com's isAutomatedWithCDP and its worker
variant) override Error.prepareStackTrace and console.log an Error: with
CDP's Runtime domain enabled, Chrome serializes console arguments for the
debugger and calls the override. Playwright enables Runtime on every page and
worker. Patchright (patchright-core, a Playwright fork pinned to the same
1.63.0) never does.
- playwright-core is replaced by patchright-core (same API; two runtime
imports, the rest types).
- Without Runtime, a page's console messages and uncaught errors don't reach
execute. pageConsole.start()/stop() (new page-console.ts) enables Runtime
on that one page through its own CDP session, drops what Chrome replays
from before, and feeds the same execute logs. Documented in the skill and
the MCP execute description.
- patchright-tuning.ts: Patchright finds elements by walking the DOM over CDP
(for closed shadow roots), and pulled the whole DOM tree before every
count()/evaluateAll()/all(). Through the extension, getByRole("link").count()
on a 4,000-element Wikipedia page took ~650-1,900 ms vs Playwright's ~9-29
ms. count() and querySelectorAll() go back to Playwright's lookup (injected
script in the isolated world, which pages can't see) and the shadow-root
scan is off; Playwright never reached into closed shadow roots either. The
internals are reached through the first page's main frame; if an update
renames them, lookups stay correct but slower and relay.log records
patchright.tuning.
Verified in the user's Helium:
- deviceandbrowserinfo.com: isAutomatedWithCDP and isAutomatedWithCDPInWebWorker
gone; only hasInconsistentWorkerValues remains (Helium reports
hardwareConcurrency 16 on pages, 18 in workers; neither engine touches it).
Sannysoft 31/31, BrowserScan 18/18 normal, reCAPTCHA v3 0.9, CreepJS 0%
headless/stealth, Fingerprint scraping demo not blocked: unchanged.
- Upstream test suite: 880/888, the same 8 intentional failures as before.
- Benchmark page (form, iframe, 200-item list, snapshot, screenshot), 3 runs
each: medians within noise, identical form results and snapshot hashes.
- Wikipedia: count/all/evaluateAll/textContent/isVisible within a few ms of
Playwright with the same values; click, hover, fill, waitForSelector same.
- pageConsole: off by default (no page logs, page can't detect a debugger);
start() captures log/warn/error/pageerror across executes and reloads;
stop() makes the page undetectable again.
- Mouse/typing/scroll humanization unchanged.
Agent scrolling stuttered: Playwright's mouse.wheel is one wheel event (the
page jumps by the whole delta in one frame), and before acting on an
off-screen element Playwright calls DOM.scrollIntoViewIfNeeded, which snaps
the page there instantly.
- Each wheel event is now split into an eased ~60 Hz burst (quick start,
slowing to a stop) with the original event carrying the last frame.
- DOM.scrollIntoViewIfNeeded on the top frame first scrolls toward the
element with wheel flicks of 450-900 px from where the pointer rests,
re-measuring after each and stopping when the element stops moving; the
original command then only fine-tunes. Logged as input.scroll.
- relay.ts imports human-input by name instead of a star import (repo style).
Verified in the user's Helium: wheel(0, 800) now moves over 28 frames, at most
80 px per frame (was 800 px in one frame); clicking a button 2,600 px down
scrolls over 105 frames, at most 83 px per frame, in 3.1 s. cli typecheck, lint.
Playwright teleports the pointer: one mouseMoved straight to the exact center
of the target, then a press and release ~50 ms apart. The events are trusted,
but behavioral bot detection scores exactly that shape.
The relay now paces Input.* commands per tab (cli/src/human-input.ts):
- each pointer move is preceded by a curved trajectory from the last position
(cubic Bezier with a sideways bow, minimum-jerk speed, Fitts'-law duration,
fading tremor, occasional overshoot and correction), sent at ~60 Hz with the
round trip counted toward each gap so samples don't arrive in bursts;
- clicks land 1-3 px off center (same offset for move, press, release), after
a 30-130 ms settle, with a 60-140 ms hold;
- key presses are spaced 30-110 ms apart;
- one tab's input runs in order, since Playwright doesn't always wait for the
move before pressing (that interleaved two paths in the first attempt).
Each movement is logged to relay.log as input.move. OPENCODE_BROWSER_HUMAN_INPUT=0
turns it off. The skill tells agents to use pressSequentially where typing is
watched.
Verified in the user's Helium: a 690 px click went from 1 mousemove in 0 ms
to ~45 moves over ~650 ms (path ratio ~1.03, bow 40-80 px, 15-20 ms gaps),
clicks hit 1-3 px off center, typing 40-110 ms per key; a 4-click httpbin
form still submits correctly (1.7 s -> 3.7 s); bot.sannysoft.com 0 failed,
BrowserScan 18/18 normal, reCAPTCHA v3 score 0.9. cli typecheck, lint.
Two ways agent tabs ended up loose in the user's tab list:
- When the relay was done with a tab (session deleted or detached), the
extension only ungrouped it. A tab an agent opened now closes with its
group; a tab the user lent an agent still just leaves the group.
- Reloading the extension (now also done by install) detached every tab, and
the dying worker reported those detaches to the relay, which dropped its
sessions' tabs and later treated them as the user's. On runtime.reload the
extension now stops reporting detaches and freezes its stored attachments;
those (tab id + URL) live in chrome.storage.local, and the new worker
re-attaches the same pages, so the relay reclaims each session's tab on
the next hello. The URL check keeps a browser restart from re-attaching a
stranger that reused a tab id.
Verified: extension and cli typecheck, lint. In the user's Helium: a "news"
session's lobste.rs tab survived POST /extension/reload (the session still
answered with its page), and `session delete news` closed that tab.
Reloading the extension (or an extension update) emptied its memory and
session storage, so on reconnect it ungrouped every relay group's tabs it no
longer recognized: the groups vanished and the agents' tabs stayed open as
ordinary tabs.
- Which tabs agents opened (tab cleanup) and which groups are agents'
(collapse/placement) now live in chrome.storage.local, cleared on browser
startup since tab and group ids don't survive a restart.
- After a reconnect, tabs an agent opened stay in their group (the relay
reclaims named sessions' tabs, idle cleanup closes the rest); only tabs the
user lent an agent go back to ordinary tabs.
- install reloads a connected extension through the relay (new POST
/extension/reload, sending runtime.reload) after replacing the unpacked
files, waiting up to 5s for a just-restarted relay to see it, so updates
apply without a trip to chrome://extensions.
- The extension's hello carries its build time and the relay logs it, so a
browser running an old build shows in relay.log.
Verified: extension and cli typecheck, lint. In the user's Helium,
POST /extension/reload reconnected the extension with the new build within a
second (relay.log). The reload-without-ungrouping path couldn't be checked
headless (Chrome for Testing blocks a command-line extension after
runtime.reload).
Agent tabs unused for 10 minutes (was 30) now close, checked every minute (was 5), so a tab goes within about 11 minutes. The agent guidance, skill, MCP tool, and CLI flag descriptions say 10.
Verified: extension and cli typecheck, cli build.
With vertical tabs the far right is the bottom of the list. Agent groups now sit at the start of the strip, right after pinned tabs (the top of a vertical strip), keeping their order; a tab opened or moved in before them puts them back.
Verified: extension typecheck and lint. Headless Chrome against an isolated relay with a pinned tab: [research] and [Agent · example.net] sat right after the pinned tab and stayed there after the user opened another tab.
Agent groups landed wherever Chrome put the new tab. Each agent group now moves to the end of its window's tab strip when it gains a tab, and after the user opens a tab or moves one into the window (debounced 150ms), keeping the groups' order among themselves. A user dragging a group elsewhere isn't fought until the next new tab.
Verified: extension typecheck and lint. Headless Chrome against an isolated relay: with user tabs open, two agent sessions' groups ([research], [Agent · example.net]) sat at the far right, and stayed there after the user opened another tab.
After reinstalling, the running relay and every MCP server opencode had
started kept the old code, and the relay's build check then refused them
("relay build ... is newer than CLI build"; restart the client). Install now:
- writes the runtime's fingerprint (sha256 of dist/cli.mjs) into the
opencode-browser MCP entry's environment, so the entry changes whenever the
runtime does and opencode restarts the server with the new code;
- restarts a running relay whose build no longer matches (detected with
`status --json`'s stale flag), keeping tabs open.
Verified: cli typecheck and build; reinstalling on this machine updated the
MCP entry, restarted the stale relay, opencode reloaded the MCP server (26
tools), and an MCP execute in the user's browser returned HN's newest stories.
Agent tab groups stayed expanded and took over the tab strip. A new module,
background/agent-groups.ts, collapses every agent group (conversations'
groups and agent sessions' groups) when it's created, and again whenever the
user's active tab in that window moves outside it. Chrome expands a group by
itself when one of its tabs becomes active (the agent focuses it or the user
picks it), and collapsing a group that holds the active tab would switch the
user away, so that case is left open. A handoff ("Your turn") expands the
tab's group and keeps it open while it waits; it folds back up once the
handoff resolves. Known groups survive worker restarts in session storage.
Verified: extension typecheck and lint. Headless Chrome against an isolated
relay: the "checkout" session's group was collapsed after its tab opened,
expanded while a handoff waited, and collapsed again after Continue.
Agent tab groups had opaque names (every conversation's group was
"opencode"; MCP/CLI sessions showed ids like mcp-48092553), and tabs agents
opened stayed open forever.
Names:
- A conversation's group is named after the conversation title (cut to 28
characters; "opencode" until it has one), refreshed when it groups a tab.
- An agent session's group uses the session's chosen name ("github"); ids
the relay or MCP made up (mcp-<hex>, adjective-animal-###) become
"Agent · <site>", following the tab's navigation. Each session keeps one
group by id, so renames no longer split its tabs.
Cleanup (background/tab-cleanup.ts):
- Tracks only tabs agents created (browser.tabs.open, relay tabs.create);
an agent command or the user switching to the tab counts as use. Tabs the
user shared are never tracked; pinning a tab or dragging it out of the
group hands it to the user.
- Every 5 minutes, closes tracked tabs unused for 30 minutes
(chrome.storage.local tabCleanupIdleMinutes; 0 turns it off), skipping
the active tab of the focused window, tabs playing audio, recording, or
waiting for a handoff. State survives worker restarts.
- On demand: "Close agent tabs" in the panel's agents menu, the relay
command tabs.cleanup, POST /tabs/cleanup, the MCP tool tabs_cleanup, and
`opencode-browser tabs cleanup [--idle-minutes N]`.
- The skill and the in-session guidance tell agents to name sessions,
close their tabs, and that idle tabs close by themselves.
Verified: extension and cli typecheck, lint. Headless Chrome against an
isolated relay: a "github" session's tab was grouped as "github", an
unnamed session's as "Agent · iana.org", and `tabs cleanup --idle-minutes 0`
closed both and their groups. The conversation group name and the 30-minute
alarm were not exercised end to end.
With OPENCODE_BROWSER_PACKAGE set from a source checkout, install reported "(from source)" and wrote a bun host wrapper for the installed runtime. A package spec now always means a real runtime install run with node.
Verified: cli typecheck; installing a packed 0.0.2 on this machine wrote a node host wrapper and MCP entry pointing at the runtime.
The extension's relay link now talks to OpenCode Browser's relay
(ws://127.0.0.1:19988, protocol 2) and nothing in the extension refers to
Browser Control:
- Renamed browser-control.ts / src/browser-control / browser-control.tsx to
agent-relay.ts / src/agent-relay / agents.tsx; panel, welcome tab, page
pill and card, badges, and the toolbar menu ("Let agents use this tab")
speak of agents. Storage keys are agentRelayPort/agentRelayProfile.
- Synced with upstream's extension at 8c80ac2: removes other extensions'
frames and password-manager overlays (1Password closed shadow hosts,
LastPass) while attached or running, re-attaches after a target_closed
detach, retries CDP calls that hit an extension frame or a lost debugger,
falls back to tabs.update for Page.navigate, names tab groups after the
agent session, and ports the offscreen recording cleanup. profile.rename
is gone (the relay no longer sends it).
- The "rejected" status is removed (our relay accepts our IDs);
"incompatible" now says to run `npx opencode-browser-cli install`.
- Reliability: reconnects back off exponentially (0.5s to 15s, +/-25%
jitter) with a 10s connect timeout, listeners register once per worker,
and per-connection timers are cleared on close.
- Logging: a 500-entry relay event log (connects, close codes, backoff,
slow or failed commands) in memory and chrome.storage.session, with Copy
diagnostics in the agents menu, the problem notice, and the welcome tab.
- Agent guidance points at browser.* for the user's tabs and describes the
opencode-browser MCP server as part of the same product.
Verified: typecheck, build, lint, and no "browser control"/19989 matches.
Headless Chrome for Testing against an isolated relay: status connected,
execute returned example.com's title, a handoff completed from the page's
Continue, a default-mode recording wrote a 2.6 MB webm, "Let agents use this
tab" attached a user tab, password-manager overlays were removed (synthetic
elements), and the link reconnected about 3s after a relay restart. Light
and dark screenshots checked. The target_closed re-attach path was not
exercised.
OpenCode Browser no longer depends on the separate Browser Control product.
Its relay, CLI, MCP server, and agent guide (anomalyco/browser-control
8c80ac2, MIT, Anomaly) now live in packages/browser-extension/cli and ship
as the opencode-browser-cli npm package:
- Renamed throughout: `opencode-browser` command and MCP server,
OPENCODE_BROWSER_* environment, opencode-browser skill, injected page ids.
- Its own port, 19988, so a Browser Control relay on 19989 can't hold it,
and it accepts only OpenCode Browser's store and unpacked extension IDs
(the path-hashed bundled-extension origin is gone).
- All files under one data root (src/paths.ts: ~/.local/share/
opencode-browser, %LOCALAPPDATA% on Windows, OPENCODE_BROWSER_HOME):
runtime, logs, relay catalogs and lifecycle, sessions, secrets.
- One entry (src/main.ts, bundled to dist/cli.mjs with npm dependencies
external): setup commands (install, extension, uninstall, host) go to
setup.ts, everything else to the relay CLI; `status` prints setup state
first. The managed relay respawns the same entry.
- install now installs this exact version into <data root>/runtime with
npm (OPENCODE_BROWSER_PACKAGE overrides the spec), points the native host
and a new "opencode-browser" MCP entry at it, and warns about leftover
browser-control MCP entries instead of configuring them. uninstall also
removes the MCP entry and the data root.
- Logging: relay.log is always on (relay ready, extension connected/
rejected/closed with codes, every HTTP request with status and ms except
status/version polls, faults) and rotates to relay.log.1 instead of
truncating; host.log records each native messaging request with timing.
- cli/ has its own package.json, bun.lock, and tsconfig so its pinned
dependencies (effect 4.0.1, playwright-core 1.63.0, ...) stay out of the
monorepo lockfile. The release workflow installs, typechecks, builds, and
smoke tests it.
Verified: cli typecheck; browser-control's own test suite run against the
port outside the repo: 880/888 pass, the 8 failures assert the removed
layout (dist/mcp.js, path-hashed origins, extension/dist). From an npm pack
tarball in a temp HOME: install (5.7s), the native host answered service and
plugin requests, the MCP server listed 25 tools over stdio, and `execute`
started a managed relay, drove headless Chrome with the extension to
example.com, and returned the title; status and relay.log looked right.
cli/package.json is now the one release version: the store zip and the
extension bundled in the npm helper are stamped with it. Bumped to 0.0.2
(0.0.1 is on npm and in the store draft).
.github/workflows/publish-browser-extension.yml runs on a
browser-extension-v<version> tag (checked against cli/package.json) or by
hand: typecheck, build the helper and the store zip, smoke test the helper,
upload the zip as an artifact, then publish opencode-browser-cli to npm with
provenance (trusted publishing, or OPENCODE_BROWSER_NPM_TOKEN; skipped when the
version exists) and attach the zip to a GitHub release. Manual runs only
build unless `publish` is checked.
Verified: actionlint (only the repo's custom runner label is unknown to it);
locally, cli build + `bun run package` produced version 0.0.2 in both the zip
(no key) and the bundled extension, the built helper ran, and `npm pack
--dry-run` packs 0.0.2.
The opencode-browser-cli npm package (packages/browser-extension/cli) does
everything `opencode browser install|status|uninstall|host` did and works with
any opencode release, so the CLI no longer needs to ship it. Removed the
command, its handlers, and services/browser-extension.ts; commands.ts and
index.ts match the branch base again, so this PR no longer changes
packages/cli. The README, plugin header, and host comment describe the npx
helper instead.
Verified: cli and extension typecheck, root lint; `git diff <merge-base> --
packages/cli` is empty.
Every switch of the active tab in the panel's window rewrote the session's
"opencode-browser.page" context (1s debounce), so a session showed a stream
of "Instructions updated" rows while the user browsed, including while the
agent was working or the user chatted from the TUI.
The background no longer pushes page context. The composer sends it with
`prepare` right before a prompt from the side panel, and only when it
changed since the last one it sent to that session. A tab included with a
new conversation is described as shared.
Verified: typecheck, build, lint; headless panel against the live service:
the entry was written with the first prompt, unchanged after switching tabs,
and updated to the new page with the next prompt. The test session was
deleted.
The composer only sent text. Images can now be pasted, dropped, or picked with a + button; they show as removable thumbnails above the text and are sent inline as data URLs (like the desktop composer), with or without text. PNG, JPEG, GIF, and WebP up to 20 MB; attachments are kept per draft and restored if sending fails.
Verified: typecheck, build, lint; headless panel against the live service pasted an image, sent it with a prompt to a new conversation (the model answered, the timeline showed the thumbnail), then the test conversation was deleted.
Agents could only use tabs they opened or the user shared, so "can you see
this tab?" ended with instructions to click Share tab. The plugin adds
browser.tabs.request({ query?, reason? }) next to the built-in browser.tabs
tools: it finds the user's current tab (or the most recently used open tab
whose title or URL matches the query), shows a "Share the tab you're on?"
dock in the panel with the tab's title, site, and the agent's reason, and on
Share gives the session that tab (same path as the Share tab button) and
returns { tabID, title, url }. Tabs the session already has return without
asking; browser/extension pages and a missing panel fail with guidance.
Session guidance now points agents at browser.tabs.request instead of asking
the user to click Share tab.
Verified: typecheck, build, lint; light/dark screenshots of the dock with an
injected request. The relayed tool call itself was not exercised end to end
(needs the plugin loaded in the live service).
While a conversation is open, its title in the header is a menu of recent conversations across every directory, like the directory picker on a new conversation. The directory line under the title is gone. History is global too and only shows when no conversation is open (the picker replaces it), so the list is fetched once.
Verified: typecheck, build, lint; headless panel against the live service opened a conversation from History, the title menu listed sessions from several directories, and picking one switched to it.
`opencode browser install` only exists on this branch, so nobody on a
released opencode can connect the extension. packages/browser-extension/cli
is a standalone npm package (opencode-browser-cli) that does the same setup
without changing opencode:
- install: copies itself to ~/.local/share/opencode-browser (npx caches can
be cleared), registers the ai.opencode.browser host for every installed
Chromium browser (macOS/Linux manifests, Windows registry), adds the
Browser Control MCP to opencode's global config (jsonc edits keep comments),
starts the service, and copies the bundled unpacked extension to a
permanent folder for Load unpacked.
- host: answers the extension with the URL and password from the user's
installed `opencode service start` / `service get password`, and installs
the extension's plugin.
- status, extension (opens the folder), uninstall.
The bundle includes jsonc-parser and the extension build (manifest key kept
so the unpacked ID matches the helper). The panel, welcome tab, store copy,
and privacy policy now point at `npx opencode-browser-cli install`. The
opencode CLI command is unchanged.
Verified: lint, extension typecheck; `npm pack` then npx from the tarball in
a temp HOME/XDG registered Helium, kept a commented opencode.json and added
the MCP entry, started the service; the wrapper answered service (URL +
password) and plugin (written) messages over native messaging; status and
uninstall worked.
- `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).
- welcome.html: first-run checklist with live status for the opencode
connection (copyable `opencode browser install`, auto re-check), site
scripts, Browser Control (offline reads as idle; conflict/rejected/
incompatible get fixes), and opening the side panel (button, shortcut, pin
hint). It uses its own watch-only port, so it never answers approvals.
- Panel setup screens share the welcome page's copy and components
(onboarding.tsx); manual server entry is a disclosure.
- Panel Browser Control: header menu while connected or holding tabs
(working/waiting dot, tab list, "Let Browser Control use this tab"), a
"Your turn" dock with Show tab and Continue, and a dismissible fix-it strip.
- Page pill and handoff card restyled for light/dark with system fonts only
(pages' own "Inter" made them render in italics).
- Relay retries no longer flip the status to "connecting" each attempt, which
made the conflict/rejected notices flicker; it still shows after a live
connection drops.
Verified: typecheck, build, lint; 62 light/dark screenshots of the welcome
page, panel setup and Browser Control states, and page pill/card, including a
real relay on port 19990 where Continue in the panel completed a handoff and
"Let Browser Control use this tab" attached a user tab.
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