reference
Permissions
Every permission SessionCourier requests, why it needs it, and what it deliberately does not ask for.
Install-time permissions
SessionCourier requests five permissions when you install it. None of them shows a host-access warning — that part is optional and on demand (see below).
| Permission | Why it’s needed |
|---|---|
cookies | Read, create, edit and delete cookies — the core of the product |
storage | Persist your settings (like your language choice) locally |
activeTab | Know which site the current tab shows, to display its cookies |
scripting | Read and write the current tab’s localStorage, on your explicit action — see below |
sidePanel | Show the UI as a side panel instead of a popup |
That’s the minimum set this product can function with: access to the cookie store, a place to keep its own settings, awareness of the current tab so the panel opens on the right site’s cookies, and a place to put the panel.
What scripting does, precisely
Some session state lives in a page’s localStorage rather than in cookies, and unlike
cookies there is no background API that can reach it — only code running in the page
itself can. So SessionCourier runs short scripts in the tab you are looking at, in an
isolated world, and only when you ask it to.
It reads that one site’s localStorage when you start a Playwright storageState
export or a token scan; what it reads goes into the export file on your disk, or onto
the screen. It writes to that one site’s localStorage when you restore a saved
session into the page — only then, only after a confirmation that names the entries it
will set, and only by adding or replacing those entries. It never clears or deletes
storage you did not import, it checks inside the page that it really is on the site you
expected before writing, it never touches another tab, and it never runs in the
background.
There are no content scripts: nothing is injected into pages you are not actively exporting from or restoring into. Neither what it reads nor what it writes is transmitted to us or to anyone else.
Optional host access
Working with cookies for sites beyond the active tab requires host access, and SessionCourier requests it optionally and on demand: you grant access per host when you first need it, through the browser’s own permission prompt.
Every grant is revocable at any time — open chrome://extensions, pick SessionCourier, and remove hosts under the site-access settings. The extension keeps working for the hosts you’ve kept.
What is not requested
Just as telling is what the install prompt does not ask for:
- No
<all_urls>at install. SessionCourier never gets blanket access to every site; host access is opt-in, per host, revocable. - No
tabs,history, orwebRequest. It cannot enumerate your open tabs, read your browsing history, or observe your network traffic. - No remote code. Everything the extension runs ships in the reviewed store package; nothing is loaded from a server at runtime.
The same minimal-footprint approach backs the trust story: no network requests of its own, no telemetry without opt-in, and reproducible builds you can verify against the store package. Details on the main page.