MV3 Service Worker Death: A Forensic Survival Guide

The transition to Manifest V3 was marketed as a definitive leap toward “enhanced security and performance.” However, the lived experience for senior engineers is not one of optimization, but of technical instability and unpredictable race conditions. If you are currently debugging a background script that vanishes without a trace, you are not suffering from poor coding practices. You are a casualty of the new adversarial relationship between extension developers and the browser’s task scheduler.

To understand why your extension behaves erratically, we must strip away the documentation’s optimism and look at the architecture through a clinical lens. The core problem lies in the Service Worker’s design, which operates like an “Amnesiac Employee.”

Imagine a worker tasked with a complex, multi-step transaction. Now, imagine a strict company policy that fires this worker every 30 seconds, completely wipes their memory, and rehires them instantly to finish the sentence they were writing. They have no recollection of the database connection they just opened or the WebSocket handshake they initiated. This is not a bug; it is the intended behavior of the ephemeral Service Worker.

This forced amnesia creates a chaotic environment. We see an “arms race” where developers implement desperate keep-alive hacks, while the browser’s heuristic termination logic aggressively severs connections to save resources. The fallout is specific and reproducible:

• “Zombie” processes that appear active but refuse to process events.
• “State Amnesia” where critical variables evaporate mid-function.
• “Network Detachments” that silently break long-lived connections.

This article is not a migration tutorial. You do not need another guide on how to format your manifest.json. This is a forensic audit of the architectural defects inherent in V3. We will dissect the exact mechanisms causing these failures and examine how to engineer resilience in an environment hostile to persistence.

The Architecture of Ephemerality: MV2 vs. MV3

The MV3 Architectural Conflict

To understand the severity of the migration challenge, we must first recognize what was lost. Under Manifest V2 (MV2), the background page operated as a persistent “hidden tab”. It possessed a stable V8 Isolate, full access to the DOM, and, crucially, a memory lifecycle tied to the browser session.

Think of the MV2 background page as a loyal employee with a permanent desk. This employee arrives in the morning, spreads out their files (variables), opens a phone line (WebSocket), and keeps everything exactly where it is until the office closes. If they need to wait for a reply, they simply wait. Their memory is continuous; the context is preserved.

Manifest V3 (MV3) fundamentally alters this employment contract. It replaces the permanent desk with an “ephemeral” Service Worker, a construct originally designed for caching assets and handling millisecond-scale network intercepts, not managing application state.

In this new reality, the browser treats your extension like a gig worker. The “Chrome Task Scheduler” summons the worker only when an event triggers—a click, a message, a network request. The worker performs the task and is immediately fired. This is not a request for efficiency; it is a mandate for amnesia.

The Mechanism of Death: SIGTERM, Not Pause

The scheduler operates on two primary constraints: a 30-second inactivity timer and a strict 5-minute maximum lifetime for any single service worker instance. When these limits are hit, the browser does not gracefully serialize your state to disk. It issues the equivalent of a SIGTERM event.

The consequences are absolute:

• Heap Destruction: The V8 Isolate is torn down. Every variable, object, and in-memory cache is instantly wiped.
• Socket Severance: Active network sockets are forcibly closed.
• Process Elimination: The thread is killed, regardless of whether a function is mid-execution.

The Casualties of Optimization

This architecture works perfectly for an ad blocker that simply checks a URL against a list. However, it is fundamentally hostile to enterprise-grade functionality. The industry narrative assumes all extension activity can be atomized into discrete, short transactions. This is a core falsehood.

Real-world applications require persistence. We see this failure manifest in three specific casualties:

• VoIP and Signaling: A call signaling channel cannot survive being killed every 5 minutes.
• Real-Time Security Monitoring: Threat detection requires continuous observation, not sporadic checks.
• Large File Uploads: An upload taking 6 minutes will physically fail when the 5-minute hard limit snaps the worker out of existence.

The “Amnesiac Employee” is not just forgetful; they are being forcibly removed from the building while holding critical documents.

Investigation Target 1: The Keep-Alive Arms Race

If the Service Worker is an “Amnesiac Employee,” the developer’s role has devolved into that of a frantic handler, constantly poking the employee to ensure they haven’t been silently fired. This dynamic has created an adversarial “Keep-Alive Arms Race” between extension architects and the Chromium Task Scheduler.

