Page Agent runs inside the page it controls
Page Agent is JavaScript embedded in a web application. It reduces the page DOM to text, sends that structure and the user's instruction to a chosen language model, then acts on the interface. Because it works in the existing page, it does not need a Python service, screenshot model, or separate headless browser for a single-page task. That makes it well suited to adding a copilot to a product the team already owns.
The boundary is also restrictive. An in-page agent inherits the application's browser context and can manipulate only what its integration and extension expose. Our checkout contained 250 files and about 23,684 source lines, small beside a browser automation platform but still organized as a workspace monorepo. The README explicitly says the project targets client-side enhancement. Crawlers, scheduled scraping, and remote test fleets should use an external browser controller.
Text-based DOM control avoids screenshot dependence
Page Agent reasons over a simplified document structure rather than pixels. That can make buttons, inputs, labels, and accessible text cheaper for a language model to interpret, and it avoids screen-resolution differences. It is especially appealing in an internal ERP or CRM where the developers can improve labels and markup. A natural-language instruction can then operate the same controls a user sees.
DOM access does not guarantee correct actions. Hidden state, custom canvases, ambiguous labels, asynchronous updates, and prompt injection in page text can still confuse an agent. The repository has 4 CI workflow files, while the roadmap keeps safeguard and user-takeover items unchecked. Use allowlisted actions, visible previews, confirmation for destructive steps, and application permissions that limit what a mistaken click can change.
What happened when we ran it
We cloned commit d02db1e into an unprivileged Node 22 Debian container with 3 CPUs, 8 GB of RAM, and no secrets. The 1.4 MB checkout held 250 files and roughly 23,684 source lines. It is an npm-workspace monorepo with 4 CI workflow files. Our harness found no root Dockerfile and no root tests directory, though the configured test command was present and runnable.
Installation succeeded in 45 seconds. npm added 735 packages and used 412 MB on disk. The build completed in 24 seconds, and the test command completed successfully in 16 seconds. The measurement block does not provide the number of tests, so a pass count would be invented. These results show that the selected workspace commands worked in a fresh container.
Npm audit found 17 known vulnerabilities: 3 critical, 9 high, 4 moderate, and 1 low. Our measurement does not identify affected packages, reachable code paths, or available fixes. A team should inspect the full audit for the pinned version, separate development-only packages from browser-shipped dependencies, and confirm the final bundle. Passing tests do not cancel dependency advisories, particularly for code placed inside authenticated pages.
Model privacy is part of the integration
The normal setup brings an OpenAI-compatible base URL, model name, and API key. Page Agent itself has no hosted backend in bring-your-own-key mode. When a user starts a task, the extension sends the natural-language instruction and simplified page structure to the configured provider. The privacy document says this cleaned HTML can still contain visible text, form values, or other sensitive information.
The free testing API deserves a separate warning. It is limited to evaluation, may be rate-limited or discontinued, prohibits sensitive data, and processes requests through Alibaba Cloud infrastructure in Mainland China. The terms advise users in regions with strict localization rules against it. Production teams should choose their own compliant model endpoint, document what DOM content leaves the browser, and prevent the agent from reading pages outside the approved application scope.
The MCP server adds Chrome and a local bridge
The beta @page-agent/mcp package lets Claude Desktop, Copilot, Cursor, and other MCP clients ask the extension to operate browser tabs. It requires Node 20 or newer, Chrome, the Page Agent extension, and model credentials. The server uses stdio toward the agent client, then starts HTTP and WebSocket services on localhost, with port 38401 as the documented default. A hub tab connects the browser extension to that bridge.
The MCP surface exposes 3 tools: execute a task, read connection or busy status, and stop the running task. That is admirably narrow. It does not create a security sandbox. An MCP client can still cause real browser actions in signed-in tabs, and simplified page content goes to the selected model. Bind the bridge locally, guard the machine account, restrict extension access, and require confirmation before purchases, deletions, messages, or permission changes.
Browser coverage and maintenance are still limited
The optional extension handles multi-tab work in Chrome. The public roadmap marks Firefox and Safari extensions as pending decisions or unchecked work, and issue 673 requests Mozilla support. Do not describe that support as planned delivery. The checked item is access to all tabs; the remaining browser entries are aspirations in a work-in-progress roadmap. Teams with a browser mandate beyond Chrome need another controller today.
Release v1.12.2 arrived on July 16, 2026, and GitHub recorded a push on August 24. The repository showed 80 open issues and pull requests combined. Issue 349 says one primary maintainer has limited review capacity and asks contributors to discuss features first. Page Agent is active and unusually easy to embed, but its dependency audit, browser coverage, and unfinished safety work argue for a controlled copilot before broad autonomous access.