Tokens and login

The three shapes

A full key can do anything your account can do through the API, so treat it like a password. An upload token can only add or update manifests on the one app it names. An onboarding token exists to hand a teammate a single command that creates their app and nothing else, and it stops working after 7 days or, for the single-app scope, after its first use.

Keep credentials out of agent conversations

Use terminal login and the standard shell prompt when you do not want credential material in a conversation. The Add app wizard’s existing limited-token setup prompt deliberately includes an upload-only token; it cannot read findings. Treat that prompt as sensitive. Its upload consent names the payload and destination, and asks the agent not to echo the token. Remediation handoffs use an already configured credential.

Invalid credentials: run npx vibebeacon@latest login, remove stale --key or VIBEBEACON_API_KEY overrides, then retry. CLI errors exit 1. JSON errors contain a safe message and reconnectCommand, never the rejected credential.

Passkeys

A passkey is the strongest way into the dashboard, and the only one that cannot be phished. Your device makes a key pair, keeps the private half in its own secure storage and gives us the public half, so there is nothing in our database an attacker could steal and replay, and your browser will not release the credential to a site that only looks like ours. Add one under Settings, Security, name it after the device, and keep one per machine. A passkey sign-in also counts as a strong session, which is what the admin area asks for, so it is a second way in that does not depend on GitHub being reachable. Magic links and GitHub keep working exactly as before, and removing your last passkey locks nothing.

Device login

The easiest way to get a full key without typing one in: sign in from a terminal.

npx vibebeacon@latest login

1. The CLI asks VibeBeacon for a device code and an 8-character user code, then opens your browser to a page showing that code (or prints the URL if it cannot open one).
2. You approve it there, signed in the normal way (magic link or GitHub). Approving mints a full key named after this machine's hostname.
3. The CLI polls in the background and stores the key once you approve, or stops if you deny it or ten minutes pass.

Once stored, the CLI and the MCP server both use it automatically, so you do not pass --key or set an environment variable for everyday use.

whoami and logout

Check which account a stored credential (or --key) belongs to:

npx vibebeacon@latest whoami

Remove the stored credential from this machine:

npx vibebeacon@latest logout

Where the credential lives

The file holds the key, the API base URL if you set one, and when it was created, as plain JSON. It is written with file mode 0600 where the filesystem supports it, so only your own account can read it, but it is not encrypted at rest by an OS keychain. Nothing in the file is ever logged or printed unmasked; the CLI shows only the prefix and last four characters, for example vb_live_****a1B2.

See also

For the API endpoints behind device login and scoped tokens, see the API page. For every CLI command that uses a credential, see the CLI page.

Understand the next scan

Inventory refresh is separate from verified remediation. Keep app identity and scan scope consistent, inspect changed alert IDs and reasons, and use the real score explanation. Read scan results and agent access for pending processing, read-only findings JSON and authentication errors. Choose explicit handoff and upload permissions in Fixing an alert.