Preface

When running agents with DeepSeek Harness (dsh), a very common problem arises: project conventions, interface locations, and coding preferences are clearly explained in one conversation, but when starting a new session, you have to explain everything all over again. Short conversation windows cannot fit complete design documents, and long-term facts have no fixed landing point, so in the end you can only rely on manual copy-pasting.

DeepSeek Harness is designed with “everything is a plugin”: models, tools, skills, sessions, storage, and interfaces can all be replaced or reorganized. Memory is no exception. There is a category of plugins dedicated to this in the community plugin directory, and dsh-mnemon is one of the solutions oriented towards “local-first, layered persistent memory”.

This article is organized after checking the plugin directory page, GitHub repository README, quick start documentation, and package.json: what it is, how the three layers of memory divide their responsibilities, how to install it, and how to verify it for the first time. The community plugin directory deepseek-harness-plugin.com is an independent site and has no official affiliation with DeepSeek / HyperMind. The installation commands mentioned in the article shall prevail as per the original text on the directory page.

What is it

dsh-mnemon is a memory plugin for DeepSeek Harness, maintained by the GitHub organization omdsh-dev, with the MIT license. As of 2026-08-17, the repository language is TypeScript, the package.json version is 0.2.2, and the GitHub star count is 62.

It connects Mnemon to DSH, providing a unified memory control plane, but does not require all knowledge to enter the same database:
- Runtime Memory: Preferences, collaboration rules, project conventions, and environmental facts that are needed every round
- Project Archives: Complete narratives such as designs, surveys, processes, retrospectives, and handovers
- Memory Spaces: Cross-session facts, decisions, entities, and relationships, recalled on demand

The positioning of the directory page can be summarized in one sentence: Local-first persistent memory based on Mnemon, sharing long-term memory across Mnemon agents, with runtime memory and retrievable project documents stored locally.

You need to distinguish two things. dsh-mnemon is a DSH-side plugin; Mnemon is an independent local memory engine (CLI + SQLite). The plugin uses Mnemon Native as the third-layer engine by default, and can also be connected to other Providers, but the storage and workspace models of the first two layers remain unchanged.

How the three layers of memory divide their responsibilities

The official documentation provides a very clear comparison table. The three layers are not three copies of the same content, but are stored separately based on “whether it needs to appear every round, whether it needs to be read in full, and whether it needs to be recalled across tasks”.

Layer Suitable for Storage How to Enter Agent Context Managed By
Runtime Preferences, collaboration rules, project conventions, environmental facts Compactly projected to USER.md / MEMORY.md, available every round Deterministically managed by dsh-mnemon Host
Archives Designs, surveys, processes, retrospectives, handovers First retrieve, then read the full text on demand Deterministically managed by dsh-mnemon Host
Memory Spaces Cross-session facts, decisions, entities, and relationships Recall bounded evidence from activated memory spaces Mnemon Native or third-party Provider

The judgment rules can be remembered in three sentences:
1. What is needed every round goes into runtime memory.
2. What needs to be read in full goes into archives.
3. What needs to be recalled on demand across tasks goes into memory spaces.

The priority is also fixed: current instructions, repository files, and real-time tool results are always higher than historical memory. Ordinary chats should not force recall.

The runtime fact source is runtime/memories.json, and USER.md and MEMORY.md are derived projections. The capacity is calculated in UTF-8 bytes: the upper limit of USER.md is 4 KiB, the upper limit of MEMORY.md is 10 KiB, and the maximum size of a single piece of content is 8 KiB. The maximum size of a single archive body is 2 MiB, and the total active archive size is up to 10 MiB. These numbers come from the repository’s storage model documentation, not estimates.

Core Features

Local-first, third layer is replaceable

The default path does not rely on cloud memory services. Runtime memory and archives are locally deterministic storage; Mnemon Native uses a local CLI + SQLite. As of the current README, the third layer can also connect to these nine Providers:

Provider Form Applicable Directions in Documentation
Mnemon Local CLI + SQLite Precise writing, entities, type relationships, local-first sharing
OpenViking HTTP + viking:// Resource tree and asynchronous refinement
Honcho HTTP workspace / peers Team and Agent peer
Mem0 Platform or self-hosted HTTP Existing user / Agent memory
Hindsight HTTP memory bank Bank, entities, and Provider-native graphs
Holographic Local structured fact files Auditable facts, trust scores, local entities
RetainDB HTTP project / user Project and user dual-scope portraits
ByteRover Local brv CLI Code knowledge tree and curate process
Supermemory HTTP container Document ingestion and container-level sharing

