WorkDaddy: a CDP injection layer for the WorkBuddy desktop client

The multi-account problem WorkDaddy targets

WorkBuddy is an Electron desktop client. Signing into a second account normally means signing out of the first, and the login flow runs through a QR scan or OAuth page. Anyone who keeps a personal account and a work account, or who manages several client accounts, repeats that scan every time they switch, and each switch drops whatever session state the previous account held.

WorkDaddy exists to remove that repetition. Its README describes the product as a "WorkBuddy desktop enhancement assistant" with independent per-account backups that switch on a click, cross-account session migration, and automation tasks that run on events or a schedule. The audience is narrow and practical: people who already run WorkBuddy daily, on macOS 11 or newer, or Windows 10 and 11, and who are willing to run a third-party daemon beside the official client. The README also states that account and configuration data stay on the local machine, which is the main argument for people who would otherwise keep a second machine just to hold a second login.

One detail worth noting early: the README says the daily points check-in task is disabled by default, and that the first time the panel opens it warns about account risk and asks before enabling the task. That is an unusually explicit acknowledgement that automating a vendor's sign-in flow is not risk-free.

How the CDP injection actually works

WorkDaddy does not patch or re-sign the WorkBuddy binary. The README is explicit about this: the launcher starts WorkBuddy with an extra `--remote-debugging-port=9222` argument, and the binary and its signature stay untouched. A daemon process then connects to that debugging port using the Chrome DevTools Protocol.

The data flow has four parts. First, the daemon watches login and authentication network events, with a file watcher as a fallback, and each time a login or token refresh happens it backs the current login information up under `account.uid` into a stable directory. Second, it calls `Runtime.evaluate` to push `inject.js` into the renderer process, which renders a robot button and a multi-tab panel in the lower right corner of the WorkBuddy window. Third, the daemon exposes a local HTTP API on `127.0.0.1:47832`, and the injected components call it with `fetch` for actions such as account switching, theme application, check-in, decision-dialog suppression and sleep control. Fourth, the panel itself is split into tabs: accounts, theme, sessions, models, enhancement, automation, computer and about.

The README gives its own reason for choosing CDP over an official plugin mechanism: it targets the running application instance, notices login changes at the event level, and injects interface and style patches, so it keeps working after an official WorkBuddy upgrade as long as the interface has not changed much. That is also the design's weak point, and the project says so indirectly: the whole approach rests on the assumption that WorkBuddy's renderer keeps exposing the same debugging surface and the same DOM structure.

Installing WorkDaddy on macOS and Windows

The README splits downloads by client edition. Users of the mainland WorkBuddy client download the `WorkDaddy` package; users of the international WorkBuddy AI client download the `WorkDaddy AI` package. The release assets are named `WorkDaddy-<version>.dmg`, `WorkDaddy-AI-<version>.dmg`, `WorkDaddy-Setup-<version>.exe` and `WorkDaddy-AI-Setup-<version>.exe`. On macOS you open the dmg and drag `WorkDaddy.app` into Applications. If Gatekeeper blocks the first launch, the README walks through System Settings, Privacy and Security, the "Open Anyway" button, and the admin password prompt. Launching the app starts its own daemon and injects the components; the README says you are done when you see the robot button.

For corporate or VPC clients, macOS scans automatically for apps with a `WorkBuddy` prefix that contain `Contents/MacOS/Electron`, and shows a system picker when it finds more than one candidate. A fully custom name can be configured from a source checkout:

node scripts/workbuddy-target.js --configure --platform darwin \
  --profile workbuddy-cn \
  --binary "/Applications/企业客户端.app/Contents/MacOS/Electron" \
  --data-dir "$HOME/Library/Application Support/WorkDaddy"

Running from source is the developer path. The README gives two scripts, and the second one restarts WorkBuddy in debugging mode on port 9222:

git clone https://github.com/babygoton/WorkDaddy.git
cd WorkDaddy
bash scripts/install.sh
bash scripts/relaunch-with-cdp.sh

`install.sh` creates `~/Library/Application Support/WorkDaddy`, migrates old `HelloBuddy/accounts` backups on first run while leaving the old directory in place, takes an initial backup of the current WorkBuddy account, clears old launchd registrations, starts the daemon manually, and opens the management interface at `http://127.0.0.1:47832`. The README notes that the daemon is started manually at the end of installation and is not registered for login autostart, so after a reboot you start the WorkDaddy side yourself. The mainland and international clients share one daemon and are distinguished by profile rather than by whichever CDP port answers first:

WBSWITCH_PROFILE=workbuddy-cn bash scripts/relaunch-with-cdp.sh
WBSWITCH_PROFILE=workbuddy-ai bash scripts/relaunch-with-cdp.sh

