workbuddy-switch: a Tauri account switcher for WorkBuddy and CodeBuddy CLI

The problem: one login slot, several WorkBuddy accounts

WorkBuddy and CodeBuddy CLI keep a single active login on disk. The README describes the shared state file as workbuddy-desktop.info, and every account you own competes for that one slot. If you have a personal account, a team account and a spare with expiring credits, moving between them means backing up an auth file, closing the client, writing new credentials and restarting. That is the workflow workbuddy-switch automates.

The project is aimed at people who already run WorkBuddy or CodeBuddy CLI and hold more than one account. That includes anyone juggling credits with different expiry dates, and anyone who wants CodeBuddy CLI to prefer whichever account is about to waste credits. It is not a general credential manager and it does not create accounts; it moves existing login state around.

How the switch actually works: backup, close, write, restart

The README is explicit about the sequence for a WorkBuddy switch: back up the authentication file, close WorkBuddy, write the target account, restart. Progress is reported live in the UI. That ordering matters, because the client holds the auth file while running, so writing underneath a live process is the failure case the app is designed to avoid.

Session copying is a separate mechanism. Selected sessions are copied to the target account under new ids, and the README names three pieces: the jsonl body, a workbuddy.db index, and edge-sync registration. Cloud attribution follows the target account. This is a copy, not a move, so the source account keeps its sessions.

CodeBuddy CLI reuses the same account library but keeps its own default account. On macOS and Linux the integration goes through apiKeyHelper; on Windows it writes env.CODEBUDDY_AUTH_TOKEN into ~/.codebuddy/settings.json. The README states that neither path touches the token a running session already holds. That single design decision explains most of the project's rough edges.

The CodeBuddy CN IDE path is different again. It injects Safe Storage credentials into the CodeBuddy CN desktop client, naming state.vscdb and planning-genie.new.accessTokencn, then restarts the IDE. The README says this is unrelated to CodeBuddy CLI and to the international CodeBuddy build.

Installing from npm and running the first switch

The npm route gives you the same interface as the desktop app in a browser. Install it globally and run it with no arguments to start a local service and open the browser:

npm i -g workbuddy-switch
workbuddy-switch

A second command prints the current account to the terminal, which is the quickest way to confirm the tool can read your existing login state before you change anything:

workbuddy-switch status

For the desktop build, the README points to GitHub Releases rather than a package manager. The macOS Apple Silicon package is workbuddy-switch_<version>_aarch64.dmg, Windows x64 uses workbuddy-switch_<version>_x64-setup.exe, and Linux x64 ships a .deb plus an AppImage. In the webui mode the README notes that permissions come from the terminal process that started the service, so a terminal with Full Disk Access needs no further step.

Once running, the flow is add an account by OAuth device flow scan, import from the machine, or paste a token manually, then use the switch action on the account card. If macOS reports no permission on the first switch, the README directs you to App Management first and Full Disk Access second, then a restart of the app. Only when an official release package still reports as damaged does it suggest clearing the quarantine attribute:

xattr -rd com.apple.quarantine "/Applications/workbuddy-switch.app"

Auto rotation and the limits of a helper-based switch

The most interesting feature is background rotation for CodeBuddy CLI. The app periodically queries credit expiry across accounts and sets the CLI default to the most urgent account, meaning the one expiring soonest that still has credits. Seven decision rules gate each check, and they exist to stop the default account flapping. There is a cooldown of cooldown_minutes (default 120), an active guard of active_guard_minutes (default 30) that skips rotation when a CLI session has written recently, a minimum urgency of min_urgency_hours (default 72), and a minimum expiry gap of min_gap_hours (default 24) so a marginal difference does not trigger a switch. A value filter, min_remaining_credits, defaults to 0 and is off.

Those settings live in ~/.wb-switch/auto_rotate_config.json or the settings page, alongside check_interval_minutes (default 5).

The limitation is stated plainly in the README and is worth repeating: rotation only updates the default account used by later restore or load operations. It does not hot-switch a running session. On macOS and Linux the next helper execution reads the newest account; on Windows the newest token goes into settings. Either way you must reload the session through ACP or restart CodeBuddy CLI. The README also warns that running /resume in the same process does not guarantee the authentication config is re-read. If your expectation is that the account changes mid-conversation, this is the wrong tool.

Credit and token statistics, and where the numbers come from

The account cards surface credit balance and expiring resources, with anything expiring within seven days highlighted and sorted by urgency, the top card labelled as suggested for priority use. Filtering by account or time range does not re-request the official interface; only the refresh action triggers collection. That is a deliberate caching choice, and it means a filtered view can show older numbers than the header timestamp suggests.

Credit statistics aggregate official request usage into daily trends, model distribution, per-account consumption and request detail. The README is honest about the fallback: when official data is unavailable, the page clearly falls back to local balance snapshots. Treat those two modes as different in reliability.

Token statistics cover WorkBuddy, CodeBuddy CLI and CodeBuddy IDE separately, with input, output and cache read and write shown in K, M and B units, plus composition share, a heatmap, project and model top tens and session rankings. These are reporting views over data the app already collects; they are not a billing system, and the README does not claim reconciliation with official invoices.

A real alternative: the CLI's own login flow

The obvious alternative is doing nothing and using the login command built into WorkBuddy and CodeBuddy CLI. That approach has no extra install, no permission prompt and no background process, and it never risks writing a stale token into a config file. Its cost is that every switch is manual and you must log in again each time, which is exactly the friction this project removes.

The difference in approach is that workbuddy-switch treats credentials as files to be swapped while the client is closed, whereas the native flow treats them as a session you establish interactively. The file-swapping approach is faster and scriptable through the rotation rules, but it inherits the constraint that a running process keeps whatever token it loaded at start. If you switch accounts rarely, the native flow is simpler and has fewer moving parts.

Maintenance, licence and what an upgrade costs you

The repository is not archived and the last push was on 2026-09-16, with v0.1.37 released on 2026-09-10. The version numbers in the releases are close together, which suggests a project still being adjusted rather than one in a frozen state. That also means behaviour can shift between minor releases, so pinning a version is reasonable if you depend on the rotation defaults.

The project is MIT licensed, which permits commercial and private use with the licence text retained. The README does not document rollback, so there is no stated procedure for returning to a previous version after an upgrade. Upgrades go through GitHub Releases with signature verification via tauri-updater, and the README says a new version can be applied from the lower left of the app or downloaded manually from the release page.

One maintenance cost is worth naming: the app writes into other applications' config and credential stores, including ~/.codebuddy/settings.json and the CodeBuddy CN state database. A change to how those clients store credentials would break the integration, and the README does not describe a compatibility contract with those clients.

Editorial conclusion

Adopt workbuddy-switch if you hold several WorkBuddy or CodeBuddy accounts and are tired of hand-editing auth files, and if you accept that a switch only takes effect on the next session load or CLI restart rather than mid-conversation. Skip it if you need live credential rotation inside a running session, if you are not on macOS, Windows or Linux x64, or if you will not grant the macOS App Management or Full Disk Access permission the switch path needs. Before relying on it, verify three things on your own machine: that the app can write your WorkBuddy auth file after you grant permission, that your CodeBuddy CLI picks up the new default account after an ACP reload or restart, and that the credit expiry query returns real data rather than the local balance snapshot fallback the README describes.

Frequently asked questions

Official sources

1. changexbc/workbuddy-switch on GitHub
2. Issues
3. License: MIT
4. README
5. Releases