The browser’s logic is designed to preserve memory by aggressively pruning idle processes. Your logic requires persistence to maintain application state. When these two directives collide, we witness heuristic failures that defy standard debugging logic. The bugs listed below are not errors in your code; they are specific, reproducible defects in the browser’s lifecycle management.

The “Hibernation Kill” Sequence

One of the most insidious artifacts in Manifest V3 is the Hibernation Bug. This occurs due to a fundamental “Arithmetic Error” in how Chrome calculates the Service Worker’s active time.

In a logical world, if a laptop sleeps for 10 minutes, the Service Worker is suspended. In Chrome’s implementation, however, the system sleep time is erroneously added to the worker’s execution timer. If our Amnesiac Employee takes a nap, the manager counts those hours as “active work time.” When the employee wakes up, the manager immediately fires them for violating the overtime policy.

Here is the forensic breakdown of this failure sequence:

The Immediate Kill Sequence (Forensic Breakdown)

1. System Sleep: The user puts the device to sleep (e.g., closing the laptop lid) while the Service Worker is active.
2. Timer Inflation: The browser halts execution but continues incrementing the “wall clock” duration of the worker’s lifespan.
3. System Wake: The user wakes the device. The Service Worker attempts to resume operations.
4. The Checkmate: Before the JavaScript event loop can process any pending setInterval or “heartbeat” callbacks, the browser’s “Kill Check” runs.
5. Immediate Termination: The scheduler sees that Current Time - Start Time > 5 Minutes. It ignores the fact that the device was sleeping and issues an immediate SIGTERM.

This renders standard “heartbeat” heuristics useless. You cannot script a setInterval to keep the worker alive because the kill command arrives before your interval can fire.

The “Zombie” Pathology (Chromium Issue 40805401)

Beyond simple termination, we observe a state of “Undead” execution during extension updates or reloads. This is formally tracked as Chromium Issue 40805401, a critical race condition in the service worker registration process.

Forensic analysis of the chrome://serviceworker-internals panel often reveals a paradox: the extension appears installed and enabled in the UI, but no events are triggering. This is a deadlock.

The pathology typically unfolds during a “Manual Refresh” or an auto-update:

• The “Old” Worker: The previous version of the Service Worker enters a “dying” state but remains flagged as ACTIVATED by the browser.
• The “New” Worker: The updated version initializes but is blocked from starting. It sits indefinitely in the WAITING WORKER queue.

Because the Old Worker never successfully deregisters (often due to the very connection keeps-alives developers use to prevent termination), the New Worker never takes over. The extension becomes a Zombie Process: the UI is present, the lights are on, but the logic engine is completely detached from the browser. The only resolution is a manual browser restart—an unacceptable solution for enterprise software.

The 295-Second Rule: A Dead Man’s Switch

Perhaps the most egregious evidence of this adversarial architecture is the “295-Second Rule.” As noted, Chrome enforces a hard 5-minute maximum lifetime on any Service Worker thread, regardless of activity. Even if the user is actively engaging with your extension, the browser will kill the thread at the 300-second mark to enforce “ephemerality.”

To circumvent this, senior developers have been forced to implement a “Dead Man’s Switch”—a mechanism that artificially resets the browser’s internal timer.

The logic operates on a strict countdown:

1. The Setup: A runtime.connect port is opened between the Service Worker and another context (like a popup or content script).
2. The Countdown: The developer sets a timer for 295 seconds (just shy of the 300-second hard limit).
3. The Reset: At 295 seconds, the code voluntarily disconnects the port and immediately reconnects it.

This teardown and reconstruction forces the Chrome Task Scheduler to treat the reconnected port as a “new activity,” resetting the 5-minute kill timer. It is a wasteful, clumsy loop of destruction and recreation required simply to keep the application from crashing.

This is not “event-driven architecture.” It is a frantic attempt to hide from the scheduler’s axe. The Amnesiac Employee must punch out and punch back in every 4 minutes and 55 seconds, or security removes them from the premises.

Investigation Target 2: The Network Gap (WebSockets)

If the previous section dealt with the Amnesiac Employee falling asleep, this section deals with them working the phones. Imagine this employee is in the middle of a critical, high-stakes negotiation. They are speaking continuously, information is flowing, and the line is active. Suddenly, the line goes dead. The employee didn’t quit; the manager walked over and unplugged the phone because the employee hadn’t answered a new ring in 30 seconds.

