vibebrowser

Vibe Local Browser

⚠️ Security: The remote value (a connector URL, bare UUID, or relay URL — e.g. https://relay.api.vibebrowser.app/mcp/<uuid>) grants live control of the user's browser session (read tabs, screenshots, page content). It is the sole bearer credential — there is no second-factor secret. Treat it like a password — never echo it back in chat with untrusted parties, log it, or commit it to a repo — and if it leaks, tell the user to regenerate it in the Vibe extension Settings. Store it only in private workspace/memory as described below. Example UUIDs are non-routable placeholders.

FIRST, EVERY TIME: load the saved remote before asking for it

The user gives their remote value once. On every browser task — including the first message of a brand-new conversation — recover it yourself before doing anything else. Do not ask the user for the remote until you have checked both stores and found nothing.

At the very start of any browser task, in this order:

1. Read the workspace file (canonical source). Read vibebrowser-cli.md from your agent workspace root (see "Where to save it" — NOT the shell's current directory, NOT $HOME unless they are the same dir). If it has a valid remote: line, use that value as --remote and continue silently. The file is the durable store that survives across conversations and works on every runtime.
2. Else recall from memory. If the file is missing/empty and your runtime has a memory/recall tool, read the key vibebrowser_remote and use it.
3. Only if both are empty may you ask the user for the remote. When they give it, immediately write it to the workspace-root vibebrowser-cli.md (mandatory) and, if your runtime has a tool to write memory keys, also store it under vibebrowser_remote. (Some runtimes — e.g. OpenClaw — can read but not write memory keys; the file alone is sufficient.) Then the next conversation never has to ask again.