fix(browser): keep the IndexedDB model cache cleared after a reset

[leoisadev1]

Follow-up to #42, fixing Greptile's P1 there. clearModelCache() deletes the IndexedDB model cache, but a load that started before the reset still held the old cache. After #42 closed its connection on versionchange, the old cache reopened on its next write. That recreated the deleted database and wrote the model back, where a new cache read it, even after a reload.

An IndexedDB cache now stays empty once its database is deleted, or once a reset has run since it was created. Its reads miss and its writes are dropped. Only caches created after the reset open the database again. Another tab's reset retires this tab's cache the same way, so that tab stops caching the model until it reloads.

The IndexedDB tests now use fake-indexeddb (Apache-2.0, dev only) instead of a hand-rolled mock. They cover Greptile's P2 as well: a reset must delete stored models, and a clear that targets the wrong database now fails. The three write-back tests fail on main.

I checked the same scenarios in headless Chrome's real IndexedDB, loading the built cache.js over plain http on this machine's Tailscale address. On main, a write after a reset was readable from a new cache in all three cases: a cache that had opened before the reset, one first used after it, and a delete from another tab. With this change, none were readable. Stored models are gone after a reset, and a cache created afterward reads and writes normally.

I also ran the remover on WASM from this branch's build over the same plain-http origin, so it used IndexedDB:

• The first image processed in 57 s. The PNG has alpha from 0 to 255, with 245,444 fully transparent pixels.
• After a reload the model sat in IndexedDB: 3 files in 34 entries. A second image processed in 40 s with no model fetch.
• Esc returned to the picker, and an unreadable file showed "This image could not be opened. Try exporting it as PNG or JPG."

Not tested: WebGPU, iOS, and the Cache API path, which this change does not touch. Root lint, typecheck, test and build pass.

Created with Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
bg0-docs	Ready	Preview	Sep 29, 2026 6:39pm UTC
bg0-web	Ready	Preview	Sep 29, 2026 6:39pm UTC

[devin-ai-integration]

Devin Review found 1 potential issue.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Fixes IndexedDB cache clearing after database reset.

Do not merge until an unopened cache can no longer restore a model after another tab clears the database.

Findings

1.  Unopened cache restores deleted models ▶

Summary

The PR retires IndexedDB cache instances after a local reset or an open connection’s cross-tab version change, and adds fake-indexeddb tests. If a user clears the model cache in one tab while another tab holds an unopened cache instance, that instance can recreate the database and store a pre-reset model on its first write.

_{Reviews (1) · Last reviewed commit: "fix(browser): keep the IndexedDB model c..."}

[greptile-apps]

Comments Outside Diff

These findings could not be posted inline.

•  An unopened cache can restore a model after another tab resets IndexedDB ▶

  • Bug
    • A cache created in tab A before tab B’s reset can make its first write afterward, recreating bg0-model-cache and making the stale model readable in B. This contradicts the intended cross-tab reset protection.
  • Cause
    • At packages/browser/src/cache.ts:104-110, createdAt !== resets checks only tab A’s module-local counter. Because A had never opened IndexedDB, it had no connection to receive versionchange and set deleted when B deleted the database.
  • Fix
    • Coordinate reset state across tabs or otherwise verify that an unopened cache is still valid before its first write; a connection’s versionchange handler alone cannot cover this path.