sz-chrome-remote-extension.git/extensions, 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-11-06T11:49:39+00:00extension: end a /chrome authorize grant with its session2026-11-06T11:49:39+00:00Igor Soarezigor@soarez.org2026-11-06T11:49:39+00:00urn:sha1:ff99a4432a3feedfac10d9514ce661a9cb95004c
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 grant2026-11-06T11:49:39+00:00Igor Soarezigor@soarez.org2026-11-06T11:49:39+00:00urn:sha1:68216dcb01c8cd5894c6e2b4914d7c619d75ab35
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.
extension: show the bridge footer only for grants given this session2026-10-26T13:42:32+00:00Igor Soarezigor@soarez.org2026-10-26T13:42:32+00:00urn:sha1:ee1ddab7f9f24adfc55a41e62efa3156a282c7a8
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.
feat(remote): drive a companion extension on another host through a broker2026-10-14T11:16:02+00:00Igor Soarezigor@soarez.org2026-10-14T11:08:17+00:00urn:sha1:7e2196bd1f046707d1930f8c3d9aa7e4cc390bd6
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.
Release 0.15.57 (#28)2026-09-29T00:24:49+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-29T00:24:49+00:00urn:sha1:1d7c4704e3b6cd2bd018de9d963e60eb23508f50Drop the full-screen tab rule for automation targets (#27)2026-09-29T00:19:57+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-29T00:19:57+00:00urn:sha1:72233686a3fb5fabc496dc301c85beaf8aec9f0b
0.15.54 opened Pi's automation target as a tab in the user's window while it
was full screen, assuming macOS would merge a new window into it as a hidden
window tab. Chrome disables automatic window tabbing (app_controller_mac.mm),
so that never happens; the hidden tabs came from the tab-group bug fixed in
0.15.56. Always prefer Pi's own window.Report hidden Pi tab in /chrome doctor (#26)2026-09-29T00:18:03+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-29T00:18:03+00:00urn:sha1:0192da77e06b6ee3d0ce04e9d43ea387372281ca
Chrome ignores clicks and typing in hidden pages. Doctor now asks the worker
whether this session's own tab is visible (automation.status includeVisibility,
which never creates or activates a tab) and reports the reason and fix when it
is hidden.Keep tab ownership across extension reloads (#25)2026-09-29T00:04:23+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-29T00:04:23+00:00urn:sha1:104d7f442e7e3596781f32d8f42df39fc1c41aa0
storage.session is wiped when the extension reloads, which it does on every
pi-chrome update, so Pi lost track of its automation window and session tabs
and left them behind. Mirror ownership to storage.local, restore it only when
the session copy is missing, re-check every restored tab (same window; adopted
tabs still in Pi's group), and drop the local copy on browser startup.Create session tab groups in the tab's own window2026-09-28T23:45:18+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-28T23:45:18+00:00urn:sha1:b33d18552599664901356ae27db0270df3cc3129
chrome.tabs.group without createProperties.windowId creates the group in the
current (user's) window and moves the tab there, so a session's automation tab
left its dedicated window and became a hidden inactive tab. Make the unit mock
match Chrome's behavior.
Release 0.15.562026-09-28T23:38:27+00:00Tianren Dongtianrendong.dtr@gmail.com2026-09-28T23:38:27+00:00urn:sha1:9e4514f020ecab9af0a8b8d36f01fc802ff5123e