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.

Published as @openviking/dsh-memory-plugin.

Install

DSH is covered by the unified memory-plugin installer, which asks which profile to install into (default web):

bash <(curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/examples/memory-plugin-shared/install.sh)

Or add the package to a profile directly:

dsh plugin --profile web add @openviking/dsh-memory-plugin
dsh --profile web --dump-config    # should list the openviking-memory group

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.

Requirements

• @deepseek-ai/dsh 0.1.0-rc.6 or newer in the 0.1.x release line
• Node.js ^22.19.0 or >=24
• 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, so there is nothing extra to add to a profile. The supported peer range starts at 0.1.0-rc.6 and stops before 0.2.0, allowing current DSH releases whose core packages resolve to newer release candidates. The local devDependencies and overrides stay pinned to rc.6 so CI continues to exercise the minimum supported contract.

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.

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', … }). 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.

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 credentials travel 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; the proxy then applies the usual OPENVIKING_* → ovcli.conf → ov.conf chain and reloads when those files change.

Two consequences follow from the proxy being one process per profile:

• The actor peer is process-level. Recall, capture, and commit still resolve a peer per session from that session's workspace, but tool calls carry the peer resolved at boot. Set OPENVIKING_PEER_ID when one process serves several workspaces and you need tool calls attributed exactly.
• 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, serving only skills/. DSH already mounts a filesystem provider over the project and user skill roots; an isolated provider adds the bundle's skill without shadowing or duplicating that catalog.

Configuration

OpenViking credentials use the same resolution order as the other memory plugins:

1. OPENVIKING_* environment variables
2. ~/.openviking/ovcli.conf
3. ~/.openviking/ov.conf

Common environment variables:

The patch can also carry plugin config:

- insert:
    - id: openviking-memory
      name: '@deepseek-ai/cordis-plugin-group'
      group: true
      isolate:
        openvikingMemory: true
      config:
        - id: openviking-memory-runtime
          name: '@openviking/dsh-memory-plugin'
          config:
            endpoint: http://127.0.0.1:1933
            recallTokenBudget: 2000
            scoreThreshold: 0.35
            captureToolResults: false
            commitTokenThreshold: 20000
            mcpToolCallTimeoutMs: 60000

Behavior

• agent/session-start injects the OpenViking profile and available-memory index through agent.inject().
• 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.
• Failed writes enter the shared OpenViking pending queue for replay at the next session start.
• tools/pre-execute blocks DSH filesystem and shell tools from treating viking:// URIs as local paths, pointing the model at the bridged mcp__openviking__* tools instead.

Each DSH session maps to dsh-<session-id> in OpenViking. Workspace-derived actor peers are resolved per session and sent on every session-specific request.

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, 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 skill from skills/ through its own isolated ctx.skills provider, so the model gets the same guidance on when to search, read, and write that the other integrations ship.

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

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).