Preserve the original cookie meaning

Session-only and persistent cookies have different lifetimes. The checkpoint retains that distinction; it does not manufacture a future expiry date to make a session-only cookie look persistent. Restoration also cannot override a website's decision to invalidate a session. The archive preserves available local state, not an entitlement to remain signed in.

How the local checkpoint works

Mac Profiles encrypts the cookie snapshot with AES-GCM and keeps its key in macOS Keychain. It restores the saved entries before navigation. Saving uses observed changes, a three-second polling fallback and the normal profile-close path. A missing key or damaged archive produces an error instead of silently replacing the saved data with an empty snapshot.

A crash still has a recovery window

A normal close waits for the save operation. An abrupt process or machine failure can lose changes after the last completed checkpoint. A three-second polling interval is not a three-second durability guarantee: collection and writing also need to complete. After a forced stop, verify the site's session before continuing a sensitive workflow.

Cookie recovery is not full-session recovery

The checkpoint covers cookies exposed by WebKit's cookie API. It does not claim a complete export of every partitioning detail, IndexedDB database, localStorage value or in-memory page state. Tab restoration is a separate feature. An open tab can be restored while the site still asks you to sign in again.

What the current checks establish

The encrypted-cookie regression suite currently passes 253 checks covering the implementation's tested cases. That count is evidence about those cases, not every website. For a pilot, test one session-only cookie and one persistent cookie on a site you control, then compare normal close, restart and interrupted execution. Keep the observed outcomes with the build and operating-system version.