Introduction¶

Running agents with DeepSeek Harness (DSH) usually requires building the model layer yourself: finding endpoints, filling in keys, and handling groups. If the model is used via the WorkBuddy desktop app, things become more cumbersome—the authentication state is internal to the App, the model list is inside the App, and there is no ready-made API key to copy for CLI tools.

The dsh-workbuddy-model introduced below takes a different approach: it directly reuses the WorkBuddy desktop App’s logged-in account and registers the models inside the App as a DSH provider.

What is this¶

In a nutshell: it connects the logged-in models in the WorkBuddy / WorkBuddy AI desktop app to DeepSeek Harness. The Domestic and International versions display their respective model groups, using their own accounts and credits.

Repository: a404855501/dsh-workbuddy-model (https://github.com/a404855501/dsh-workbuddy-model), npm package name dsh-workbuddy-model, published version 0.1.3, license MIT. The package author is arnen7000. The ‘Source’ section of the README states that it was modified based on the build output of the npm package dsh-workbuddy-connect@0.7.9, with the main change being adaptation for the DSH desktop version.

First, let’s limit the scope of its capabilities: the plugin provides model invocation capabilities, not moving the App interface into DSH, nor exporting model weights locally. The distribution format is only the pre-built artifacts lib/; there is no rebuildable source tree in the repository.

Core Features¶

The plugin’s functionality can be broken down into three points:

1. Retrieve credentials from the WorkBuddy desktop App’s authentication state. On Windows, it reads CodeBuddyExtension/.../auth under %LOCALAPPDATA% / %APPDATA% and locates WorkBuddy.exe during decryption; macOS and Linux each have a set of path branches, but none have been run on real devices.
2. Register models as a DSH provider. The provider ID is workbuddy (Domestic version) and workbuddy-ai (International version).
3. No heavy dependencies. The README explicitly states that Python is not needed, nor is a native compilation toolchain; runtime dependencies are all pure JavaScript, with no .node modules.

The package exports besides the entry lib/index.js, also exports ./client and ./cordis.patch.yml; dsh.bundle.patch in package.json points to this patch file, indicating it is hooked into the host via a bundle patch. bin is lib/bin.js.

Installation and Activation¶

The only prerequisite is that WorkBuddy desktop App (either Domestic WorkBuddy or International WorkBuddy AI) is installed and logged in locally.

Command line installation:

dsh plugin --profile web add github:a404855501/dsh-workbuddy-model

Or use the DSH Plugin Market: Open the plugin market, search for workbuddy-model, and click install. Installation, upgrade, and uninstallation are all handled in the interface, so you don’t need to remember commands.

When you need to pin to a local snapshot (modify code, lock version), use local directory installation:

dsh plugin --profile web add <plugin-directory>

The desktop version method is different: the desktop profile is exclusive to the App, and dsh plugin --profile desktop add will be rejected by the CLI. To use it in the desktop version, you must go through the App’s built-in plugin page: Sidebar Plugins → Add Plugin → Arrow → Install Third-party Plugin, enter dsh-workbuddy-model (npm package name) or file:<plugin-directory>; choose China mainland mirror source for the installation source, and after installing, click Enable Immediately. Local paths must have the file: prefix; bare paths will be treated as link: symlinks by pnpm and may silently fail to install on some machines.

Verification after installation:

dsh plugin --profile web list

is incompatible with dsh ... should not appear at the end. Upgrading uses the same add command and takes effect after restarting dsh.

Installation Script Authorization¶

During the first installation, you will likely encounter ERR_PNPM_IGNORED_BUILDS. The reason is not in the plugin’s build itself: the dependency @earendil-works/pi-ai brings in @google/genai and protobufjs, and these two packages each declare an installation script, which pnpm does not execute by default.

The README describes the two scripts as follows: the protobufjs script only checks the version prefix written by the dependant and prints a WARN line to stderr if it doesn’t match; @google/genai’s preinstall is just an echo. None of them write files, go online, or compile.

In the desktop version plugin page, click Allow these scripts and retry directly. In the CLI, the CLI will write placeholder items in the profile’s pnpm-workspace.yaml, change set this to true or false to true, and then re-run the same add command:

allowBuilds:
  '@google/genai': true
  protobufjs: true

Authorization is saved in the current profile, and no further questions will be asked.

Environment Requirements¶

Regarding the core version, there are two statements in the README: the installation environment table writes >= 0.2.1-rc.1, while the ‘Scope’ section writes a minimum of 0.1.7, and explains that older cores (e.g., 0.1.5-rc.2) will fail during the loading stage in testing because the @deepseek-ai/schemastery it carries does not have .volatile(); starting from 0.1.2 it will directly report this DSH core is too old …. The author also emphasizes that package.json’s peerDependencies intentionally does not declare any @deepseek-ai/* version range: these packages are provided by the host, and declaring a range will only be misinterpreted as “environment too old” when the host uses pre-release versions.

Combinations that have run real conversations are only Windows x64: Core 0.2.1-rc.3 (Desktop version), 0.2.1-alpha.2, 0.2.2-alpha.2, 0.1.7-rc.1, Domestic version 5.9.3, International version 5.8.4. Environments above 0.1.7 other than those in the table can be installed, but the author does not guarantee they will work well.

Platform support is divided by credential source:

• Windows x64: Tested.
• macOS: Untested (branches complete), reads ~/Library/Application Support/CodeBuddyExtension/...
• Linux: Untested (branches complete), probes $XDG_CONFIG_HOME and $XDG_DATA_HOME; WSL additionally probes mounted Windows directories.

On non-Windows platforms, if the Electron binary for decryption is not automatically found, it can be explicitly specified:

# Domestic version
WORKBUDDY_ELECTRON_BIN=/path/to/WorkBuddy
# International version
WORKBUDDY_AI_ELECTRON_BIN=/path/to/WorkBuddyAI

On macOS/Linux, whether the WorkBuddy desktop App exists and whether it writes the same auth file, the README explicitly states that this has not been verified; differences in path separators and case sensitivity can only be confirmed by running once on the corresponding platform.

Use Cases and Notes¶

Who is this for: People who have WorkBuddy desktop App installed and logged in locally, want to call the models inside the App directly in DSH, and don’t want to write a provider themselves. You can share the same account and credits across devices in the App.

Check these points before installing:

1. Provider IDs will conflict. The registered ID is workbuddy / workbuddy-ai, which is the same as other WorkBuddy bridge plugins like dsh-workbuddy-connect. If you install both, the one registered later will silently not activate—no error, just it won’t appear in the model list. Uninstall other bridges before installing.
2. Essentially a client impersonation. The plugin impersonates the DSH as the WorkBuddy official client to call interfaces. There is a channel verification mechanism upstream, which may become invalid at any time. App upgrades or upstream changing verification rules could cause it to fail.
3. Runs with the current dsh process permissions. The plugin runs with the permissions of the process that started dsh. It can access credential paths, network egress, and the file system scope equivalent to that process. It is recommended to review the code and license in lib/ before installing (MIT, plus THIRD_PARTY_NOTICES.txt).
4. No source tree. This repository only distributes pre-built artifacts lib/, and lib/ is the only source of implementation.

Uninstallation¶

dsh plugin --profile web remove dsh-workbuddy-model

remove will also remove dependencies and bundle registrations, so you don’t need to manually modify the configuration. Only when the CLI is unusable or the profile is already corrupted do you need to manually delete the dependency lines in package.json and the entries in dsh.profile.bundles, and then run pnpm install.

Appendix: Sources¶

Plugin repository: https://github.com/a404855501/dsh-workbuddy-model

Community directory page: https://www.skillhub.cn/plugins/a404855501/dsh-workbuddy-model

The version numbers, commands, and platform descriptions above all come from the repository README and package.json; the macOS/Linux sections are the README’s own “branches complete, untested” and have not been verified on physical devices.