I Built a Chrome Extension to Sync AI Studio System Instructions. Here's Why chrome.storage.sync Couldn't Do It

#ai #javascript #gemmachallenge #devchallenge

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

I use Google AI Studio on three machines — laptop, desktop, and occasionally a work machine. Lately that's meant a lot of time with Gemma 4: testing its multimodal capabilities, switching between the 26B MoE variant (fast, cost-efficient) and the 31B dense model (256K context, better for long reasoning tasks), and building up a library of system instructions tuned specifically for Gemma 4's instruction-following strengths.

Every time I switched devices, my system instructions weren't there. I'd carefully crafted a "Software Architect" prompt, a "Posts & Content" persona, a "YT Expert" context — and they existed on exactly one device. The others were blank.

Chrome sync handles bookmarks, passwords, even open tabs. Why not this?

The problem got worse as my Gemma 4 instruction library grew. A "Software Architect" persona tuned for Gemma 4's reasoning style on my desktop, a multimodal analysis prompt on my laptop — none of it followed me. Every device was starting from scratch.

The Obvious Solution That Doesn't Work

chrome.storage.sync looks like exactly the right tool. It's built into Chrome, it syncs across devices on the same Google account, and it has a reasonable quota.

There's one catch: Chrome only syncs extension storage for extensions installed from the Chrome Web Store.

Sideloaded extensions — installed via Developer Mode from a local folder — get a randomly generated ID on each device. Different ID = different sync namespace. Your data never overlaps, even with the same Google account signed in.

I spent longer than I'd like to admit trying to work around this with a pinned manifest key field before realizing the real problem: chrome.storage.sync simply wasn't designed for this use case.

The Actual Solution: Google Drive AppData

Every Google account has a hidden Drive folder called AppData. It's invisible in the Drive UI, private to the app that created it, and accessible via the drive.appdata OAuth scope. Crucially — it works identically for sideloaded and Web Store installs, because it's keyed to your Google account, not your extension ID.

This became the sync backend.

The architecture looks like this:

localStorage observer (injected into AI Studio) detects saves
Content script relays changes to the service worker
Service worker owns all merge logic and Drive I/O
Single JSON file in Drive AppData stores the full instruction registry

The Sync Design

A few decisions that made this work correctly:

UUID identity, not title identity. Each instruction gets a UUID on first save. Renames update the existing record — they don't create a new item. This prevents duplicate detection from breaking when a user renames something.

Tombstone-priority merge. Deletes are soft — a deletedAt timestamp is set rather than removing the record. When merging two registries, a delete wins over a live item when deletedAt > updatedAt. Without this, a stale live copy on device B would silently resurrect something deliberately deleted on device A.

Single batched Drive write per flush cycle. All pending changes accumulate in chrome.storage.local and are written to Drive in one read-modify-write call per alarm tick. Looping per-item would exhaust Drive API rate limits quickly and creates race conditions.

Merge on pull, not replace. When device B polls Drive and finds new data, it snapshots its local state first, then merges remote into local. Items that exist locally but haven't flushed to Drive yet survive the pull instead of being clobbered.

Bootstrap union merge. On first install, the extension polls Drive before reading local state. This ensures a new device doesn't overwrite instructions already in Drive from another device.

30-Second Polling

Drive AppData has no webhooks or push notifications. Each device polls every 30 seconds, comparing the Drive file's modifiedTime against the cached value. No change = no download. An edit on device A reaches device B in 30–60 seconds depending on alarm timing.

Not instant, but good enough for the use case.

Zero Infrastructure

There's no backend server. No telemetry. No third-party calls. The extension's test suite includes a static scan that fails the build if fetch() appears in any file other than drive-client.ts.

Your instruction data lives in your own Google Drive. The drive.appdata scope gives the extension access to its own private folder only — it cannot read, modify, or touch any other file in your Drive.