Prevent Next.js client exceptions.
You deploy, and some users hit a blank screen with "Application error: a client-side exception has occurred." They refresh a few times and it clears, which makes it feel random. It is not. The usual culprit is your PWA service worker caching HTML with a Cache-First strategy. After a deploy, the old cached HTML is served from the service worker, but it references JavaScript chunk files that no longer exist because the new build renamed them. The browser asks for a chunk that is gone, the app throws, and the user sees the crash. This blueprint fixes the root cause, not the symptom.
The agent updates your service worker to stop serving stale HTML. It switches navigation requests to a Network-First strategy, so the browser always tries to fetch the current HTML (which points at the current chunks) and only falls back to cache when offline. It then bumps the CACHE_VERSION so every existing client clears its corrupted cache on the next visit, which flushes out the users already stuck in the bad state.
You watch it work in the task workspace: the agent locates your service worker, rewrites the caching logic, updates the version, and verifies the change before handing you the result. The fix lands on a branch in your repository with a pull request ready to merge.
The first pass fixes the crash. You can steer the rest with plain follow-up messages:
Each follow-up wakes the same repository and the agent continues on its own code.
Why does refreshing sometimes fix it? A refresh occasionally pulls fresh HTML, but with Cache-First the service worker often serves the stale copy again. Network-First makes fresh the default.
Will this slow the app down? No. Navigation still uses the network first, which it effectively did before the cache went stale, and assets stay cached.
Does this only apply to Vercel? No. The same stale-HTML-versus-new-chunks problem happens on any host when a service worker caches HTML too aggressively. The fix is the same.