BigFish turns DeepSeek Harness session events into an always-on-top window

The plugin owns the window, so DSH owns the lifetime

BigFish has no launcher of its own. The project puts the split plainly: entry belongs to DSH, lifecycle belongs to DSH, display layer belongs to desktop. What you get is a transparent, frameless, always-on-top native window that floats over VS Code, the browser or a file manager without being one of them, and it is not a separate desktop pet you start and forget about.

That ownership split shows up in the first five minutes of use. The install sequence begins by closing the DSH Host rather than a browser tab, because an older plugin left running would keep its Helper alive. The same split is what the context menu exposes: hide for this run only hides the window and leaves the plugin enabled, while close for this run ends the current Helper and it stays gone until DSH starts again.

Two prerequisites ride along with it. A DeepSeek Harness WebUI that already runs, and a DSH CLI able to run plugin --profile web. Node 22.19 is the floor declared in package.json, which ships as an ES module with main at src/index.js.

State comes from session events, never from watching your screen

Only agent events move the pet. It does not screenshot, it does not attach itself to VS Code or the browser, and it does not infer activity from what you are doing in another program, so typing elsewhere cannot flip it into a working state by accident. The display follows the session, not the keyboard.

Two details make that more than a slogan. Reasoning effort appears only when DSH hands over the effort the request actually used, and the project states it will not infer effort from the model name. And the state machine lives in ordinary JavaScript exposed through its own entry points:

"exports": {
  ".": "./src/index.js",
  "./client": "./lib/client.js",
  "./protocol": "./src/protocol.js",
  "./reducer": "./src/companion-reducer.js"
}

src/protocol.js and src/companion-reducer.js are where events become states, so another package can consume the same reduction instead of reimplementing it.

When several sessions run at once the window picks the one that needs you, in a fixed order: waiting for confirmation, then error, then working, then thinking, then idle. With more than one active task the bubble lists them together rather than hiding all but one.

The status card refuses to invent a progress bar

The card reports what the session actually knows. With a todo list present you get the project directory name, the current phase, the current todo and real progress such as completed 3/5 steps. With no todo list it falls back to phase text: analysis, implementation, verification. It will not manufacture a completion percentage, and that refusal tells you more about the plumbing than any animation would.

Tuning happens inside DSH, not in a config file you edit: Settings, then Plugins, then Plugin configuration, then the BigFish desktop companion entry. Character size runs from 55% to 140%, with a 60% mini tier in the right-click menu. Bubble size is a separate 80% to 120% range, because a shrunken character still needs legible text. Bubble display can stay always on, go fully hidden, or name individual states. Activity level sets blink and idle frequency, reduce motion cuts walking and loop frames, notification sound covers task completion and errors. Respond to sub-Agents is off by default, so a swarm of child agents will not take over the window until you ask. DSH stores these, so a plugin update normally keeps them.

One build detail worth knowing: the alpha channel's settings and desktop strings are Simplified Chinese only.

Install starts by quitting the DSH Host

Shut down the DSH Host before you type anything, so no previous Helper is still running while the new package lands. On Windows, open PowerShell inside your DSH install directory:

cd D:\DSH

Then add the stable npm package through the DSH plugin command:

pnpm dsh plugin --profile web add dsh-dafeiyu

If a global dsh command is already on your PATH, drop the pnpm prefix and run dsh plugin --profile web add dsh-dafeiyu instead. Swapping the package name for dsh-dafeiyu@alpha follows the pre-release tag.

Linux and macOS use the same command from Terminal, only the paths differ. Under WSL2 you run that line in the WSL shell, and the plugin starts the bundled Windows Helper through cmd.exe by itself, so there is no chmod step and no Python inside WSL. A native Linux desktop uses the bundled Linux Helper, not the Windows executable. If npm is out of reach, take the tarball from GitHub Releases, leave it packed, and aim the same command at the file:

pnpm dsh plugin --profile web add ~/Downloads/dsh-dafeiyu-<version>.tgz

Start the DSH WebUI as usual afterwards. The window comes up on its own; nothing launches the Helper by hand.

Linux wants X11 first, and only Ubuntu 24.04 passed desktop acceptance

