Three DSH experiments from BitFun: Tauri GUI, MCP plugin bridge, and a Rust runtime

[bobleer]

DSH v0.1 landed, so I spent today testing three different integration boundaries instead of building one giant wrapper. I contribute to BitFun; all three repos are MIT licensed and the maturity notes below are intentional.

1. Native desktop shell for the official DSH Web UI

https://github.com/bobleer/deepseek-harness-gui

A Tauri 2 host that opens a workspace, starts dsh web --host 127.0.0.1 --port 0 in that directory, and embeds the official UI on loopback. It adds native window chrome, settings, keychain-backed API key storage where available, theme/locale, and close-to-tray without forking the DSH frontend. CI is green; build it from source for now.

2. MCP bridge for the DSH plugin ecosystem

https://github.com/bobleer/deepseek-harness-plugin-mcp

This one lets an MCP-capable agent search and inspect public dsh-plugin repositories. With explicit opt-in flags it can also add/remove plugins from a DSH profile, start that profile, and expose registered ctx.tools as dsh__* MCP tools. Catalog access is read-only by default; install and runtime execution stay off until enabled. CI is green, but the npm package name is not published yet, so use the GitHub source rather than the README npm command.

3. Layered Rust runtime experiment

https://github.com/bobleer/deepseek-harness-rust

An early Rust reimplementation of the lower runtime layers: typed contracts and events, append-only session state, turn/step loop, filesystem/shell/persistence services, plus a DeepSeek SSE adapter. It is not a Cordis port. The default branch is a runtime code drop, not a ready CLI/ACP distribution yet; the README quick-start is ahead of what is currently checked in.

The three repos answer different questions: how to put the official DSH UI in a native desktop host, how to make DSH plugins reachable from the wider MCP ecosystem, and what the runtime contracts look like when expressed in Rust.

BitFun is the production workbench these experiments came from: https://github.com/GCWing/BitFun. If the direction is useful, feedback on the repos is more valuable than generic praise; a star on BitFun also helps us keep pushing the DSH integration work.

[bobleer]

One of the three experiments is worth separating from the desktop/Rust work: deepseek-harness-plugin-mcp treats the DSH plugin ecosystem as an interoperability layer for any MCP-capable agent. Catalog inspection is read-only by default; profile mutation and live dsh__* runtime tools require separate explicit opt-ins. npm is not published yet, so this is source preview rather than a one-command install. A source-level design note and the production gaps we are tracking are here: GCWing/OpenBitFun#2270

[bobleer]

Update: all three repos just got merged into awesome-deepseek-harness, and I wrote up the plugin-mcp design on Dev.to (link in the thread). The MCP bridge is the piece I most want feedback on - treating the dsh-plugin topic as a read-only catalog other agents can query is the seam I keep going back and forth on.

[bobleer]

Compatibility update from the BitFun side: we now have a reproducible end-to-end DSH plugin → MCP → external client round trip, not just an architecture sketch.

Using DSH 0.1.0-rc.6, the current bridge at commit 8b292eb, and dsh-tool-schema at 8539ae3, the runtime projected 27 tools. Calling dsh__schema through MCP returned a structured validation result with valid: true.

The same probe also found a real boundary: dsh-tool-calculator executes inside DSH, but returns primitive numeric structuredContent (198), while the MCP SDK expects an object/record. So calculator is not counted as compatible yet.

Exact commits, request, response, and reproduction notes: bobleer/deepseek-harness-plugin-mcp#3

Disclosure: I contribute to BitFun and this bridge is one of our DSH interoperability experiments. This is evidence for two plugins, not a claim that the whole ecosystem works.