workbuddy-auto-signin: a single-file Python script that claims WorkBuddy's daily points

The problem: points that only accrue if you open the client

WorkBuddy is Tencent's AI workbench, and its points accrue through daily check-in plus a set of growth-centre actions: travel gifts from Buddy, dispatching Buddy, opening blind boxes, claiming tasks, streak redemption and make-up check-ins for missed days. The README frames the script's purpose narrowly: claim the daily check-in points automatically. That framing undersells it, because the growth-centre table lists eight separate reward flows the script also drives.

The audience is narrow and specific. You need to have installed and signed in to the WorkBuddy desktop client, because the script authenticates with the credential file that client writes on login. It reads only that local file. The README states the repository contains no keys and is safe to share, which matters if you plan to fork it or hand it to a colleague.

If you never open the desktop client, the script has nothing to read. That is the first boundary to understand.

How the script authenticates and what the check-in loop actually does

There is one Python file, signin.py, and no package manifest. The README lists zero dependencies: standard library only, any Python 3. Authentication comes from the credential file the desktop client writes, and the script auto-detects the credential path per platform (Windows, macOS, Linux). No token is bundled in the repository.

The check-in logic is described as idempotent: query state first, claim only if unsigned. Running it twice does not double-claim, and the README notes the endpoint tolerates both response shapes for an already-signed account. The script recognises HTTP 401 and 403 as an expired login, and recognises when it is outside a check-in season. Those are the failure paths it names; anything else falls back to a generic error string in the report.

Output is a single line of JSON. The README gives this example: 成功领取 100 积分（连续 7 天，累计 700 积分）, which is a success report carrying the streak length and cumulative total. That one-line contract is what makes the script composable: a timer can write it to a log, or an AI automation can read the report field and relay it.

Version 1.6.0 introduced polling make-up check-ins, described in the release title as changing check-in opportunities from once a day to seven times. Version 1.4.0 addressed server faults being silently swallowed and made blind-box failures self-diagnosing. Those two releases tell you where the sharp edges were.

Installing workbuddy-auto-signin and running it once by hand

There is no package to install. Clone the repository, or use the repository page's Code then Download ZIP option if git is not available; the README says the result is the same. Then run the script in the foreground before you schedule anything.

git clone https://github.com/88lin/workbuddy-auto-signin.git
cd workbuddy-auto-signin
python3 signin.py auto

On Windows the README uses python rather than python3. If you are unsure which command exists on your machine, run python3 --version and python --version and use whichever produces output. The auto argument is the one the README passes in every example, including the AI-automation prompt.

What you should see is one line of JSON. The report field carries the human-readable result, such as the points claimed, the streak, and the cumulative total. If that line says the login state has expired, or that no credential file was found, the script cannot proceed and you need to sign in to the desktop client again.

For Windows scheduling, the repository ships install-windows.ps1. Run it from the repository directory:

powershell -ExecutionPolicy Bypass -File .\install-windows.ps1

The README states this creates two scheduled tasks, WorkBuddyAutoSignin at 00:05 daily and WorkBuddyGrowthPoll every four hours, both silent, both writing to signin.log, both set to catch up after a missed run. It detects pythonw.exe and signin.py automatically. If detection fails, the README says to edit the $ManualPythonw variable at the top of the script and point it at the full path to pythonw.exe. macOS uses a launchd template instead: workbuddy-auto-signin.plist.example, which the README says requires editing absolute paths into it before loading. The example plist is a template, not a drop-in file.

Why the Windows installer creates two tasks instead of one

This is the most interesting design decision in the project and the README defends it at length. Check-in is once a day. The growth centre is not. Buddy leaves on a trip and returns with a gift after one to four hours, and the gift has to be claimed manually. A single 00:05 run means a gift that arrives at 03:00 sits unclaimed until the next day, and the day's single dispatch slot goes unused if that run fails.

So the four-hour poll exists for two reasons. It claims gifts as they arrive and re-dispatches Buddy, and it also re-checks check-in state, claiming only if unsigned. That second job is a safety net for the 00:05 run: if the machine was off, asleep, or the network was not up yet, the poll catches it. The README argues the cost is negligible because an already-signed account only produces a query request, and the endpoint is idempotent.

