AIPex: a Chrome extension that turns the browser you already use into an agent runtime

The migration tax AIPex is trying to delete

Most browser agents ask for the same three concessions. Install a separate browser build, pay a subscription, or hand over browsing data. The README frames the project as a direct answer to that pattern, and the tagline is blunt about it: your browser already works. The target user is not a QA team building a test suite. It is an engineer who is already logged into twelve internal dashboards in Chrome, has a session cookie that took an SSO dance to obtain, and wants an agent to click through those dashboards without re-authenticating anywhere. AIPex ships as a Chrome Web Store extension and an Edge Add-ons listing, so the install path is the one users already trust. The claimed benefit is not raw speed. It is that cookies, tabs, history and other extensions are all present on first launch, which removes an entire category of setup work that competing approaches push onto the user.

Two entry points, one local daemon

The architecture in the README is a chain, not a cloud service. An AI agent speaks stdio to a bridge process called aipex-mcp-bridge, that bridge opens a WebSocket to the extension, and the extension executes actions through browser APIs. The documented WebSocket URL is ws://localhost:9223/extension, set in the extension Options page. The same daemon serves a terminal client. browser-cli ships inside aipex-mcp-bridge, so scripts and coding agents reach the identical runtime rather than a parallel one. That single-daemon design is the most consequential choice in the project. It means an MCP session and a shell command can address the same tab, and it means there is exactly one place where the trust boundary sits. A lower-level aipex-cli is still available for raw tool calls, while browser-cli wraps the same surface in command groups named tab, page, interact, download, intervention and skill. The README does not describe authentication on that local socket, which is worth noting rather than assuming.

DOM snapshots before screenshots, and why that matters for cost

The README makes a specific claim about method: agents search structured page snapshots with glob and grep patterns and act by stable element UIDs, avoiding screenshot loops for most tasks. The roadmap confirms the ordering, listing the accessibility tree and an optimised DOM as done and vision as unchecked. This is a real trade-off, not a free win. Text snapshots are cheaper to send and faster to act on, which is why the README argues they reduce token and latency overhead relative to repeatedly shipping full-page images. But a DOM-derived view flattens anything the DOM does not describe well: canvas applications, WebGL interfaces, image-only controls, and pages that render their interactive surface inside a single div. The project has not yet shipped the vision path that would cover those cases, so the honest reading is that AIPex is strongest on conventional form-and-list web applications and untested by the maintainers on the visual-first ones. The page search syntax shown in the docs, browser-cli page search "button*" --tab 123, hints at glob matching over element descriptors rather than semantic understanding.

Getting it running: extension, MCP config, and the CLI

Installation starts in the browser. Add the extension from the Chrome Web Store or Edge Add-ons, click the AIPex icon, and type or speak an instruction in natural language. That path needs no configuration beyond an API key, since the project is BYOK. For agent control, the README gives per-client config. Cursor uses .cursor/mcp.json, Claude Desktop uses claude_desktop_config.json, and Windsurf uses mcp_config.json, all with the same server block: a command of npx and args of -y and aipex-mcp-bridge under the key aipex-browser. Claude Code takes a one-liner instead, claude mcp add aipex-browser -- npx -y aipex-mcp-bridge. VS Code Copilot reads .vscode/mcp.json with a servers key rather than mcpServers. After the config, the extension Options page needs the WebSocket URL ws://localhost:9223/extension and a click on Connect. The terminal route is npm install -g aipex-mcp-bridge, then commands such as browser-cli status, browser-cli tab list, browser-cli tab new https://example.com, and browser-cli interact click btn-42 --tab 123. Note the explicit --tab flag on the page and interact commands: the CLI does not guess which tab you meant.

The skill package is the part that saves agent context

AIPex bundles a skill named aipex-browser aimed at runtimes that implement the skill protocol, with Claude Code and OpenClaw-compatible runtimes named as examples. The skill contains tool usage strategy, full parameter schemas for all 30+ browser tools, and common automation patterns, with the definition in skill/SKILL.md. The reason this exists is practical. An agent that has to discover thirty tools by trial and error burns context and produces malformed calls. Pre-loading schemas front-loads that cost once. The limitation is equally practical: the skill is only useful to runtimes that speak the skill protocol. If your agent only supports MCP, you get the tools but not the strategy document, and you are back to teaching the agent how to use them. The README does not state how the skill is versioned against the tool list, so a skill package and an extension that drift apart is a plausible failure mode to watch for after upgrades.

Where AIPex is the wrong tool

The design assumes a real browser, a real profile, and a local daemon. That rules out several common situations. Headless CI is the clearest one: browser-cli is documented for scripts and CI jobs, but it still talks to the local daemon and the extension, so the job needs a running browser with the extension connected. If your pipeline has no interactive session, AIPex is not the mechanism. Cross-browser coverage is a second gap. The install listings cover Chrome and Edge only, and nothing in the material describes Firefox or Safari support, so a team that must validate across engines cannot use this as its only automation layer. A third case is multi-tenant or shared machines, where a local daemon on port 9223 that drives a logged-in profile is a different security proposition than a sandboxed remote browser. Finally, the roadmap still lists vision as unchecked, so anything that requires looking at pixels rather than reading a DOM is outside what the project currently claims to do.

How it differs from Playwright-style automation

Playwright launches its own browser instance and drives it through a protocol, with the profile created fresh unless you deliberately point it elsewhere. That isolation is the feature: reproducible state, no dependence on what the developer happens to be logged into, and clean parallel execution. AIPex inverts the trade. It attaches to the browser you are already using, so the logged-in state is the input rather than an obstacle. For exploratory work, internal tooling, and personal automation, that inversion is the whole point. For regression suites that must run identically on every machine, it is a liability, because the test depends on a human profile that nobody versions. The MCP bridge and the local daemon also mean the agent's actions are not recorded as a replayable script the way a Playwright spec is. The README describes a control path, not a test framework, and that distinction should decide which of the two you reach for.

Licence, versioning, and what a v0.1.0 upgrade costs

AIPex is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive starting point, but the licence covers the repository, not the third-party model you connect with your own key, and it does not govern the Chrome Web Store listing or the Edge Add-ons listing. Those are separate distribution channels with their own review cycles. On maintenance, the release history shows v0.0.15 and v0.0.16 in January 2026 and v0.1.0 in March 2026, with the last push to main in August 2026. The 0.x version number is the signal that matters: the MCP tool surface, the aipex-browser skill schemas, and the browser-cli command groups can all change between minor releases, and the skill package is only as current as the release it shipped with. Anyone pinning aipex-mcp-bridge in a script should pin the version rather than relying on the -y npx invocation shown in the README, which always resolves to the latest published package.

Editorial conclusion

Adopt AIPex if you already live in a logged-in Chrome or Edge profile and want Cursor, Claude Code or a shell script to drive that same session without exporting cookies or standing up a second browser. Skip it if you need Firefox, Safari, headless CI execution, or a managed hosted agent with no local daemon. Before wiring it into anything that touches production accounts, verify three things yourself: that the extension connects to ws://localhost:9223/extension on your machine, that the 30+ MCP tools listed in mcp-bridge/README.md cover the actions you actually need, and that the daemon binds only to localhost in your configuration. The project is at v0.1.0, so treat the tool surface as stable enough to evaluate and not yet stable enough to depend on.

Official sources

1. AIPexStudio/AIPex on GitHub
2. License: MIT
3. Project website
4. README
5. Releases