SessionRelay × DeepSeek Harness (DSH) integration
A native DSH plugin that brings SessionRelay project memory into DSH's system
prompt — the equivalent of the SessionStart hook that CLI-shaped clients
(ZCode, Claude Code) get for free.
中文 · SessionRelay upstream
Why this exists
SessionRelay is an MCP server, so it can be queried by any MCP client. But an
MCP server cannot inject anything into a conversation: the initialize
response carries no instructions, no resources, and no prompts (verified
against srelay serve directly). Anything that appears in the model's context
without the model asking for it must be placed there by the client.
CLI-shaped clients get this almost for free: their process working directory
is the project root, so a SessionStart hook can resolve the project and shell
out to srelay decisions / srelay unresolved. DSH is a desktop GUI:
| signal | DSH desktop result |
|---|
process.cwd() | the installation directory, not the project |
ctx.cmdlineArgs | empty array (no argv for a GUI launch) |
AssembleContext | { scope?, signal? } only — no cwd, no project |
All three are dead ends, so this plugin resolves the project a different way
(see below) and registers a systemPrompt.section() provider — DSH's official
injection point — that renders the brief before each model step.
What it does
- Brief injection. A
systemPrompt section, evaluated on every assembly
(i.e. before each model step), showing the project's recent decisions and
unresolved questions. Bounded to 1200 chars, with an mtime-keyed cache so a
repeat evaluation costs ~1 ms instead of ~310 ms.
- Project resolution. A four-step fallback chain that needs no
configuration in the common case.
- Six native tools.
srelay_search / srelay_show / srelay_record
for querying, plus srelay_bind_project / srelay_confirm_bind_project /
srelay_cancel_bind_project for the two-stage binding.
Project resolution
① env SRELAY_PROJECT_ROOT → if it points at a directory containing .sessionrelay
② DSH session inference → most recent session group under ~/.dsh/sessions
③ registry single survivor → exactly one project registered and alive
④ dangling → do not guess; list candidates for the user
Step ② is the interesting one. DSH groups its own session storage by working
directory slug:
~/.dsh/sessions/
--E-music~0020player-- ← E:\music player
--D-agent1super-- ← D:\agent1super
That slug is DSH's own record of which directory a session belongs to, so it is
the most reliable "which project am I in" signal available to a plugin. The
encoding (mirrored from src/adapters/dsh/format.ts) is:
| input | slug |
|---|
: | (dropped) |
\ / | - |
| space | ~0020 |
| non-ASCII | ~ + 4 uppercase hex |
Because - is ambiguous (a real directory may contain a hyphen), decoding is
not a pure string operation. The plugin walks the segments depth-first and
prunes on real filesystem existence — only prefixes that actually exist are
explored. This recovers paths like D:\agent1super\tmp\docx-build correctly.
Step ④ deliberately refuses to guess. Injecting the wrong project's brief is
worse than injecting nothing: it would show project A's decisions inside a
project B conversation, and the model has no way to tell they are unrelated.
Two-stage binding
srelay_bind_project decides which database decisions get written to, so it
is not a decision the model may make on its own. If a model in a project B
session mis-resolved and bound itself to project A, every decision it then
recorded would be written into A's SQLite — irreversibly.
This mirrors SessionRelay's own rule that AI never gets delete tools; the same
constraint extends to "which store do writes go to":
srelay_bind_project({ projectPath }) — proposes only. Records a pending
proposal and returns text explicitly asking the user to confirm.srelay_confirm_bind_project() — applies, and only after the user has
said so.srelay_cancel_bind_project() — drops a pending proposal.
Proposals are tracked per scope, so multiple concurrent conversations do not
share binding state. A target path is only accepted if it already contains a
.sessionrelay database — otherwise binding a fresh directory would report
success and then fail silently on every subsequent call.
Self-contained runtime (vendor/)
The plugin ships its own SessionRelay runtime under vendor/ and prefers it over
any globally installed copy:
① SRELAY_CLI_PATH env → development escape hatch (point at a working copy)
② vendor/ (bundled) → default; works with no npm install and no network
③ global npm location → fallback only
vendor/ is a build artifact, not tracked in git — it is ~67 MB and carries
better-sqlite3 native bindings for every platform, which would bloat the
repository (the whole repo is ~13 MB). Generate it with:
node vendor-srelay.mjs # fetch from npm
node vendor-srelay.mjs --from <path> # copy from an existing install (offline)
Install
The plugin is a DSH bundle: a package whose manifest declares
dsh.bundle.patch, listed in the profile's dsh.profile.bundles.
// ~/.dsh/profiles/<profile>/package.json
{
"dependencies": { "dsh-srelay-brief": "file:/path/to/integrations/dsh" },
"dsh": { "profile": { "bundles": ["…", "dsh-srelay-brief"] } }
}
Then pnpm install in the profile directory. The plugin needs
@deepseek-ai/dsh-tools as a peer; DSH resolves it from its own installation.
Development notes
Four things bit us during development and are worth knowing before editing:
apply must be synchronous. Cordis calls apply and expects a fiber;
an async apply returns a Promise, and DSH reports
failed to import and silently skips the plugin. Resolve optional peers with
createRequire(import.meta.url) rather than await import(...).- The section
text provider must return a string, not a Promise.
renderPrompt calls text.indexOf('{{') directly; a Promise throws
text.indexOf is not a function. Use execFileSync, never an async wrapper.
SRELAY_PROJECT_ROOT only affects serve. Every CLI subcommand
(search, show, list, decisions) resolves the project from cwd
alone. When shelling out, pass cwd: root; setting the env var does nothing.- The two-stage bind needs all three tools. Proposing without a confirm
tool means the user can say "yes" and nothing can act on it.
- Resolve paths with
fileURLToPath, never new URL(...).pathname.
.pathname percent-encodes non-ASCII characters, so a plugin installed under
a directory like D:\dsh插件 记忆\ resolves to
D:/dsh%E6%8F%92%E4%BB%B6%20%20%E8%AE%B0%E5%BF%86/... and every existsSync
fails. The vendored runtime is then silently skipped and the plugin falls back
to a global install — a 67 MB payload carried for nothing. When you test this,
test under a non-ASCII path: an ASCII-only path hides the bug completely
(that is exactly how it survived one round of "verified offline" testing).
Also build the path in one step; dirname(fileURLToPath(url)) followed by
join(..., 'dist') yields vendor/dist/dist/....
Self-test
node selftest.mjs
Covers slug decoding against real DSH directory names, the resolution chain,
the section registration contract (deliberately not awaiting the provider),
tool registration via a stub collector, and the full two-stage binding flow. It
does not require DSH to be running.
