Oh-DSH: a DeepSeek Harness runtime with Desktop, Web and TUI surfaces

What Oh-DSH adds to DeepSeek Harness

DeepSeek Harness (DSH) is the upstream runtime, session store and plugin loader. Oh-DSH is a distribution layer on top of it. The README describes the project as packaging "DeepSeek Harness、Node.js、本地开发工具和内置插件" into installable Desktop, Web and TUI editions, and the README credits dsh-TUI as "Oh-DSH TUI 的直接上游插件" and DSH-better-sidebar as the source of Git Review, file and PTY host capabilities.

The target user is a developer who wants an agent runtime next to a local workspace rather than in a browser tab alone. The built-in panels are Workspace, a PTY terminal, a browser, a file browser, Side chat and Trajectory. Git Review shows working-tree changes and commit diffs, lets you attach review comments to code lines, and handles branch, commit and push from the same sidebar.

That is a different pitch from a chat wrapper. The model service can stay in the cloud, while workspace, terminal, sessions and plugin state are organised locally under one data directory.

One command, three surfaces, one data directory

The mechanism is a single launcher, `ohdsh`, that starts whichever surface is installed. The README states that all three surfaces share sessions, credentials, skins and the plugin cache, while keeping separate profiles. By default they use `~/.ohdsh` for cache, configuration, sessions, credentials and plugin state, and `OH_DSH_HOME` relocates the whole directory.

The repository layout shows how this is assembled. `bin/` holds the launcher, `plugins/` holds the bundled plugin set, `upstream/` holds git submodules for DSH-better-sidebar, dsh-TUI and dsh-context, and `dsh-source.json` pins the DSH source. The Makefile enforces the pin: it runs `git submodule update --init --recursive` for those three submodules, and recompiles dsh-TUI only when the checked-out revision differs from `.stage/tui-compile.stamp`. The comment in the Makefile explains the intent, that an incremental checkout never stages a stale renderer build as the new pin.

The plugin marketplace is the part worth reading closely. All three surfaces can search, preview and install plugins and share the same transaction and recovery state. The README adds a caveat that installation may succeed in every terminal while some plugins only take effect in Web or Desktop and not in TUI, and says the interface distinguishes this. That is honest, and it is also the sharpest edge in the design: a successful install is not the same as a working plugin.

Installing Oh-DSH with install.sh and running a first session

Linux and macOS install from the repository's `install.sh`. With no arguments it installs the TUI and registers `ohdsh` in `~/.local/bin`, so you need a new terminal before the command resolves.

curl -fsSL \
  https://raw.githubusercontent.com/hust-open-atom-club/oh-dsh/main/install.sh \
  | bash

To get Web or Desktop instead, pass the surface explicitly. The same command repeated is an in-place upgrade, according to the README.

curl -fsSL \
  https://raw.githubusercontent.com/hust-open-atom-club/oh-dsh/main/install.sh \
  | bash -s -- --surface web

Windows uses `install.ps1` from the repository root, and without parameters it also defaults to TUI:

irm https://raw.githubusercontent.com/hust-open-atom-club/oh-dsh/main/install.ps1 | iex

After installation, the launcher starts only surfaces that are installed. `ohdsh web --port 3080` sets the Web port; the Desktop direct entry point `oh-dsh-desktop` is still kept.

ohdsh tui
ohdsh web --port 3080
ohdsh desktop

For a first real use, start the TUI and switch to the `liangshen` agent preset, which the README says keeps Minimal two-tool mode on the first turn, opens the full tool directory after the first tool call, and re-anchors after compaction. Web and Desktop expose the same preset in settings.

ohdsh tui
# then, inside the TUI:
/preset liangshen

If you would rather build from source, the README lists `git submodule update --init --recursive`, `pnpm install`, `pnpm run build:dsh`, `pnpm run build` and `pnpm run stage:dsh` before adding `bin` to `PATH`. The Makefile shortcuts are narrower: `make tui ARGS="--lang zh"` stages and starts only the TUI, `make web ARGS="--port 3080"` only Web, `make desktop` only Desktop. `make tui` defaults to inline mode, continuing from the current cursor position; pass `ARGS="--fullscreen"` for alternate screen.

