# DSH WorkBuddy Connect: borrowing a desktop app's models for a CLI harness > This plugin exposes the models of a signed-in WorkBuddy desktop app inside DeepSeek Harness, reusing that app's login instead of asking for new credentials. It is tightly coupled to the harness kernel version, reaches into non-official client interfaces, and documents its own failure modes in detail. **corrinehu/dsh-workbuddy-connect** — 将 WorkBuddy 桌面 App 包含的模型自动接入 DeepSeek Harness，零配置使用。Bring the models in the WorkBuddy desktop app into DeepSeek Harness with zero configuration. - Repository: https://github.com/corrinehu/dsh-workbuddy-connect - Stars: 1,429 · Forks: 136 - Language: TypeScript - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/corrinehu-dsh-workbuddy-connect ## What the plugin actually connects DSH WorkBuddy Connect brings the models available in an already signed-in WorkBuddy or WorkBuddy AI desktop app into DeepSeek Harness. The premise is zero configuration: the plugin reuses the desktop app's login state, so there is no second credential to paste, and switching accounts in the app is followed automatically. Two editions exist and are kept apart. The domestic edition appears as a WorkBuddy group, the international edition as WorkBuddy AI, and the two do not mix: their models, accounts and credits are separate, each follows its own app's login state, and installing only one gives only one group. The settings screen shows one card per edition, each with its own account and balance. Beyond the model list, the plugin surfaces the things a user actually notices when working with a hosted model. The remaining credit balance appears next to the model selector in the input box, in the form WB.3,401 for the domestic edition and WB AI.3,401 for the international one, and it is not polled automatically: every read is a real billing query, so the plugin reads it once on mount and offers a manual refresh button. Rate multipliers are shown after each model name, such as GLM-5.2 multiplied by 0.79, and promotion badges such as limited-time-free or night discount appear after that. The package is MIT licensed, published as dsh-workbuddy-connect with a binary entry point and a client export, and it declares Node 22.19 or 24 or later as its engine range. ## The version matrix is the first thing to check The plugin version must match the harness kernel version, and the README is blunt that a mismatched pair causes the harness to fail at startup. The mapping it gives is short: kernel 0.2.1-rc.2 pairs with plugin 0.7.9, 0.2.1-rc.1 with 0.7.7, 0.2.0-rc.2 with 0.7.6, 0.2.0-rc.1 with 0.7.0, and 0.1.5 through 0.1.7 with 0.6.5. Older lines are kept for history only, with 0.3.1 and 0.2.6 as the last versions for their kernels. The warning that npm latest is not necessarily right for you follows from that table, and the notes column gives the reasons. Version 0.7.9 adapts only to 0.2.1-rc.2, and the README points out that 0.2.0-rc.2 and 0.2.1-rc.2 are different lines, so you should check the kernel version built into your own app rather than assume. Version 0.7.7 came with a kernel upgrade to @earendil-works/pi-ai 1.3.0, which meant a leftover 0.87.1 override had to be removed. Version 0.7.6 fixed missing enterprise model catalog entries, and 0.7.1 dropped support for 0.2.0-rc.1 entirely. That coupling is the price of the integration. A plugin that patches the harness client and reads another app's private interfaces has to move in step with both, so the release history reads as a series of adaptations rather than as independent feature work. ## Installing per interface, and why the Desktop case is different For the Web and terminal interfaces the install is a command, and the README gives the manual route for both: ```sh dsh plugin --profile web add dsh-workbuddy-connect@0.7.9 dsh web ``` The terminal shell needs its own plugin version, and installing an older plugin against an older shell fails with an events is not iterable error, so the shell package is required to be at 0.10.0-beta.5 or later. Reasoning tier detection is not available in the terminal interface at all; it exists in the Web and Desktop model selectors. The Desktop case is the awkward one, and the README explains why. In some Desktop distributions, especially the official Electron build, the desktop profile is managed by the app itself, and the official build refuses the standalone command line profile desktop outright. Other distributions may behave differently, so the guidance is to check which distribution you have before assuming anything, and never to bypass its verification. The README even suggests letting an agent look for a compliant non-marketplace install path, while being clear that this is not guaranteed to exist. The README also recommends handing the install to a local agent that can run commands and read files, and provides a written instruction block for that purpose, including a rule that any local file or configuration change needs consent and a backup. ## The command line surface and what logout really does There is a small command line interface of its own, exposed through the harness plugin exec command. The status subcommand reports login state and remaining credits, with a --json flag for machine-readable output, and there are doctor for diagnostics and logout for clearing credentials. A provider flag selects the edition, defaulting to the domestic one: ```sh dsh plugin --profile web exec dsh-workbuddy-connect status --provider workbuddy-ai dsh plugin --profile web exec dsh-workbuddy-connect doctor --provider workbuddy-ai ``` The behaviour of logout is precise and worth stating exactly. It deletes only the credential copy the plugin kept for itself. It does not touch the desktop app's own login, and it does not promise that the model group disappears, because the group still works while the app's credential file remains. Verification of a successful install is a specific procedure: restart the interface, confirm that the WorkBuddy or WorkBuddy AI group appears in the model selector, and complete a short conversation with a model from that group. Only a reply that comes back normally counts as installed. ## Credits, multipliers and why a price can become unknown The billing surface is more detailed than most integrations bother with, and one behaviour in it is genuinely instructive. Multipliers are read from the service and shown after each model name, in the model dialog and in the dropdown in the input box, and they are display only: the README states they do not affect the actual request. Promotion badges for limited-time free or night discounts are also read from the service, synchronised each time the harness starts, and the international edition gets them from a server field named modelPromotions, which carries its effective time window so an expired badge is withdrawn automatically. The instructive case is what happens when the discount ends. Because the server writes the discounted price directly into the model's multiplier field, the original price cannot be reconstructed. Rather than keep showing a stale discount or claim the model is free, the plugin displays that the price is unknown and that a refresh will update it. That is a small design decision worth more than it looks. Most integrations would keep showing the last known number, which quietly misinforms. Enterprise accounts are handled separately, reading a period quota through the enterprise billing interface and showing the period reset time, but the README notes that enterprise credit support currently covers only the domestic edition, and that the international enterprise path is still read through the personal interface because it has not been verified. ## Why reasoning tiers are detected on demand The plugin exposes reasoning tiers such as low, high and max where WorkBuddy declares them, and the README devotes a section to why it does not fill in the gaps for every other model. The argument is that tier information currently lives partly in upstream interfaces and partly in the client's private UI logic, and that the model catalog changes quickly. A plugin that guessed a uniform tier set for every undeclared model would be chasing undocumented product behaviour with no stable contract. There is also a measurement point. Some models accept a reasoning effort parameter but ignore unknown values and fall back to default behaviour, which means a request returning success does not prove a tier is real. The detection flow therefore confirms that the upstream validates the parameter at all, then checks which canonical tiers are accepted, one at a time, and it is triggered by the user in the Web and Desktop selectors. Detection sends a small number of requests, which can consume credits, and the result only states that the upstream currently accepts that tier, without promising that it changes reasoning quality, speed or credit consumption. A model with no declared tier and no detection result simply uses the WorkBuddy default. ## Where the integration is fragile The README's known limitations section is the most useful part of the documentation, because it says where this will break. The international model catalog comes from the app's own interface, which the server routes by User-Agent. That is a private implementation, so an upstream change can break it. The plugin degrades in a defined order, from the account's last successful catalog to a built-in list, and marks the source, the update time and the failure reason on the card, but it makes no promise of long-term compatibility. The domestic catalog goes through the same kind of interface as the official command line tool and is unaffected. Credential handling is the other fragile point. The plugin needs to locate the app executable to decrypt the stored credentials, and on Windows the domestic edition looks at a default path and then at uninstall registry records, while the international edition has no verified default path and checks the registry only. On Linux it cannot be discovered automatically. The environment variables WORKBUDDY_AUTH_FILE, WORKBUDDY_AI_AUTH_FILE, WORKBUDDY_ELECTRON_BIN and WORKBUDDY_AI_ELECTRON_BIN allow explicit paths, and changes take effect only after fully quitting and restarting the harness. The final line of the README states the underlying position: the plugin depends on non-official WorkBuddy client interfaces, so a WorkBuddy update can require a plugin update. Treat the version matrix as part of the interface rather than as documentation. ## Conclusion This plugin suits someone who already pays for WorkBuddy models and wants them inside a terminal or web harness without a second login. It is the wrong choice if you need an integration that survives upstream changes, because it depends on non-official client interfaces, and it is the wrong choice for the official Electron desktop build, where the profile is app managed and the standalone command is refused. Verify first that the plugin version matches your harness kernel exactly, that your edition's model catalog loads rather than falling back to the built-in list, and that the credit balance query returns before you rely on the integration for paid work. ## FAQ ### Which DSH WorkBuddy Connect plugin version matches my harness? The mapping is kernel 0.2.1-rc.2 to plugin 0.7.9, 0.2.1-rc.1 to 0.7.7, 0.2.0-rc.2 to 0.7.6, 0.2.0-rc.1 to 0.7.0, and 0.1.5 through 0.1.7 to 0.6.5. A mismatch can stop the harness from starting, and the desktop edition follows the kernel built into the app rather than the npm latest. ### Does the plugin need separate credentials for WorkBuddy? No. It reuses the login state of the signed-in WorkBuddy or WorkBuddy AI desktop app, and follows account switches automatically. The domestic and international editions keep separate model groups, accounts and credits. ### How do I check my credit balance from the command line? Run dsh plugin --profile web exec dsh-workbuddy-connect status, with --json for machine-readable output and --provider workbuddy-ai to target the international edition. There is also a doctor command for diagnostics and a logout command that clears only the plugin's own credential copy. ### Does the plugin detect reasoning tiers for every model? No. Tiers that WorkBuddy declares are shown directly. For undeclared models the Web and Desktop selectors can run a user-triggered detection that confirms the upstream validates the parameter and then checks which tiers are accepted, which sends a few requests and may consume credits. The terminal interface has no detection. ## Sources - [corrinehu/dsh-workbuddy-connect on GitHub](https://github.com/corrinehu/dsh-workbuddy-connect) - [Issues](https://github.com/corrinehu/dsh-workbuddy-connect/issues) - [License: MIT](https://github.com/corrinehu/dsh-workbuddy-connect/blob/main/LICENSE) - [README](https://github.com/corrinehu/dsh-workbuddy-connect/blob/main/README.md) - [Releases](https://github.com/corrinehu/dsh-workbuddy-connect/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/corrinehu-dsh-workbuddy-connect