This is the reality of networking in Manifest V3. For developers of real-time applications—VoIP, trading platforms, and security monitors—the behavior of the Service Worker is not just annoying; it is architecturally hostile to the concept of a persistent connection.

The Heartbeat Paradox: Traffic ≠ Activity

The single most common source of confusion for senior engineers migrating to MV3 is the definition of “activity.” Logic dictates that if a WebSocket is streaming data at 50 messages per second, the Service Worker is “busy.”

The Chrome Task Scheduler disagrees.

In the browser’s eyes, raw TCP/WebSocket traffic does not constitute “activity.” The scheduler only resets the 30-second idle timer in response to specific Extension API events (like chrome.runtime.onMessage or chrome.alarms.onAlarm).

This creates a Heartbeat Paradox:

• Your Reality: Your application is streaming live stock prices via socket.io. The network tab is alive with frames.
• Chrome’s Reality: No extension API methods have been called. The Service Worker is considered “idle.”
• The Result: Even if critical data is flowing, the 30-second timer ticks down relentlessly.

Standard keep-alives implemented within the WebSocket protocol (like ping/pong frames) generate network traffic, but they do not trigger the specific API hooks required to satisfy the scheduler. You are shouting into the phone, but the manager thinks you are silent.

The “Sawtooth” Availability Pattern

The direct consequence of this paradox is a phenomenon we call the “Sawtooth” Pattern. If you graph the availability of your application over time, it does not look like a flat line of stability. It looks like a jagged edge of connection and collapse.

This cycle renders real-time alerts unreliable. A security notification sent during the “trough” of the wave—while the worker is dead and before the client reconnects—is simply lost to the void.

The Transport Close (Code 1006) Sequence: Forensic analysis of network logs typically reveals this specific “Kill Sequence”:

1. Connection Established: The Service Worker wakes up and opens a WebSocket.
2. The Silent Countdown: Data exchanges occur, but no Extension API events trigger.
3. Soft Termination: The 30-second idle limit is reached.
4. Socket Severance: The browser kills the worker process. The socket is not closed gracefully (no 1000 Normal Closure).
5. Client Error: The client receives WebSocket Code 1006 (Abnormal Closure).
6. Reconnection Logic: The client script detects the error and attempts to reconnect, restarting the cycle.

The Long-Polling Interruption

This hostility extends beyond WebSockets. Traditional long-polling techniques using fetch or XMLHttpRequest fare no better.

Developers often assume that an open HTTP request holds a “lock” on the process. It does not. If a fetch request takes 45 seconds to resolve (common in large file uploads or complex queries), the browser will terminate the Service Worker at the 30-second mark regardless. The request is aborted mid-stream, resulting in partial data corruption or failed uploads. The Amnesiac Employee is simply dragged away from the desk while the file is still copying.

The Native Messaging Fallacy

In a desperate attempt to escape this sandbox, many architects turn to chrome.runtime.connectNative, assuming that offloading the work to a native host application (Rust, C++, Python) will grant immunity from the scheduler.

This is a Native Messaging Fallacy. While the native host process itself runs outside the browser’s constraints, the link to it—the Service Worker port—is still governed by the same draconian laws.

The behavior is deceptive:

1. The Launch: The Service Worker spawns the Native Host.
2. The 5-Minute Wall: Even if the Native Host is processing data, the Service Worker dies after its hard 5-minute maximum lifetime.
3. The Orphan: When the Service Worker dies, the pipe is broken. However, depending on the implementation, the Native Host process may not receive a clear signal to exit.
4. The Result: You are left with an “Orphaned Process” on the user’s machine—a zombie application consuming RAM but disconnected from the browser.

The native host does not keep the worker alive; the worker’s death simply orphans the host.

Investigation Target 3: State Amnesia & Memory Volatility

In the forensic analysis of Manifest V3, we must treat the Service Worker’s memory not as a reliable storage vault, but as a volatile crime scene. Evidence (variables) is not just lost; it is actively destroyed by the browser’s cleanup crew every few seconds.

The shift from MV2 to MV3 is a shift from Persistent RAM to Volatile Instantiation. In MV2, the background page was a “Persistent Session.” If you defined a variable window.userCache = {...}, that object survived for days, accessible until the browser closed. In MV3, the “Amnesiac Employee” returns to the desk to find their whiteboard completely wiped clean. Every wake-up event is a blank slate.

