Named from the extension's own manifest by the installer, so it arrives in Downloads as something a
person can identify rather than as extension.zip.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The route I added returned 401 to an <a download>, which Chrome reports as "Try to sign in to the
site" — a plain navigation carries no Bearer token, so that advice cannot work. The platform publishes
extension/ to /plugins/browser/extension.zip instead, which is served without auth like plugin icons.
zip.ts moved to the platform: extensions are meant to be a marketplace of them, not this plugin's
private trick.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two halves of the same coupling, both left behind by this morning's extraction.
The pairing UI was Settings/IntegrationsSettings/BrowserRelay.tsx — a PLATFORM screen driving this
plugin's pairing, calling /browser/relay-token, and working only because the plugin happens to serve
that path. It is a panel here now, beside the tab list rather than buried in settings: it shows
whether the extension is connected and how many tabs it holds, which is the first thing anyone looks
at when a capture does not work, and that is not configuration you set once.
The download link pointed at public/browser-relay-extension.zip, a static file. That file was 58 lines
behind the source it claimed to be — built in August from something that predated a February commit,
never rebuilt, and serving an extension missing the multi-session recovery path that the same February
commit added. Anyone downloading it got the version that cannot recover from exactly the failure they
were about to hit.
So the archive is built from the extension directory per request. There is no second copy to fall
behind, which is the only durable fix for that class.
zip.ts is hand-rolled and stored rather than deflated. The route's own history says it used to shell
out to `zip`; this manifest's "nothing to declare" is worth more than 30 KB on a download that happens
once, and Chrome accepts stored entries. Timestamps are fixed at the format's zero so the same
directory always produces identical bytes — which is what makes the ETag meaningful and "did this
change" answerable by comparing two files. Verified by unzipping the output and diffing background.js
against the source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhasandClaude Opus 5