Linux is where the support statement becomes a checklist. The Helper targets x86_64 desktops with glibc 2.35 or newer, and the official binaries are built on Ubuntu 22.04. Desktop hardware has been accepted only on Ubuntu 24.04 with glibc 2.39. Ubuntu 22.04 itself and other distributions have not been through desktop acceptance, and CI only builds and smoke-tests the Helper on Ubuntu 22.04 under Xvfb, a virtual framebuffer with no real display behind it.

A graphical session is mandatory, so DISPLAY or WAYLAND_DISPLAY has to be set. The Helper tries X11 or XWayland through xcb before it falls back to Wayland, which means a Wayland-only desktop ends up on the XWayland path. Debian and Ubuntu machines generally need libxcb-cursor0 as well. ARM, remote SSH without a display, containers and bare servers sit outside what this version targets. If you drive DSH from a build server, this plugin has nothing to offer.

macOS ships an ad-hoc signed Helper, and Finder is what breaks it

macOS arrived in 0.1.4 as an experimental native Helper, and the project's own note is worth taking at face value: CI has verified the Universal architecture, AppKit rendering and process lifecycle, while real Apple Silicon experience is still being collected from user reports. The application carries an ad-hoc signature. There is no Developer ID signature and no notarization.

The practical failure mode is Finder, not macOS. Installing from npm, downloading in Terminal, and installing a browser-downloaded tarball directly all avoid Gatekeeper. Extracting the payload with Finder produces an app bundle carrying a quarantine flag, and that is the case that gets blocked on double-click. Download in Terminal when you can:

gh release download --repo QCYTSN/dsh-dafeiyu

If you already extracted the bundle, right-click the Helper and choose Open once, or strip the flag by passing the extracted bundle to the tool:

xattr -dr com.apple.quarantine dsh-dafeiyu-helper.app

No Xcode, Python or PySide6 is needed on this path, because the release package carries the native Helper.

Updates are a manual step, and the release feed is the only notice

New commits in the repository do not change an installed plugin, and the project does not pretend otherwise. When a release appears, quit DSH and run the update command:

pnpm dsh plugin --profile web update dsh-dafeiyu

Running the add command again also works, because it resolves whatever the npm latest tag points at. Alpha users swap the package name for dsh-dafeiyu@alpha in the same command.

There is a warning attached to the notification story: starring the repository only bookmarks it and sends no update mail. Subscribing through Watch, Custom, Releases, or to the releases.atom feed, is what tells you a version changed. Releases also carry the same tarball that the npm install resolves, which matters when npm sits behind a registry mirror.

The cadence is brisk. Version 0.1.14 shipped on 2026-09-15 and the last push was on 2026-09-16, with 0.1.12 and 0.1.13 both released on 2026-09-14. A project moving that fast deserves a changelog you read on purpose: CHANGELOG.md, docs/UPDATING.md and docs/ACCEPTANCE.md are the three files to bookmark. Note that the Chinese README here is cut off partway through the alpha update instructions, so anything about rollback and version downgrades has to come from docs/UPDATING.md rather than from inference.

Where running the Helper yourself differs

The alternative approach is to run the Helper yourself. requirements.txt pins PySide6>=6.7,<7, and the tree still carries scripts/build-helper.ps1, scripts/build-helper.sh and scripts/build-helper.mjs, so a Python helper is where the binaries in runtime/bin/ and native/macos/ come from. Install PySide6 in your own environment, write your own always-on-top window, point it at the WebUI and poll for status, and you get the same picture with more parts to manage: a process to start, a window to place, a poll loop to keep honest. This plugin receives events from inside the DSH process and inherits its start and stop, which removes the polling question and hands you a fixed lifetime instead.

Licensing splits in a way worth reading closely. The code is MIT. The pet artwork ships under its own terms in assets/dsh-pet-LICENSE.txt, with ASSET_LICENSE.md at the repository root. Using the character on your own desktop and redistributing it are not the same question, and those two files are not the same grant.

Editorial conclusion

Side by side with a terminal session, or with several DSH sessions running at once, dsh-dafeiyu earns its place: no window to place, no second process to start, no Python to install. Skip it on a headless box, on ARM, or on a distro older than glibc 2.35, because no desktop Helper targets those. Verify first that your DSH CLI accepts plugin --profile web and that your session exports DISPLAY or WAYLAND_DISPLAY, then check whether the .tgz from GitHub Releases works for you if npm sits behind a mirror.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. QCYTSN/dsh-dafeiyu on GitHub
4. README
5. Releases