cookie-share moves login sessions between browsers through your own Worker

The gap cookie-share fills sits between a logged-in tab and a second browser

The problem starts with a specific situation: a site that keeps you signed in with a cookie, and a second device or browser where you are not signed in. The README describes the usual workarounds as scanning QR codes, copying passwords, or exporting cookies by hand, and points out that many sites do not support multi-account switching at all. That is the space cookie-share occupies. It is a Tampermonkey userscript, so it runs inside a browser you already control, and it pairs with a backend you host yourself rather than a third-party service.

The intended audience is individual users rather than teams. The project description names multi-account switching, sharing video memberships and co-renting planets as the scenarios, and the feature list calls out single-device use as the privacy-first path. The script's own words: "Send your cookies from a logged-in browser, receive them on any other device or browser with one click." There is no password involved, because the credential being moved is the session cookie itself, which means the script inherits the full risk of the session it carries. That is worth keeping in mind throughout the rest of this look.

Two storage paths sit behind the same panel, and only one of them leaves your machine

The panel has two destinations for a cookie payload, and the choice between them changes the whole shape of the deployment. Since v0.1.0 the script can store cookies locally with no backend at all, and the Cookie List is built to distinguish local records from cloud records. The README describes the local path as the one to use for personal use on a single device or when privacy is the top concern. The cloud path is for moving a session between different devices or browsers, and it requires a server the user runs.

The cloud path has two implementations, a Cloudflare Worker with a D1 database or a Node.js server, and the README marks the Worker route as the recommended one. The visible mechanism is a small set of operations: send cookies from the current tab to the server, receive cookies from the server and set them in the current tab, and delete cloud records from the same interface. Search over the Cookie List by ID or URL, plus a per-record copy button, arrived in v0.6.3. The same release added a quiet safety net: failed receives automatically restore your original cookies, so a broken transfer does not leave you logged out of the tab you were already using.

For the cloud path, a randomly generated unique ID is the addressing scheme for a share, and the user can set a custom ID instead. You send under an ID on the device that is signed in, and you enter the same ID on the device that is not. There is also an admin panel for managing all stored cookies, which sits behind a path segment on the same worker domain.

HTTPOnly support depends on your script manager, and the script now says so out loud

The most interesting claim in the feature list is the one that ordinary page JavaScript cannot make. The script reads and writes HTTPOnly cookies, which browsers deliberately hide from page scripts. Reaching them requires a privileged userscript API, and the repository's own naming makes the dependency clear: the relevant capability is GM_cookie, and a failure there is fatal to the whole product, since the session cookie is the payload.

The v0.6.3 release turned that silent failure into a visible one. According to the changelog notes in the README, if the userscript manager lacks GM_cookie support, the script shows a clear error with a link to the setup guide instead of failing silently. The README also tells you where to fix the related permission in the Tampermonkey settings screen, with a screenshot pointing at the setting.

This is a real constraint on adoption, and it is a property of your environment rather than of the project. The script assumes a userscript manager with cookie permission and a Tampermonkey-style panel. Anyone who wants to run this inside a locked-down corporate browser, or in a mobile browser with no extension support at all, is out of luck regardless of how the backend is deployed.

Deploying the Worker takes one click, then three secrets and a D1 binding

The README offers a one-click deploy path through a Cloudflare Workers deploy button, and then a local development path with Wrangler. In the hosted path you authorize Cloudflare, fill in the three environment values, and Cloudflare creates and binds the D1 database as COOKIE_DB for you. The Worker creates the required tables on its first request, so there is no manual D1 setup and no separate KV configuration.

For local work, the repository ships a Wrangler setup and a package.json with the usual scripts. Installing dependencies and authenticating to Cloudflare are the first two steps:

npm install
npx wrangler login

For local development the README says to copy .dev.vars.example to .dev.vars. If .dev.vars is missing, wrangler dev falls back to PATH_SECRET=dev and ADMIN_PASSWORD=dev-password, which is convenient for a laptop and clearly unsuitable for anything else. The package.json also exposes a migration command that applies the D1 schema to a live database:

wrangler d1 migrations apply COOKIE_DB --remote

