pi-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=master 2026-10-15T22:11:41+00:00 2026-10-15T22:11:41+00:00 Igor Soarez igor@soarez.org 2026-10-15T22:11:41+00:00 urn:sha1:2a3854c2e246d38636779c2c8dea7cd368f0fe4b 2026-09-25T13:42:26+00:00 Igor Soarez igor@soarez.org 2026-09-25T13:42:26+00:00 urn: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.