Account and sync
Signing in, what follows you to another machine, and what the session does in a second tab.
The panel, the assistant and the sync need an account. The panel asks you to sign in before it shows its tools, because your profiles, scripts and wildcards are kept under it. An account exists to move your setup between machines, and to pay for the parts that run on a server.
Signing up
Email, and a password of at least ten characters with an upper case letter, a lower case letter and a digit. The same list drives the checklist you see and the check that enforces it, so the two cannot disagree.
The username is checked for availability before you submit, then claimed by a database constraint rather than by the browser. Two people picking the same name at the same moment is decided by the unique index, which is the only thing that can decide it correctly.
Confirmation is a six-box code panel rather than a link: it verifies the address and hands back to the normal sign-in. Resending is allowed once a minute, because the auth service refuses more anyway, and a button that lies about what it did is worse than a disabled one.
Signing in
Three ways, on the site and in the panel's sign-in card alike:
- Email and password.
- Google, Microsoft or GitHub. The buttons follow the providers the auth service reports as enabled. A new account made this way stops at a username step before it is ready.
- A passkey. Add one under Account on the site. A passkey belongs to holysn.com, so the extension signs in through the site: it opens a small sign-in window there, and the site hands back a one-time code bound to that window. No token passes through the site's server.
Forgot your password? on the sign-in form sends a link that expires, and it works on any device.
On a new device signed in with a password, Pro may ask for a code before it turns on.
Log out of all devices, under Account on the site, ends every session at once. A page or panel signed in elsewhere notices on its own and shows the sign-in form. Only "this session no longer exists" signs you out, never a network failure.
Where the session lives
One key, holding the access token, the refresh token, its expiry and your user record. In the extension it lives in extension storage, which is what makes the settings page, the panel and the worker one session rather than three.
The panel runs inside the instance's page, where the instance's own scripts run too, so it gets the session without its refresh token. The refresh token stays in the extension's worker.
A token within thirty seconds of expiry is treated as already gone, everywhere.
Refreshing, and why it is guarded
The auth service rotates the refresh token on every use, and revokes the whole family if one is used twice. Two tabs refreshing at the same moment would sign you out permanently.
So in the extension the worker is the only place a session is refreshed, once for every tab, and only in the last five minutes of the stored token. The panel asks the worker for the next access token rather than refreshing it itself.
Once a minute the worker also checks that the session still exists. A session ended by Log out of all devices, revoked, or expired on the server signs the extension out, and the panel shows the sign-in card.
Signing out posts to the auth service and then clears the local bundle. The local half is what makes it a sign out, so a network failure does not leave you apparently signed in.
What follows the account
| Follows you | Stays on this machine |
|---|---|
| Profiles, saved scripts and snippets | Which profile is active |
| Custom commands | Dark mode, in-page tabs, the assistant's voice |
| Themes | The vault's derived key |
| Vault entries, as ciphertext | Recorded audio, which is never stored anywhere |
| Recorded tests | Conversation drafts before they sync |
| Conversations with the assistant | |
| How often each command is used |
Usage counting is a command name and a date. Never the argument, never the instance. It is written locally and synchronously, so the network is never in the path of a keystroke, and flushed in the background. Signed out, nothing is counted at all: there is no anonymous bucket.
A second tab
The two share one session, because they share one storage key. Conversations cross through local storage and its change event; so does a heartbeat that lets one tab say "another tab is working", and a pointer to which conversation is open, so switching in one follows in the others.
Every per-account key is suffixed with your user id, precisely so that a shared machine never shows one account the previous account's data.
A second machine
Nothing local is shared. It gets its own session, its own refresh-token family, and state arrives only through the account.
Conversations merge last-write-wins on the time the client wrote, with ties keeping the local copy. Usage accumulates from both.
What does not cross is the in-flight indicator: that is local storage only, so a second machine cannot tell that the first one is mid-answer. A multi-step run is the exception, because its state is an event log on the server: a second machine can attach to a run that started on the first and replay it from the beginning. The tool results already in that log are what stop it running a tool twice.