# Actionbook: a browser agent that reads pages behind your logins

> Actionbook pairs a hosted MCP endpoint with a Chrome extension so an AI client drives your real, already signed-in browser. Here is how the pieces fit, what the README does and does not specify, and where the approach breaks down.

**actionbook/actionbook** — Let your AI agent get the sources behind logins and paywalls.

- Repository: https://github.com/actionbook/actionbook
- Website: https://actionbook.app
- Stars: 1,603 · Forks: 120
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/actionbook-actionbook

## The problem Actionbook targets: agents that stall on logins and rendering

Most browser automation fails in the same two places. The first is authentication: the data a user actually wants is behind a session, and a fresh automated browser has no session. The second is rendering. The README argues that modern sites use virtual DOMs, streaming components and single-page apps, so an agent that takes a snapshot after every step and re-parses the page fails on dropdowns, date pickers and login walls. Its own illustration is an agent searching one room on Airbnb taking five minutes.

Actionbook's answer is to stop treating the page as something to be parsed from scratch. The extension drives the Chrome you are already using, so your cookies and sessions are in place, and the agent is handed an action manual that says what to do rather than being left to infer it. The README frames the outcome as finished work rather than answers: a sourced report, a clean CSV, or ready-to-send drafts. The audience is therefore narrow and specific: people whose job involves pulling information out of sites they have accounts on, and who already work inside an MCP-capable AI client.

## How the extension, the MCP endpoint and action manuals fit together

There are three moving parts. The Chrome extension is installed from the Chrome Web Store and, once you sign in from the dashboard, connects to the hosted MCP endpoint automatically. That endpoint is https://edge.actionbook.app/mcp, and it is what you paste into your AI app's connector settings. Your client is the third part: it calls the endpoint, the endpoint reaches the extension, and the extension operates your real Chrome.

The README describes a stateless architecture, which is what allows concurrent operation: the claim is that dozens of tabs can be worked in parallel rather than one page at a time. The tool surface is deliberately small. Actionbook exposes a single actionbook MCP tool whose subcommands split into action lookup (search, manual) and browser control (goto, snapshot, click, type, and others). The README says the agent discovers the full command set from the tool description once connected, which means the client does not need a hardcoded command list.

The routing decision is the interesting part. According to the README, Actionbook makes direct API requests when possible and falls back to UI automation when not, with login handled either way. That is a pragmatic split: API calls are faster and less brittle, but most sites do not expose one, so the UI path has to exist. What the README does not document is how the choice is made, or what happens when a direct API call silently returns different data than the rendered page. That is a real gap if you intend to rely on the output for anything consequential.

## Installing Actionbook: extension, connector, dashboard

The README is explicit that there is no CLI install. Actionbook runs as a remote MCP connector paired with the Chrome extension. The three steps below are the quick overview the README gives; it points to the dashboard for per-client instructions and screenshots.

First, install the Chrome extension from the Chrome Web Store. The store listing identifier in the README is bebchpafpemheedhcdabookaifcijmfo.

Second, add Actionbook as a connector in your AI app. The README names Claude (Settings, then Connectors, then Add custom connector), ChatGPT (Settings, then Connectors), Perplexity, Hermes, OpenClaw, and any other MCP-compatible app. The value you paste is the endpoint:

```bash
https://edge.actionbook.app/mcp
```

Third, finish setup from the dashboard, which the README says walks you through connecting your client and confirms the extension is linked. Note the README's own warning: the standalone @actionbookdev/cli package is deprecated, and the remote connector plus extension is the supported path. If you find an older tutorial that tells you to install that package, it is describing the legacy flow.

Once connected, you talk to the agent normally. The README's quick-start example is a single sentence:

```
Open stripe.com, linear.app, and vercel.com, then grab the pricing from each.
```

Behind the scenes the agent fetches action manuals and operates your Chrome, opening tabs, reading snapshots, clicking and filling forms across pages concurrently. The README also offers a nudge phrase to add to a prompt: "Use Actionbook to understand and operate the web page." What you should see after setup is the extension reporting as linked in the dashboard; the README does not describe an error state for a failed link, so treat a dashboard that does not confirm the link as the signal to stop.

## Recipes, concurrency and the parts the README leaves open

The feature that separates Actionbook from a one-shot browsing prompt is Recipes. The README says that when a task works the way you want, you save it as a Recipe and run it again with new inputs. That is a sensible design: the expensive part of agentic browsing is figuring out the sequence, and re-deriving it every run is waste. Recipes turn a successful run into a parameterised one.

The concurrency claim follows from the stateless architecture. The README's demonstration is an agent visiting 192 First Round portfolio company websites and collecting their taglines in two minutes, and it states the video is not sped up. That is the project's own figure, presented as a demonstration rather than a reproducible benchmark, so treat it as an illustration of the intended shape of the workload (many independent pages, one extraction each) rather than a number you can expect on your own sites.

Where the documentation thins out is failure handling. The README does not document what happens when a site changes its layout and an action manual no longer matches, whether a Recipe fails loudly or drifts quietly, or how a partially completed multi-tab run is reported. There is a request-a-website page for suggesting sites you want indexed, which implies coverage is curated rather than automatic, but the README does not say how long indexing takes or what happens for an unindexed site. These are the questions to answer before you build a workflow that depends on the output.

