Introduction¶

DeepSeek Harness (DSH)’s plugin mechanism allows for supplementing agents with tools and prompt segments, but memory is not a default capability. For developers who need to preserve user preferences, long-term facts, or project context across multiple sessions, the lack of persistent memory means that context might need to be re-supplied in every session.

ben7am1n/dsh-memory is a DSH memory plugin: it provides cross-session memory using a single local SQLite file and FTS5 indexing, without requiring embedding services, API keys, or sidecar processes.

Below is an introduction to its positioning, features, installation commands, configuration options, and applicable boundaries.

What is it¶

dsh-memory is maintained by ben7am1n and is licensed under MIT. It targets the cross-session memory scenario for DeepSeek Harness, working through three model-visible tools and a memory:recall prompt segment.

It stores memory in a local SQLite file and uses FTS5 for keyword retrieval. Memory can be preserved across process restarts; when the plugin is uninstalled, it removes the corresponding tools and prompt segments and closes the database.

Runtime environment requirements: Node.js:

^22.19.0 || >=24.0.0

Under Node 22/24, due to the use of node:sqlite, an ExperimentalWarning may be printed when running harness.

Core Features¶

This plugin provides three tools to the model:

1. memory_write: Stores a self-contained persistent fact; tags can be added and items can be pinned.

2. memory_search: Performs keyword searches on memory text and tags.

3. memory_forget: Deletes incorrect or expired memories.

The plugin also provides a memory:recall prompt segment. This segment renders memory within the character budget, prioritizing pinned items followed by the most recently updated items. This way, the model doesn’t need to call search first every time to see recent important memories; search is better suited for finding older content outside the budget.

Retrieval is lexical, not semantic. The search adds quotes to each token, causing FTS5 operators to match literally rather than changing the query semantics.

The prompt for memory_write guides the model to avoid storing temporary task states, keys, and facts already recorded in the repository.

Installation and Usage¶

First, execute the installation command:

dsh plugin --profile web add dsh-memory

The default bundle line stores memory to:

$DSH_HOME/memory/memory.db

On the same machine, all profiles share this default storage location.

path is a required configuration with no code-side default. It can point to a SQLite file or use :memory: for temporary storage.

The plugin does not set a code-side default for path to avoid scattering persistent user facts across the directory where harness is started. Deployment values should be placed in the patch row.

Configuration¶

Default configuration example:

- id: memory
  name: dsh-memory
  config:
    path: !!js dshHomePath('memory/memory.db')
    promptRecentCount: 10
    promptMaxChars: 2000
    maxTextChars: 2000
    searchLimitDefault: 10
    searchLimitMax: 50
    promptOrder: 50

Configuration errors during loading will throw errors directly. For example: empty path, non-positive boundary values, or searchLimitDefault greater than searchLimitMax.

Typical Usage and Development¶

After installation, the model can write persistent facts via memory_write, retrieve memories via memory_search, and delete invalid memories via memory_forget. memory:recall renders memories into the prompt within the character budget, prioritizing pinned items followed by most recent updates.

If you want to develop this plugin locally, you can execute the following workflow:

pnpm install --ignore-workspace
pnpm run typecheck
pnpm test
pnpm run build

These commands complete dependency installation, type checking, testing, and building, respectively.

Use Cases and Notes¶

dsh-memory is suitable for these scenarios:

• Wants DSH to preserve a small amount of long-term facts across sessions rather than re-supplying context every time.
• Wants memory retrieval to not depend on external embedding services, API keys, or sidecar processes.
• Can accept keyword retrieval instead of semantic similarity retrieval.
• Wants to control the context the model sees via tags, pinning, and recent memories.

It is not suitable for strong semantic similarity retrieval, large-scale vector recall, or scenarios that must rely on semantic matching.

Please note before use:

1. The plugin runs under the permissions of the current dsh process; check the source code, license, and configuration source before installing.

2. Default shared storage writes to $DSH_HOME/memory/memory.db. When using multiple profiles on the same machine, confirm whether these profiles should share the same memory.

3. The prompt for memory_write guides the model to avoid writing temporary task states, keys, and facts already recorded in the repository, but actual usage should still comply with the project’s security policies.

4. :memory: is suitable for temporary storage, not as a long-term memory solution for preservation across restarts.

Conclusion¶

The value of dsh-memory lies in making DSH’s memory extension a low-dependency local SQLite + FTS5 solution: it provides write, search, and forget tools, and also recalls recent and pinned memories via prompt segments. For developers who only need to remember a small amount of persistent facts across sessions, it is lighter than introducing an embedding service.

• GitHub: https://github.com/ben7am1n/dsh-memory
• Directory Page (from plugin index, please verify yourself before visiting): https://www.skillhub.cn/plugins/ben7am1n/dsh-memory