techwithanirudh/mastra-slack-agent-template/agent-browser

agent-browser

Fast browser automation CLI for AI agents. Chrome/Chromium via CDP with accessibility-tree snapshots and compact @eN element refs.

Install: npm i -g agent-browser && agent-browser install

Screenshots saved to the sandbox (e.g. via agent-browser screenshot page.png) can be viewed directly with the read_file tool. The image is delivered to you visually, so you can inspect page state, verify layouts, or read on-screen content instead of guessing from snapshots alone.

Work WITH the user

ALWAYS treat the requesting user as a collaborator sitting next to you. Work is invisible to them unless you show it:

• Narrate as you go: a short one-line explanation per meaningful step ("logging in", "form submitted, confirmation page loaded") keeps them in the loop without spamming.
• Send screenshots of key steps with upload_file, after navigation milestones, before/after actions (submitting forms, payments, deletions), and whenever you claim something happened. A claim with a screenshot beats a paragraph.
• When building or changing a website: screenshot the result and VIEW it yourself with read_file before declaring success. This is strongly recommended, it is how you catch broken layouts, unstyled pages, and overlapping elements you would otherwise miss. Then send that screenshot to the user too.
• Even better than screenshots: record the session (agent-browser supports video recording) and upload the recording when the task involved a multi-step flow the user will want to trust or replay.

Start here

This file is a discovery stub, not the usage guide. Before running any agent-browser command, load the actual workflow content from the CLI:

agent-browser skills get core             # start here: workflows, common patterns, troubleshooting
agent-browser skills get core --full      # include full command reference and templates

The CLI serves skill content that always matches the installed version, so instructions never go stale. The content in this stub cannot change between releases, which is why it just points at skills get core.

Specialized skills

Load a specialized skill when the task falls outside browser web pages:

agent-browser skills get electron          # Electron desktop apps (VS Code, Slack, Discord, Figma, ...)
agent-browser skills get slack             # Slack workspace automation
agent-browser skills get dogfood           # Exploratory testing / QA / bug hunts
agent-browser skills get vercel-sandbox    # agent-browser inside Vercel Sandbox microVMs
agent-browser skills get agentcore         # AWS Bedrock AgentCore cloud browsers

Run agent-browser skills list to see everything available on the installed version.

Why agent-browser

• Fast native Rust CLI, not a Node.js wrapper
• Works with any AI agent (Cursor, Claude Code, Codex, Continue, Windsurf, etc.)
• Chrome/Chromium via CDP with no Playwright or Puppeteer dependency
• Accessibility-tree snapshots with element refs for reliable interaction
• Sessions, authentication vault, state persistence, video recording
• Specialized skills for Electron apps, Slack, exploratory testing, cloud providers

Troubleshooting

Known bug: hung sessions

Symptom: agent-browser open or agent-browser close hangs and times out with no output at all, and a new --session name doesn't help: every subsequent agent-browser call hangs too, not just the one session.

Cause: the agent-browser daemon can get wedged, either by a crashed/frozen Chrome child that never gets reaped, or by a command that got killed mid-flight (e.g. by this sandbox's own execute_command timeout) without the daemon handling the cancellation cleanly. Once wedged, the daemon hangs on every call regardless of session name, because sessions share one daemon.

Do not just retry with a different --session name, that never fixes a wedged daemon and only burns turns (this has happened repeatedly and wasted a lot of time). Instead, the moment a second consecutive hang happens on the same task:

pkill -9 -f 'agent-browser' 2>/dev/null
find ~/.agent-browser -maxdepth 1 \( -name '*.sock' -o -name '*.pid' \) -delete 2>/dev/null

Then retry once with a fresh session. If it hangs again, stop and report it instead of looping.

This sandbox also persists across turns in the thread, so a session left open (never closed) can carry a live Chrome process into the next turn and cause this same hang later. Always agent-browser close --session <name> when you're done with a session, not just when you hit an error.

Observability Dashboard

The dashboard runs independently of browser sessions on port 4848 and can also be opened through a proxied or forwarded URL such as https://dashboard.agent-browser.localhost. Agents should stay on the dashboard origin: session tabs, status, and stream traffic are proxied internally, so session ports do not need to be exposed.