The script side then needs two values from you, the backend address and the transport secret. The README is emphatic about the address format: do not add a trailing slash, and the example is the worker domain plus the path secret. The admin panel sits one segment further down the same path and is opened with ADMIN_PASSWORD.

Three secrets separate the panel, the transport and the admin surface

The security story rests on a small number of named values, and it is worth separating them because they protect different things.

PATH_SECRET is a path segment on the worker domain. It keeps the ordinary endpoints off the public root, and the admin panel lives under the same path with an admin suffix. The README's own example shows the shape of the URL, with the secret embedded in the path, and the instruction not to append a trailing slash.

TRANSPORT_SECRET is the encryption key for the wire. The README states that all cloud operations, which includes send, receive, the cloud list and cloud delete, use TRANSPORT_SECRET encrypted envelopes. That is the mechanism that keeps the payload opaque while it is in flight, and it is the reason the project can claim that data never touches a third-party service in the sense that no operator reads it.

ADMIN_PASSWORD guards the admin panel where all stored cookies can be reviewed and removed.

The important operational point is that these are independent values and a misconfiguration in any one of them has a different symptom. A wrong PATH_SECRET gives an unreachable address, a wrong TRANSPORT_SECRET gives failures at the encryption step, and a wrong ADMIN_PASSWORD blocks the management panel. Since the backend is yours, rotating any of them is a matter of changing configuration and redeploying rather than contacting anybody.

The v0.4.1 KV to D1 switch is a hard break, not a migration path

The clearest limitation in the project is a version break that the README treats with an explicit warning. Starting from v0.4.1 the backend uses a D1 database and is not compatible with the older KV based versions. Upgrading requires redeployment and data migration.

That means an existing deployment cannot simply be pointed at a new script release. A user who upgrades the userscript and leaves the old Worker in place gets a backend running the previous storage model, and the mismatch surfaces as transfer failures rather than as a clear upgrade message. The user has to redeploy the Worker and migrate the stored data by hand, and the migration script in package.json applies the D1 schema to a live database, which is a step with its own failure modes on a database that already holds records.

Other limits are smaller but still worth naming. The repository includes a Node.js test entry point alongside the Vitest suite, and a dry-run deploy check, so there is a test surface, but the README does not document a rollback procedure for a bad deployment. There is also no documented way to change the transport secret without invalidating the envelopes that existing clients already hold, so a rotation plan is left to the reader.

Where cookie-share is the wrong tool, and what to use instead

There are cases where a project like this is simply the wrong shape. If your goal is to distribute one login among several people on a schedule, with an audit trail and the ability to revoke a single member, a session-transfer script is a poor fit. It moves a live session token, and the shared secret is the session itself, so revocation means rotating the session on the site, not revoking a key. Sharing a single subscription account this way also puts the account at whatever risk the target site assigns to concurrent sessions.

The alternative approach for team credential distribution is a real password manager with per-person vaults and shared items, or a dedicated secrets manager that stores and rotates a credential. The difference in approach is direct: those tools distribute the credential and keep the authorization model explicit, while cookie-share distributes the proof of a login and leaves authorization in the hands of the target website. Another difference is retrieval: a manager returns the same secret to a different person, while cookie-share writes a session into a browser tab and then the browser holds it.

For a single person who wants a second profile of their own account on the same machine, the local-only mode is the right answer and no backend is needed at all. The Cookie List separates local and cloud entries, so a self-hosted deployment can start small and gain a worker later.

Editorial conclusion

cookie-share suits an engineer who wants to move one login session between a phone, a desktop and a work profile without sharing passwords, and who is willing to run a Worker with three separate secrets. It does not suit a team that needs shared, auditable credential distribution, and it does not suit anyone unwilling to hold a live session token. Before adopting, verify that your script manager exposes GM_cookie to the userscript, confirm that your Worker still uses the D1 layout introduced at v0.4.1 rather than the older KV one, and decide up front whether local-only mode is enough, because that choice removes the whole transport layer from the picture.

Frequently asked questions

Official sources

1. fangyuan99/cookie-share on GitHub
2. License: MIT
3. Project website
4. README
5. Releases