Choosing DSH Plugins: From Architecture Layers to Agent Workflows

Why plugin selection matters

DSH’s ecosystem offers many plugins (sidebar, TUI, vision, memory, scheduling, workflow). Selecting plugins requires understanding which architectural layer they modify.

Four architectural layers

Interaction entry – changes how the user invokes the Agent. Example plugins: dsh-at-file, dsh-TUI, dsh-better-sidebar.

Agent tools – registers new tools or services the Agent can call. Example plugins: ModLens, @anionex/dsh-vision-toolkit.

Cross‑session state – persists data beyond a single conversation. Example plugin: dsh-mnemon.

Scheduling & workflow – creates new Agent instances, handles retries, approvals and failure recovery. Example plugins: dsh-automation, dsh-workflow.

Before installing, ask “what remains after the plugin is disabled?” to gauge added dependencies, data stores and runtime entry points.

Practical installation order

dsh-at-file

– smallest, least intrusive plugin that adds “@” path completion in the input box.

Choose one entry point: dsh-better-sidebar for a web‑based side panel or dsh-TUI for a terminal‑centric UI.

Install @anionex/dsh-vision-toolkit when image‑based tasks become common.

Add dsh-mnemon only after the project repeatedly needs cross‑session memory.

Finally consider dsh-automation and dsh-workflow for scheduled or repeatable multi‑Agent pipelines.

Plugin deep‑dives

dsh-at-file

Typing @ in the input box searches the current workspace, skips common dependency, cache and build directories, refuses symlink traversal, absolute paths and paths outside the workspace. Large repos may need custom ignore rules. The plugin is locked at version v0.6.2 and can be added with:

dsh plugin --profile web add https://github.com/omdsh-dev/dsh-at-file/archive/refs/tags/v0.6.2.tar.gz

It only inserts the relative path; it never injects the file content into the Agent’s context, keeping troubleshooting straightforward.

Web vs terminal entry points

dsh-better-sidebar

embeds a file manager, preview, embedded browser, real terminal, Git panel and background‑task view in a side panel. It depends on node-pty and requires Node.js ≥ 20 and pnpm ≥ 10. dsh-TUI offers a terminal‑centric UI with streaming Markdown, tool cards, command/file completion, session recovery and still relies on the DSH service for model calls. It is in public beta and needs the DSH CLI (≥ 22.19 or ≥ 24) plus pnpm ≥ 10.

Vision Toolkit

The toolkit equips the Agent with image‑question answering, OCR for long screenshots, element localisation, cropping, colour picking, pixel‑diff and HTML page capture. Install with:

dsh plugin --profile web add @anionex/dsh-vision-toolkit

Requires Node.js ^22.19.0 or ≥ 24.0.0 and Python ≥ 3.11. By default, image‑understanding requests are sent to an external shared service; local‑only operations (cropping, colour analysis, etc.) stay on the machine. Users handling confidential designs should replace the default endpoint with a trusted service.

Memory plugin (Mnemon)

Mnemon splits memory into three scopes: short‑term task context, project documentation, and long‑term recall. The default backend is Mnemon Native but can be swapped for other providers. Uninstalling the plugin does **not** delete stored data, so projects must plan backup, migration and cleanup strategies.

Automation and Workflow

dsh-automation

runs scheduled tasks. Each run creates a fresh root Agent and Session, does not inherit chat history or approvals, and offers two permission levels: read-only and workspace-write. If a task requires human approval, the run fails. The plugin is currently tagged v0.1.6. dsh-workflow records each step, artefacts and recovery points for repeatable multi‑Agent pipelines (e.g., code review, parallel research). It requires Node.js ≥ 22.19 and a compatibility.json that matches the DSH version it was built against. Checking the compatibility record before installing is essential.

Permission boundaries and safety checks

Plugins run in the same Node.js process as DSH; Cordis’s inject mechanism decides which services a plugin can access but does not sandbox file, network or process capabilities. Profiles isolate dependencies and configuration, making experiments, switches and rollbacks easier, yet they are **not** security sandboxes.

Before installing, review the README, source repository, recent commit dates, package.json scripts and version constraints. The analysis is locked to DSH source commit 47f943859bef60e4160492346772ded9b24f765a. Keeping lock files and profile configurations enables future rollback.

Final habit

Install a few plugins, verify what they add and what remains after disabling, then expand the set. This approach helps estimate maintenance cost and avoids unexpected data leaks or permission escalations.

References

DeepSeek Harness official repository

DSH source commit 47f9438 pnpm allowBuilds configuration guide

https://plugin.dshx.dev/