Where Oh-DSH gets in the way

The installer's safety story is narrow. The README states that it does not touch an existing installation before verifying the published SHA-256 digest, so a failed download, a digest mismatch or an interrupted extraction leaves the old installation usable. That covers installation. It does not cover what happens after a bad upgrade, and the README does not document rollback or a downgrade path. `--uninstall` removes by surface, which is not the same thing.

The surface split is the second constraint. Web-only and TUI-only editions exclude Electron, and the TUI-only edition is aimed at SSH and pure terminal environments. A plugin that only takes effect in Web or Desktop is effectively absent on the TUI, even though the marketplace reported a successful install. If your workflow depends on a specific plugin, the surface choice comes before the plugin choice.

There is also a real entry cost for source builds. The README requires Node.js, pnpm and platform build tools, plus recursive submodule initialisation. The official installer avoids this by shipping a pinned DSH and Node runtime, which is the reason it is the recommended path. Anyone who needs a reproducible build from source inherits the submodule and toolchain setup instead.

Oh-DSH compared with running DSH plugins directly

The alternative is to assemble the same parts yourself: DeepSeek Harness as the runtime, dsh-TUI for terminal rendering and its command system, and DSH-better-sidebar for Git Review, files and the PTY host. Those are the upstream projects the README credits, and Oh-DSH states it keeps upstream implementations and attribution while adding the unified launcher, profiles, data directory, cross-surface skins, interface adaptation and release packaging.

The difference is where the integration work lives. Running the upstream plugins directly means you own the wiring between them, and you choose and manage a Node runtime. Oh-DSH fixes the DSH and Node versions per release and gives you one `ohdsh` command plus one `~/.ohdsh` directory shared by three interfaces. The trade-off is control: you inherit Oh-DSH's pinning cadence, its release surfaces and its plugin bundling rather than picking your own combination.

There is also a narrower comparison inside Oh-DSH itself. The Web-only edition drops Electron, which matters on a server or a light install. The full edition adds Desktop, Web, TUI, the Node runtime and the built-in plugins. Choosing between them is a packaging decision, not a feature decision, because sessions and credentials are shared either way.

Licence, maintenance and upgrade cost

Oh-DSH is MIT licensed, and the repository carries a `THIRD_PARTY_NOTICES.md` alongside the `LICENSE` file, which is where the upstream attributions for DSH, dsh-TUI and DSH-better-sidebar are recorded. MIT on the wrapper does not relicense those upstream projects; if you redistribute a build, read `THIRD_PARTY_NOTICES.md` and the upstream licences rather than assuming the top-level MIT covers everything.

The last push to the repository was on 2026-09-12, and the most recent release listed is v0.2.0 from 2026-09-08, following v0.1.12 and v0.1.11 earlier in September. The project is not archived.

Upgrade cost is mostly the repeated install command. The README says running the same install command again performs an in-place upgrade, and the digest check protects the running installation until verification passes. What the README does not describe is version pinning for the installer or a way to install a specific older release through the script; the GitHub Releases page is the documented route when you need to choose a package manually or distribute offline. Budget for reading the release notes between versions, because the surfaces are packaged per release and the pinned DSH and Node versions move with them.

Editorial conclusion

Adopt Oh-DSH if you want a DeepSeek Harness runtime with a local workspace (PTY terminal, Git Review, file browser) and you accept that plugins can silently fail to apply on TUI. Do not adopt it if you need a documented rollback path or a headless server-only deployment, because the README documents `--uninstall` per surface but no downgrade procedure. Before installing, read docs/usage.zh.md for the surface matrix and confirm which plugins your target surface actually loads; the marketplace labels this, but the README does not list the plugins per surface.

Frequently asked questions

Official sources

1. hust-open-atom-club/oh-dsh on GitHub
2. License: MIT
3. Project website
4. README
5. Releases