Third-party Providers are disabled by default and must be explicitly enabled in the settings. The settings page manages reusable Provider services, and the Memory Spaces page manages specific instances, activation, scopes, and metadata. If an engine does not have graph edges, delete semantics, or enumerable content, the plugin will not fake these capabilities.

Cross-agent shared bounded memory

Mnemon-native mnemon.db is not a private format of dsh-mnemon. Other agents that also connect to Mnemon can read and write the same long-term facts, entities, and relationships as long as they point to the same storageRoot and Store.

The sharing scope only covers the memory spaces layer. Runtime memory and project archives will not be automatically exposed to other agents. Do not interpret “sharing the third-layer memory” as “automatically sharing the complete DSH context”.

There are three storage scopes:
- global: Uses ~/.mnemon by default (or MNEMON_DATA_DIR), suitable for multiple workspaces on the local machine to share a single control plane
- workspace: Uses .mnemon under the workspace, suitable for project isolation
- custom: Explicit path, semantics are handled globally, suitable for team conventions or isolated environments

Switching scopes will not automatically migrate, merge, or delete old root directories. The respective workspaces, users, banks, projects, containers, and URIs of remote Providers still belong to their own namespaces, and switching DSH workspaces will not secretly rewrite them.

Writes are supervised, queries are bounded

Operations on the workbench are not “stuffing the entire conversation into the database”. The README separates clicks from actual execution:
- Retrieval: Concurrent native recall from each Provider, read-only
- Agent Query: Create a new independent top-level task Agent, only receive bounded evidence before organizing answers, read-only
- Precipitate Memory / Save to Memory: Independent task Agent judges, routes, deduplicates, and refines, controlled by the Host before writing to disk; only writes to disk after passing the judgment
- This Round’s Memory: Expand this round’s recall, writes, and archive retrievals, click to jump to the corresponding page

These background tasks do not reuse or occupy the main conversation history by default. You can separately specify the Provider and model in “Settings → Memory System → Background Task Agent”.

Web, Chat, and Headless share one system

  • Sidebar WebUI (default): Left sidebar “Memory System” workbench, the first-level page order is Status, Runtime, Archives, Memory Spaces
  • In-chat: This round’s memory, save to memory, can jump to the corresponding page
  • Headless: No workbench or slash command interface, but retains runtime injection, archive retrieval, memory spaces tools, workspace routing, and supervised writing
  • Commands: /mnemon status, recall, related, remember, forget

The plugin list for each DSH profile is independent of each other. Installing it on the Web does not mean it is also available on Headless.

Installation and Enablement

The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please check the source code repository and license before installation; only install sources you trust.

The recommended baseline given in the quick start documentation is: dsh-mnemon v0.2.0, DSH 0.1.0-rc.6, Mnemon 0.2.3 or higher. The current repository version is 0.2.2. Back up before upgrading and repeat verification in an isolated directory. Node requires >=20.

1. Install Mnemon Native first

Mnemon is the default engine and the starting point for local-first use. macOS can use Homebrew Cask:

brew install --cask mnemon-dev/tap/mnemon

macOS / Linux can also use Go:

go install github.com/mnemon-dev/mnemon@latest
mnemon --version

Windows requires the official ZIP of v0.2.3 or higher (providing AMD64 and ARM64). The plugin will look for mnemon.exe from locations such as PATH, GOBIN / GOPATH, %LOCALAPPDATA%\Programs\mnemon, and does not accept .cmd / .bat wrappers. If it cannot be found, set MNEMON_CLI_PATH or write the absolute path in the user settings, for example:

mnemon:
  cliPath: 'C:\Users\alice\AppData\Local\Programs\mnemon\mnemon.exe'

mnemon status will open a valid Store, which may initialize data or perform upstream migrations, so do not treat it as a completely side-effect-free installation detection.

2. Install the DSH plugin

The installation command given on the directory page is:

dsh plugin add github:omdsh-dev/dsh-mnemon

For reproducible installations, fix the commit hash as per the directory page instructions:

dsh plugin add github:omdsh-dev/dsh-mnemon#<commit>

The repository README and quick start guide install by profile. For a complete workbench:

dsh plugin --profile web add dsh-mnemon
dsh --profile web

For one-off Headless tasks, install separately:

dsh plugin --profile headless add dsh-mnemon
dsh --profile headless "Check the persistent project context before answering."

For local checkout, use the absolute path:

