PawWork (爪爪) Review: A Selection-First Chrome Agent That Outputs Office Files

The problem PawWork solves is the logged-in page you cannot script

Most browser automation assumes a clean session. PawWork assumes the opposite: the README frames the already-logged-in Chrome as a programmable computer, and the extension as the agent on that machine. That framing matters because the interesting data usually sits behind a login you cannot replay in a headless runner, and the interesting UI is a page you are looking at right now. The README states the extension is a Chrome MV3 unpacked build, not a selection widget and not a Chrome Web Store app, so the intended user is someone who will open chrome://extensions, flip Developer mode, and load a folder. The stated use cases are concrete: restyle a page or hide clutter, scrape a logged-in view into a sheet, auto-fill forms through action refs, download with page identity, batch tabs or sit on an SPA after navigate, and inject a reading aid on the same tab. Note the phrasing in the repository: tried and plausible, explicitly not a benchmark list. The README also says anything a Tampermonkey userscript could do is in scope, which sets the ambition level honestly. If your job is a public page with no session, PawWork is more machinery than you need.

Side panel to service worker to offscreen agent, and what each tool actually touches

The mechanism is short enough to state in one line, and the README does: side panel, then service worker, then an offscreen SessionWorkspaceService, then an AI SDK ToolLoopAgent. Four hops, one of them offscreen, which is how the extension keeps a workspace alive outside the panel's lifetime. The tool surface splits into four groups. action works the live tab: take a snapshot, then mutate using that generation's ref plus rev. run executes sandboxed guest JS, and inside it a guest sys object exposes tabs, eval, fetch, cdp, download and screenshot. sheet, doc and web hold session state: a Univer table, a Univer document, and site HTML marked with data-paw-kind=site. inspect, acquire and clarify read the session, bring public web content in, and pause for a question or a plan. The README is explicit that sys is not a model tool, which is the design decision worth pausing on. The model does not call sys.fetch directly. It writes a run block, and the guest JS calls sys. That indirection is why login, cookies and captcha are handled by sys.fetch({ as: "page" }) inside run rather than by a dedicated fetch tool. It also means the agent's reach is bounded by what you let the sandboxed script do, not by a fixed verb list. The plan card is session-only, per the README, so nothing about the plan survives a restart.

Loading it unpacked: chrome://extensions, a BYOK key, and the reload button

There is no store listing and no daily npm step. The README gives two acquisition paths: download the Release zip, or clone the repo and use the extension/ folder. Then chrome://extensions, Developer mode, Load unpacked, and select the folder whose root holds manifest.json. Open the side panel, paste a BYOK key into pagewand_providers, and send a task on a normal http(s) page. After editing files in the load folder, click 重新加载 on the extension card. That is the whole loop, and it is worth stating plainly because the absence of a build step is the main ergonomic advantage of the unpacked approach. The one packaged playbook is page-restyle, invoked either as a skill or by hand through run plus sys.eval. The repository also documents a test command, node --test tests/runtime-regression.test.mjs, which is the only automated check named in the material. Note what is not documented in the README excerpt: the exact shape of the pagewand_providers value, and whether it accepts multiple providers. Treat that as something to read in the code or AGENTS.md before you commit to a provider.

The constraints that decide whether the first task even runs

The limits section is the most useful part of the README because it is written as gates rather than caveats. Chrome 135 or newer is required. On Chrome 138 and later, you must open the extension details and enable Allow User Scripts if your task needs sys.eval or page fetch. Close F12 on the target tab before CDP, or you get CDP_BUSY. Restricted pages such as chrome:// and the Web Store return NEED_PAGE. The README's own table is blunt about the rest: no Chrome Web Store install, no hosted model, no Tampermonkey catalog, and no chrome:// or Web Store coverage. The failure modes are named as error codes, which is better than prose, but it also tells you the extension surfaces these as agent-visible states rather than pre-empting them. The stale-generation problem is the one to internalise: action mutations are keyed to a snapshot's ref and rev, so a page that re-renders between snapshot and mutate is where a task will most plausibly break. There is no stated retry or reconciliation policy in the material. The CDP_BUSY constraint is also easy to trip in normal use, since anyone debugging a page has DevTools open by default.

