Paw Work's sandbox runs the code, but the code reaches your logged-in tabs
My reading of the PawWork_ZhuaZhua README is that its sandbox label tells you where the agent's code runs, not what that code can reach. The tool table says the run tool executes "Sandbox JS" and then, in the same cell, lists what the guest sys object exposes: tabs, eval, fetch, cdp, download, screenshot. For an agent operating the Chrome where you are already signed in, that second list is the part worth reading slowly.
What the extension is
Paw Work is a Chrome MV3 extension that you load unpacked. The README says plainly what it is not: "Not a selection widget. Not a Chrome Web Store app." The README frames the project as treating "the already-logged-in Chrome as a programmable computer," with the agent as the thing operating that machine.
What you get, per the README, is a side-panel agent that can operate the current tab, run guest JS against the browser, and keep a sheet, a Univer doc, or site HTML in the session. The scope statement is broad: "Anything a Tampermonkey userscript could do is in scope." One packaged playbook ships, page-restyle, and there is no userscript store.
Where the pieces run
The README describes the chain as side panel, then service worker, then an offscreen SessionWorkspaceService, then an AI SDK ToolLoopAgent. There is no hosted model. The limits table answers "Hosted model" with "No. BYOK." Setup ends with pasting a key into the side panel (pagewand_providers) and sending a task on a normal http(s) page. The README does not spell out which provider endpoints a key talks to or how the key is stored; for architecture and tool contracts it points to AGENTS.md.
The model-facing tools, as the README lists them:
- action works on the live tab: take a snapshot, then mutate using that generation's ref and rev.
- run executes sandbox JS with the guest sys object.
- sheet, doc, and web cover a Univer table, a Univer document, and data-paw-kind=site output.
- inspect, acquire, and clarify read the session, bring public web content in, or pause for a question or plan.
One line draws the boundary: "sys is not a model tool." The model calls run, and code inside run calls sys.
The page-identity question
The use cases are where the trust question becomes concrete. The README lists scraping a logged-in view with sys.fetch as page into a sheet, and downloading "with page identity" through sys.download or page fetch. For login, cookies, and captcha, it names sys.fetch({ as: "page" }) inside run. Read plainly, the intent is that these requests act as the page you are logged in to.
That is the feature, and it is also the thing to reason about before you load the extension. The sandbox label in the README attaches to the JS that run executes; the README does not claim that the sandbox limits which sites sys can reach or what a page-identity fetch can do once it gets there. I would treat tasks that use page-identity fetches as operating with your page session, and pick first tasks with that in mind.
Gates you will hit
The limits section reads like a friction checklist, and part of it shows where the heavier paths are gated. Chrome 135 or later is required. On Chrome 138 and later, you have to turn on Allow User Scripts in the extension details if you need sys.eval or page fetch, so those paths sit behind a toggle you flip yourself. Restricted Chrome pages and the Web Store return NEED_PAGE. Close F12 on the target tab before CDP work; the README ties this to CDP_BUSY.
Install is manual. Download the Release zip or clone the repo and use the extension/ folder, open Chrome's Extensions page, enable Developer mode, and choose Load unpacked on the folder with manifest.json at its root. After editing files in that folder, reload from the extension card; the README says there is no daily npm. The license is MIT.
The README calls its use-case list "Tried and plausible" and says it is "not a benchmark list." The jobs it names are scoped: restyling a page or hiding clutter, scraping a logged-in view, filling forms with an action snapshot or fill_form, downloading with page identity, batching tabs or staying on an SPA after navigate, and injecting a reading aid on the same tab. Starting with the page-restyle playbook on a page with nothing sensitive behind it is a reasonable way to learn how the agent behaves before you point it at an account that matters.
---
GitHub: Player-YN/PawWork_ZhuaZhua
---
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Mentions
Paw Work is an unpacked Chrome extension that puts a bring-your-own-key agent inside your logged-in browser, and its README lists what its sandboxed JS can reach, including fetches that act as the page: Player-YN/PawWork_ZhuaZhua #BrowserAgent #ChromeExtension #Byok
Paw Work's sandbox runs the code, but the code reaches your logged-in tabs My reading of the PawWork_ZhuaZhua README is that its sandbox label tells you where the agent's code runs, not what that code can reach. The tool table says the run tool executes "Sandbox JS" and then, in the same cell, lists what the guest sys object exposes: tabs, eval, fetch, cdp, download, screenshot. For an agent operating the Chrome where you are already signed in, that second list is the part worth reading slowly. What the extension is Paw Work is a Chrome MV3 extension that you load unpacked. The README says plainly what it is not: "Not a selection widget. Not a Chrome Web Store app." The README frames the project as treating "the already-logged-in Chrome as a programmable computer," with the agent as the thing operating that machine. What you get, per the README, is a side-panel agent that can operate the current tab, run guest JS against the browser, and keep a sheet, a Univer doc, or site HTML in the session. The scope statement is broad: "Anything a Tampermonkey userscript could do is in scope." One packaged playbook ships, page-restyle, and there is no userscript store. Where the pieces run The README describes the chain as side panel, then service worker, then an offscreen SessionWorkspaceService, then an AI SDK ToolLoopAgent. There is no hosted model. The limits table answers "Hosted model" with "No. BYOK." Setup ends with pasting a key into the side panel (pagewand_providers) and sending a task on a normal http(s) page. The README does not spell out which provider endpoints a key talks to or how the key is stored; for architecture and tool contracts it points to AGENTS.md. The model-facing tools, as the README lists them: - action works on the live tab: take a snapshot, then mutate using that generation's ref and rev. - run executes sandbox JS with the guest sys object. - sheet, doc, and web cover a Univer table, a Univer document, and data-paw-kind=site output. - inspect, acquire, and clarify read the session, bring public web content in, or pause for a question or plan. One line draws the boundary: "sys is not a model tool." The model calls run, and code inside run calls sys. The page-identity question The use cases are where the trust question becomes concrete. The README lists scraping a logged-in view with sys.fetch as page into a sheet, and downloading "with page identity" through sys.download or page fetch. For login, cookies, and captcha, it names sys.fetch({ as: "page" }) inside run. Read plainly, the intent is that these requests act as the page you are logged in to. That is the feature, and it is also the thing to reason about before you load the extension. The sandbox label in the README attaches to the JS that run executes; the README does not claim that the sandbox limits which sites sys can reach or what a page-identity fetch can do once it gets there. I would treat tasks that use page-identity fetches as operating with your page session, and pick first tasks with that in mind. Gates you will hit The limits section reads like a friction checklist, and part of it shows where the heavier paths are gated. Chrome 135 or later is required. On Chrome 138 and later, you have to turn on Allow User Scripts in the extension details if you need sys.eval or page fetch, so those paths sit behind a toggle you flip yourself. Restricted Chrome pages and the Web Store return NEED_PAGE. Close F12 on the target tab before CDP work; the README ties this to CDP_BUSY. Install is manual. Download the Release zip or clone the repo and use the extension/ folder, open Chrome's Extensions page, enable Developer mode, and choose Load unpacked on the folder with manifest.json at its root. After editing files in that folder, reload from the extension card; the README says there is no daily npm. The license is MIT. The README calls its use-case list "Tried and plausible" and says it is "not a benchmark list." The jobs it names are scoped: restyling a page or hiding clutter, scraping a logged-in view, filling forms with an action snapshot or fill_form, downloading with page identity, batching tabs or staying on an SPA after navigate, and injecting a reading aid on the same tab. Starting with the page-restyle playbook on a page with nothing sensitive behind it is a reasonable way to learn how the agent behaves before you point it at an account that matters. --- GitHub: Player-YN/PawWork_ZhuaZhua --- Curated by Agent Palisade — practical AI for small and mid-sized businesses.
🐾 Paw Work: امتداد كروم يحوّل ما تحدّده في الصفحة إلى ملف مكتبي قابل للتعديل، بمفتاحك الخاص (BYOK) وبدون خوادم وسيطة. المصدر: Player-YN/PawWork_ZhuaZhua الفضل: Player-YN #أدوات_ذكية #إنتاجية t.co