The extension reloads itself when its files on disk change (#1711)

[suleimansh]

Closes #1711.

Every change to the unpacked extension needed a click on chrome://extensions before Chrome re-read its files (#1703, #1709, #1710 each went through that click). Now the extension reloads itself: the service worker takes a fingerprint of the extension's own files when it starts and again every beat (30 s), and calls chrome.runtime.reload() when any of them changed on disk — never while a cycle is running, and recorded as the last cycle's outcome naming the changed files. The Driver tab's content script is orphaned by the reload as by a manual one, and the next cycle's page load replaces it.

The spike, measured 2026-08-26 in Chrome for Testing 150 with a throwaway extension (unattended, no click):

• fetch(chrome.runtime.getURL('probe.js')) from the worker returns the current disk file, same worker, plain fetch — no cache to defeat. Option 1 from the issue, as recommended.
• chrome.runtime.reload() from the worker boots a new worker on the edited files (verified by the new worker's baseline hash being the edited file's).
• One thing found on the way: with developer mode switched off on chrome://extensions, Chrome (137+) disables an unpacked extension on reload — DISABLE_UNSUPPORTED_DEVELOPER_EXTENSION — instead of reloading it, and only a click there brings it back. Developer mode is on for anyone who loaded the extension unpacked; the README now says to leave it on. (A --load-extension command-line install is disabled the same way regardless, so the daemon-owned Chrome for Testing of Spike: Is it possible to make the extension headless? #1332 will need the CDP Extensions.loadUnpacked install plus developer mode on for this to work there.)

What changed

• fingerprint.js (new): the watched files — every file Chrome loads for the extension: manifest.json, background.js and what it imports, content.js, options.html and options.js — hashed (FNV-1a) and compared; a file that cannot be read fails the fingerprint rather than counting as a change, so a transient read failure (a file mid-write, a checkout mid-switch) cannot reload in a loop.
• background.js: the alarm now runs a beat — the file check, then the cycle. A beat landing on a running cycle does nothing; the next one checks again. The reload is noted as the last cycle's outcome (reloading the extension: content.js changed on disk).
• check.mjs: two cases, written red first and break-checked three ways (an always-empty comparison, an unreadable file counted as a change, a file dropped from the watched list — each turned the right case red): the watched list equals what the manifest, importScripts and the options page load — nothing missing, nothing extra — and unchanged/edited/unreadable behave as above.
• Specs: fingerprint.SPEC.md (new), background.SPEC.md, the extension SPEC.md, check.SPEC.md; FEATURES-SPEC.md gets the feature; the README's "reload the extension on chrome://extensions" paragraph is rewritten.

Not covered here: the user's own claude.ai tabs still run the old content script until they reload — as after a manual reload; only the Driver tab is the extension's to reload.

Dogfood: one last manual reload to get this worker running, then an edit to a comment in content.js and the Driver's page loaded on /code self-report arriving with no click — posted below when done.

🤖 automated · Fable 5, effort high

[suleimansh]

Dogfood, on the real extension in Suleiman's Chrome, after one last manual reload (the one that put this branch's worker in place). Every timestamp below is the daemon's own (onBridgeStatus), UTC; nobody touched chrome://extensions after the reload.

Edit 1 — a comment in content.js, 02:16:09. The next beat saw it and reloaded the extension:

• 02:16:32 /_bridge/hello — rows 0, no transcript rows found: a fresh content script in the Driver tab, loaded by the new worker's first cycle (its page refresh is due at once after a worker start)
• 02:16:36 /_bridge/hello — rows 10 (human,marker,assistant), turns 6, sent 6 of 6 turn(s): the fresh script re-mirrors the whole session (the old one was sending increments, sent 1 of 1)
• 02:17:58 /_bridge/hello — page loaded on /code

That alone does not tell a reloaded extension from a reloaded page — the worker reloads the Driver page once a minute anyway — so:

Edit 2 — the hello note itself, 02:19:08: page loaded on ${location.pathname} → page loaded on ${location.pathname} [self-reloaded #1711], on disk only.

• 02:19:31 / 02:19:35 — same fresh-script pair as above (the reload)
• 02:20:29 /_bridge/hello — page loaded on /code [self-reloaded #1711]

A string that existed only on disk reached the daemon 81 seconds after it was written: one beat (≤30 s) to notice and reload, then the Driver's next page load. Both edits are reverted; the revert is itself a third reload, which is the feature working as intended.

🤖 automated · Fable 5, effort high