OpenViking Memory for DeepSeek Harness
An installable DeepSeek Harness bundle that adds OpenViking auto-recall, session capture, viking:// URI protection, and the OpenViking MCP tool surface.
Requires an OpenViking server with viking://~ home-alias support. Recall targets the
caller's own context space through viking://~/memories and viking://~/skills; the uid-less
viking://user/memories shorthand is rejected by newer servers.
Published as @openviking/dsh-memory-plugin.
Install
DSH is covered by the unified memory-plugin installer:
curl -fsSL https://openviking.ai/install | bash
# AI agents: not sure about running this? The script's header says what it does and how to verify it.
It installs into the npm dsh's web profile; pass --dsh-profile <name>
for another one. On macOS it also offers DeepSeek Harness Desktop as a separate
harness, dsh-desktop (see DeepSeek Harness Desktop).
Or add the package to a profile directly:
dsh plugin --profile web add @openviking/dsh-memory-plugin
dsh --profile web --dump-config # should list openviking-memory-runtime
dsh plugin forwards to pnpm inside the profile directory, so the bundle has to
be a real package. Linking a source checkout (dsh plugin --profile web add ./examples/dsh-memory-plugin) only works when that checkout has its own
node_modules, because Node resolves the bundle's dsh peers from the source
tree's realpath rather than from the profile.
It also needs node examples/memory-plugin-shared/sync.mjs run first: the
shared/ modules the bundle imports are generated, not committed.
DeepSeek Harness Desktop
Desktop keeps its plugins in a reserved desktop profile under
${DSH_HOME:-$HOME/.dsh}/profiles/desktop, separate from the CLI's profiles.
The bundle runs there unchanged; only the way it gets installed differs.
-
Plugins page (macOS and Windows, manual): Plugins → Add plugin → enter
@openviking/dsh-memory-plugin → Install, then turn it on if its switch is
off. The page does not ask for OpenViking credentials, so write
~/.openviking/ovcli.conf yourself first. Uninstall from the same page. The page shows docs/DETAIL.md
(DETAIL.zh.md in Chinese) as the plugin's detail
document, through meta.detail in locale/*.json.
-
Installer (macOS, needs Node.js): with Desktop present the installer
selects the dsh-desktop harness, and --dsh-profile desktop routes there
too. It uses Desktop's own launcher at OPENVIKING_DSH_DESKTOP_CLI when set,
otherwise the one in /Applications or ~/Applications, otherwise a dsh
on PATH that resolves into the app.
-
Desktop's launcher (macOS). Open Desktop once so the profile exists, quit
it with ⌘Q (closing the window only hides it), run the command, then reopen
Desktop:
DSH_DESKTOP="/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh"
"$DSH_DESKTOP" plugin --profile desktop add @openviking/dsh-memory-plugin
"$DSH_DESKTOP" plugin --profile desktop ls # should list the package
"$DSH_DESKTOP" plugin --profile desktop rm @openviking/dsh-memory-plugin
An npm-installed dsh refuses --profile desktop, and no dsh boots that
profile or runs --dump-config on it, Desktop's own launcher included. To
confirm an install, use plugin --profile desktop ls or check that
profiles/desktop/package.json lists the package under dsh.profile.bundles.
On Windows, install from the Plugins page and configure the connection in
~/.openviking/ovcli.conf; the installer does not cover Windows. Desktop has
no Linux release.
Requirements
@deepseek-ai/dsh 0.1.0-rc.6 or later, below 1.0.0 (see DSH version compatibility)- Node.js
^22.19.0 or >=24 for the bundle itself. The host decides in
practice: DSH 0.2.1-rc.2 and later need Node.js >=24.9, and Desktop ships
its own runtime, so it needs no system Node.js.
- A reachable OpenViking server
The bundle has no runtime npm dependencies. Its message structures come from
createUserMessage (@deepseek-ai/dsh-llm), its tool surface from
@deepseek-ai/dsh-mcp-client, and its skill provider from
@deepseek-ai/dsh-skill-filesystem — peerDependencies that DSH itself already
installs. Keep those packages in the host installation rather than adding
individual DSH core packages to the profile. DSH initializes profiles with
nodeLinker: hoisted and autoInstallPeers: false, then makes the host packages
available through its module fallback at boot. A missing-peer warning during
dsh plugin add alone does not prove startup is broken.
Everything under shared/ and skills/ is generated by
node examples/memory-plugin-shared/sync.mjs — edit
examples/memory-plugin-shared/lib/ and examples/skills/, never the vendored
copies.
DSH version compatibility
The peer range is >=0.1.0-rc.6 <1.0.0-0. DSH checks each @deepseek-ai/dsh-*
peer when it loads a plugin, with pre-releases included in the range, so this
admits every 0.x release and pre-release from 0.1.0-rc.6 on, including ones
published after this bundle. The bundle touches a small DSH surface —
createUserMessage and boundContextSummary from @deepseek-ai/dsh-llm and
the plugin entry points of @deepseek-ai/dsh-mcp-client and
@deepseek-ai/dsh-skill-filesystem — so the range is not narrowed to the
releases tested so far.
Verified releases: 0.1.0-rc.6, 0.1.5-rc.1, 0.1.5-rc.2, 0.1.7-rc.2,
0.2.0-rc.2, 0.2.1-alpha.1, 0.2.1-rc.2, and 0.2.1-rc.3 (built from the
same source tag as Desktop 0.2.1-rc.3). A daily job
(.github/workflows/host-compat.yml) runs the bundle's tests against the
releases DSH's latest, next, and alpha dist-tags point at, installs each
of those releases from npm, adds the packed bundle to a web profile and checks
--dump-config lists it, and opens an issue when any of that fails, so a breaking release is usually caught before users
reach it; if the bundle still fails to start on a new release, pin DSH to a
verified one and open an issue. Every one of those checks uses npm dsh on
Linux, because Desktop is not on npm and has no Linux build. A further smoke step
emulates Desktop's launcher with the same release: it initializes a desktop
profile the way Desktop's first launch does, adds the bundle through
runCli({ manageDesktopProfile: true }), and checks that the profile lists it,
that npm dsh still refuses that profile, and that no dsh dumps its config. Real Desktop builds are checked by
hand. DSH 1.0 and later, pre-releases included, fall outside the
range and DSH refuses to load the bundle; dsh plugin allow-version grants an exact-version
exemption if you accept the risk. Local devDependencies and overrides stay
pinned to rc.6 to exercise the minimum supported contract.
Troubleshooting startup
If startup reports that @deepseek-ai/dsh-llm does not export assertNever,
inspect the affected profile before changing dependencies:
dsh --version
dsh plugin --profile web why @deepseek-ai/dsh-skill
dsh plugin --profile web why @deepseek-ai/dsh-skill-filesystem
dsh plugin --profile web why @deepseek-ai/dsh-llm
Replace web with the affected profile name. Check its package.json,
pnpm-lock.yaml, and pnpm-workspace.yaml under
${DSH_HOME:-$HOME/.dsh}/profiles/<profile>/, including dependency overrides.
dsh-skill@0.0.1-rc.1 imports assertNever from the old location. A profile-local
copy can shadow the newer host package and break both DSH's own skill loader
and this plugin. As of 2026-09-14, the skill and skill-filesystem npm latest
tags still point to 0.0.1 release candidates; installing either without a
version is not an upgrade strategy.
If these old packages are direct profile dependencies added only to satisfy
this plugin, remove those constraints and let DSH supply its matching packages:
dsh plugin --profile web remove @deepseek-ai/dsh-skill @deepseek-ai/dsh-skill-filesystem
dsh plugin --profile web add @openviking/dsh-memory-plugin@latest
dsh --profile web
If another plugin requires them, update that plugin's constraints instead of
removing them blindly. Keep autoInstallPeers: false and nodeLinker: hoisted
in the profile's pnpm settings. Do not patch the import in node_modules: a
mixed DSH package family can have other incompatible interfaces. Updating this
memory plugin alone does not remove conflicting profile-local packages.
Use dsh --profile <profile> to start a named profile. dsh web is an alias for
the stock web profile, not a subcommand to append after --profile.
Design notes
Why injection uses pre-step user messages, not the system prompt
Recall and profile context enter through the agent/pre-step waterfall as
durable, source-attributed user messages
(source: { kind: 'plugin:openviking-memory', … }). The producer-owned kind is
required by DSH session format v4; the plugin still recognizes legacy
kind: 'plugin' messages while older sessions are replayed.
They are deliberately not added to the system prompt: a DSH preset whose
persona declares complete: true (the stock minimal preset does) restores
that persona as the sole prompt section after assembly, silently discarding
every other contribution — a system-prompt-based memory plugin loses its
context under such presets with no error. Pre-step injection also makes each
injection a session event that replays, is visible to compaction, and never
reaches request/header.
What triggers recall
Recall runs on a pre-step whose entering batch contains user-authored input.
The query is built only from those messages: user-role messages with
source.kind absent or user. Messages that DSH or other plugins inject
(time-context, plugin:* notices, this plugin's own blocks) and tool results
are excluded, using the same rule capture uses. A batch made only of injected
context sends no search request.
How the tool surface is mounted
mcp.mjs mounts @deepseek-ai/dsh-mcp-client on servers/mcp-proxy.mjs, the
same stdio proxy every other OpenViking memory integration starts, so the model
gets the server's full tool set instead of a hand-maintained subset and the
transport behaves identically across harnesses. Pointing the bridge straight at
the server's /mcp endpoint does not work: with stateless_http=True the
server still answers GET /mcp with an idle 200 SSE stream, and once the MCP
SDK client opens that standalone stream it stops resolving POST responses, so
tools/list never returns. The proxy owns the transport itself and is
unaffected.
The bundle's resolved connection — url, MCP url, key, account, user and auth
mode — travels to the proxy through the child environment, because DSH scrubs
credential-shaped names out of the inherited env and a subprocess cannot see the
Cordis patch. It goes with OPENVIKING_CREDENTIAL_SOURCE=env, so the proxy reads
no config file and reaches the server exactly as the runtime does, including
with no key when the runtime has none. A changed ovcli.conf therefore takes
effect for the tools when DSH restarts the bundle, as it does for the runtime.
Two consequences follow from the proxy being one process per profile:
- MCP actor scope is process-level. With the default
recallPeerScope: all, MCP tool calls omit the actor peer header. With actor, they use the peer resolved at boot. Automatic recall, capture, and commit resolve their peer from each session's workspace.
Desktop boots the bundle in its profile directory, which is no repository, so
there the boot peer is empty and actor-scoped tool calls fall back to broad
recall. Set actor_peer_id in ovcli.conf or OPENVIKING_PEER_ID to give
them a peer; either one also overrides the workspace peer of every session.
remember is not session-scoped. The server's MCP remember stores into
its own short-lived session rather than the live dsh-<session-id> stream —
the same behavior the Claude Code, Codex, and Cursor integrations have.
Automatic capture still records the conversation itself.
The bridge and the skill provider are mounted last in apply(), after every
lifecycle registration, so a proxy that cannot start holds up nothing above it.
Why the skill gets its own provider
skills.mjs registers a second ctx.skills provider with
includeDefaultRoots: false and bundledSkillDir pointing at skills/. DSH
reads this host-owned bundle directly rather than asking a workspace filesystem
to resolve a path outside its root. The provider discovers no project or user
roots, so the bundle does not duplicate that catalog or override
higher-priority project skills. Those roots belong to DSH's own
skill-filesystem: dsh-base's host-level row in headless, acp, and
sdk, whose app bundles keep it, and per-preset rows in web and desktop,
where dsh-web-app disables the host row and the standard, ptc, and
cordis agent presets each mount their own skill-filesystem and
tool-skill. The bundle's provider registers at host level, which every
preset reads, so those agents see the bundled skills. The minimal preset mounts no tool-skill, so its agents
see no skills, these included, and sdk-minimal has no skills service, so the
provider never starts there.
Configuration
OpenViking credentials use the same resolution order as the other memory plugins:
OPENVIKING_* environment variables~/.openviking/ovcli.conf~/.openviking/ov.conf
Common environment variables:
| Variable | Purpose |
|---|
OPENVIKING_URL / OPENVIKING_BASE_URL | OpenViking server endpoint |
OPENVIKING_API_KEY / OPENVIKING_BEARER_TOKEN | Bearer credential |
OPENVIKING_ACCOUNT | Trusted-mode account |
OPENVIKING_USER | Trusted-mode user |
OPENVIKING_PEER_ID | Explicit actor peer |
OPENVIKING_WORKSPACE_PEER | Derive a peer from each DSH session workspace's git identity by default; 0 sends no peer |
OPENVIKING_RECALL_PEER_SCOPE | all for cross-workspace recall or actor for isolation |
The profile's cordis.patch.yml can also carry plugin config:
- id: openviking-memory-runtime
config:
endpoint: http://127.0.0.1:1933
recallMaxTokens: 2000
scoreThreshold: 0.35
captureToolResults: true
skipSubagentSessions: true
commitTokenThreshold: 20000
mcpToolCallTimeoutMs: 60000
Recall normally uses POST /api/v1/search/search with mode: "context".
recallMaxTokens (OPENVIKING_RECALL_MAX_TOKENS) sets this request's
max_tokens budget for server-assembled context. When it is unset, the plugin
omits max_tokens and uses the server's default budget.
recallLimit (OPENVIKING_RECALL_LIMIT) scales the category quotas for context
recall; it is not a strict cap on the final number of entries. When explicitly
set, it allocates at least one slot to each of the six categories: events,
entities, preferences, experiences, resources, and skills. For example,
recallLimit: 4 sends six one-slot quotas, so the result can contain more than
four entries. Lowering it does not expand the set of categories searched.
Actual results still depend on matching content, score filtering, deduplication,
and the token budget. When unset, the server's coding preset supplies the quotas.
The older size settings apply to fallback recall, not the primary context request:
recallTokenBudget (OPENVIKING_RECALL_TOKEN_BUDGET) controls the estimated
token budget of the locally rendered block when both server-side context and
the legacy /api/v1/search/recall endpoint are unavailable and recall falls
back to raw search results.recallMaxContentChars (OPENVIKING_RECALL_MAX_CONTENT_CHARS) limits each
item's content in that local fallback. It also sets the legacy /recall
request's max_chars to max(1000, recallMaxContentChars * recallLimit).
Behavior
- Agent startup injects the OpenViking profile, the available-memory index, and the
<available-skills> catalog through agent.inject(), and registers the per-session disposal commit. On DSH 0.1.7 and later this runs from the serial agent/created event ({ agent, source, signal? }), which holds queued input until it settles; DSH 0.1.0-rc.6 and 0.1.5 emit agent/created without source and start the session through agent/session-start instead. Startup runs once per agent, and agent/pre-step delivers the profile only if startup did not.
agent/pre-step retrieves with the current step input and appends a durable plugin message to that same step.session/event captures user, assistant, and optionally tool-result messages without scraping a transcript.turn/end checks the OpenViking pending-token threshold and commits when required.skipSubagentSessions: true excludes sessions marked with header.origin: subagent from automatic profile, recall, capture, and commit; it defaults to false.syncTurns: false stops every new write: no captured messages, no threshold or shutdown commit. Writes queued while the toggle was on are still replayed by the background drainer once the server recovers — they were captured with the toggle on. Profile injection and recall are unaffected; it defaults to true.skillCatalog (default true) and skillCatalogTokenBudget (default 1200; 0 also turns the catalog off) govern <available-skills>. The catalog comes from one GET /api/v1/skills?node_limit=200 call: the user's own skills first, then those shared under viking://agent/skills minus any whose name the user also owns, each description cut to about 40 tokens. Its budget is separate from profileTokenBudget. When the descriptions do not fit, the catalog lists names only (with a ... +N more tail if even the names do not all fit); when not even one name fits, it shrinks to a one-line count; with no skills, or a server without the endpoint, it is omitted.- Failed writes enter the shared OpenViking pending queue. A background drainer (default every 60s,
OPENVIKING_PENDING_DRAIN_INTERVAL_MS) probes the server health and replays the queue in-process, so a transient write failure recovers without restarting dsh; it does not consume the session-start retry budget. Session-start replays keep consuming retries as before.
Each DSH session maps to dsh-<session-id> in OpenViking. IDs that contain Windows-invalid path characters are normalized to a readable underscore form plus a stable hash, so two native IDs cannot collapse onto the same OpenViking session; already-portable IDs keep their existing mapping. Existing sessions whose native IDs require normalization start a new OpenViking session after this upgrade. Workspace-derived actor peers are resolved per session and sent on every session-specific request: the peer is the git identity of the session's workspace — the normalized origin URL (git@github.com:volcengine/OpenViking.git becomes github.com-volcengine-openviking), else the repository root path, that fallback keeping the older rule where every non-letter-or-digit character becomes -. With the default peer settings, no peer is sent outside a git repository, and what is remembered there goes to the user-level space viking://user/<you>/memories. One repository therefore keeps one peer across subdirectories, worktrees, clones and machines, while a fork's different origin keeps it separate. Memories written under the older path-derived peer stay reachable: the default recallPeerScope: all sweeps every peer under the user.
Workspace peer settings are loaded from session.header.cwd when the session first uses memory. A workspace can set peer.id to name its project explicitly, or peer.source to choose a preset or template chain. For example, <root>/.openviking/config.json can contain:
{
"version": 1,
"peer": { "id": "my-project" }
}
The shared loader also applies config.local.json and machine registry overrides. Explicit host peerId, environment overrides and pinned ovcli.conf credentials retain their existing precedence. The resolved peer stays fixed for the session's runtime state; new sessions load the current workspace settings. A session without a cwd falls back to the process's working directory.
Tools
The model sees the OpenViking MCP tools under the bridge's server-qualified
names — mcp__openviking__search, mcp__openviking__read,
mcp__openviking__list, mcp__openviking__tree, mcp__openviking__grep,
mcp__openviking__glob, mcp__openviking__remember,
mcp__openviking__write, mcp__openviking__edit,
mcp__openviking__forget, mcp__openviking__add_resource,
mcp__openviking__add_skill, and the rest of whatever the connected server
advertises. The list re-syncs when the server announces a change, so a server
upgrade adds tools without a bundle release.
mcp__openviking__forget performs permanent deletion. The calling model should
use it only when the user explicitly requests deletion.
The bundle also serves the shared openviking-memory and openviking-skills
skills from skills/ through its own isolated ctx.skills provider, so the
model gets the same guidance the other integrations ship: when to search, read,
and write, and how to find, use, create, share, and migrate OpenViking skills.
Testing
npm ci # installs the exact-pinned dsh devDependencies the tests exercise
npm run check # syntax check every shipped module + package/PLUGIN_VERSION agreement
npm test # node --test *.test.mjs — runs in the repo's PR workflow
The 0.3.2 compatibility check installed the packed bundle through
dsh plugin add in isolated profiles and exercised DSH 0.1.0-rc.6,
0.1.5-rc.1, and 0.1.5-rc.2 with matching core packages. It covered Web startup
and browser loading, skill discovery/read, MCP tool calls, profile/recall
injection, user/assistant capture, resume deduplication, threshold commits, and
disposal commits. The check used a local HTTP/MCP fixture and a deterministic
model adapter on macOS with Node.js 26.5.0; it verifies harness integration, not
real-server memory extraction. The rc.2 CLI also exited cleanly on SIGTERM.
The startup failure from issue #4944 was reproduced by adding the reported
old skill packages to an rc.2 profile; removing those direct dependencies and
reinstalling the bundle restored the same integration checks. A clean rc.2
profile with the published 0.3.0 bundle did not reproduce that import error.
live-recall.test.mjs is an opt-in end-to-end gate against a real OpenViking
server: it stores a sentinel memory through a session commit, waits for
extraction, and asserts recall returns that sentinel — the property no stub
can certify. Enable it with OPENVIKING_E2E=1 plus the normal credential
chain; it skips otherwise (including in CI until a server secret exists).
