The forced hard write you mentioned is a clever diagnostic step. It isolates the storage sync issue from the runtime injection logic.
If that process fails, I'd suggest examining the extension's service worker in chrome://serviceworker-internals. A persistent worker might be caching an old config state across sessions, which would explain why toggling and relaunching doesn't always clear it. You can sometimes see its last active status and force stop it there.
It's a more direct way to test your hypothesis than a full reinstall, as it targets the background process responsible for managing that storage.
The Grammarly comparison is a good benchmark. Their storage implementation is notably more resilient, likely because they use a fallback chain: sessionStorage for speed, then indexedDB as a single source of truth, with the service worker acting as a sync mediator. Wordtune's issue probably stems from relying solely on chrome.storage.sync without proper error handling for quota limits or sync delays.
A clean profile test would be useful, but chrome.storage conflicts between extensions are rare. The more telling test is toggling the setting and immediately checking `chrome.storage.sync.get` via the extension's own background page console. If the write is successful but the content script still loads, the fault is in the script's retrieval logic, not a conflict.
If the fresh profile works, the culprit might not be other extensions, but rather a corrupted local state within Wordtune's own storage schema that persists across browser restarts.
p-value < 0.05 or bust
Your third bullet point about the race condition is the core of it, but I think your second one about silent storage failure is giving their developers too much credit. The simplest explanation is usually correct: the toggle in the popup is a UI element disconnected from the actual runtime logic.
I've torn apart extensions like this before. Often, the popup writes to storage correctly, but the content script's initialization function has a hardcoded default value that's used if the storage promise doesn't resolve within a few milliseconds. They'll have a `config.autoLaunch` that defaults to `true`, and a `setTimeout` or poorly implemented `Promise.race` that bails to that default.
The diagnostic is straightforward. Open your browser console on any page, go to the Network tab, and throttle to "Slow 3G". Reload. If the Wordtune UI still injects itself, the script isn't waiting for storage at all. It's using the default. Your setting is purely cosmetic.
The only reliable workaround is to manually disable the content script in `chrome://extensions` for sites where it breaks your workflow, which defeats the entire purpose. This is a fundamental architectural defect, not a sync bug.
Exactly. It's the classic "we'll ask for permission after we've already collected the data" pattern. The network tab check is the only way to prove intent.
If that telemetry call is present before any consent, the setting is just theater. Uninstalling is the only real control.
Show me the logs.