PawWork versus a userscript manager, and why the difference is the model

The README invites the comparison itself: anything a Tampermonkey userscript could do is in scope, and there is no userscript store. So take the comparison seriously. A userscript manager runs code you wrote or installed, deterministically, on matching pages, with no model in the loop and no per-run cost. PawWork runs a ToolLoopAgent that decides which tool to call, and the model is your own key. The practical difference is where the work sits. With a userscript, you express the outcome as code in advance. With PawWork, you describe the outcome and the agent picks between action, run, sheet, doc and web, and, per the README, can pause for a question or a plan through clarify. That is a real gain for one-off or shifting tasks, and a real cost for anything you will run a hundred times, where a userscript is cheaper, faster and reproducible. The second difference is state. A userscript has no session workspace. PawWork keeps a Univer table, a Univer document and site HTML alive in the session, which is what makes the office-file output possible at all. If your task is stable and your page is public, a userscript is the smaller tool and you should probably use it.

Maintenance surface, licence, and what an unpacked extension commits you to

The licence is MIT, stated in the README and in the LICENSE file, which permits commercial use and modification. That is not legal advice, and MIT gives no warranty, so the practical implication is that you own the consequences of running it. The maintenance picture is unusual in a way that cuts both ways. There is no build step and no daily npm, so upgrading means replacing files in the load folder and clicking 重新加载. The releases listed are unpacked artifacts and one tagged v1.0.0-unpacked, which tells you the distribution model is the repository itself rather than a versioned store channel. The cost you take on is Chrome's own: an MV3 extension that depends on an offscreen document, on CDP access, and on the Allow User Scripts toggle is exposed to Chrome's permission and platform changes, and the README's Chrome 135 and 138 thresholds show that exposure is already live. The other maintenance item is the provider key, since BYOK means model availability, pricing and deprecations are yours to track, not the project's. The repository points to AGENTS.md for architecture and tool contracts, which is where to look when the README's summary is not enough.

Who should load it, and the first thing to break on purpose

Load PawWork if you have a provider key, you are comfortable with an unpacked MV3 extension, and your task is a logged-in page you can select on: restyling, scraping a view you can see, filling a form, or turning that view into a sheet or document. Do not load it if you need a store install, a hosted model, a skill catalog, or coverage of chrome:// and Web Store pages, because the README states plainly that none of those exist. The repository is honest about its own scope in a way that many agent projects are not, and the one-skill catalog is the clearest signal of where it is in its life. The first thing to verify is not a feature but a failure: pick a page that re-renders on interaction, take an action snapshot, mutate with the ref and rev, and watch whether the generation holds. That single round trip exercises the ref and rev contract that every action call depends on, and it is the cheapest way to find out whether the tool fits the pages you actually work on.

Editorial conclusion

Load PawWork if you already have a provider key, you are willing to run an unpacked MV3 extension, and your task is a logged-in page you can select on: restyling, scraping a view you can see, filling a form, or turning that view into a sheet or document. Skip it if you need a Chrome Web Store install, a hosted model, a skill catalog, or coverage of chrome:// and Web Store pages, because the README states none of those exist. Before trusting it with a real workflow, verify three things on your own machine: that your Chrome build is 135 or newer and that Allow User Scripts is set if your task needs sys.eval or page fetch, that your provider key works from the pagewand_providers field, and that a single action snapshot plus one mutate round trip survives your target site, since a stale ref or rev is the failure the tool contract is built to prevent.

Official sources

1. Issues
2. License: MIT
3. Player-YN/PawWork_ZhuaZhua on GitHub
4. README
5. Releases