PawWork_ZhuaZhua: a Chrome side-panel agent that turns the logged-in tab into the machine

The problem Paw Work picks, and the people it picks it for

Most browser agents ask you to start from a URL. Paw Work starts from a state. The README frames the extension around treating the already-logged-in Chrome as a programmable computer, and the agent as the process running on it. That framing decides the audience: people whose work happens behind a login, on a page they cannot hand to a hosted scraper without exporting cookies or replaying a session.

The intended first move is selection-first. You are on a live page, you select something, you describe the outcome, and you take away an editable office file. The repository topics name the pieces: chrome-extension, byok, llm, pptx, tldraw, univer. The three output surfaces in the session are an Univer table, an Univer document, and a site canvas marked data-paw-kind=site.

It is explicitly not a selection widget and not a Chrome Web Store app. The README says it is an unpacked MV3 extension, and the limits table repeats the point: no CWS install, no hosted model, no Tampermonkey catalog. If those three absences are dealbreakers for you, you are not the target user, and the project is not pretending otherwise.

Side panel to service worker to offscreen agent: the actual data path

The chain is short and worth memorizing before you debug anything. The README gives it as side panel to service worker to offscreen SessionWorkspaceService, which hosts an AI SDK ToolLoopAgent. Everything the model can do passes through that offscreen service, and the session workspace is what keeps the sheet, the document and the page together between turns.

The tool surface is split in a way that matters. `action` operates the live tab: it takes a snapshot, and you mutate using the ref and rev from that same generation, so a stale ref is not silently applied. `run` executes sandboxed JS, and inside it the guest `sys` object exposes tabs, eval, fetch, cdp, download and screenshot. `sheet`, `doc` and `web` are the three canvases. Then `inspect`, `acquire` and `clarify` read the session, pull public web content in, and pause for a question or a plan card.

The single most important line in the README is that `sys` is not a model tool. It lives inside `run`. That is a deliberate boundary: the model asks for a script, the script gets the browser primitives. The README also notes that login, cookies and captcha are handled through sys.fetch with as: page inside run, which is the sanctioned way to reach an authenticated endpoint with the page's own identity rather than a fresh request context.

Loading it unpacked and sending a first task

There is no store listing and no daily npm step. You either download the Release zip or clone the repository and use the extension/ folder. In Chrome, open the extensions page, turn on Developer mode, and load the folder whose root holds manifest.json.

chrome://extensions

The README states that after this you should see a side-panel agent named 爪爪 · 完全解放版. Open the side panel, paste a BYOK key under the pagewand_providers setting, and send a task on a normal http(s) page. That last constraint is not decorative: restricted pages return NEED_PAGE.

pagewand_providers

The loop after that is edit, reload, retry. The README says that after you edit files in the load folder you click 重新加载 on the extension card. There is no build watcher. For a first real use, the README's own examples are the honest starting set: restyle a page or hide clutter, scrape a logged-in view into a sheet, auto-fill a form, download with page identity, or batch tabs. The repository also ships one packaged playbook, page-restyle, and a regression suite you can run from a checkout.

node --test tests/runtime-regression.test.mjs

That command is the only test entry point the README gives. It runs the runtime regression file from the repository root.

The constraints that decide whether the first task works

The limits section is short and unusually specific, which is a good sign. Chrome 135 or newer is required. On Chrome 138 and above, if you need sys.eval or page fetch, you must enable Allow User Scripts from the extension details page. 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 rather than failing silently.

The CDP_BUSY rule is the one that will bite people first, because the natural instinct when an agent misbehaves is to open DevTools and watch. Doing that on the target tab takes the debugging channel the extension wants. The workaround is to inspect a different tab or read the session through `inspect`, but the README does not describe a recovery path beyond the error name, so treat it as a constraint rather than a feature.

The other real limitation is scope of automation. The README states plainly that anything a Tampermonkey userscript could do is in scope, and that there is no userscript store. In practice that means the ceiling is high and the floor is bare: you get primitives, not a library of solved pages. If your expectation is a shelf of ready playbooks, the project currently ships one, page-restyle.

Where Paw Work is the wrong tool

Paw Work is the wrong tool when the page is not the point. If your data already lives behind an API you can call directly, routing through a logged-in tab adds a Chrome dependency, a CDP dependency and a BYOK key for no gain. The README's own framing, that the logged-in browser is the computer, is also the honest statement of the cost.

It is also the wrong tool for unattended or scheduled work. Nothing in the README describes a headless mode, a server component, or a scheduler. The README says there is no server, which is a privacy property and an operational limit at the same time. A task that must run at 03:00 on a machine nobody is sitting at is not what this is.

Finally, it is the wrong tool if you need a supported distribution channel. The limits table answers the Chrome Web Store question with a flat no, and the releases are named unpacked, which tells you what the update path is. You re-download or re-clone. There is no auto-update story in the README.

Compared with a userscript manager

The nearest thing in kind is Tampermonkey, and the README invites the comparison by saying anything a userscript could do is in scope. The difference is in who writes the code. A userscript manager runs code a human wrote and installed; the catalog is the value. Paw Work runs code a model writes per task, against a snapshot of the live DOM, with the browser primitives handed to that generated script through `sys`. The value is the loop, not the catalog, which is exactly why the README concedes there is no userscript store.

That trade changes failure modes. A userscript fails predictably because it is fixed. A generated script fails on the shape of the page, and the ref and rev pairing on `action` is the project's answer to acting on a page that moved between the snapshot and the mutation. If you already maintain a set of userscripts that work, replacing them with generated scripts buys flexibility and costs determinism. If you maintain nothing and keep hitting one-off pages, the calculus flips.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push to main was on 2026-09-09, the same day as the v1.0.0-unpacked release. Two earlier unpacked builds landed on 2026-09-01. That is a young project with a compressed release history, and the naming convention (unpacked plus a commit hash) tells you releases are cut from the tree rather than from a versioned pipeline.

Upgrade cost is manual by design. You replace the folder, reload the extension, and re-enter your key if the storage did not survive. The README's instruction to click 重新加载 after editing files in the load folder is the same operation you perform on an upgrade. There is no migration note in the README, so check your session state after replacing the folder.

The licence is MIT, per the LICENSE file and the README's License section. MIT is permissive: you can fork, modify and redistribute, including commercially, provided the copyright notice and permission notice are preserved. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, read LICENSE and THIRD_PARTY_NOTICES.md yourself, since the extension bundles third-party components including Univer and tldraw and those carry their own terms.

Editorial conclusion

Load it if you already live in Chrome with your sessions logged in, you are comfortable pasting a BYOK key, and the job is page-shaped: restyle clutter, scrape a logged-in view into a sheet, fill a form, batch tabs. Skip it if you wanted a Chrome Web Store listing, a hosted model, a catalog of ready-made skills, or anything that must run on chrome:// and Web Store pages. Verify three things before you rely on it: your Chrome build is 135 or newer (138+ if you need sys.eval or page fetch), Allow User Scripts is on in the extension details, and F12 is closed on the target tab so CDP does not return CDP_BUSY. The last push to main was on 2026-09-09, the same day as the v1.0.0-unpacked release.

Frequently asked questions

Official sources

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