dsh-ai-memory

dsh plugin --profile web add dsh-ai-memory

dsh-ai-memory

Memory bridge between DeepSeek Harness and ai-memory.

ai-memory shares one memory across

20+ coding agents: Claude Code, Codex, Cursor, Gemini CLI, OpenCode, and more

all read and write the same wiki. DSH could only ever read it. This plugin

makes DSH a full writer too.

---

What this is not

Read this first, because it decides whether this package is for you.

• It is not ai-memory. ai-memory is a separate project by a different

author. This plugin does not contain it, does not bundle it, and does not

replace it.

• It is not a fork of ai-memory. There is no shared code and no git

relationship. ai-memory is written in Rust; this plugin is a single ~800-line

JavaScript file that calls the ai-memory command-line program you install

yourself. See [Credits](#credits).

• **It is not affiliated with, endorsed by, or supported by ai-memory's

author.** It is an independent third-party integration.

• It does not capture anything. It only finalizes sessions that ai-memory

has already captured. Capture comes from DSH hook wiring that you install

separately — see [Prerequisites](#prerequisites).

Credits

The memory engine this plugin drives is entirely the work of others:

akitaonrails/ai-memory — MIT

licensed. One Rust binary that captures agent sessions through lifecycle

hooks, consolidates them into a searchable Markdown wiki, and serves that

memory to 20+ harnesses over MCP and HTTP.

No ai-memory code is included here. This repository contains zero lines

taken from that project. It is a DSH-side adapter that shells out to the

ai-memory binary, nothing more. If this plugin is useful to you, the credit

belongs upstream — please star their repository.

Memory between harnesses

This is the point of the plugin, so it is worth stating precisely.

ai-memory is built on the idea that memory should follow you, not your editor.

Quit Claude Code mid-task, open Codex in the same directory, and the next agent

picks up a real handoff. That works because every harness writes into one shared

store, and session-end consolidation turns the raw record into readable wiki

pages the next agent can search.

DSH was the odd one out. ai-memory's consolidation is triggered by a **session

end** event, and DSH never fires one — its session-terminating path exits

through a signal that emits no disposal event at all. So DSH sessions landed in

ai-memory as raw observations and stopped there:

Claude Code session ends ──► consolidated ──► wiki page ──► readable by every harness
DSH session ends         ──► raw observations only ──► invisible to every harness

DSH could search the memory other agents wrote, but nothing DSH did ever became

memory the others could read. One-way, in the wrong direction.

This plugin closes that loop by firing the finalize step DSH never fires. With

it installed:

DSH session ends ──► this plugin ──► ai-memory finalize-session ──► wiki page
                                                                      │
              Claude Code, Codex, Cursor, Gemini CLI, … ◄────────────┘

A DSH session becomes a page that Claude Code can retrieve, that a teammate's

Codex can search, that shows up in the next agent's handoff brief. **DSH stops

being a read-only consumer of the shared memory and becomes a peer writer in

it.**

That is the whole value: not a new memory system, but one harness joining an

existing one properly.

Prerequisites

Two things must already work. The plugin will not do either of them for you.

1. A running ai-memory server with capture wired into DSH.

Install ai-memory from upstream,

then wire DSH's lifecycle hooks so events are captured. ai-memory >=3.2.0

supports DSH natively; earlier versions need the legacy Claude Code bridge

configuration. A manual, single-command-string example supporting older servers

is in [docs/hooks-dsh.json](docs/hooks-dsh.json); see its native migration notes.

Verify capture independently before blaming this plugin:

ai-memory status          # sessions and observations should be increasing
ai-memory doctor          # inside your project directory

2. The ai-memory CLI on the same machine.

That is all. It resolves its own data directory and server URL, so the default

configuration needs no settings at all.

If the server is not running, this plugin logs a clear warning at startup and

does nothing else. Capture failing is a separate problem with a separate cause.

Install

dsh plugin --profile web add dsh-ai-memory

From GitHub instead of npm:

dsh plugin --profile web add github:rasyidmmz/dsh-ai-memory

Restart DSH afterwards. The loader imports plugin code without a cache-buster,

so an edited or newly added plugin is not picked up until the process restarts.

Confirm it loaded by searching the harness log for ai-memory:

[dsh-ai-memory] active v1.2.0 -- fast path session/disposed (zero idle cost) + ...
[dsh-ai-memory] preflight: ai-memory v3.1.1 | data_dir=... | server=127.0.0.1:49374

The preflight line is the fastest way to confirm the plugin found the same

ai-memory your hooks are writing to.

From the DSH marketplace — the half this plugin does not bring

Installing from a marketplace gives you the finalize half in one row. Two

things are still yours to provide, and the startup log now names whichever one

is missing instead of looking merely idle:

1. ai-memory itself. The plugin shells out to the ai-memory binary; it does

not bundle or install it. When the binary is missing the log says so, with the

install link and the exePath key that overrides the expected location, and

nothing is finalized until it appears.

2. Capture hooks. ai-memory only knows about a DSH session if DSH forwards

lifecycle events to it.

…(truncated)