I tried setting the LLM to "http://0.0.0.0:8080" and the extension crashed and now continues to crash at startup.

I don't get it. It's just docs. I don't see anything. Even the video in your GitHub readme doesn't work in my browser.

Really appreciate the in-depth feedback.

Iframe and CSP are big problems. For the in-page version, I chose to leave out Shadow DOM, canvas, and iframes. Although I know one of the developers forked a version to control same-origin iframes. I don't think it's practical to try to hack around browser security (and website security) — that's why I built the browser extension. I'm hoping the bridge that lets a page call the extension can cover most use cases.

My original HTML dehydration script was ported from `browser-use`. You're absolutely right that it's getting heavier over time, and it's the key factor influencing the overall task success rate. I'm looking to refactor that part and add an extension system for developers to patch their own sites. Hope it turns out well.

Thank you for the feedback. I'll be extra cautious to keep the dehydration code maintainable.

Please use your own LLM api instead!

The free testing LLM is Qwen hosted by Aliyun. Qwen and DeepSeek are the only ones I can afford to offer for free. It's just there to lower the try-out barrier; please DO NOT rely on it.

The library itself does NOT include any backend service. Your data only goes to the LLM api you configured.

I tested it on local Ollama models it works fine.

I'm looking into a European testing endpoint. The legal and compliance requirements are quite hassle, and persuading my company to pay for that infrastructure is gonna be a tough sell.

Ask the project to offer an EU-hosted endpoint or a self-hosted Docker image, and to publish a clear dataflow diagram showing which inputs, inference steps, logs and backups are stored or processed in Mainland China.

Practically that can be done by provisioning EU clusters with Terraform on AWS eu-west-1 or a European host like Hetzner, using geolocation DNS or Cloudflare load balancing to steer users and pin accounts to a region, while accepting higher costs, more complex CI/CD and subtle GDPR issues around backups and telemetry.

Currently the only dependency is zod for schema parsing.

I'm intentionally building on a lightweight, in-page JavaScript foundation to carve out some differentiation from the Python-heavy agent ecosystem.

The "protocol" layer of AG-UI does look interesting. I'll look into it to see if I can reuse something, although it seems to be evolving more toward an integration framework rather than an open protocol.

Really glad this resonates with your use case. Lightweight embedding is exactly my priority scenario. Would love to hear how the work goes!

This library does not include a LLM services. The one on the homepage is only for demonstration and testing. The npm package and extension requires your own LLM api config. Doc here https://alibaba.github.io/page-agent/docs/features/models

Thanks!

Bookmarklets are such an underrated feature. It's super convenient to inject and test scripts on any page. Seemed like the perfect low-friction entry point for people to try it out.

Spent some time on that UX because the concept is a bit hard to explain. Glad it worked!

The tension is real, but I think it's the same trust model problem that browser extensions solved years ago — just re-emerging with sharper stakes. The key insight is that 'inside the page' doesn't mean 'unlimited': you can constrain the agent to a declared action space (a list of semantic intents your app exposes) rather than letting it operate on arbitrary DOM mutations. Essentially the app becomes the API surface, and the agent calls into it rather than scripting the UI directly. The session inheritance is then a feature, not a risk, because the agent operates exactly at the permission level of the authenticated user — it can't escalate beyond what a human clicking around could do. The harder unsolved problem is prompt injection: if the page content itself can influence the agent's instructions (e.g., a user-generated comment telling the agent to 'click delete account'), you need the same kind of sandboxing logic that email clients use to strip active content.

This is the problem every agent has to face.

PageAgent’s differentiator is that site developers can embed it directly into their own pages. In that scenario, with proper system instructions plus a built-in whitelist/blacklist API for interactive elements, the risk is pretty manageable.

For the general-agent case, operating on pages you don’t control, the risk is definitely higher. I’m currently working on the human-in-the-loop feature so the user can intervene before sensitive actions.

Would love to hear other approaches if anyone has ideas.

Advantages and disadvantages of sandboxing agents with OS DAC/MAC, VM, container, user-space, WASM runtime, browser extension permissions, and IDK IFrames and Origins?

How are AI agents built into browsers sandboxed by comparison?

Recent work in sandboxing agents; https://news.ycombinator.com/item?id=47223974

No and please don’t do that.

If you only use it as a personal assistant. You can connect to your llm service directly.

If you plan to integrate it into your web app. It’s better to have a proxy api for the llm and auth the request with cookie or something.

Everything happens at runtime, on the HTML level.

It uses a similiar process as `browser-use` but all in the web page. A script parses the live HTML, strips it down to its semantic essentials (HTML dehydration), and indexes every interactive element. That snapshot goes to the LLM, which returns actions referencing elements by index. The agent then simulates mouse/keyboard events on those elements via JS.

This works best on pages with proper semantic HTML and accessibility markup. You can test it right now on any page using the bookmarklet on the homepage (unless that page CSP blocks script injection of course).

WebMCP doesn’t seem to be available for use inside webpages or extensions.

Full transparency: I work at Alibaba and published this under Alibaba's open-source org. I sometines maintain it during work hours, so yes, Alibaba technically pays me for it. That said, this is my project — it's MIT-licensed, includes no backend service, and is open for anyone to audit.

The free testing LLM endpoint is hosted on Alibaba Cloud because I happen to have some company quota to spend, but it's not part of the library. Bring your own LLM and there is zero data transmission to Alibaba or anywhere else you haven't configured yourself.

I highly recommend using it with a local Ollama setup.

Glad it worked well! The Chrome extension is my focus right now. It handles simple tasks pretty reliably and fast, but still has a long way to go for more complex workflows. Lots to improve.

I added in the system prompt that it should skip CAPTCHAs and hand control back to the user. Currently working on a proper human-in-the-loop feature. That's actually one of the key advantages of running the agent inside your own browser.

Could you elaborate on what kind of security problems you’re referring to? Like hallucination?

Thanks!

It supports any OpenAI-compatible API out of the box, so AWS Bedrock, LiteLLM, Ollama, etc. should all work. The free testing LLM is just there for a quick demo. Please bring your own LLM for long-time usage.

In my plan. Should be easy since I use wxt as the extension framework.

Darn. Pageant would've been a nice name though. Maybe `page-agent.js` is more relevant in web dev community.

Came here to say missed opportunity to call it "PAgent". Rolls off the tongue better than Page Agent.

Not yet. Currently focused on the more common interaction patterns. PRs welcome though!

I've been trying to arrive to something like this with my own sidepanel extension called Klue but its more of a user notes + web page context approach. Nice to see another take on this! https://chromewebstore.google.com/detail/cackjmmgcmnkjnffabk...

Thanks for sharing! We need more projects like this in the JS ecosystem.