ScriptCat: a Tampermonkey-compatible userscript manager with background scripts

The problem ScriptCat addresses: scripts that stop when the tab closes

A conventional userscript runs inside a page. When the tab closes, the script's world goes with it. Anything that needs to happen on a timer, in the background, or across pages has to be faked with a pinned tab or an external process. ScriptCat's stated purpose is to remove that constraint. The README describes it as a userscript manager built on Tampermonkey's design philosophy, fully compatible with Tampermonkey scripts, that also implements what it calls a background script execution framework with API extensions. The intended audience is therefore two groups: people who already run Tampermonkey scripts and want to keep them, and people writing automation that does not belong to any single page. The README lists auto check-ins and scheduled reminders as the motivating examples. That is a narrow but real gap, and it is the reason to look at this project rather than at a plain userscript host.

How the background script model and the sandbox fit together

The repository is a TypeScript monorepo built with rspack, organised under src/, packages/, rspack-plugins/ and eslint-rules/, with a pnpm workspace file at the root. Two mechanisms carry the design. The first is the sandbox: the README states that scripts run in isolated environments so that malicious code cannot affect other scripts, and that scripts must explicitly request the permissions they need, with additional confirmation for sensitive operations. The second is the background execution framework, which keeps scripts running without the page limitation. Those two choices interact. A background script has no page to attach to, so the permission model has to do more work than it does in a page-bound userscript, and the sandbox has to hold across a longer lifetime. The repository's example/ directory shows the surface area this produces: cat_file_storage.js, cat_bg_input_menu.js, cloudcat.js, a crontab/ folder, early-start.js, error_retry.js, plus a long list of gm_* examples covering cookies, downloads, notifications, tabs, XHR and value storage. The crontab and early-start examples are the ones that only make sense if execution really does outlive the page. The README does not document how the background runtime is isolated from the extension's own privileged context, so treat that as the thing to inspect in the source before you trust it with anything sensitive.

Installing ScriptCat and running a first script

The README's recommended path is the extension store, and it lists store links for Chrome, Edge and Firefox, with a separate beta listing for each. Firefox is marked MV2, Chrome and Edge are marked available. If the stores are unreachable, the README says to download the latest ZIP package from GitHub Releases and install manually. There is no documented CLI install and no package manager install for the extension itself; the npm scripts in package.json are for building the extension from source, not for installing it as a user.

After installing, the workflow the README describes is to get scripts from the ScriptCat Script Store or another userscript market, or to write your own. The repository ships runnable examples you can load into the editor; example/gm_log.js is the smallest of them and demonstrates the logging API. Its metadata block is the part that matters: @match decides which pages the script attaches to, and @grant declares the API you are asking for. If you leave out @grant, the privileged function is not available, which is the sandbox and permission model doing its job. The README does not spell out the full @grant list; the example/ directory is the practical reference, with separate files for clipboard, cookie, download, notification, tab and XHR access.

To build the extension from source rather than install it, the repository requires pnpm and exposes these scripts:

pnpm install
pnpm dev
pnpm build
pnpm pack

pnpm install triggers a preinstall hook that runs only-allow pnpm, so npm and yarn are rejected. pnpm dev starts rspack in development mode, and pnpm build produces a production bundle. pnpm pack runs scripts/pack.js, which the repository layout suggests is what produces the release ZIP. The README does not document the output directory for pnpm build, so check rspack.config.ts for the destination before you go looking for a loadable folder.

The beta release line is the main practical limitation

The most recent releases listed are v1.5.0-beta.4, v1.5.0-beta.3 and v1.5.0-beta.2, and package.json carries version 1.5.0-beta.4. The repository itself is not archived and the last push was on 2026-09-22, so the code is moving. But what is moving is a beta line. The README's own store table separates stable and beta listings, which tells you the project treats them as different products for different users. If you install the stable store build you are not on the version that package.json describes, and if you install the beta you are accepting pre-release behaviour. Neither path is documented as reversible: the README does not document rollback, and it does not document a downgrade procedure or a version pin for the store builds. A second limitation is compatibility. The README claims full Tampermonkey compatibility and simultaneously asks users to report incompatible scripts through GitHub issues. Both statements are in the same paragraph. That is an honest admission that the compatibility claim is aspirational in places, and it means any migration should be tested script by script rather than assumed. The README also does not state which Tampermonkey APIs are unimplemented, so the failure mode you should expect is a script that installs cleanly and then silently does less than it did before.

ScriptCat versus Violentmonkey and Tampermonkey

Violentmonkey is the closest comparison people search for, and the difference is architectural rather than cosmetic. Violentmonkey is a userscript manager in the conventional sense: scripts are bound to pages, and anything beyond that is the script author's problem. ScriptCat adds the background execution framework and the crontab-style scheduling that the README advertises, which is the feature Violentmonkey does not try to provide. If your scripts are page-bound, the extra machinery buys you nothing and you are carrying a larger TypeScript codebase for no benefit. Tampermonkey is the other reference point, and the relationship is different again: ScriptCat is explicitly built on Tampermonkey's design philosophy and aims to run Tampermonkey scripts, so the choice there is about whether you want the additional background APIs and the built-in editor, not about a different scripting model. The README's editor claim is specific: syntax highlighting, intelligent completion and ESLint, plus debugging tools. That is a development-environment argument, not a runtime one, and it is the part of the pitch that a page-bound user has the least reason to care about.

Licence, maintenance and what upgrading costs you

ScriptCat is licensed under GPL-3.0, as stated in the README and in package.json, which carries the string GPLv3. Note that package.json also sets private to true, so the repository is not published as an installable npm package; the licence governs the source you build and any redistribution you make of it. For most users this is a non-issue because they install a store build and never redistribute anything. It becomes relevant if you fork the extension, ship it internally, or bundle it into a product, because GPL-3.0 carries obligations that permissive licences do not. That is a description of the licence, not advice; read the LICENSE file and, if you are redistributing, get your own opinion. On maintenance, the observable facts are that the repository is not archived and the last push was on 2026-09-22, with three beta releases in the preceding month. The upgrade cost is the part the README is silent on. There is no changelog in the repository root, no documented migration path between minor versions, and no statement about how long a stable release is supported. If you run background scripts on a schedule, an extension update can change the runtime under them without a documented way back, and that is the risk to price in before you depend on it.

Editorial conclusion

Adopt ScriptCat if you already have Tampermonkey scripts and want something that also runs background scripts on a schedule, and you are willing to track a beta release line. Do not adopt it if you need a frozen, long-supported version or a documented rollback path, because the README does not describe either. Verify first that your existing scripts install without the compatibility problems the README asks you to report through GitHub issues, and check the current release tag before you deploy it to anyone but yourself.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. scriptscat/scriptcat on GitHub