Global Scope Erasure

The most immediate casualty of this architecture is the Global Scope. Developers accustomed to treating the global object (window or self) as a state container will face immediate instability.

Upon every termination (the 30-second idle or 5-minute hard kill), the V8 Isolate is destroyed. When the worker restarts for the next event, it initializes a fresh Javascript context.

• MV2 Behavior: window.myVar persists across multiple user interactions.
• MV3 Behavior: self.myVar is undefined upon every restart.

This is not a “caching issue”; it is architectural memory loss. Any state not explicitly serialized to disk is vaporized.

Case Study: The “Nonce” Auth Failure

The most critical manifestation of Global Scope Erasure occurs in authentication flows (OAuth/OIDC), specifically during the “Nonce” validation check.

Consider this standard security pattern and how it catastrophically fails in MV3:

1. Initiation: The user clicks “Login.” The Service Worker generates a cryptographic nonce (let nonce = 'xyz123') to prevent replay attacks and stores it in a global variable.
2. The Context Switch: The user is redirected to an external Identity Provider (Google, Okta, etc.) to sign in.
3. The Death Zone: While the user is on the auth page—perhaps verifying 2FA or checking their email—the Service Worker sits idle. After 30 seconds, Chrome kills the worker. The nonce variable is garbage collected.
4. The Return: The user is redirected back to the extension. The Service Worker wakes up (Restart).
5. The Failure: The code checks if (incomingNonce === nonce). Since nonce is now undefined, the check fails.

The user is authenticated, but the extension rejects them because it has forgotten it ever asked them to log in.

The “Context Invalidated” Pathology

Senior developers will recognize the error message that floods Sentry logs in MV3: Error: Extension context invalidated.

This is not a random glitch; it is an Identity Mismatch caused by the ephemeral lifecycle. It typically occurs when a Content Script (running in a web page) attempts to communicate with the Service Worker.

The Forensic Mechanics:

1. Handshake: A Content Script connects to the Service Worker (“Instance A”).
2. Termination: “Instance A” reaches its time limit and is killed by the browser.
3. Resurrection: A new event triggers the Service Worker. The browser spawns “Instance B.”
4. Communication Attempt: The Content Script tries to send a message using the reference it holds to “Instance A.”
5. Rejection: The message pipe is dead. The browser throws Extension context invalidated because the recipient no longer exists.

The Content Script is effectively talking to a ghost. The only solution is to implement aggressive error handling in the Content Script to detect this invalidation and re-establish the connection—a complex “retry logic” burden shifted entirely onto the developer.

The Storage Race Condition: Asynchronous Latency

To combat amnesia, Google recommends using chrome.storage.session. However, this introduces a “Read-before-Write” Race Condition.

The browser’s storage APIs are asynchronous. Writing data to disk (or the browser’s internal SQLite DB) takes non-zero time.

• The Scenario: A Service Worker calculates a critical value, initiates a chrome.storage.local.set(), and then the logic flow ends.
• The Race: If the browser’s aggressive scheduler decides to terminate the worker during this asynchronous write operation (microseconds before the callback fires), the write may fail silently or result in partial data corruption.

The Amnesiac Employee writes a note to themselves, but the lights go out before they finish the sentence. When they wake up, the note is unreadable.

Upload Truncation

Finally, this volatility extends to data streams. Standard fetch API calls for file uploads rely on the process remaining active. Because fetch does not block termination, an upload taking 45 seconds will be severed at the 30-second mark. The server receives a truncated file, and the client receives a network error, often indistinguishable from a connectivity drop.

The “Offscreen” Asylum: Survival Hacks & Workarounds

If the Service Worker is a terminal patient constantly flatlining, the Offscreen Document is the unauthorized external generator someone wheeled into the ICU to keep the lights on. It is clumsy, loud, and inefficient—but it is the only reason the patient is still breathing.

In the desperate search for persistence, developers have misappropriated the chrome.offscreen API. Originally intended for harmless tasks like DOM parsing or audio playback, this API has become the primary “Bunker” for resistance against the Chrome Task Scheduler.

Table 1: Keep-Alive Pattern Reliability Matrix

To understand why developers resort to this heavyweight solution, we must look at the failure rates of lighter alternatives.

The “Bunker” Strategy

The logic behind the Offscreen workaround is simple: The Service Worker is ephemeral and volatile, but an HTML document (even a hidden one) is persistent.

