ScriptCat and the background script it adds to Tampermonkey's model

Background scripts keep running without a page open

The part that separates ScriptCat from a plain userscript manager is a background script execution framework. A traditional userscript lives and dies with the page that triggered it. A ScriptCat background script keeps running continuously, not bound to any page load, and the store has a dedicated zone for them at a script type filter of 3.

That changes what a script can be. Work that has to survive navigation, or that has to happen when no tab is in the foreground at all, is the kind of thing the background layer is there for. The API surface is also described as an extension on top of the standard set rather than a subset of it, which is the claim to check against the development documentation if you are porting something.

The example directory backs the claim with files rather than adjectives: `example/cat_bg_input_menu.js` is a background script, `example/early-start.js` and `example/error_retry.js` are about ordering and failure, and `example/crontab/` is a whole directory for timing.

A crontab directory is what scheduled scripts look like

Scheduled scripts run on a timer rather than on a page visit. The stated uses are auto check-ins and scheduled reminders, which is the category of task that a page-triggered userscript cannot do at all, because the page is the trigger.

The repository makes the shape of that feature visible in `example/crontab/`, a directory rather than a single file. Files rather than one means several timing jobs can sit in the same project, each with its own schedule, and the extension is what runs them.

What the README does not give is the schedule syntax. No cron expression format, no timezone handling, no statement about what happens to a job whose time passes while the browser is closed. The development documentation is where those answers are supposed to live, along with the developer guide and an edit-this-page link so readers can correct it.

The sandbox isolates scripts from each other, not from your pages

Two mechanisms are named for safety. A sandbox runs scripts in isolated environments so that one script cannot reach another script's state, and a permission model requires every script to declare what it needs, with extra confirmation for sensitive operations.

Read that second half carefully. Isolation is between scripts. The permission layer is what stands between a script and the browser, and it is a consent model rather than a restriction model: the README says scripts must explicitly request required permissions and that sensitive operations need additional confirmation. A script that asks for clipboard, cookie and network access and is granted them has all three.

The examples show how wide that surface is. `gm_cookie.js`, `gm_clipboard.js`, `gm_download.js`, `gm_xhr.js` and `gm_notification.js` are separate example files, and `grant_none.js` exists as the minimal grant case. `inject-into.js` and `require_css.js` cover injecting into the page, which is the opposite of staying behind the sandbox boundary.

The store table marks the Firefox rows as MV2

Installation is through the extension stores, and the README keeps a table with a status column that says more than the links do. Chrome and Edge have stable and beta listings, both marked available. Firefox has a stable listing and a separate beta listing in one row, and that row carries the status MV2 rather than available.

That label is the thing to notice. A beta channel that is still on the older extension manifest format is a narrower commitment than the Chrome beta next to it, and the table is where you would see it.

If the stores are unreachable, the fallback is a ZIP from the releases page for manual installation. The repository publishes release tags there: v1.5.0-beta.4 on 2026-09-18, v1.5.0-beta.5 on 2026-10-15 and v1.5.0 on 2026-10-23. The root package.json is private and reads 1.5.0, matching the newest tag.

Cloud sync carries your scripts, subscriptions carry collections

Two sync features sit at the top of the feature list. Script cloud sync moves scripts between devices, and the stated reason is recovery: switching browsers or reinstalling a system and getting the scripts back. Script subscriptions are collections of scripts that can be created and managed, and they are the part aimed at teams, since a collection can be shared for collaboration and used to combine scripts.

The distinction matters for what you trust. Cloud sync is about your own scripts surviving a reinstall, which is a backup problem. A subscription is about which scripts a group runs, which is a distribution problem, and it inherits every review question that comes with running code you did not write.

Neither feature is described with a sync target, a conflict policy, or a statement about what happens when two devices edit the same script. The README does not say where the state lives, and for a tool whose whole value is a long-lived script collection, that is the first question to take to the documentation.

pnpm is enforced in preinstall, rspack does the bundling

The build is rspack with cross-env driving the mode, and the dev script has two documented variants. One enables React DevTools, the other sets NO_MAP so source maps are skipped:

"dev": "cross-env NODE_ENV=development rspack",
"dev:react-devtools": "cross-env NODE_ENV=development REACT_DEVTOOLS=true rspack",
"dev:noMap": "cross-env NODE_ENV=development NO_MAP=true rspack",
"build": "cross-env NODE_ENV=production rspack build"

The package manager is not a convention here, it is a gate. The preinstall script runs `pnpm dlx only-allow pnpm`, which fails the install under any other manager, and pnpm-workspace.yaml and pnpm-lock.yaml sit at the root next to a packages directory, so this is a workspace rather than a single app.

The rest of the toolchain is worth knowing before you send a patch. Lint is a concurrent chain of prettier, tsc, an i18n check, an issue-template check and eslint, with eslint backed by a local rules directory and an eslint.config.mjs. Tests run through vitest, and end-to-end work runs through Playwright, which needs a browser first:

pnpm exec playwright install chromium
pnpm exec playwright test

There is a patches directory and a scripts directory with a pack script, plus two Playwright configs, one of them named scratch.

Three beta tags in a month, and the store says available

The release history is the maintenance signal here, and it is a specific one. v1.5.0-beta.4 landed on 2026-09-18, v1.5.0-beta.5 on 2026-10-15, and the stable v1.5.0 on 2026-10-23. The last push to the repository was on 2026-11-02, so the work is ongoing.

For a user, that translates into a choice about channels rather than about features. The beta listings are separate extension IDs in the Chrome and Edge stores, so testing 1.5 means installing a second, separate extension rather than opting the existing one into a pre-release channel.

Licensing is GPLv3, the author field reads CodFrm, and the documentation site is a separate project from the extension, with the store, the developer guide and the Discord and Telegram community all living at their own addresses.

Editorial conclusion

ScriptCat suits someone who already has Tampermonkey scripts and wants background and scheduled execution without rewriting them. It does not suit anyone who assumes a sandbox means a script cannot touch the pages you visit. Before switching, check three things: that the scripts you rely on are among the compatible ones, what permissions the ones you trust actually request, and whether the Firefox MV2 listing in the store matters for the browser you use.

Frequently asked questions

Official sources

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