Everything on this page that changes the device goes through the wizard. At a keyboard, open it; in a script, give it the same answers as flags.
The wizard shows you the state before you act on it: which account is answering, whether its credential still validates, and whether a shell variable is overriding the file. That is the reason to prefer it — the commands each do one thing and none of them tells you what the others found.
Signing in
The wizard
As flags
Without a browser
Authorization happens before any other screen: the wizard opens your browser and you approve the device there. Nothing is pasted.If the website gave you a ten-character code, pass it as an argument and the wizard uses it instead:On a device that already holds a credential, it asks whether to keep the current account or continue with the code — which is how a wrong-account install gets corrected. The same browser handoff (RFC 8628 device flow with PKCE), and nothing else: it signs this device in and installs nothing. The result is written to ~/.config/probe/config.json. These flags only sign in. Given with another action, an install flag or a website code, they are refused rather than silently dropped.Or skip the file entirely and set PROBE_TOKEN in the environment. This is the air-gapped path. You can skip signing in as a separate step. The first client.run() or probe run start with no token triggers the same browser approval inline on a TTY and persists the result. PROBE_AUTO_LOGIN=0 disables that; headless and CI keep a clean AuthError and should set PROBE_TOKEN.
Agent sign-in
A coding agent can sign you up or in to Probe for you, with no form to fill in. It uses the auth.md agent registration protocol (workos/auth.md v0.6.0). Ask your agent to set up Probe, and it follows useprobe.ai/auth.md (with useprobe.ai/agents.md).
The agent registers
It asks Probe for a registration with your email, and gives you a link and a 6-digit code.
You approve it in the browser
Open the link, sign in with Google, and type the agent’s code on research.prbe.ai/authorize. That is the only browser step.
The agent gets its token
An access token that lasts one hour, which the agent can renew for 30 days. It can do what your probe key can: read, write and delete research, publish it, and use the assistant. Like every key, it cannot manage the team or mint API keys.
New to Probe
If you have no team yet, the agent sets one up with you in the chat, then runs npx probe-research install to set up this device. You approve the device in the browser once.
Switching accounts
One machine can hold several accounts — a second team, a staging endpoint, a laptop handed on. Exactly one is active.
Switch to an account saved here lists every other account this device already holds, with its endpoint and whether it can still authenticate, and switches to the one you pick. No browser needed. Remove a saved account deletes another account’s saved credentials; the active one leaves by Sign out.See Accounts. Accounts are stored as named contexts, the way kubectl stores clusters.A context carries the endpoint, its credentials, and its anchors — the active workspace and project that scope commands like probe run start. Switching and removing are the wizard’s account screen. The same project name can exist in two tenants. Under the wrong context a list command returns the other tenant’s same-named copy instead of erroring, so a healthy project can read as wiped. Check which account is active before concluding anything is missing — the wizard’s summary block, or probe context list.
Signing out
It names what it is about to do, and it names anything it cannot do — an exported credential in your shell, for instance.
- the token this device holds is revoked, not merely deleted
- the active context is cleared
- session capture stops, so it cannot keep uploading to the account you just left
- local import history is cleared
The plugins stay installed. Removing those is Uninstall — see Diagnose and repair.
Credentials in your shell outrank the config file. PROBE_TOKEN, PROBE_MCP_TOKEN, PROBE_INGEST_TOKEN and PROBE_SERVICE_TOKEN are all checked before it, so after a sign-out the CLI still authenticates if one of those is exported. No command can unset a variable in your parent shell — the wizard and probe doctor name any they find instead.
Tokens
This one has no wizard screen: minting is deliberately a browser act, and the secret is yours to copy.
Omitting --scope requests read + write + delete. A token can never exceed the scopes your own role confers.
Minting deliberately requires a human in a browser — a leaked token must not be able to mint more tokens. token create prints a URL and a code and waits for approval.The secret is printed once and never stored. Copy it then.
The MCP credential
The MCP server is read-only and prefers a separately minted read-only token. The wizard’s sign-in mints one alongside your API credential, and Install asks for it on its own if this device signed in without one. A token the API now refuses is replaced by signing in again (probe wizard --action login).
It never falls back to PROBE_TOKEN or your sign-in’s write credential: with no read-only token, the MCP answers with an authentication error rather than reading with a key that can write. It exposes no mutation tools either way.
Resolution order
Credentials in the environment outrank the config file. In order:
Plus PROBE_BASE_URL for the endpoint and PROBE_HMAC_SECRET for optional body signing.
In CI
Skip the wizard entirely.
Mint the token with --scope read --scope write unless the job genuinely needs to delete things. For configuring a machine unattended, see Unattended use. 