That reasoning is sound, but it depends on the endpoint genuinely being idempotent, which is a claim about someone else's server rather than about this code. If Tencent changes the semantics, the safety net becomes a source of duplicate calls. The four-hour interval is also a fixed constant in the installer, not a documented configuration knob.

The AI-automation mode and what it costs you

The second scheduling mode does not use the system timer at all. WorkBuddy's own automation feature triggers on a schedule, runs the script, and an AI model reports the result. The README is explicit that this consumes one model call per run and leaves one chat record per run. The check-in logic is deterministic code; the model only runs the command and relays the report field.

Cross-platform coverage is the reason to pick this mode: it works on Linux, which the system-level mode does not. The README's prompt template tells the automation to run the script with auto, report the report field in one sentence, and additionally alert the user if the report contains any of four strings: claim failed, login state expired, no credential file found, or network unreachable. That string-matching contract is fragile in an obvious way. It depends on the script's error wording staying stable, and the README does not document those strings as a stable interface.

The README also offers a one-shot setup path: paste the repository URL into WorkBuddy and ask it to clone the repository and set up a 00:05 daily check-in. It distinguishes this clearly from the recurring prompt, noting the setup instruction runs once while the automation prompt runs on every trigger. That distinction is easy to miss and worth reading twice.

Where this breaks, and when it is the wrong tool

The README is unusually candid about the central risk: the check-in endpoint was reverse-engineered from the desktop client, and a Tencent release can invalidate it. The repository's own tip asks readers to star it so they can find their way back when a streak mysteriously breaks. That is not marketing language; it is an accurate description of the maintenance model. You are depending on a third party's private API and on the author noticing when it changes. The last push was on 2026-09-14, and releases shipped on 2026-09-09, 2026-09-10 and 2026-09-11, so the project is currently being fixed quickly. That cadence is not a guarantee about next quarter.

Second, the script cannot run anywhere except a machine with the desktop client's credential file. That rules out a server, a container, or CI. The README states this plainly: scheduling must run locally because the script depends on the local desktop login state. Any plan that involves a VPS is a plan this project does not support.

Third, the failure surface is under-documented. The README does not document rollback, does not document how to revoke or rotate the credential the script reads, and does not describe what happens to the growth-centre flows when only part of them fail. Version 1.4.0's release note about server faults no longer being silently swallowed suggests that earlier versions could fail quietly, which is the worst behaviour for an unattended timer.

If you only want the daily check-in and nothing from the growth centre, the two-task Windows installer is more machinery than you need. Mode A with a single daily automation would do.

Alternatives and the licence question

The realistic alternative is not another script. It is the WorkBuddy client itself, or the browser version. Opening the desktop client once a day and clicking through the growth centre costs a minute and carries no reverse-engineering risk: when Tencent changes an endpoint, the client changes with it. The difference in approach is total. This project reimplements the client's HTTP calls from the outside and inherits every breaking change; the client is the thing being imitated.

A middle option is a general-purpose browser or UI automation tool driving the web interface. That approach survives API changes but breaks on layout changes, needs a logged-in browser session, and is heavier than a single Python file. The README does not compare against any of these, so treat the trade-off as yours to make rather than one the project has argued.

The licence is MIT, per the LICENSE file and the repository's licence badge. MIT is permissive: you can modify and redistribute, including commercially, provided the copyright notice and permission notice are preserved. That is a statement about the licence text, not legal advice, and it does not address the separate question of whether automating a service's endpoints is permitted by that service's terms. The README says nothing about WorkBuddy's terms of service, and the repository contains no disclaimer section. If that question matters to your organisation, it is unanswered here.

Editorial conclusion

Adopt it if you already run the WorkBuddy desktop client on a machine that stays on, you are comfortable with a reverse-engineered endpoint, and you want the growth-centre rewards claimed without opening the app. Do not adopt it if you use WorkBuddy only in a browser, or if you need a supported API with a stability guarantee. Before scheduling anything, run signin.py once in the foreground and confirm the JSON report matches your actual account state.

Frequently asked questions

Official sources

1. 88lin/workbuddy-auto-signin on GitHub
2. License: MIT
3. Project website
4. README
5. Releases