Introduction¶

The organization of DSH emphasizes “everything is a plugin”. For those using DSH for agent orchestration, a practical issue is the lack of stable long-term memory between sessions: preferences, working directory conventions, or task rules confirmed in the previous round must be re-explained in the next round.

Below is an introduction to dsh-goodmemory. It is a DSH plugin maintained by hjqcan that uses GoodMemory as a memory backend. It recalls relevant memories before the DSH model step and writes back completed human/assistant dialogue after a successful round.

What is this¶

One-sentence definition: dsh-goodmemory provides automatic, durable, cross-session memory for DeepSeek Harness, backed by GoodMemory.

It solves the problem of DSH session context continuity across sessions: the plugin places relevant memory as an identifiable DSH user/message into the context before the model call, and writes the selected text back to GoodMemory after a successful round. This ensures the model-visible context remains reconstructible from the DSH session log, while different sessions can share long-term memory.

The plugin does not copy the DSH JSONL logs nor create a second memory schema; it only sends the selected text to GoodMemory, which remains the single source of truth for memory and storage. The license is MIT.

Core Features¶

1. Automatic Memory Read/Write: Recall relevant memories before the DSH model step; write back completed human/assistant exchanges after a successful DSH round.

2. Controllable Recall Conditions: Recall only runs when the final agent/pre-step batch contains direct user text; other actions like tool calls or plugin-injected context do not trigger another lookup.

3. Limited Writeback Content: Writebacks include direct user text and final assistant text; tool calls/results, reasoning, images, recalled memory, and injected context are excluded.

4. Maintain Context Traceability: The recalled context is an identifiable DSH user/message, so the model-visible context remains reconstructible from the session log.

5. Two Runtime Modes:

   • managed mode: Default mode, starts the goodmemory-http-bridge sidecar on a random loopback port, uses an in-memory bearer token, and places SQLite data in $DSH_HOME/goodmemory/memory.sqlite.
   • external mode: Connects to an existing GoodMemory HTTP bridge; activation validates health, the precise phase-39.http-memory.v1 contract, and authenticated recall.

6. Failure Handling: Runtime recall/writeback failures are logged, and the DSH round continues; startup failures remain fatal.

7. Initial Scope: Version 0.1.1 does not add model tools, MCP server, DSH commands, or management UI.

Installation and Activation¶

First, confirm the version. dsh-goodmemory@0.1.1 supports the following combinations:

DSH is still in RC. dsh-goodmemory pins DSH peers; new DSH RCs are not supported until integration tests pass.

Install and enable the web profile from npm:

dsh plugin --profile web add dsh-goodmemory@0.1.1
dsh --profile web --dump-config
dsh --profile web

The first command installs the plugin, the second views the merged configuration, and the third starts the web combo.

If you want to use the headless combo, replace web with headless in the commands above:

dsh plugin --profile headless add dsh-goodmemory@0.1.1
dsh --profile headless

Install from local source code:

pnpm install
pnpm pack
dsh plugin --profile web add ./dsh-goodmemory-0.1.1.tgz

After the steps above, the plugin bundle inserts a goodmemory row; subsequent profile, home, or CLI patch layers can replace its full configuration.

Managed Mode¶

Managed mode is the default mode. It starts the published goodmemory-http-bridge, runs on a random loopback port, creates an in-memory bearer token, enables the recommended retrieval preset, and writes SQLite data to:

$DSH_HOME/goodmemory/memory.sqlite

Install Bun before use. If the Bun executable is not in the default location, you can specify it using GOODMEMORY_BUN_BINARY:

export GOODMEMORY_BUN_BINARY=/path/to/bun

If you want to change the database path, you can override the goodmemory row in the profile’s cordis.patch.yml:

- id: goodmemory
  name: dsh-goodmemory
  config:
    mode: managed
    databasePath: /absolute/path/to/memory.sqlite

On normal HMR or process exit, the plugin waits for in-progress writebacks and then terminates the managed sidecar. If the sidecar crashes after activation, the plugin will not automatically restart it; DSH will log the failure and continue running until the plugin is reloaded.

External Mode¶

External mode connects to an existing GoodMemory HTTP bridge. The token is placed in an environment variable, not in the DSH config:

export GOODMEMORY_HTTP_BRIDGE_TOKEN='replace-with-a-secret'
goodmemory-http-bridge --recommended

Configure external in cordis.patch.yml:

- id: goodmemory
  name: dsh-goodmemory
  config:
    mode: external
    baseUrl: http://127.0.0.1:8739
    tokenEnv: GOODMEMORY_HTTP_BRIDGE_TOKEN

Activation validates health, the precise phase-39.http-memory.v1 contract, and authenticated recall. Invalid configuration, missing token, authorization failure, or contract mismatch will cause the plugin activation to fail.

Scope and Memory Boundaries¶

The default scope is DSH-isolated. GoodMemory’s durable scope excludes sessionId, so different DSH sessions under the same user/workspace/agent scope can share long-term memory.

If you need to share memory with another GoodMemory host, you must explicitly configure the same userId, workspaceId, and agentId; when the other side omits nullable workspace or agent fields, set the corresponding field to null.

Management Access¶

The initial version does not introduce model tools, MCP servers, DSH commands, or management UI. Health checks, reviews, revisions, exports, and forgetting still use GoodMemory’s CLI and Inspector:

goodmemory inspector serve

Applicable Scenarios and Considerations¶

It is suitable for the following scenarios:

• You are using DSH combos for agent workflows and want to preserve long-term memory across sessions.
• You are willing to use GoodMemory as the memory backend and need either managed sidecar or external bridge access methods.
• You want the model-visible context to remain reconstructible from the DSH session log.

Considerations:

• DSH is RC, and dsh-goodmemory pins DSH peers; new DSH RCs require waiting for integration tests to pass.
• The plugin runs with the current DSH process permissions; you should check the source code, dependencies, and MIT license before installing.
• Runtime recall/writeback failures are logged and allow the DSH round to continue; startup failures remain fatal.
• Managed sidecars do not automatically restart after a crash and require a plugin reload.
• The token for external mode should be retained in an environment variable, such as GOODMEMORY_HTTP_BRIDGE_TOKEN.
• The initial version does not provide additional model tools, MCP servers, DSH commands, or management UI.

Conclusion¶

The value of dsh-goodmemory lies in integrating GoodMemory into the DSH model steps: recalling relevant memories before the pre-step and writing back selected text after a successful round, while maintaining the reconstructibility of the DSH session log.

GitHub: https://github.com/hjqcan/dsh-goodmemory

Directory page: No verifiable URL is provided for the material in this article; you can search the DSH community directory by the plugin name dsh-goodmemory.