Skip to main content

Overview

All commands run against the active user (naive use <id>, or NAIVE_ACTIVE_USER_ID) or the API key’s default user. naive browser declares no --user flag — passing one is an invalid_input error. See use.

Sessions

session create options

Drive a session

act and navigate send a stable Idempotency-Key automatically so a retried logical step never double-submits. An act instruction carrying a secret-shaped value (API key, JWT, card number, any random-looking 20+ character token) is refused with 403 forbidden — on every session, --allow-writes or not — and a refused call is not billed; rewording does not get past it, because the check reads the value rather than the topic. A second, advisory check refuses instructions that name a password, 2FA/OTP code, CVV, PIN, SSN or API key as the thing being entered — a speed bump, not a guarantee. Naming a surface is allowed ("…into the Name field in the Create API key dialog"). Use naive browser signup / login, which fill the value server-side. extract reads the page’s accessibility tree (visible text), which does not include link href attributes or the page URL — so it can’t return a real URL. Use instead:
  • naive browser links <id> — a direct DOM read returning { url, links: [{ text, href }] }. Filter with --contains <text> (matches href or text) and cap with --limit <n> (default 300, max 1000).
  • the url field in the output of act / navigate — the page URL after the step, i.e. where a click navigated (including SPA routes with opaque path tokens).
links is read-only; on a saved-login (context-backed) session it is capability-gated (--allow-extract) and redacted, just like extract.

Autonomous signup & login

Options (both)

signup may require human approval depending on the user’s Account Kit. When gated it returns status: "pending_approval" and runs only after naive approvals approve <id>. The generated password is stored in the user’s vault under login:<service> and never printed. The 8.5 credits in the table above are charged only for a sign-up that completed. Success is decided by the page having left the registration form, not by the submit click landing — a combined auth page renders sign-in by default, and the click used to succeed on the wrong button. A sign-up that does not complete fails with 502 provider_error and reason: "no_navigation_after_submit", is not charged the 8.5 (the session’s browser-time floor still applies), and leaves the vault entry pending. naive browser login reads it regardless of status, so an account that does exist is still reachable.

Output

Saved logins

context grant and revoke are human-only (use ≠ destroy). The CLI authenticates with an agent key, so grants are normally created from the dashboard. An agent can use a granted saved login but can never create the grant or revoke a shared login.