G10hdz/Opencode-chrome

opencode-chrome lets opencode use your real Chrome: the
one already logged into Gmail, your dashboards, your staging site. Ask in the
terminal, watch it happen in your browser. An unofficial, community-built
bridge in the spirit of Claude in Chrome / Codex in Chrome.
> **Unofficial.** Not affiliated with or endorsed by the opencode project.
> BYOK: your model keys stay in your opencode config. This bridge collects
> nothing and talks only to localhost.
What it looks like
It works because it drives *your* browser session, so anything you can see
while logged in, the agent can see too.
How it works
A tiny local bridge (npx opencode-chrome, an MCP server plus a WebSocket on
127.0.0.1:19223) and an MV3 extension that connects to it and drives only the
tabs you attach from the toolbar, using the Chrome DevTools Protocol. An
attachment is limited to the tab's current origin. No backend, no accounts,
no analytics.
Requirements
- Node 18 or newer
- Google Chrome (or Chromium) 116 or newer
- opencode (or any MCP client that launches a local stdio server)
Install
**1. Extension:** download the repo (or the latest
release), open chrome://extensions, enable Developer
mode, "Load unpacked", select the extension/ folder. The toolbar badge
shows off until the token is configured and the bridge is running.
**2. Bridge:** add to your opencode config (opencode.json):
**3. Pair the token:** the bridge generates a token at
~/.config/opencode-chrome/token (or prints it to stderr and copies it to
your clipboard at startup; set OPENCODE_CHROME_TOKEN to use your own).
Paste it into the extension's options page (right-click the toolbar icon →
Options); it shows a live connection status and reconnects the moment you
save. Connections without this token are refused, so other local processes
can't drive your browser.
**4. Attach a tab:** restart opencode, open the page you want to share, and
click the extension icon. Its badge shows on for attached tabs. Cross-origin
navigation detaches the tab by default; for legitimate flows (SSO redirects)
list the extra origins in ~/.config/opencode-chrome/policy.json:
The bridge pushes the allowlist to the extension on connect (env override:
OPENCODE_CHROME_POLICY). Entries apply per attached origin and are not
symmetric; with no file the policy is strict exact-origin.
The same command works from another local MCP client. How many sessions run at once is set in the extension options, under Sesiones. It stays at one unless you change it.
Site adapters
Declarative per-origin recipes live in ~/.config/opencode-chrome/adapters/
(env override: OPENCODE_CHROME_ADAPTERS). list_recipes enumerates them;
run_recipe(name, params?) executes one on an attached tab. The adapter's
origin must be inside the attachment's reach — exact match or allowlisted,
same rule as SSO redirects and OOPIF frames.
Steps: navigate, wait_for (+ optional timeout), init_script, eval,
columns. init_script registers JS on new documents for the duration of the
recipe only (auth/session setup), then it is removed.
{{key}} placeholders come from params; inside eval each placeholder is
substituted as a JSON-encoded literal (write search({{q}}), no quotes) so a
param value can never break out of the script's context. The eval JS lives
only in files you install — there is no free-form eval tool. See
examples/adapters/hackernews.json.
Tools
| Tool | What it does |
|---|---|
| browser_status | bridge connection and attached tabs |
| list_tabs | attached tabs with id, title, url |
| new_tab(url?, background?) | open a tab (active unless background:true) |
| close_tab(id) / activate_tab(id) | tab management |
| navigate(url?, action?, ignore_cache?, handle_before_unload?, tabId?) | go to a URL or action back/forward/reload; waits for load; handle_before_unload auto-answers that dialog |
| snapshot(tabId?) | accessibility-style text tree with [ref] per interactive element; selector, interactive_only, in_viewport_only, max_chars, frame scope it; sensitive fields are redacted |