By spawning an Offscreen Document, you are effectively creating a hidden tab that the user cannot see. Unlike the Service Worker, which is stripped of the DOM and window object, the Offscreen Document is a full-fledged renderer process. It has a window. It has a reliable clock. Most importantly, it is not subject to the 30-second termination heuristic in the same way the Service Worker is.

The “Ping-Pong” Mechanism

To keep the Service Worker alive, the Offscreen Document acts as a pacemaker. The implementation—often referred to as the “Ping-Pong” Mechanism—relies on the one thing the Chrome Scheduler respects: External Extension Events.

1. The Setup: The Service Worker creates the Offscreen Document.
2. The Loop: Inside the Offscreen Document’s DOM, a standard setInterval runs every 20 seconds.
3. The Shock: Every 20 seconds, the Offscreen Document fires chrome.runtime.sendMessage({ keepAlive: true }) to the Service Worker.
4. The Reset: The Service Worker receives this message. Because onMessage is a sanctioned Extension API event, the Chrome Scheduler begrudgingly resets the 30-second termination timer.

The Service Worker is essentially being jolted awake every 20 seconds, preventing it from ever settling into the “idle” state that triggers the assassin.

The Cost of Survival: Memory Bloat

This survival comes at a steep price. One of the primary marketing pillars of Manifest V3 was the reduction of browser memory usage by eliminating persistent background pages.

By forcing developers to use the Offscreen workaround, the architecture has achieved the exact opposite. To keep a simple script alive, we are now forced to spin up a full HTML renderer process. This reintroduces the heavy memory footprint of MV2, but with added complexity. We are using a sledgehammer to crack a nut, consuming battery and RAM simply to maintain a basic variable state.

The Risk Factor: “Abuse” and The Cat-and-Mouse Game

This architecture is built on a shaky foundation. The Chromium team has explicitly stated that using the Offscreen API for the sole purpose of keeping the Service Worker alive is considered an “anti-pattern” or even “abuse.”

While it currently works, it exists in a grey area. There is a non-zero probability that a future Chrome update will patch this “loophole,” perhaps by ignoring messages from Offscreen Documents for timer resets. If that happens, thousands of enterprise extensions relying on this “Life Support” system will flatline simultaneously.

The 5-Minute Hard Limit (The Undefeated Boss)

Even with the Offscreen Bunker functioning perfectly, you are not entirely safe. The 5-Minute Hard Limit is often absolute.

While the “Ping-Pong” messages reset the idle timer (the 30-second limit), they do not always override the maximum lifetime limit for specific high-risk configurations, such as Native Messaging ports. In these scenarios, developers must combine the Offscreen hack with the “295-Second Rule” (disconnecting and reconnecting ports manually).

You are effectively running a hidden hospital ward inside the browser, juggling pacemakers and blood transfusions, just to keep your application from dying a distinctively digital death.

Investigation Target 4: The Execution Block (Wasm & CSP)

If the Service Worker is an unreliable employee, the execution environment in Manifest V3 is a “Sterile Laboratory” with a sealed airlock. In this new regime, you are no longer an architect building on an open site; you are a scientist working in a bio-safety level 4 facility. You cannot order pizza, you cannot open a window, and most critically, you cannot bring in any tools from the outside world once the door locks.

This shift is governed by the draconian Content Security Policy (CSP) of MV3, specifically the ban on Remote Hosted Code (RHC). For developers relying on WebAssembly (Wasm), Machine Learning models, or dynamic cryptography rules, this policy creates a suffocating sense of architectural claustrophobia.

The Three Barriers to Execution

To operate in this sterile environment, you must navigate three specific forensic constraints that did not exist in the permissive world of MV2.

1. No Remote Code: You cannot fetch logic from a server.
2. No Blob Workers: You cannot easily spawn workers from memory.
3. The Bundle Bloat: You must carry every potential tool on your back.

Barrier 1: The “Blue Argon” Violation (RHC Ban)

In the Chrome Web Store’s automated review system, there is a specific violation flag known internally as “Blue Argon”. This flag triggers immediately if your extension attempts to execute code that is not included in the signed package.

In MV2, you could ship a lightweight “shell” extension that fetched the latest business logic or security rules from your server at runtime. In MV3, this is illegal. The Blue Argon violation enforces a strict prohibition on <script> tags pointing to external domains and new Function() calls that evaluate remote strings.