## Where Actionbook is the wrong tool

The clearest limitation is architectural. Browser control runs through a hosted endpoint at edge.actionbook.app and a Chrome extension. If your environment forbids sending page content through a third-party service, or if you need the whole pipeline to run on your own hardware, this design is disqualifying regardless of how well it works. The repository being Apache-2.0 does not change that, because the operating path is the hosted connector, not a local binary you compile and run.

The second limitation is the client requirement. Actionbook needs an MCP-capable app. If your tooling does not speak MCP, there is no documented fallback: the README's deprecation note removes the CLI route that would previously have covered that case.

The third is scope. This is for sites you are signed into and for tasks that end in an artefact. If you need a deterministic script that runs in CI with no browser and no session, a headless automation library is a better fit, because you can pin behaviour in code and diff it. Actionbook's value comes precisely from the parts that are hard to pin down: a real browser, real sessions, and pages that change.

## Actionbook compared with a headless browser library

The obvious alternative is a headless browser automation library such as Playwright or Puppeteer, driven by your own code. The difference is not quality, it is where the intelligence sits. With a headless library you write selectors and waits yourself. You get reproducibility and full control, and you pay for it every time a site ships a redesign, because your selectors break and you fix them.

Actionbook inverts that. The action manual carries the knowledge of how to operate a site, the agent decides the sequence at runtime, and the extension supplies the session. You trade determinism for tolerance of change. The README's own framing of the trade-off is that agents without this layer are slow and brittle: slow because they snapshot and parse after every step, brittle because they do not understand virtual DOMs, streaming components and SPAs. Whether that framing holds for your sites is testable, and it is the first thing worth checking.

A second alternative is simply not using an agent for the retrieval step. If your task is a fixed extraction from a fixed site on a schedule, a small script is cheaper to run and easier to audit than a browser agent. Actionbook earns its place when the target set is large, varied, or changes often enough that maintaining selectors is the dominant cost.

## Licence, repository layout and upgrade cost

The repository is Apache-2.0, and package.json carries the same identifier. That covers the source in the repository. It does not describe the hosted MCP endpoint or the Chrome extension, which are separate artefacts distributed through the Chrome Web Store and actionbook.app. If your review process treats licence and hosting as one question, split them: the code you can read and the service you connect to are not the same thing, and the README's own text points to the dashboard and documentation site for the operational details. This is a description of what the files say, not legal advice.

The repository is a pnpm workspace with turbo as the task runner, packageManager pnpm@10.24.0, and build, dev, test, lint and clean scripts that fan out across packages. Releases are managed with changesets: the version-packages script runs changeset version and then node scripts/sync-versions.js, and the release script states that publishing is handled by CI rather than locally. The most recent releases listed are extension builds, actionbook-extension-v1.1.9 on 2026-06-11, v1.1.7 on 2026-06-07 and v1.1.6 on 2026-06-06. The last push to the default branch was on 2026-09-08.

For an end user, upgrade cost is low: the extension updates through the Chrome Web Store and the connector endpoint is a URL you pasted once. For anyone building on the repository, the cost is different. The build:release script filters a specific set of packages, including @actionbookdev/sdk, @actionbookdev/mcp, @actionbookdev/tools-ai-sdk, @actionbookdev/json-ui and @actionbookdev/openclaw-plugin, which tells you the release surface is broader than the extension alone. Expect to keep the pnpm and turbo toolchain current. The README does not document a rollback path for a bad extension release, so pinning behaviour on the hosted side is not something you can do from the client.

## Conclusion

Adopt Actionbook if your work happens inside sites you are already signed into and your client speaks MCP, because the extension reuses those sessions instead of asking you to script logins. Do not adopt it if you need self-hosted execution, a scriptable CLI, or an auditable open-source pipeline end to end: the README states the standalone CLI package is deprecated, the browser control runs through the hosted edge endpoint, and the repository itself is a pnpm and turbo monorepo rather than a runnable agent. Before connecting a client, verify three things in the dashboard flow: that your client is listed as supported, that the extension reports itself linked, and that the endpoint https://edge.actionbook.app/mcp is the one your connector settings accept.

## FAQ

### What is action in AI?

In Actionbook's model, an action is a step the agent performs on a page, such as goto, snapshot, click or type. These are the browser control subcommands exposed by the single actionbook MCP tool.

### What is an action book?

Actionbook is an AI agent that runs in your Chrome side panel, reads data behind your logins and operates websites you already use. It ships as a Chrome extension plus a hosted MCP endpoint at https://edge.actionbook.app/mcp rather than a standalone CLI.

### How do I connect Actionbook to an MCP client?

Open your AI app's connector settings and paste the Actionbook endpoint https://edge.actionbook.app/mcp, then finish setup from the dashboard, which the README says confirms the extension is linked. The README names Claude, ChatGPT, Perplexity, Hermes and OpenClaw as supported apps.

## Sources

- [actionbook/actionbook on GitHub](https://github.com/actionbook/actionbook)
- [License: Apache-2.0](https://github.com/actionbook/actionbook/blob/main/LICENSE)
- [Project website](https://actionbook.app)
- [README](https://github.com/actionbook/actionbook/blob/main/README.md)
- [Releases](https://github.com/actionbook/actionbook/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/actionbook-actionbook