sz-chrome-remote-extension.git, branch master

extension: end a /chrome authorize grant with its session

2026-11-06T11:49:39+00:00

The grant lives on globalThis so /reload keeps it, but nothing cleared it when pi replaced the session in the same process. After /new, /resume or /fork the next session started authorized and announced it in the footer. Drop the saved grant on session_shutdown for new, resume and fork. Reload keeps it. Quit leaves it alone, so a subagent quitting in the same process does not take its parent's grant with it. grant-scope.test.mjs loads the shipped module once per runtime in one shared context, the way pi keeps globalThis across reloads and switches, and checks the tools and the footer after each. It fails on 85b4988, and its /chrome authorize cases fail with only the PI_CHROME_AUTHORIZE fix.

extension: keep PI_CHROME_AUTHORIZE grants out of the persisted grant

2026-11-06T11:49:39+00:00

The env grant was saved to globalThis like a /chrome authorize grant. After a /reload or a session switch (/resume, /fork, /new) the new runtime restored it, skipped the env branch, and left envGranted false, so the footer announced a grant the user never gave. Read the variable again on each session_start instead of persisting it. A restored grant now always comes from /chrome authorize. A timed env grant restarts its countdown on each reload or switch.

broker: refuse uploads from outside the staging directory

2026-11-06T09:20:16+00:00

page.upload and a raw DOM.setFileInputFiles through cdp.call now have to name files whose real path is under /tmp/pi-chrome-uploads (PI_CHROME_UPLOAD_DIR), on the broker's host. Anyone holding the token could otherwise attach any file the user can read to a page.

extension: show the bridge footer only for grants given this session

2026-10-26T13:42:32+00:00

A standing PI_CHROME_AUTHORIZE is not session state worth a line at the bottom of every session that has it; announce only access the user granted through /chrome authorize.

mcp: pi-chrome-mcp joins the fork as sz-chrome-remote-extension, loading the fork's own extension

2026-10-15T22:11:41+00:00

pi-chrome 0.15.57: stand in for pi-tui, collect the primer from prompt sections

2026-10-15T05:49:35+00:00

pi: native MCP instead of pi-mcp-adapter

2026-10-02T03:31:21+00:00

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____*, 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 arrangement

2026-09-25T13:42:26+00:00

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.

FORK.md: what the fork changes, setup, upstream releases

2026-10-14T11:16:02+00:00

feat(remote): drive a companion extension on another host through a broker

2026-10-14T11:16:02+00:00

PI_CHROME_REMOTE=host:port sends every command to a broker/broker.mjs there, with its bearer token, instead of binding a bridge on this machine. Unset, the extension behaves as upstream. A remote session never binds or takes over a port: when the broker is unreachable the tools fail rather than drive some other browser. A pi-chrome-remote prompt section says which browser chrome_* drives and how files move to and from its host; chrome_upload_file wants absolute paths there. PI_CHROME_AUTHORIZE grants every session up front.