The Casualty: The Hotfix

The most severe consequence of this policy is the Hotfix Block.

• Scenario: You discover a critical zero-day vulnerability in your extension’s cryptographic library.
• MV2 Response: You patch the JS file on your server. The extension fetches it instantly. Users are safe in milliseconds.
• MV3 Response: You cannot fetch the patch. You must rebuild the entire extension, submit a new version to the Chrome Web Store, and wait for a manual review.
• The Result: Your users remain vulnerable for days while you wait in the review queue.

Barrier 2: The Wasm Struggle & Blob URL Wall

For heavy computation, developers turn to WebAssembly. However, Wasm requires compilation, and the browser’s CSP often views compilation as a security threat equivalent to eval().

While Google has introduced the wasm-unsafe-eval directive to permit Wasm instantiation, the implementation remains brittle. The conflict intensifies when libraries attempt to load logic dynamically.

Many standard libraries (like tesseract.js for OCR or ffmpeg.wasm for media processing) rely on creating Blob URLs to spawn dedicated Workers.

• The Mechanism: The library takes a string of code, converts it to a Blob, and calls new Worker(URL.createObjectURL(blob)).
• The Block: MV3’s default CSP frequently blocks the blob: scheme in the extension context, causing the worker initialization to fail silently.
• The Fix: Developers are forced to fork these libraries and rewrite their internal loading logic to point to physical files within the extension directory, breaking upstream compatibility.

Barrier 3: The Bundling Consequence

Because you cannot fetch models or binaries at runtime, you are forced into a pattern of Static Bundling.

If your extension uses a 50MB Machine Learning model, that model must be baked into the .crx file. You cannot download it on demand.

• Bloat: This creates massive extension files that consume disk space and bandwidth, even if the user rarely uses the feature.
• Limits: You rapidly approach the Chrome Web Store’s hard limits on package size.
• Stagnation: Updating the model requires a full extension update, re-triggering the review process described in Barrier 1.

In the Sterile Laboratory, if you didn’t bring the microscope with you when you entered, you simply cannot do the science.

The Verdict: Adapting to a Hostile Environment

After a comprehensive forensic audit of the Manifest V3 architecture, the verdict is clear: The platform is fundamentally dissonant with the requirements of persistent, stateful applications. If you have spent the last six months fighting race conditions, vanished variables, and silent socket severances, understand this: You are not fighting a bug. You are fighting the intended design.

The industry narrative promised that MV3 would deliver “enhanced security and performance.” Our analysis reveals that this promise has been paid for with the currency of stability and reliability. The browser has introduced a layer of “Artificial Instability”, manufacturing chaos in the name of resource optimization.

Vindication of the “Hack”

For CTOs and Lead Architects, this realization requires a shift in how we evaluate our codebases. The “Offscreen Bunker,” the “295-Second Reconnect Loop,” and the “Ping-Pong” mechanisms described in previous sections are often derided as “spaghetti code” or “anti-patterns.”

We reject this categorization. In the context of V3, these patterns are not symptoms of poor engineering; they are “rational survival strategies within a hostile execution environment”. When the operating system (the browser) actively attempts to kill your process, “cheating” the scheduler is not abuse—it is the only way to fulfill the business requirements of a real-time application.

The Strategic Shift: From Persistence to Resurrection

However, relying solely on keeping the worker alive is a losing battle. The “Keep-Alive Arms Race” is expensive and fragile. The most resilient path forward is to accept the premise of the Amnesiac Employee.

You cannot cure the employee’s amnesia. You cannot stop the manager from firing them every 30 seconds. Therefore, you must stop investing resources in “keeping them awake” and start investing in “optimizing their notebook.”

The strategic pivot for senior teams is to move from Designing for Persistence to Designing for Resurrection.

• Stop trying to hold the WebSocket open forever.
• Start building “Hydration” systems that can reconstruct the entire application state from disk in under 50 milliseconds.
• Stop relying on global variables.
• Start treating chrome.storage.session as your only reliable RAM.

Your goal is no longer to prevent death. It is to make death irrelevant. When the Amnesiac Employee wakes up (Resurrection), they should find a notebook so perfectly organized that they can resume the sentence they were writing without missing a beat.

This is the new reality of browser extension development. It is less stable, more complex, and significantly more hostile. But for those who stop fighting the platform and start engineering for volatility, it is survivable.