A first real use is account switching. Open the panel from the robot button, go to the accounts tab, and the README says you can view account count, points, check-in status and login state, then switch, delete or add an account, with encrypted import and export of the account backup. The "log in to a new account" path supports OAuth authorisation without quitting WorkBuddy: you scan in the browser and the account is added to the list.

Where the injection approach breaks down

The largest limitation is stated by the project's own architecture, not by a bug report. Because WorkDaddy injects into the renderer rather than integrating through a supported extension point, its compatibility is tied to WorkBuddy's interface. The README's own justification, that it works after an official upgrade as long as the interface has not changed much, is the same sentence that admits a large interface change can break the injection. There is no documented rollback path in the README if an injected component leaves the panel in a bad state.

The second limitation is operational. Automation tasks with timed or event triggers need the WorkDaddy local service to stay running, and any step that touches the page also needs the corresponding WorkBuddy client to be available. The README states this directly. So a scheduled check-in task is not a server-side job; it depends on a desktop process that the user starts manually after a reboot.

Third, task portability is partial. The README says task export does not include account backups or run logs, and that there is no online task marketplace and no automatic task updates. Imported tasks stay disabled, and tasks with the same ID are not overwritten. That is a deliberately conservative design, but it means sharing an automation package is a manual file exchange.

Fourth, the data boundary has exceptions. The README says account backups and local configuration stay on the machine, but the project also contacts WorkBuddy's official APIs for login and points, GitHub Releases for update checks, and, when you explicitly run a model connectivity test, the model service you configured together with the corresponding API key. Sanitised error diagnostics are on by default and can be turned off on the About page. Anyone who cannot accept an outbound error-reporting channel should know that the default is on.

WorkDaddy compared with a plain browser automation script

The obvious alternative is a personal Playwright or Puppeteer script that drives the WorkBuddy web interface, or a small Electron automation project that logs in, clicks through the daily check-in and copies session data between accounts. The difference is where the automation lives.

A browser script owns the whole flow: it opens its own browser, holds its own cookies, and can be run headlessly on a server. It also has to reimplement login, and it cannot see the desktop client's local state, so anything stored in the client's own data directory, including the session list and the model configuration, is out of reach unless you reverse the storage format yourself.

WorkDaddy goes the other way. It attaches to the client that is already running, uses the client's own authenticated session, and reads and writes through the client's own UI and local API surface. That is why it can offer things a browser script cannot easily do: per-account backups keyed by `account.uid`, copying a session from one account to another, and suppressing permission dialogs inside the running app. The cost is that it inherits every constraint of the host: the client must be installed, the debugging port must be open, the interface must match, and the daemon must be running. If your goal is unattended automation on a machine with no desktop session, WorkDaddy is the wrong shape; if your goal is to operate the desktop client you already use, without reimplementing its login, the injection approach is the shorter path.

The README also mentions a CodeBuddy profile whose adaptation is postponed and is not part of the current release packages. The published builds cover the two WorkBuddy clients only.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-14. Release 1.2.0 is dated 2026-09-08, with 1.1.9 on 2026-09-06 and 1.1.8 on 2026-09-05, so the release cadence in the days before that push was fast. The primary language is JavaScript.

The upgrade cost is mostly on the WorkBuddy side, not the WorkDaddy side. The README says the installer identifies the official client, shows its path and version, and lets corporate users browse to their own `.exe`; the selection is stored in WorkDaddy's personal data directory, kept on update by default, and can be changed in the installer. It also says WorkDaddy locks the selected client version, and that after a client upgrade or move you confirm again through the installer. In practice, every WorkBuddy update is a moment to check whether the panel still renders and whether the automation steps still match the interface. The README's own compatibility claim is conditional on the interface not changing much, so treat each client upgrade as a compatibility event.

On licensing, the README carries an AGPL-3.0 badge, but the repository's `LICENSE` file is reported by the hosting platform as NOASSERTION, meaning no recognised licence identifier was detected. Those two signals do not agree, and the README is not a licence grant. If you plan to redistribute WorkDaddy, ship it inside a company image, or build a derivative, read the `LICENSE` file itself and get your own legal review; nothing here is legal advice. The practical point is that you cannot rely on the badge alone.

There is also a `schemas/` directory and an `examples/automation-packages/` directory in the repository, which suggests the task JSON format is documented somewhere in-tree, but the README does not describe the schema, so anyone writing tasks by hand should read those files rather than infer the format from the panel.

Editorial conclusion

Adopt WorkDaddy if you run several WorkBuddy accounts on one machine and want account switching, per-account session copying and local automation without touching the official installer. Do not adopt it if you need a supported integration path, an audited permission model, or a client whose UI you cannot keep stable. Before installing, confirm the version of the WorkBuddy client you are targeting, because the project locks the selected client and asks you to reconfirm through the installer after a client upgrade or move, and check the LICENSE file in the repository, which GitHub reports as NOASSERTION rather than a recognised identifier.

Frequently asked questions

Official sources

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