Wenmoux/checkbox: a Node.js sign-in box for dozens of Chinese sites and apps

What the sign-in box actually removes from your day

The problem is not signing in. The problem is that a person who uses a dozen Chinese forums, novel apps and game communities ends up doing the same small ritual on each one: open the app or mobile site, tap the check-in button, collect the coin or the day's free minutes, close it. The README's checklist runs from 时光相册 and 书香门第 through NGA, 晋江, 起点读书, 猫耳FM and 麦当劳. Each entry is one site's daily routine reimplemented as a script.

The audience is narrow and specific. You need to be comfortable editing a YAML file, running Node from a terminal, and extracting cookies from a browser or a packet capture. The README does not pretend otherwise: the usage section is titled with the phrase 懂得自然懂, roughly "those who get it, get it." There is no dashboard, no account system, no onboarding. If you have never pulled a Cookie header out of devtools, this project will be a wall.

How a run works: one entry point, one task list, one script per site

The repository is flat by design. checkbox.js is the entry point; index.js and checkbox_old.js sit beside it; scripts/ holds the per-site modules; sendmsg.js handles notifications; config.yml.temple is the template you copy. package.json declares axios, crypto-js, iconv-lite, js-yaml, ws and yargs, which tells you the shape of the thing: HTTP calls, some AES or MD5 signing on sites that require it, GBK decoding for older forums, a WebSocket dependency for whatever needs a live connection, and yargs for command-line arguments.

The data flow is: read config.yml, read the cbList key to decide which tasks to run, hand each task name to its module in scripts/, let that module replay the site's own check-in request with your stored cookie, then pass the result to sendmsg.js for a push notification. State lives on the remote site, not locally, so there is no database and no migration story. That is why the whole project is a folder of scripts rather than a service.

One design consequence is worth stating plainly: because each module mimics a private app or mobile-web endpoint, a site changing its request signing breaks exactly one file. The README's changelog shows this pattern of incremental additions rather than refactors, and the author's own note says the code was written by someone who "didn't know what JS was" at the start and copied from others. Treat scripts/ as a collection of independent, unevenly maintained adapters, because that is what it is.

Installing checkbox and running your first task

The README's local path is four commands. Clone the repository, enter the directory, install dependencies, run the entry point. Note that the README itself writes `node checkbox.js`, while package.json's start script points at index.js, so both entry points exist in the tree.

git clone https://github.com/Wenmoux/checkbox.git
cd checkbox
npm install
node checkbox.js

Before that last command works you need a config file. The README says to copy config.yml.temple and rename it to config.yml, then fill in the cookies for the sites you want, without changing the existing format. It adds a warning worth repeating: every colon must be followed by a space.

cp config.yml.temple config.yml

Inside config.yml, the task list is the cbList key. If you would rather not edit the list, the README says you can append script names after the entry point, separated by spaces, which is the form used for scheduled jobs.

node checkbox.js acfun csdn

For the Sector0x Microtown task, the README gives a dedicated block. You first log in officially to obtain access_token and refresh_token, then place them under the sector0x key along with missions, limit, slot_count and the flags dry_run, yes, log_limit and note_limit. The README states that yes: true is required for a real claim or creation, and dry_run: true only previews. The task name is sector0x.

node checkbox.js sector0x

If you run it in Qinglong instead, the README provides a single ql repo line, notes that the panel's RepoFileExtensions setting must include sh, that you add a scheduled task for that repo command, that you run the install task manually without disabling it, and that you fill cookies and cbList in ql/data/config/config.yml. It also warns that the latest Qinglong version is required, otherwise you create the config file by hand.

Where checkbox breaks, and what it does not promise

Cookies expire. Every task in this project depends on a cookie or token you pasted by hand, and the README offers no refresh mechanism, no expiry warning, and no way to tell a failed login apart from a failed check-in beyond reading the push message. A silent failure at 3 a.m. is the normal failure mode, and you find out when the streak resets.

The second limitation is coverage drift. The README's own list shows entries struck through, such as SF轻小说 and 一亩三分地, and several entries marked complete have no link at all, including 联想智选app, 游戏动力app, 考试宝 and 克拉漫播. A checked box in that list means someone wrote a script at some point, not that the endpoint still answers today. There is no test suite: package.json's test script is `node index.js csdn`, which is a single manual invocation, not a test run.

Third, this is the wrong tool when the site offers a real API, when you need auditability, or when the account matters enough that a ban would hurt. The scripts replay mobile app traffic, and the README says nothing about rate limits, retry policy, or what happens when a site starts rejecting the pattern. If you want a supported integration, look at the platform's official developer program instead.

Finally, the README carries the line 未经允许,禁止搬运, an explicit restriction on redistributing the code, which sits awkwardly next to the MIT licence in the repository root. The licence file is what governs use of the code; the README line is the author's stated wish. If you plan to fork or republish, read both.

Checkbox versus writing your own cron scripts

The obvious alternative is a handful of curl commands in a crontab, one per site, each with its own cookie header. That approach is more transparent: you see exactly which URL is hit and with what parameters, and when a site changes, you fix one line. Checkbox wins on volume. For a single site, a curl line is better. For fifteen sites, the config.yml plus cbList model and the shared push notification in sendmsg.js is less work than fifteen separate scripts, and the per-site signing logic that some of these platforms require (which is why crypto-js is a dependency) is already written.

The other alternative is a hosted multi-account check-in panel. Those usually add a web UI, account management and scheduling, at the cost of running a service and trusting it with your cookies. Checkbox keeps everything in a file you own, which is the trade it makes: no UI, no account store, but also no server to maintain beyond whatever cron or Qinglong instance you already have.

Maintenance, updates and what the MIT licence means here

The repository is not archived and the last push was on 2026-06-19, about three months before this writing. The changelog's most recent entry is dated 2026-05-17 and adds the Sector0x Microtown task; before that, entries are spaced months apart through 2024. So the project receives occasional additions, mostly new site scripts, rather than continuous work. Plan for that rhythm: you are not pulling weekly fixes, and a site that breaks may stay broken until someone files an issue or sends a pull request, which the README explicitly invites.

Upgrade cost is low in the abstract and annoying in practice. There are no releases in the repository metadata, so updating means pulling master and re-running npm install. Your config.yml is not part of the repository, so it survives a pull, but any change to config.yml.temple's structure means comparing the two files by hand. If you run under Qinglong, the README's ql repo command is what refreshes the scripts.

On licensing, the repository ships an MIT licence file, which permits use, modification and redistribution with the copyright notice. The README separately asks that the code not be reposted without permission. I am not a lawyer and this is not legal advice; if you intend to redistribute, the two statements are in tension and you should resolve that yourself rather than assume the permissive one wins.

Editorial conclusion

Adopt it if you already keep cookies for a handful of the listed sites and want one cron entry instead of ten. Do not adopt it if you need a supported API, a stable plugin interface, or help with a site that is not in the checklist. Before running anything, copy config.yml.temple to config.yml, keep the space after every colon, and confirm the site you care about is still marked with an x in the README's sign-in list rather than struck through.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Wenmoux/checkbox on GitHub