Extension service worker

#How an extension service worker works

The worker registers listeners for events at its top level. When an event arrives, the browser starts the worker and runs the matching listener. The worker has no DOM, so it cannot change web pages directly. It works through extension APIs for tabs, storage, scripting and messaging.

State that must survive between events belongs in extension storage. The Chrome documentation describes the lifecycle and the rules for the worker.

#Why it matters for AI agents

An agent that acts across tabs needs a background component to coordinate the work. That component can stop between tasks. Anything the agent must remember across runs, such as a log or a queue of work, must be written to storage. A plain variable is not enough.

#Wield and the extension

The Wield docs describe what the extension does, not how its code is built. The extension runs each recipe in a tab of the site. It reuses a tab the user already has open, or a background tab it opened earlier. It shows the Allow window before any write.

#Related terms

• Manifest V3
• Content script
• Native messaging

#FAQ

#How long does an extension service worker stay alive?

Chrome stops idle extension service workers and starts them again when an event arrives. The Chrome documentation explains the exact rules. Do not design a tool that depends on the worker staying loaded.

#Is it the same as a web page service worker?

No. A page service worker uses the Service Worker API. It sits between a web page and the network for one origin. An extension service worker is the background script of an extension. It uses extension APIs and is not tied to one web page.