Browser control inside your existing session
BrowserKitten's README describes an unpacked Chrome MV3 extension that treats the already logged-in browser as the agent's working environment. The side panel accepts tasks, the content script handles page selection and actions, and the offscreen runtime runs the agent. Sessions can contain sheets, Univer documents, and site HTML artifacts.
The useful distinction is where the work happens: the agent can act in a browser session that already has access to your accounts. That makes permission review and supervision part of evaluating the product. The supplied sources describe these capabilities; our recorded run did not exercise them.
What our recorded run establishes
Our run took place on September 25, 2026 at 12:30:20.007 UTC against commit 1951ed05128b4cb3512cb67859f6fea331b7c23b, dated September 17, 2026 at 13:29:39 +08:00. The recorded configuration was 3 CPUs, 8 GB of memory, and image ghcr.io/astral-sh/uv:python3.12-bookworm.
The Python-oriented harness marked its install step successful in 6 seconds and recorded 35 dependencies occupying 37 MB. Its install tail identifies Python 3.12.12. A step labeled build returned exit 0 in a rounded 1 second, with an empty recorded tail. Neither result proves that the extension was loaded, packaged, or exercised in Chrome. Dependency download details are not established by the supplied tails.
Pytest exited 5 after a rounded 1 second. The tail says no tests ran in 0.02s, and the recorded summary contains 0 passed, 0 failed, and 0 total tests. This invocation provides no result for the project's documented JavaScript checks. No new execution or complete-log reconciliation was performed, and the parser summary does not establish exhaustive test coverage.
The checkout summary recorded 189 files, approximately 72,506 source lines, 2.8 MB, a tests directory, and 1 CI workflow. These are recorded repository metrics, not measures of reliability or browser performance.
The pip-audit summary recorded an advisory total of 0. Audit coverage is unknown. That result does not establish the security of the extension, its vendored JavaScript, its browser permissions, or a selected model endpoint.
Loading the extension is a separate check
The README explicitly says there is no package.json and no build step. Clone the repository or unpack a release archive, open chrome://extensions, enable developer mode, and choose Load unpacked with the folder containing manifest.json. Open the side panel and supply an OpenAI-compatible API key, which the README says is stored in chrome.storage.local. The project supplies no hosted model.
Chrome 135+ is required. On Chrome 138+, enable Allow User Scripts for sys.eval or page-identity fetch. The README says to close DevTools on the target tab before using sys.cdp, otherwise it returns CDP_BUSY. Restricted pages such as chrome:// and the Web Store return NEED_PAGE.
The README documents these checks:
node --test tests/runtime-regression.test.mjs
node tests/browser-smoke.cjs <path-to-playwright>
The architecture guide gives the broader logic-test command used by CI:
node --test tests/*.test.mjs
It says CI runs those Node checks and release-package shape assertions without installing a browser. The Playwright smoke command is manual and uses a separate Chromium instance with a disposable profile. Our harness ran neither command, so their outcomes remain unverified here.
Release packaging is documented separately:
python scripts/pack_extension.py --zip dist/pawwork.zip
For a practical evaluation, load the extension in a separate profile and run the documented browser smoke check before assigning it account-changing tasks. This is a recommended next step, not work completed in our run.
Permissions and recovery limits
The manifest requests <all_urls> host access plus sidePanel, activeTab, tabs, scripting, storage, alarms, downloads, offscreen, tabGroups, webNavigation, userScripts, and debugger permissions. Guest JavaScript runs in QuickJS without direct chrome.* access, but can request browser operations through sys. The sandbox does not remove the authority of those host operations.
The v1.1.0 release notes describe sys.waitFor, with code, selector, or text conditions and a maximum timeout of 120 seconds, plus guest sleep(ms). These are documented release capabilities, not measured workload results.
The architecture guide states that call registration and tab leases live in service-worker memory. There is no durable call journal or exactly-once execution across crashes. Sessions and artifact blobs use IndexedDB and OPFS, while optional durable tasks store progress and scheduling information. A normal conversation turn does not automatically create a durable task.
If a page-changing call has an unknown outcome after interruption, the guide advises reading the resulting page state before deciding whether to retry. It also documents that screenshots are not atomic snapshots, tab IDs do not identify a document across navigation, a session cannot run concurrent turns, and ordinary and durable-task turns have no hop limit.
Those limits make supervised research and drafting a more suitable starting point than unattended payments or irreversible account changes. This is an editorial recommendation based on the documented boundaries, not a finding that a security flaw or transaction failure occurred.
How to read the ratings
These are editorial evidence ratings on a 1-5 scale: 1 means the supplied evidence is insufficient to establish the criterion, 2 means documented limitations materially constrain it, 3 means the documented path is usable with explicit requirements, 4 means the supplied documentation gives substantial actionable detail, and 5 would require broader corroboration than is available here. They are not benchmark scores. In particular, the community rating reflects missing evidence, not a finding of poor community support.
Setup receives 3 because the documented path avoids an application build but requires developer mode, a model key, and version-specific permissions. Documentation receives 4 for the concrete loading instructions, commands, and architecture boundaries, with deeper material mainly in Chinese. Community receives 1 because the supplied extracts do not establish contributor participation or support responsiveness. Maturity receives 2 because the documentation identifies crash-recovery limits and keeps real-browser smoke testing manual; our run adds no browser validation.