dsh plugin --profile web add "link:/absolute/path/to/dsh-mnemon"

Upgrade and uninstall:

dsh plugin --profile web update dsh-mnemon
dsh plugin --profile web remove dsh-mnemon

Uninstalling only removes the plugin registration, and will not delete memory data in global, workspace, or custom directories.

How to Verify for the First Time

The official quick start guide writes the process from a blank environment to the first verifiable recall as fixed steps.

  1. Open “Settings → Memory System”, confirm the display form (default Sidebar) and storage location (default global ~/.mnemon). Saving will initialize a new runtime graph and switch the Host, and you generally do not need to refresh the browser.
  2. Open the left sidebar “Memory System → Status”, confirm “Connected” in the upper right corner, that Mnemon and dsh-mnemon can display versions, and that Runtime, Documents, and Memory Spaces have no errors.
  3. Open “Memory Spaces → Overview → Create Memory Space”, manually select the enabled Provider. Start with local-first, select Mnemon Native, write a clear theme for the name, write “what content belongs here and what tasks should trigger recall” in the description, then enable read activation.
  4. Click “Precipitate Memory” in the upper right corner, fill in a piece of stable, self-contained information that will still be useful in the future, without secrets. Only click confirm to start the independent task Agent to write; canceling the popup will not change the state.
  5. Open “Memory Spaces → Retrieve”, first perform a direct retrieval, then perform an Agent query on the same question. The results should show the memory space source, category, importance, and ID.

You can also use commands in the chat:

/mnemon status
/mnemon recall <focused query>
/mnemon remember <content>

An empty /mnemon is equivalent to status. status is a deterministic read and does not start a model. recall returns up to 10 entries. forget requires an exact ID without spaces, which is a destructive operation, and should only be executed when the user explicitly requests it or the content is confirmed to be wrong/outdated.

After returning to the chat, if the memory tool was called in this round, a “This Round’s Memory” will appear below the reply, and you can expand it to jump to the corresponding page. “Save to Memory” will first open an editable confirmation popup, and canceling will not write to disk.

Applicable Scenarios and Notes

It is more suitable for these situations:
- The same project needs to maintain conventions, environmental facts, and decisions across multiple sessions, and you do not want to re-explain the configuration every morning
- There are multiple Mnemon agents on the local machine, and you want to share the same long-term memory spaces without sending data to the cloud
- You need both short-term memory visible every round and retrievable design documents and retrospectives, and do not want to stuff everything into a single vector database

Please pay attention to the following points, all from the repository documentation and not additional additions:
1. Permissions and Source: The plugin runs with the permissions of the current dsh process. Check the GitHub repository source code and MIT license before installation; GitHub installation may execute build scripts on the local machine, only allow packages you trust.
2. Do not store secrets: There is currently no deterministic secret scanner. No layer should store keys, tokens, private keys, or original sensitive logs.
3. Credential storage method: Third-party Provider credentials are written to state/memory-providers.json with permissions 0600, and will not be returned to browsers, smart selection Agents, or Mnemon Packs. Disabling a Provider only cleans up local directory metadata, and does not delete remote data.
4. Uninstall does not equal clearing data: Uninstalling the plugin will not delete local or remote memory. Switching between global / workspace / custom will not automatically move data either.
5. Recall only looks at activated memory spaces: Reads to unactivated memory spaces will be rejected; after a successful write, the plugin will automatically activate the target.
6. Headless lifecycle: One-off runners exit after the Agent enters idle state, and pending background review scoring will be canceled; explicit or model-guided writes that have been completed within the task will still be persisted.
7. Remote WebUI: v0.2.2 fixed the issue where activating memory spaces on remote trusted pages failed, and tightened RPC boundaries: the remote interface retains activation capabilities, but disables loopback write operations such as editing, deleting, precipitating, backing up, and Provider configuration.

Summary

The problem dsh-mnemon aims to solve is not “making another chat record library”, but adding a layered, supervisable, and offline-by-default memory control plane to DSH: short facts go into runtime memory, complete narratives go into archives, and cross-session evidence goes into memory spaces. Mnemon remains the official preferred local engine, and the third layer can be replaced with other Providers, but it will not pretend to make up for capabilities that the engine does not have.

Directory page and repositories:
- Plugin directory: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-mnemon/
- GitHub: https://github.com/omdsh-dev/dsh-mnemon
- Mnemon engine: https://github.com/mnemon-dev/mnemon
- DeepSeek Harness: https://github.com/deepseek-ai/deepseek-harness