workbuddy-checkin

WorkBuddy Daily Credits Check-in

Automatically claim WorkBuddy daily credits (100 credits/day, 1000 credits on the 7th consecutive day). The entire process runs locally: read the local login state → call Tencent's official check-in API. No backend service.

How It Works

1. After logging in to the WorkBuddy desktop client, the login state is saved locally.The new desktop client v5.3.8+uses a JSON file:
   • macOS：~/Library/Application Support/CodeBuddyExtension/Data/Public/auth/workbuddy-desktop.info
   • Structure { account, auth: { accessToken, refreshToken, expiresAt, ... }, accounts }, the desktop client automatically refreshes it near expiry.
2. accessToken storage form falls into two types by version(both supported since 1.0.6):
   • v5.3.8 ~ 5.5.x: plaintext string, read directly by pure Node;
   • v5.6.2+：$wbEncrypted envelope object（{ $wbEncrypted: 1, envelope }, AES-256-GCM). The symmetric static key required for decryption is compiled into the WorkBuddy customized Electron; the script uses ELECTRON_RUN_AS_NODE=1(pure Node mode, without launching the GUI) to call its native binding workbuddyStorage.loggerGet() to obtain it, then follows the official AtRestCrypto sym-v1 format (sha256-derived key + domain-separated AAD) to complete decryption in this process. It follows the official key management throughout, without hardcoding any key.
3. Older WorkBuddy/CodeBuddy still stores the auth session encrypted with Electron safeStorage in state.vscdb; when the new login state file is missing, it falls back to this path, using the Electron runtime to execute safeStorage.decryptString() decryption (macOS hits the keychain; Windows/Linux uses DPAPI/keyring).
4. Runtime strategy:Node first(reads the new login state file, no Electron needed), falls back to Electron when missing (to decrypt the old state.vscdb). The WorkBuddy binary used for envelope decryption is automatically located on machines with the desktop client installed.
5. Call Tencent's official check-in API:
   • Check status:POST https://copilot.tencent.com/v2/billing/meter/checkin-status
   • Perform check-in:POST https://copilot.tencent.com/v2/billing/meter/daily-checkin
   • Authentication:Authorization: Bearer <accessToken>, and per the desktop client buildHeaders attach X-User-Id: <account.uid>; when there is auth.domain add X-Domain, enterprise accounts additionally add X-Enterprise-Id / X-Tenant-Id
   • Compatibility notes:checkin.ps1 uses the above /v2/ full signature (aligned with the desktop client);checkin.sh still uses the old form without the /v2/ prefix, with only Authorization .Both forms tested return 200(see the verification matrix in CHANGELOG 1.0.3), the gateway currently does not enforce /v2/ or X-User-Id; aligning with the desktop client is forward-compatibility hardening, not a necessary condition for fixing 401
6. The script is idempotent: directly calls daily-checkin(no longer pre-checks checkin-status）。daily-checkin returns code=10001(already checked in today) is treated as success;today_checked_in field is unreliable, pre-checking would instead miss check-ins on false positives and interrupt the consecutive check-in streak.

⚠️ v5.3.8 tested checkin-status 's today_checked_in field is unreliable (may still be falseafter a successful check-in), the logic originally planned for pre-check skipping has been removed; idempotency relies entirely on daily-checkin 's code=10001 fallback.

Compatible with legacy app name CodeBuddy(only legacy state.vscdb branch requires it; on macOS set the environment variable WB_CHECKIN_APP_NAME=CodeBuddy）。

File structure

workbuddy-checkin/
├── SKILL.md
├── references/
│   └── dependencies.md         # 依赖清单与平台差异
└── scripts/
    ├── decrypt-token.js        # 解密令牌（跨平台）
    ├── checkin.sh              # macOS / Linux / Git Bash
    ├── checkin.ps1             # Windows PowerShell
    ├── setup.sh                # macOS / Linux 一键安装
    └── setup.ps1               # Windows 一键安装

logs/ directory is created automatically after running, storing check-in logs.

Dependencies

System dependencies

Dependency	Purpose	Installation method
WorkBuddy desktop app (logged in)	Provides local login state (v5.3.8+ plaintext file / legacy state.vscdb）	Download from official website; must have logged in at least once
Node.js (20+ recommended, required for the v5.3.8+ main path)	Reads the new plaintext login state, parses JSON	Download from nodejs.org, or use the system package manager
curl (built into macOS/Linux) / curl.exe	Calls the check-in API	Built into Windows 10 1803+
Electron runtime (≥ 30, 37 recommended)	Only legacy state.vscdb branch uses it to decrypt tokens	Only needed for legacy accounts; run scripts/setup.sh or setup.ps1

v5.3.8+ users: just install Node.js and log in to the desktop app to check in directly,no need to install Electron. Electron is only used for legacy WorkBuddy/CodeBuddy accounts that have not yet migrated to the new plaintext storage.

Ready to use vs. requires installation

• Ready to use (v5.3.8+): WorkBuddy desktop app installed and logged in + Node.js already on the system → run the check-in script directly.

• Node.js required: when prompted "Node not found", install it from nodejs.org, or use WB_CHECKIN_NODE=<path> to specify it.

• Legacy accounts require Electron: when using legacy WorkBuddy/CodeBuddy (state.vscdb) and prompted "Electron not found", run:

  # macOS / Linux
  bash scripts/setup.sh
  # Windows（PowerShell）
  powershell -ExecutionPolicy Bypass -File scripts\setup.ps1
  

Optional / fallback dependencies

Dependency	Behavior when missing
Electron runtime	Only legacy state.vscdb accounts require it; the v5.3.8+ new plaintext path does not
Node.js built-in node:sqlite(included with Electron 37 / Node 22+)	The legacy branch automatically falls back to python3 to read sqlite
python3	The sh version's JSON parsing degrades to unknown, the check-in request will still be executed
npm(only used by the legacy setup when installing Electron for the first time)	After manually placing Electron, use WB_CHECKIN_ELECTRON=<path>（sh）/ -ElectronPath <path>(ps1) to specify it

For complete dependency details, see references/dependencies.md。

Quick start

macOS / Linux：

bash scripts/setup.sh     # 检测运行时并验证令牌链路（v5.3.8+ 用 Node，旧版才需 Electron）
bash scripts/checkin.sh   # 立即签到一次（验证）

Windows（PowerShell）：

powershell -ExecutionPolicy Bypass -File scripts\setup.ps1
powershell -ExecutionPolicy Bypass -File scripts\checkin.ps1

Prerequisite: the WorkBuddy desktop app is installed andlogged in on this machine; Node.js is installed on the system (v5.3.8+ main path).

Set up scheduled tasks

If the computer is not on all day, it is recommended to configure multiple time points for catch-up check-ins (the script is idempotent, repeated runs have no side effects). Recommended 09:00 / 12:00 / 15:00 / 18:00 / 21:00 to try once each; as long as the computer is on at any one of the time points, the check-in will succeed.

macOS / Linux（crontab）

crontab -e
0 9,12,15,18,21 * * * /path/to/scripts/checkin.sh >> /path/to/logs/checkin.log 2>&1

Windows (Task Scheduler)

schtasks /Create /TN WorkBuddyDailyCheckin /TR "powershell -ExecutionPolicy Bypass -File C:\path\checkin.ps1" /SC DAILY /ST 09:00 /F
schtasks /Create /TN WorkBuddyDailyCheckin2 /TR "powershell -ExecutionPolicy Bypass -File C:\path\checkin.ps1" /SC DAILY /ST 12:00 /F
# （schtasks 单任务只支持一个 /ST，多时间点需建多个任务）

macOS launchd (long-term background)

Create ~/Library/LaunchAgents/com.user.workbuddy-checkin.plist，StartCalendarInterval to configure multiple time points with an array:

<key>StartCalendarInterval</key>
<array>
  <dict><key>Hour</key><integer>9</integer><key>Minute</key><integer>0</integer></dict>
  <dict><key>Hour</key><integer>12</integer><key>Minute</key><integer>0</integer></dict>
  <dict><key>Hour</key><integer>15</integer><key>Minute</key><integer>0</integer></dict>
  <dict><key>Hour</key><integer>18</integer><key>Minute</key><integer>0</integer></dict>
  <dict><key>Hour</key><integer>21</integer><key>Minute</key><integer>0</integer></dict>
</array>

Then launchctl load ~/Library/LaunchAgents/com.user.workbuddy-checkin.plist。

Within WorkBuddy (Agent automation)

In the WorkBuddy environment, you can call the automation task tool (automation_update, recurring type), RRULE multi-value BYHOUR verified effective:

{
  "name": "WorkBuddy 每日积分签到",
  "scheduleType": "recurring",
  "rrule": "FREQ=DAILY;BYHOUR=9,12,15,18,21;BYMINUTE=0;BYSECOND=0",
  "cwds": ["<用户工作目录>"],
  "status": "ACTIVE",
  "prompt": "运行 Bash 脚本 scripts/checkin.sh（Windows 用 checkin.ps1）。该脚本幂等：今日已签到会直接跳过。读取输出并汇报：签到成功领取多少积分 / 今日已签到 / 令牌失效需打开 WorkBuddy 刷新。"
}

Note:update When a task already exists, you must explicitly pass rrule, otherwise it may be reset;cwds cannot use a Claw workspace.

Platform notes

The new-version login state file (v5.3.8+, main path: plaintext / v5.6.2+ envelope, read by Node) and the old-version state.vscdb(fallback path, Electron decryption) are both auto-detected.

Platform	Script	New-version login state file (v5.3.8+, main path)	Old-version state.vscdb (fallback)
macOS	checkin.sh	~/Library/Application Support/CodeBuddyExtension/Data/Public/auth/workbuddy-desktop.info	~/Library/Application Support/WorkBuddy/User/globalStorage/state.vscdb
Windows	checkin.ps1(or run in Git Bash checkin.sh）	%LOCALAPPDATA%\CodeBuddyExtension\Data\Public\auth\workbuddy-desktop.info(fallback %APPDATA%）	%APPDATA%\WorkBuddy\User\globalStorage\state.vscdb
Linux	checkin.sh	~/.config/CodeBuddyExtension/Data/Public/auth/workbuddy-desktop.info	~/.config/WorkBuddy/User/globalStorage/state.vscdb

Windows PowerShell execution policy uses -ExecutionPolicy Bypass; requires curl.exe(built into Win10 1803+). The old-version state.vscdb branch on Linux requires a desktop session + system keyring (GNOME Keyring / KWallet); the new-version plaintext branch has no such requirement.

Environment variables

Variable	Purpose
WB_CHECKIN_NODE=<path>	Specify the Node binary path (used by the v5.3.8+ main path, common to sh/ps1)
WB_CHECKIN_WORKBUDDY_BIN=<path>	Specify the WorkBuddy desktop main program path (used by v5.6.2+ envelope decryption to obtain the static key; set when auto-detection fails)
WB_CHECKIN_ELECTRON=<path>	Specify the Electron binary path (only used by the old-version state.vscdb fallback, sh version)
-ElectronPath <path>	Same as above (ps1 version parameter)
WB_CHECKIN_APP_NAME=CodeBuddy	Compatible with the old-version app name (only for the macOS keychain key of the old-version state.vscdb branch)
WB_CHECKIN_JITTER=<秒>	Randomly wait 0~N seconds before starting, to avoid on-the-hour storms

Troubleshooting

• Check-in fails after upgrading WorkBuddy to 5.6.2+, reporting "new-version plaintext authentication file not found" (< 1.0.6): The desktop app has changed accessToken to $wbEncrypted envelope encryption (issue #191). Upgrade the skill to 1.0.6+ to decrypt; starting from 1.0.6, if it still fails it will report the exact reason (see the next item).
• Reports "unable to obtain static key from WorkBuddy customized Electron": v5.6.2+ envelope decryption requires locating the WorkBuddy desktop main program (invoked in pure Node mode, without launching the GUI). When auto-detection paths do not cover a custom installation location, use WB_CHECKIN_WORKBUDDY_BIN=<主程序路径> to specify explicitly (on Windows it is generally WorkBuddy.exe, on macOS it is the main binary under WorkBuddy.app/Contents/MacOS/ ). If it reports "static key does not match envelope keyId", it means the official encryption scheme has been changed; please file an issue.
• "Failed to obtain token (unknown reason)" / local login state not found: First confirm that the WorkBuddy desktop app is logged in and has been opened at least once. v5.3.8+ users should check whether Node.js is installed (node -v), or use WB_CHECKIN_NODE to specify.
• v5.3.8 is logged in but still reports token failure: The local skill version is too old (< 1.0.2) and does not recognize the new-version plaintext storage; upgrade to 1.0.2+.
• Re-running on the same day prompts "check-in unsuccessful / code=10001": Old versions (< 1.0.2) did not recognize code=10001 as "already checked in"; 1.0.2+ will correctly report "already checked in today".
• 401 token expired: Open WorkBuddy to refresh the login state; the script re-reads the latest token on each run and automatically recovers the next day.
• Occasional "token expired (401)" but normal again the next day (< 1.0.3): The 401 determination originally scanned the response body for a substring; the random requestId contains exactly 401 it will be misjudged (about 0.57% per occurrence), the daily check-in is skipped and the consecutive check-in streak is broken. Starting from 1.0.3, the real HTTP status code is used for the determination.
• Windows is logged in but keeps returning 401 (< 1.0.3): the win32 candidate in 1.0.2 only probes %APPDATA%, while the desktop client actually writes the plaintext login state to %LOCALAPPDATA%; when the new file cannot be read, it falls back to the old state.vscdb, obtaining anexpired historical session token, manifesting as "can get a token but the API returns 401". Starting from 1.0.3, it prioritizes probing %LOCALAPPDATA%。When troubleshooting 401, first confirm the token source rather than suspecting the request path or request headers(measured: the gateway does not enforce /v2/ and X-User-Id, see CHANGELOG 1.0.3).
• macOS decryption error but already logged in (old-version account): the old-version migration app name is still CodeBuddy, set export WB_CHECKIN_APP_NAME=CodeBuddy and retry (only takes effect when going through the state.vscdb branch).
• Electron download slow/failed (old-version account): configure the npm mirror (see references/dependencies.md) then rerun setup; or manually place Electron and specify it via environment variable/argument. v5.3.8+ new-version accounts do not need Electron.
• Windows reports not an internal or external command: run with powershell -ExecutionPolicy Bypass -File … ; confirm that curl.exe exists.
• In the sandbox require('electron') reports an error: the Agent sandbox sets ELECTRON_RUN_AS_NODE=1by default, the script already handles it with env -u（sh）/ Remove-Item Env:(ps1); the v5.3.8+ main path uses pure Node and is not affected by this.

Windows compatibility fixes (1.0.4)

Validation for 1.0.3 and earlier versions was all done on macOS (see CHANGELOG "Known Limitations"). 1.0.4 fixes 3 issues exposed by actual runs on Windows (Git Bash / PS 5.1):

#	File	Symptom	Root cause	Fix
1	checkin.ps1	表达式或语句中包含意外的标记"}", the script cannot run at all	The file isUTF-8 without BOM, PS 5.1 parses it as GBK, the Chinese comments become garbled and break the syntax	Add UTF-8 BOM (zero code changes)
2	checkin.ps1	签到未成功：PARSE_ERR	[Console]::OutputEncoding Chinese Windows defaults to GB2312, which decodes UTF-8 JSON into garbled text andeats the closing quote，ConvertFrom-Json throws an error	Invoke-CheckinApi and restore afterward
3	checkin.sh	未找到 Node 或 Electron 运行时(but node -v is normal)	SCRIPT_DIR is MSYS's /c/..., when passed to native node.exe it gets concatenated into C:\c\Users\... → Cannot find module → the token is empty	Use cygpath -w to normalize the path passed to Node; JSON parsing changed to Node first, python3 fallback(Node is already a required dependency)

Troubleshooting tip: the error message for item 3 is extremely misleading—it tells you to install Node.js, but Node is fine; the real cause is swallowed by the decrypt called by 2>/dev/null . When you encounter this one,first run node "<脚本绝对路径>/decrypt-token.js" directly to see the real error。

Known behavior (not a bug)

• On duplicate check-in, daily-checkin returns HTTP 400(only the first check-in is 200), the business body is code=10001. The judgment basis is always the business entity's code=10001, and both scripts have treated it as successful.

Security Notes

⚠️ Credentials are the account and password: the accessToken decrypted by this skill is equivalent to your WorkBuddy account password and is highly sensitive. You must observe the following red lines:

• The token is used only in memory and is immediately consumed by the check-in request through a pipe,it is not written to any log file, not persisted to disk, not echoed to the terminal, and not committed to the repository。
• logs/ Only the check-in result is recorded (points / consecutive days / success or failure),never the original token text. Never paste or share logs or script output.
• Network access is sent only to Tencent official interfaces copilot.tencent.com/billing/meter/* and copilot.tencent.com/v2/billing/meter/*, and nothing is uploaded to any third party.
• On successful decryption, the script prints a security notice to stderr (without affecting the token pipe on stdout), so you can confirm that the credentials are being used.
• Do not use it for other people's accounts, bulk registration to farm points, or any purpose that violates the WorkBuddy user agreement; users bear the risk of use themselves.

Why these capabilities are needed (context explanation)

This skill describes itself as "daily check-in", but the complete chain requires the following capabilities, all of which run locally, have no backend, and are essential to completing the check-in:

• Read the local token: After logging in to the WorkBuddy desktop client, the login state is stored locally—v5.3.8+ uses a plaintext JSON file (workbuddy-desktop.info, readable by pure Node), while older versions use Electron safeStorage encrypted state.vscdb. It must read accessToken to call the official check-in interface; this is the core of the check-in function and cannot be bypassed.
• Node.js runtime: The main path for v5.3.8+ uses Node to directly read the plaintext login state and parse the JSON. It is recommended to manually specify a verified Node (set WB_CHECKIN_NODE）。
• Electron runtime (older accounts only): Only needed when using the older WorkBuddy/CodeBuddy (state.vscdb), to execute safeStorage.decryptString() to decrypt the token (on macOS it hits the keychain, on Windows/Linux it uses system DPAPI/keyring). It is recommended to manually specify a verified Electron (set WB_CHECKIN_ELECTRON), without relying on automatic download.
• python3 fallback (disabled by default): Only when the older branch's node:sqlite is unavailable, setting WB_CHECKIN_ALLOW_PY_FALLBACK=1 will call the external python3 to read the session store. It is disabled by default to reduce the trust boundary.
• Scheduled tasks (crontab / launchd / Task Scheduler): Used for idempotent make-up check-ins at multiple time points; the script itself does not write system schedules, and you need to configure them explicitly.

Supply chain notice

Installing Electron by defaultdoes not download automatically(to avoid silently introducing a large third-party binary). If automatic installation is needed, you must explicitly set the environment variable WB_CHECKIN_AUTO_INSTALL_ELECTRON=1 to confirm downloading electron@37。

Required permissions

This skill requires the following local permissions to run, all limited to the minimum scope:

Permission	Scope	Description
Local code execution	Only this skill's checkin.sh/.ps1、decrypt-token.js、setup.sh/.ps1, and in pure Node mode (ELECTRON_RUN_AS_NODE=1) Call the local WorkBuddy main program to extract the static key (for v5.6.2+ envelope decryption, without launching the GUI or modifying any WorkBuddy state)	Triggered manually by the user or on a schedule, not resident in the background
Local file reading	WorkBuddy login state under the user directory (v5.3.8+ login state file workbuddy-desktop.info / legacy state.vscdb）	Read the login state to obtain the accessToken required to call the official API
Network access	Only copilot.tencent.com official check-in API	Does not access any other domains
Environment variable reading	WB_CHECKIN_*(Node/WorkBuddy/Electron paths, app name, staggered timing, fallback switch)	All are explicitly configured by the local user
Scheduled tasks	crontab / launchd / Task Scheduler explicitly configured by the user	The skill does not automatically write system schedules