Skip to content

feat: add an agent-browser feature - #23

Merged
ashwin153 merged 3 commits into
mainfrom
claude/agent-browser-devcontainer-t7hk7h
Sep 7, 2026
Merged

ashwin153 merged 3 commits into
mainfrom
claude/agent-browser-devcontainer-t7hk7h

Conversation

@ashwin153

@ashwin153 ashwin153 commented Sep 7, 2026 •

Copy link
Copy Markdown
Contributor

Softlight Overview

UX Score: 5/5

Softlight reviewed this change and found no issues.

To run Softlight again, click here`` or comment @softlight.

Adds a feature for agent-browser, a browser automation CLI for AI agents. Companion to orianna-ai/devcontainer#95, which adds it to the image.

Where it installs

/usr/local/share/agent-browser/bin/agent-browser, symlinked to /usr/local/bin/agent-browser — the shared-prefix shape the other features use: one root-owned copy, readable and executable by every user, writable by none.

The published npm package is the source rather than the matching GitHub release asset. The release ships the binary alone; the package carries the per-platform binaries and the bundled skills, so one download answers both halves of the install. Only this platform's binary and skill-data are unpacked, and the rest of the tarball goes with the staging directory.

Despite coming from npm, agent-browser is a Rust binary. Like the grok feature and unlike playwright and typescript-language-server, this one needs no node runtime and installs nothing into a node version's global root.

Skills

agent-browser skills get core --full is how the CLI documents itself to an agent, and the skills are version-matched to the binary. They are not compiled in — they ship beside it as skill-data/, and the lookup that finds them expects the npm package layout, which lifting the binary into a shared prefix breaks. So AGENT_BROWSER_SKILLS_DIR is exported through containerEnv, and the install verifies the lookup resolves before it finishes.

No browser

The feature installs the CLI, not a browser. agent-browser discovers the Playwright browser cache through PLAYWRIGHT_BROWSERS_PATH, so pairing it with this repository's playwright feature is enough and needs nothing configured — which is what the orianna image does.

Downloading Chrome for Testing at build time was deliberately left out: it would land in root's home where the remote user cannot read it, it would duplicate a browser the image already has, and upstream publishes no Linux ARM64 build of it, so on arm64 the playwright pairing is the only option that works at all.

Testing

Three scenarios: ubuntu (no node in the image), ubuntu_pinned (an exact X.Y.Z), and ubuntu_with_chromium (paired with the playwright feature).

The last one drives a real page — open, read text, screenshot — because that is the only thing that proves the pairing, and then asserts that the browser doctor picked resolves inside PLAYWRIGHT_BROWSERS_PATH. It asserts the path and not the version string: an earlier revision matched the literal Chromium and went red in CI, because @playwright/cli@latest installs a build that calls itself Google Chrome for Testing 153.0.8010.12 under chrome-linux64. Reproducing that install locally showed agent-browser finds and drives it fine — the check was wrong, not the pairing. A failed launch now dumps doctor, so the next such break explains itself instead of failing silently.

Docker was unavailable in the session that wrote this, so devcontainer features test could not be run there. Instead install.sh was executed directly against the live registry — latest, a pinned 0.35.0, and a nonexistent version — and every assertion was run by hand against the resulting install, as root and as an unprivileged user, against both the Chromium and Google Chrome for Testing builds. CI runs the real thing and is green.


🤖 Generated with Claude Code

https://claude.ai/code/session_01Y13iFob848xFCkWHAzZAEb


Generated by Claude Code


Note

Low Risk
Additive devcontainer packaging and docs/tests only; no secrets at build time and no changes to existing features beyond optional playwright pairing in tests.

Overview
Adds a new agent-browser devcontainer feature that installs the Rust agent-browser CLI from the npm package tarball (not GitHub release assets), without a Node runtime.

Install places the linux amd64/arm64 binary under /usr/local/share/agent-browser with a /usr/local/bin symlink, copies bundled skill-data, and sets AGENT_BROWSER_SKILLS_DIR via containerEnv so skills resolve outside the npm package layout. The version option supports latest (resolved at image build) or pinned X.Y.Z; install.sh smoke-checks --version and skills lookup before finishing.

Browser is intentionally not installed at build time; docs and tests expect pairing with the repo's playwright feature so Chromium is found via PLAYWRIGHT_BROWSERS_PATH.

Tests add three Ubuntu scenarios: default install (no Node, skills, read-only prefix), pinned 0.35.0, and playwright pairing with a real page drive/screenshot check.

Reviewed by Cursor Bugbot for commit 3007576. Configure here.

Installs vercel-labs' agent-browser CLI, a browser automation CLI for AI
agents, into the usual shared prefix at
/usr/local/share/agent-browser/bin/agent-browser.

The npm package is the source rather than the matching GitHub release
asset: the release ships the binary alone, while the package carries both
the per-platform binaries and the bundled skills, so one download answers
both halves of the install. Only this platform's binary and skill-data are
unpacked. The CLI is a Rust binary, so the feature needs no node.

The binary finds its skills through the npm package layout, which lifting
it into a shared prefix breaks, so AGENT_BROWSER_SKILLS_DIR is exported
through containerEnv and the install verifies the lookup resolves.

No browser is installed. agent-browser discovers the Playwright browser
cache through PLAYWRIGHT_BROWSERS_PATH, so pairing it with the playwright
feature is enough; ubuntu_with_chromium covers that pairing by driving a
real page.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y13iFob848xFCkWHAzZAEb
ubuntu_with_chromium failed in CI. The pairing works; the check was wrong.

It matched doctor's Chrome line against the literal "Chromium", which is
the browser's own version string. The playwright feature installs
@playwright/cli@latest, and that release downloads a build reporting
"Google Chrome for Testing 153.0.8010.12" under chrome-linux64, so the
check only ever passed against the older build that calls itself
"Chromium".

Reproduced by installing the same @playwright/cli@latest chromium locally:
agent-browser finds and drives it, and every other assertion held.

Now asserts what it meant to -- that the browser doctor picked resolves
inside PLAYWRIGHT_BROWSERS_PATH -- and prints the line it matched. Driving
a real page runs first, since that is the capability that matters, and it
dumps doctor's report when the launch fails so a broken pairing diagnoses
itself instead of failing silently the way this one did.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y13iFob848xFCkWHAzZAEb
install.sh carries none, the way every other feature's does -- the
reasoning already lives in NOTES.md. The tests keep one line each, and the
pairing test one block, matching grok and san-francisco-font.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y13iFob848xFCkWHAzZAEb
@ashwin153
ashwin153 enabled auto-merge (squash) September 7, 2026 14:10
@ashwin153
ashwin153 merged commit a764bb8 into main Sep 7, 2026
2 checks passed
@ashwin153
ashwin153 deleted the claude/agent-browser-devcontainer-t7hk7h branch September 7, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants