Four brands, one debug port, and backups that survive uninstall

The whole mechanism is a relaunch into debug mode on port 9222

WorkDaddy does not patch WorkBuddy or CodeBuddy. It connects to a running client through the local debugging interface and injects its panel over that channel, leaving the official installer and its signature untouched. The developers' own instructions show what that costs in practice:

git clone https://github.com/babygoton/WorkDaddy.git
cd WorkDaddy
bash scripts/install.sh        # 创建备份目录 + 启动守护进程
bash scripts/relaunch-with-cdp.sh   # 把 WorkBuddy 切换到调试模式（端口 9222）

So using the tool means restarting the official client with a debugging port open on your machine. Which client gets attached is decided by profile rather than guessed, because the four clients share one daemon and each call sets `WBSWITCH_PROFILE` to `workbuddy-cn`, `workbuddy-ai`, `codebuddy-cn` or `codebuddy-intl` before running the same script. The page is explicit that the daemon does not attach to whichever debugging port happens to answer first. macOS has a fallback for when automatic detection is not enough, a `--configure` command taking `--profile`, `--binary` and `--data-dir`, run by hand from the source directory for clients with fully custom names. One runtime requirement is stated outright: the macOS launcher uses the machine's own Node.js, and the page asks for 22.13 or newer.

Enterprise clients are found by bundle convention, then pinned by version

Corporate and VPC builds do not follow the naming everyone else uses, so the discovery path is spelled out separately. On macOS the launcher scans for an application whose name begins with `WorkBuddy` and whose bundle contains `Contents/MacOS/Electron`, and it pops the system chooser when more than one candidate turns up, then remembers the selection so nobody has to hunt for a configuration file. On Windows the installer identifies the official client itself, shows its path and version in the wizard, and offers a Browse button for anyone whose executable sits somewhere else. The choice is stored in WorkDaddy's personal data directory and the installer keeps it on upgrade. Then comes the constraint that shapes everything afterwards: the tool locks the client version it was pointed at, so a client upgrade or a move turns into another round of confirmation through the installer.

Two of the four brands get a panel with almost nothing in it

The feature list runs to seventeen items, from per-account switching and encrypted backup export through theme takeover, session branching, sleep prevention and automation tasks. The scope table then says something much smaller. CodeBuddy does not show the Enhancement page (增强) at all, and its Theme page (主题) offers only the floating robot settings. CodeBuddy is two of the four supported clients, on the domestic and the international side. Support is narrowed by window as well: the CodeBuddy range covers the Electron agent window and explicitly excludes the enhancement panel in VS Code editor mode. So the feature inventory describes the WorkBuddy installations, and someone who installs CodeDaddy CN or CodeDaddy international gets a smaller product than the headline suggests. That difference lives in one table note rather than in the list a reader scans first, and the seventeen-item list is the one that gets quoted elsewhere.

New accounts join the list without logging the old one out

Adding an account is designed to avoid interrupting the one you are using. The login flow offers two paths: an OAuth authorization completed in the browser while WorkBuddy stays logged in, after which the new account appears in the list on its own, and a traditional fake logout that returns the client to its login page for a scan. Both routes end with several accounts side by side, each backed up separately, which is the reason the tool exists. Session handling follows the same logic. Conversations can be copied from one account to another, automatically or by hand, so a thread started under one identity continues under another. Session branching goes further: with it enabled, any single reply can become the start of a new conversation, carrying the chat up to that point and leaving the original untouched. That is a convenience for long threads, and it does mean chat history can be relocated between accounts down to a single message.

The download links are relative paths and the build commands still say 1.2.9

The install steps point at `[Releases](../../releases)`, separately for macOS, for Windows and for Linux. Read as a repository path, `../../releases` climbs out of the project directory, so the link resolves only where the page is rendered, not on the repository itself. The version numbers in the examples are stale in a second way. Three patch releases landed in three days, 1.2.9 on September 29, then 1.2.10 and 1.2.11 on October 1, while the documented build commands still set `WORKDADDY_BUILD_VERSION=1.2.9` and the Debian example installs `./CodeDaddy-CN_1.2.9_amd64.deb` by name. Building from the page therefore produces a binary two patch releases behind the newest tag. The asset names around all of this are worth keeping straight, because the four packages are not interchangeable: four DMGs on macOS, four Setup executables plus four Portable ZIPs on Windows, and four DEBs for amd64 and arm64 installing into `/opt/workdaddy`, `/opt/workdaddy-ai`, `/opt/codedaddy-cn` and `/opt/codedaddy`.

Portable on Windows keeps its data in the user profile anyway

The portable ZIP is there for people who do not want an installer, and it carries three documented restrictions. Data does not travel: account backups and runtime data stay in `%APPDATA%\WorkDaddy` and do not move with the ZIP, so the same account set has to be exported and imported separately on a second machine. Updates do not go through the panel, and the order is fixed: run `Stop-WorkDaddy.cmd`, confirm the old process has stopped, then unpack the new ZIP. And one profile cannot run twice, since the installed and portable builds of the same client are mutually exclusive. Two naming details go with it. Portable installs create no desktop shortcut and no uninstall entry, so nothing on the machine offers to remove them later, and the `*-win64.zip` files are temporary inputs to the installer build rather than release assets, even though they carry the same version numbering.

Uninstalling leaves account backups on disk

On Linux the documented removal is `sudo apt remove <包名>`, and the page states plainly that it does not delete account backups or runtime data; clearing them means working out which profile's directory under `~/.config/WorkDaddy` to remove yourself. The same pattern holds elsewhere, since macOS creates `~/Library/Application Support/WorkDaddy` and Windows keeps `%APPDATA%\WorkDaddy`. What the documentation does claim is that accounts and configuration stay on the machine, and encryption appears in exactly one place: the export feature writes all account backups out encrypted so another machine can import them in a single step. Nothing states what protects those files while they sit in the profile directory between runs, and the export path is the only place any key or passphrase is even mentioned. Treat a shared machine as a place where the previous user's accounts may still be recoverable after removal.

Automation packages are discovered from public repositories

The automation feature does not only let you write tasks inside the panel. It finds tasks in public GitHub and Gitee repositories and imports them, or asks WorkBuddy in natural language to create one. Once a task exists it can be edited, started by hand, triggered by an event or on a schedule, watched through run logs, stopped, and exported as JSON or as a ZIP. The repository carries an `examples/automation-packages/` directory and a `schemas/` directory, so there is somewhere for a task format to be described and for examples to live. What the page does not say is what happens to an imported package before it runs, whether a schema is checked at import time, or whether packages carry any signature or hash. Since discovery is explicitly a search of other people's public repositories, that gap is the part of this feature worth reading twice before enabling it.

Editorial conclusion

Use this if you run several accounts of the same assistant on one machine and want them switchable, and accept the shape of the deal: the official client is restarted with a debugging port open, and that port is the most privileged thing on the machine. Before installing, check three things. Whether the service permits multiple accounts and automated daily check-ins, because this repository does not answer that. Which data directories already hold credentials on your system, since uninstall leaves them in place. And whether your client version still matches, because the installer locks the version it was pointed at and every client update means confirming it again. Note also what the tool does not cover: no Enhancement page for CodeBuddy, no panel updater on Windows portable builds or on Linux DEBs, and no documented validation for imported automation packages.

Frequently asked questions

Official sources

1. babygoton/WorkDaddy on GitHub
2. Issues
3. Project website
4. README
5. Releases