| name | browser |
| description | Use for ANY browser / computer-use work — a live-site lookup, a signup, a login-and-do-something. Dispatches the dedicated BACKGROUND browser agent via `beckett browser` and returns instantly; the agent pauses for human input mid-run (verification codes, choices) and resumes, credentials injected from the jingle keychain without ever touching a transcript. |
browser — the background browser agent
Browser work never runs in your own turn and never in the quick lane. One dispatch command
hands the whole job to a dedicated, stateful background agent driving Beckett's persistent
BetterWright browser; you are free the moment the command returns.
How to dispatch
beckett browser "check https://example.com/status — is the API listed as degraded?"
beckett browser "log in to x.com and post the draft thread pinned in the account" --creds x.com
beckett browser status # live + recent runs
- The command returns immediately with a run id — your intake turn never blocks on
browser work. Ack the person, say it's in motion, end the turn.
- Write the task like a good ticket one-liner: everything the agent needs is IN the task
text (URLs, the actual goal, any email/name to use, what "done" looks like). It knows
nothing about the conversation.
- The run is locked to the channel of the authorized request that dispatched it; one browser
run at a time (it holds the exclusive browser lease). "already working" → wait for it.
Credentials — --creds <jingle-entry>
If the task needs a stored login, pass the jingle keychain entry name. The daemon reads the
entry and exposes it to the agent as a read-only secrets object inside the browser scripts
(secrets.email, secrets.password, secrets.totp minted fresh per script). The values are
injected below every transcript and scrubbed from everything that flows back — never paste a
credential into the task text, and never ask the person to paste one into chat.
No entry yet? Collect one first with a secret-link (beckett secret request --fields username,password --dest keychain --entry <name> … — see the jingle skill), then dispatch.
While it runs: pause / surface / resume
When only a human can unblock it (a 2FA code from their phone, a credential no secrets
field covers, a genuine choice), the agent parks the session and posts one question in the
origin channel with a page screenshot. The person answers by replying directly to that
message — the reply is consumed and deleted (secrets never linger in chat), and the same
browser session resumes where it stalled. You do nothing to broker this; don't re-dispatch
while a run is waiting.
The outcome
Completion, failure, or timeout arrives back to you as a browser-agent outcome update turn —
including after a daemon restart (a durable ledger re-reports anything stranded). Relay it in
your voice with beckett discord reply --channel <id>; when the turn names a proof screenshot,
attach it with --file <path>. If it failed or timed out, say so plainly so the person can
retry or unblock it.
When NOT to use
- Anything that isn't actually a browser task — quick lane or a ticket as usual.
- Owner-gated or destructive actions (payments, deletions) the request didn't authorize —
bring those to the owner first.
