sz-chrome-remote-extension.git/mcp, branch masterpi-chrome, patched to drive a signed-in browser on another host through a broker, with an MCP server
https://git.soarez.net/sz/sz-chrome-remote-extension.git/atom?h=master2026-10-15T22:11:41+00:00mcp: pi-chrome-mcp joins the fork as sz-chrome-remote-extension, loading the fork's own extension2026-10-15T22:11:41+00:00Igor Soarezigor@soarez.org2026-10-15T22:11:41+00:00urn:sha1:2a3854c2e246d38636779c2c8dea7cd368f0fe4bpi-chrome 0.15.57: stand in for pi-tui, collect the primer from prompt sections2026-10-15T05:49:35+00:00Igor Soarezigor@soarez.org2026-10-15T05:49:35+00:00urn:sha1:cc86d6114291305fcea1ed8b0904c8be0e633767pi: native MCP instead of pi-mcp-adapter2026-10-02T03:31:21+00:00Igor Soarezigor@soarez.org2026-10-02T03:31:21+00:00urn:sha1:50c251e082b8122bfd1a6e80427d0dc19fa4f246
pi 0.99+ ships MCP as a built-in, and the adapter suppresses it. The gate moves
from the adapter's approval event, which the built-in never emits, to pi's own
tool_call hook on mcp__<server>__*, which every call passes through, codemode
included. approveTools went with the adapter, so nothing backs the gate up: a
decision it cannot reach now denies rather than throws. server.mjs also treats
a client named plain "pi" as pi, which is how the built-in introduces itself.
From change request 562974, filed from the work laptop.
ship the pi side we actually run, not a different arrangement2026-09-25T13:42:26+00:00Igor Soarezigor@soarez.org2026-09-25T13:42:26+00:00urn:sha1:66dcc84d51bed88cbfb608b9dc6800a8edd32b3c
The README told pi users to install pi-chrome directly and run /chrome
authorize every session. That is not how this is used: pi reaches the same MCP
server through pi-mcp-adapter, with pi's own pi-chrome switched off, which is
why nobody types /chrome authorize.
pi/browser-gate.ts is that setup's missing piece, generalised from the one in
use: it answers pi-mcp-adapter's approval broker for one server, asking once per
session instead of once per call (the adapter's own grant only covers identical
arguments, so for a browser it asks nearly every time). /browser authorize,
/browser revoke, and PI_BROWSER_AUTHORIZE for headless runs. approveTools stays
on in mcp.json as the backstop if the gate does not load.
The README now leads with that: install the adapter, register the server in
mcp.json, copy the gate. Installing pi-chrome in pi is kept as the alternative,
with what it costs - two definitions of the browser, /chrome authorize per
session, and the trap of loading the extension twice.
Tested on an isolated pi config against a stand-in browser: with
PI_BROWSER_AUTHORIZE the call reaches the browser, without it the gate denies it.