dsh-memory-plugin for DeepSeek Harness
A new coding session can lose the decisions that made the previous one useful: naming conventions, rejected approaches, repository constraints, and the reason a workaround exists. The dsh-memory-plugin DeepSeek Harness plugin connects an AI coding session to an OpenViking memory service. Profile context can load at session start, while relevant recall material can return before later agent steps. It also captures session events for later memory processing. The tradeoff is straightforward: continuity improves only when the stored context is relevant, protected, and small enough to justify the extra tokens.
OpenViking Memory, Wired Into DeepSeek Harness
Plugin quick facts
| Item | Detail | ||
|---|---|---|---|
| Package | @openviking/dsh-memory-plugin | ||
| Maintainer | OpenViking project | ||
| Role | OpenViking-backed recall, capture, and memory tools for a named DSH profile | ||
| Connection | A reachable OpenViking server with viking://~ home-alias support | ||
| Compatibility | @deepseek-ai/dsh `>=0.1.0-rc.6 <0.2.0 | ^0.1.5-rc.1` | |
| Documentation reviewed | September 16, 2026 |
Setup and first check
Install the package into an evaluation profile, inspect the composed configuration, and keep the server scope limited to one disposable repository at first:
dsh plugin --profile web add @openviking/dsh-memory-plugin
dsh --profile web --dump-configStart the OpenViking service required by that profile, then run one session with a small, known memory set. Ask for a decision recorded in that set and confirm that the recalled item appears as a source-attributed plugin message. Keep tool-result capture off until storage, deletion, and secret-handling rules are defined.
DeepSeek Harness is still a developer-preview project. Confirm this plugin against the exact DSH release before upgrading the profile.
This integration is an installable DeepSeek Harness bundle rather than a built-in memory feature. It mounts OpenViking's memory skill and MCP tool surface into a selected DSH profile. A reachable OpenViking server remains part of the setup, so installing the package alone does not create a working memory layer.
The useful mental model has four parts:
- Profile context gives the agent durable information about the user or workspace.
- Recall searches stored memories and skills for material related to the current input.
- Capture records eligible user and assistant events from the active session.
- Commit moves accumulated material into the OpenViking processing path when its threshold is reached.
This design can help a solo builder resume a multi-day migration or return to a repository after handling another project. It is less useful when every session is disposable, the repository contains sensitive material that should not be retained, or recalled notes are too broad to guide the current task.
How Auto-Recall and Profile Injection Work Before Each Step
At session start, the bundle injects the OpenViking profile and a memory index. Before a later agent step, it retrieves against that step's input and appends the result as a source-attributed plugin message. The recalled material is not inserted into the system prompt. That distinction lets the context remain visible as a session event and avoids relying on prompt sections that a DSH preset may replace.
Recall should be treated as evidence supplied to the model, not as an instruction that overrides the repository. A practical workflow is:
- Ask the agent to state which recalled constraint affects the planned change.
- Compare that constraint with current files, tests, and task requirements.
- Ignore stale or unrelated memory instead of preserving it for consistency alone.
- Record a corrected decision when the repository has moved on.
The bundle can exclude subagent sessions from automatic profile injection, recall, capture, and commit. That can reduce noise when short-lived workers produce intermediate discussion that should not become durable workspace memory.
Session Capture, viking:// URIs, and the Server Behind Them
Session capture listens for user and assistant messages, with tool-result capture available as a configuration choice. At the end of a turn, the plugin checks whether pending material has crossed the configured commit threshold. Failed writes enter a pending queue and can be replayed after the server becomes healthy again. This helps with transient service interruptions, but it does not remove the need to inspect what is being stored.
OpenViking resources use viking:// addresses. The integration prevents ordinary filesystem and shell tools from treating those addresses as local paths, then points the agent toward the mounted OpenViking MCP tools. That guard matters because a memory URI represents a server resource, not a file under the repository root.
Before enabling capture, decide:
- which DSH profile may reach the memory server;
- whether different repositories share recall scope;
- whether tool results may contain secrets or customer data;
- how deletion requests will be handled, since forgetting a stored item is permanent;
- whether server credentials come from environment variables or OpenViking configuration files.
The server remains a separate trust boundary. Network access, retention, account separation, and backups should match the sensitivity of the sessions being captured.
Installing dsh-memory-plugin and What It Costs in Context and Tokens
Add the package to a named DSH profile:
dsh plugin --profile web add @openviking/dsh-memory-plugin
dsh --profile web --dump-configThe plugin declares the peer range >=0.1.0-rc.6 <0.2.0 || ^0.1.5-rc.1 for @deepseek-ai/dsh. The complete DSH environment requires Node.js ^22.19.0 or >=24, and the plugin also needs a reachable OpenViking server that supports the viking://~ home alias used for memory and skill paths. A source checkout has additional dependency conditions, so the packaged install is the simpler evaluation path.
Recall has a direct context cost. A larger recall budget can supply more background, but it also consumes more of the model input and can bury the current task. Start with one repository and a narrow memory set. Measure the added input tokens, the number of recalled items that materially affect a decision, and whether review time falls or rises. Capture has a storage and privacy cost as well: more retained events create more material to secure, classify, and eventually remove.
Frequently Asked Questions
Does dsh-memory-plugin replace the OpenViking server?
No. The plugin connects DeepSeek Harness to a reachable OpenViking server and exposes recall, capture, skills, and MCP operations through that connection. The server still owns the stored resources and memory processing.
Is recalled memory inserted into the system prompt?
No. The profile and memory index are injected at session start; recalled material is added as a source-attributed plugin message before later agent steps. Neither becomes an invisible system-prompt addition.
Can the plugin capture tool results?
Yes, tool-result capture is configurable. Leave it disabled when tool output may include secrets, private data, or large logs that do not belong in durable memory.
How should I judge the token overhead?
Track added input tokens and the proportion of recalled items that change a plan or prevent repeated investigation. Reduce the recall budget or narrow the memory scope when unrelated context grows faster than its practical value.
Test Durable Recall Inside a Broader Harness Decision
Memory is only one part of a reliable agent setup. Use a disposable repository to compare a clean session with a narrowly scoped recall-enabled session, then record the token difference and the decisions that were actually recovered. Compare Verdent plans to place that result beside permissions, extensibility, and workspace safety.