Wiki · Concept · Last reviewed June 25, 2026

Cookie Store API

The Cookie Store API is an asynchronous JavaScript API for reading, writing, deleting, and observing HTTP cookies from windows and service workers.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: browser API, cookies, service workers, storage, agents, privacy, audit trails

Definition

The Cookie Store API is the WHATWG standard for asynchronous access to cookies from JavaScript. MDN describes it as an asynchronous, promise-based API for managing cookies in window contexts and service workers. It is meant to replace many direct uses of document.cookie, whose string interface is synchronous, blocking, and unavailable inside service workers because it depends on the Document object.

This entry is about JavaScript access to cookies, not cookie partitioning itself. Partitioned Cookies (CHIPS) governs how some cookies are keyed across top-level sites. The Cookie Store API governs how script can get, set, delete, and observe cookies through structured asynchronous methods.

How It Works

The central interface is CookieStore. MDN lists get(), getAll(), set(), and delete() as instance methods, each returning a promise. CookieStore is reached through attributes such as window.cookieStore and ServiceWorkerGlobalScope.cookieStore; it is not constructed directly by application code.

Cookie changes can also become events. In a window, the standard describes change events on CookieStore objects with changed and deleted cookie lists. In service workers, the model is more selective: CookieStoreManager, available through ServiceWorkerRegistration.cookies, lets a service worker registration subscribe to cookie changes. Matching changes are later delivered as cookiechange events in the service worker global scope.

As reviewed for this entry on June 25, 2026, MDN marked CookieStore as Baseline 2025 and newly available since June 2025, while CookieStoreManager and service-worker cookiechange were still marked limited availability. Production claims should therefore distinguish the core asynchronous cookie methods from service-worker subscription support.

Agent Context

For browser agents, cookies are not just storage. They are session continuity, account boundaries, consent state, feature flags, fraud signals, language preferences, and sometimes tracking infrastructure. A tool-using agent that can run page scripts, operate a browser, or coordinate with service workers may indirectly change cookies even when the visible task says "log in," "open support," or "keep me signed out."

The Cookie Store API makes those changes easier to structure and observe. That is useful for debugging and offline workflows, but it also creates a cleaner surface for automation. A service worker can receive cookie-change events even when no page is open, if it has subscribed and the browser supports the feature. That moves cookie state from passive header material into event-driven workflow state.

Governance Use

Governance should treat Cookie Store operations as session-state actions. A recorder does not need every cookie value, but it should preserve enough metadata to explain important transitions: login created, session deleted, consent flag changed, account switched, partitioned state set, or service-worker subscription registered.

Agent runtimes should avoid silent cookie repair. If an agent notices a missing session cookie and recreates it, or deletes an opt-out cookie while trying to fix a page, the user-facing result may look like convenience while the governance meaning is account alteration. Cookie writes should be tied to a visible task, source origin, and human or policy authority.

Limits

The Cookie Store API is not consent management, authentication, privacy law compliance, or tracking prevention. It is a structured access API. A cookie can still carry excessive state, be set for the wrong purpose, conflict with user expectations, or interact with cross-site mechanisms such as CHIPS, Storage Access API, or Related Website Sets.

Support also matters. The core CookieStore interface and the service-worker subscription path have different availability signals on MDN. A serious implementation record should name the browser, version, context, and exact interfaces used.

Minimum Evidence Record

For agent-mediated cookie access, record the origin, top-level site where relevant, context type, method called, cookie name, path, domain, secure and same-site attributes when available, partitioned flag if present, event type, service worker registration scope, user-facing task, and whether a human approved the action. Avoid logging raw cookie values unless a security incident specifically requires protected forensic handling.

Source Discipline

Use the WHATWG Cookie Store API Standard for interface definitions and event mechanics. Use MDN for implementation-oriented summaries, secure-context notes, Baseline or limited-availability status, and developer-facing descriptions of CookieStore, CookieStoreManager, and cookiechange. Use the WHATWG GitHub repository for standard-development context, not as browser support proof.

Spiralist Reading

Spiralism reads the Cookie Store API as cookies becoming legible to modern automation. The old cookie string was opaque, awkward, and blocking. The new API is cleaner. Cleanliness is not innocence. When session memory becomes easier for agents to observe and alter, the duty to log, scope, and justify those changes becomes stronger.

Sources

Return to Wiki