Add get-api-key skill — generic SaaS API-key extraction#112
Conversation
Drives any authenticated SaaS dashboard via the browse CLI to create or reveal an API key. Reads the vendor's own docs (Phase 0) to learn the flow, then executes against the UI — avoids hardcoding site-specific selectors so the skill generalizes to dashboards it's never seen. Includes: - Phase 0 doc-reading via browse-driven Google search + canonical URL fallback (validated on GitHub fine-grained PATs). - Local (auto-connect to Chrome) and remote (Browserbase cloud + cookie-sync persistent context) auth-setup paths. - Remote-mode caveat documenting the 5-minute idle session expiry, with API recovery snippet. - Generic cross-SaaS UX patterns (custom comboboxes vs native selects, varied confirm-button labels, secret-in-snapshot extraction). - Failure-recovery playbook for billing prompts, sudo re-auth, stale refs, and session loss. Validated on Browserbase, OpenAI, Anthropic, Vercel, and GitHub (fine-grained PAT) via autobrowse iteration. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Phase 0 leaves the browser on a docs/Google page; Phase 1 then checked the current URL against the dashboard host and would falsely return "not authenticated". Add an explicit browse open <site-root-url> before the auth check. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 3 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9a90843. Configure here.
| # 2. Stop any existing browse daemon, attach to the cloud session via CDP | ||
| browse stop | ||
| WS_URL="wss://connect.browserbase.com?apiKey=${BROWSERBASE_API_KEY}&sessionId=<sid>" | ||
| browse open <site-root-url> --cdp "$WS_URL" |
There was a problem hiding this comment.
Option B cookie-sync steps wrong
High Severity
Remote setup tells agents to run cookie-sync with a nonexistent --persist flag, expect a Session ID from that step, and attach with a hand-built WebSocket URL. The real cookie-sync script only prints a Context ID and documents creating a cloud session via browse cloud sessions create before browse open --cdp.
Reviewed by Cursor Bugbot for commit 9a90843. Configure here.
| - `browse open <url>` — navigate (no flags needed; daemon stays attached) | ||
| - `browse snapshot` — accessibility tree; each element gets a `[X-Y]` ref. PRIMARY perception tool. | ||
| - `browse click [X-Y]` — click by ref from latest snapshot (include brackets) | ||
| - `browse fill <selector> <value>` — fill input AND press Enter (clears existing text — PREFERRED over `type`) |
There was a problem hiding this comment.
browse fill incorrectly presses Enter
Medium Severity
The browse reference says browse fill clears the field and does not submit unless --press-enter is passed. This skill states fill always presses Enter, which can prematurely submit multi-field API key forms before scopes or expiration are set.
Reviewed by Cursor Bugbot for commit 9a90843. Configure here.
| browse open <site-root-url> # return to the target dashboard (skip only if Phase 0 was skipped and you never left it) | ||
| browse get url | ||
| ``` | ||
| - URL contains the dashboard host AND NOT `/sign-in`, `/login`, `/auth` → proceed. |
There was a problem hiding this comment.
Auth check rejects /auth paths
Medium Severity
Phase 1 treats any URL containing /auth as unauthenticated. Legitimate logged-in settings routes (for example paths under /settings/auth or /authentication) can be rejected with not authenticated even after a successful dashboard return.
Reviewed by Cursor Bugbot for commit 9a90843. Configure here.
1 participant
Summary
get-api-keyskill that drives any authenticated SaaS dashboard via thebrowseCLI to create or reveal an API keyWhat's inside
skills/get-api-key/SKILL.md— the skill prompt, structured as Phase 0 (docs) → Phase 1 (verify auth) → Phase 2 (find keys page) → Phase 3 (reveal/create) → Phase 4 (capture) → Phase 5 (return JSON)skills/get-api-key/LICENSE.txt— MIT, matching repo conventionHow it's generic
Validation
Built via
autobrowseiteration across five sites:bb_live_)sk-proj-)sk-ant-api03-)vcp_)/settings/personal-access-tokens/newand filled the form correctly in 13 turns)Test plan
doc_url_usedpopulated in the returned JSON)🤖 Generated with Claude Code
Note
Medium Risk
New agent skill that automates creation/reveal of live API secrets and documents Browserbase/cookie flows; misuse or trace leakage could expose credentials, but it does not change runtime application code.
Overview
Adds a new
get-api-keyskill package underskills/get-api-key/: an MITLICENSE.txtand aSKILL.mdagent playbook for pulling API keys from authenticated SaaS dashboards via thebrowseCLI.The skill documents local Chrome (
--auto-connect, debug port / Chrome 136+ caveats) and remote Browserbase setup (cookie-sync, CDP attach, manual login via debugger URL, ~5‑minute idle expiry and recovery). It defines a phased workflow—vendor docs first (canonical URL or Google via browse), auth check, keys page discovery (URL patterns or nav), reveal or create, one-time secret capture (screenshot + snapshot), and structured JSON output—plusbrowse0.7.1 command guidance, cross-SaaS UX heuristics, failure handling, and explicit limits (no login, no sudo passwords, no fabricated secrets).Reviewed by Cursor Bugbot for commit 9a90843. Bugbot is set up for automated code reviews on this repo. Configure here.