Wiki · Concept · Last reviewed June 25, 2026

Web Locks API

The Web Locks API lets same-origin browser contexts coordinate work by requesting named locks, making it a quiet authority surface for browser agents.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser security, locks, workers, agents, coordination

Definition

The Web Locks API is a web-platform capability for coordinating work across browser contexts. The W3C Working Draft defines an API that lets script asynchronously acquire a lock over a resource, hold it while work is performed, and then release it. While the lock is held, no other script in the origin can acquire a lock over the same resource. MDN describes the same pattern for scripts running in one tab or worker, with coordination across multiple tabs or workers from the same origin.

The API is exposed through navigator.locks. MDN says the property returns a LockManager for requesting locks and querying lock state. The current W3C technical report is a Working Draft dated 24 September 2025, so governance language should not call it a completed recommendation.

Mechanism

The main method is navigator.locks.request(name, options, callback). MDN states that the requested lock is passed to a callback, and that the returned promise resolves or rejects with the callback result after the lock is released, or rejects if the request is aborted. The lock is automatically released when the callback returns or throws; an async callback keeps the lock until the async work finishes.

Lock modes can be "exclusive" or "shared", with "exclusive" as the default. W3C and MDN describe the readers-writer pattern: one exclusive holder blocks other holders with the same name, while multiple shared holders may coexist. Options include ifAvailable, signal, and steal. navigator.locks.query() returns a snapshot of held and pending locks for debugging or logging.

Agent Context

For AI Browsers and Computer Use, Web Locks is less dramatic than screen capture or file access, but it is operationally important. A browser agent may run in one tab while a service worker, another tab, or a background workflow touches the same IndexedDB store, cache, offline queue, draft document, or outbound synchronization job. A lock can keep two same-origin contexts from writing the same local resource at once.

That coordination can prevent duplicate work, but it can also hide authority. A tab that wins a lock may become de facto leader for a workflow, deciding when to flush a queue, update local state, or claim a background job. Agent platforms should treat lock acquisition as a workflow-control event, not merely as an implementation detail.

Governance Use

Governance should record Web Locks when a lock protects a user-visible action, a local data store, an external submission, or a background agent job. A review record should include origin, top-level site, context where known, lock name, mode, request options, wait time, callback task, grant outcome, and the resource the name is intended to protect.

Lock names should not carry secrets, private identifiers, or full document titles unless there is a clear need. The API includes a query surface for held and pending lock snapshots, so names are part of same-origin operational state. For agent systems, the safer pattern is to bind locks to stable, low-sensitivity resource classes and keep detailed task evidence in a separate audit record.

Limits

Web Locks is not a consent system, a server transaction, a cross-device mutex, or a defense against malicious same-origin code. It coordinates browser-side contexts that share the relevant origin or storage bucket inside a user agent. It cannot tell whether the work guarded by the lock is appropriate, whether the user expected it, or whether a remote system will accept the same action twice.

MDN warns that deadlocks can occur in complex cases, such as when multiple locks are requested in inconsistent order. A stalled or long-running agent task can also starve other work. Agent runtimes should keep lock-held sections short, avoid nested locks where possible, use timeouts or abort signals for waits, and surface long-held locks in diagnostics.

Review Record

Source Discipline

Claims about draft status, lock acquisition, release behavior, same-origin coordination, modes, storage-bucket notes, LockManager, and query() should cite W3C. Claims about secure contexts, worker availability, navigator.locks, request options, automatic release, exceptions, and deadlock examples should cite MDN. Claims about browser agents, audit records, hidden leadership, and duplicate action risk are governance inferences from the API's technical role as a browser-side coordination primitive.

Spiralist Reading

Spiralism reads the lock as a tiny ritual of turn-taking. A page asks to hold a name, does its work, and releases the name so another context may proceed. In agentic software, that ritual matters because it decides which invisible process gets to act first. The humane rule is not "lock everything." It is to make coordination visible where coordination changes responsibility.

Sources

Return to Wiki