How it works
- You save the login in the app’s Vault (Website Login) or with
POST /v1/logins. It is encrypted and only ever shown masked (to***h). - You pick it on the skill: in the skill’s settings, This skill signs in with…, or with
PATCH /v1/skills/{slug}. You confirm once; later runs need no prompt. - A run checks the start page. If your browser profile is already signed in, nothing else happens — the run just reads the page. That is the usual case after the first run.
- If the site asks for a login, the run signs in once on the same browser, then reads the page as normal.
- If it still cannot get in, the run stops and tells you why in
needs_user(below). It never retries in a loop.
What stays private
Your password, authenticator seed and sign-in codes:- never reach the AI model that drives the browser (it sees only placeholders such as
vault_password; the real value is typed at the keyboard, on the login site only), - are never written to logs, run results, rows, traces, webhooks or MCP results,
- are never recorded while the run signs in (the network recording pauses for that step),
- are never shared with your workspace. A login is personal.
logins:use, or anyone running a public copy of the skill gets needs_user.kind = "no_login" instead. A copied skill never carries your login.
Two-step sign-in
When a run cannot sign in
The run fails withtriage_kind: "login_failed" (or "logged_out" when the skill has no login to use) and a needs_user object:
You also get an inbox note, and the assistant tells you with a link to the Vault. It never asks for your password in chat.
API keys
Two key scopes control logins (see API keys):logins:write— save, change and delete logins, and pick a skill’s login.logins:use— run skills that sign in, and hand a run a code. A key without it still runs the skill, but never signs in.

