# Browse

Drive a real stealth browser from your shell, act on websites (order food, file an...

- Repository: https://github.com/yc-software/qm (15597 stars)
- Category: Engineering
- License: MIT
- Last updated: 2026-11-01
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add yc-software/qm --skill browse -g -a claude-code -y`
Codex: `npx skills add yc-software/qm --skill browse -g -a codex -y`
Cursor: `npx skills add yc-software/qm --skill browse -g -a cursor -y`
Gemini CLI: `npx skills add yc-software/qm --skill browse -g -a gemini-cli -y`

## Description

Drive a real stealth browser from your shell, act on websites (order food, file an expense, pull data behind a login), with per-person persistent sign-ins kept in the person's browser profile (Kernel, Anchor, Browserbase, or Browser Use, picked by which API key you have). Use for ACTING on a site; to just read a page, use curl/wget first. Requires managed model access and a keychain grant for the browser provider key; follow the missing-key steps below.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Browse (the skill-based browser)

This is the platform's browser: the logic lives in this skill and runs in your shell; only
the heavy runtime (browser-use + Chromium) is baked into your computer's image at
`/opt/browser-engine/venv`. The browser itself is a remote stealth browser you drive over
CDP, hosted by whichever provider the deployment configures. It is slow and expensive, for _acting on_ a site, not
reading one. To retrieve information (read a page, check a price, hit an API), reach for
`curl`/`wget` first; browse only when you must interact, sign in, fill and submit forms,
click through a flow, or when a plain fetch is genuinely blocked by heavy JS or a bot wall.
(To verify a localhost site you built, don't use this at all, a remote browser can't reach
your loopback; use the local headless `chromium` binary.)

## Pick the provider

Which provider you use is decided by which API key is available in your env (or obtainable
through the keychain). Org keys arrive automatically: an admin saves a provider's key as an
org credential delivered as sandbox env (admin UI → Service credentials → delivery "Sandbox
env"), and it rides into every all-internal conversation, nothing here is deploy config. A
person's own keychain key overrides the org one. A provider can also be offered as a shared
credential you call through QM's broker without ever holding the key; the provider doc
says so when it supports that (Kernel does, via `kernel`). Keys you may see today:

Use the absolute directory reported by the skill read for all `providers/` paths below.
Keep the same explicit `sandbox_id` for the skill read and every `execute` command
in this flow, including the runner.

The rest: https://github.com/yc-software/qm/blob/HEAD/skills-seed/browse/SKILL.md