ODR — DeepSeek Harness adapter

DeepSeek Harness (dsh) is an all-plugin agent harness. ODR speaks MCP, and DSH ships a first-party MCP client bridge (@deepseek-ai/dsh-mcp-client) — so this adapter is pure configuration: a Cordis overlay that inserts the ODR MCP server as an external stdio (or Streamable HTTP) server. DSH starts the child with its plugin lifecycle, discovers the six odr_* tools, and exposes them as mcp__open_dream_rsi__<tool>.

No code ships here — only two overlay files and this guide.

Files

file	transport	use when
odr.cordis.yml	stdio	DSH and the ODR checkout on one machine
odr-http.cordis.yml	streamable-http	ODR served remotely (tunnel / other host)
cordis.patch.yml + package.json	bundle (npm)	installable dsh plugin add package

The npm bundle ships the ODR Python server inside the package (open_dream_rsi/, stdlib-only) plus a tiny bridge (bridge.js) that does two things: it publishes where the vendored entry point lives (run_mcp.py), and it is the dreamer's brain — an in-process OpenAI-compatible proxy that forwards every ODR LLM call to the model the harness itself is configured with (ctx.llm.stream), so the Python child needs no API keys, no presets and no extra endpoints. The layer inserts the in-box @deepseek-ai/dsh-mcp-client row pointing the system python3 at the vendored entry point. No pip, no PYTHONPATH, no build step and no build allowance even for git installs. Bundle defaults resolve tasks.json / .dream_rsi beside the directory dsh launches from; override the mcp-open-dream-rsi row from your profile's cordis.patch.yml (same id — a config override replaces the whole config).

Install as a bundle (dsh plugin add)

The bundle ships the Python server inside the package — no pip, no PYTHONPATH. Only a system python3 (3.10+) on PATH is required. From a directory holding your tasks.json:

# from the npm registry, a tarball, a checkout, or straight from GitHub — pick one:
dsh plugin --profile <name> add dsh-open-dream-rsi            # or pin: [email protected]
dsh plugin --profile <name> add /path/to/dsh-open-dream-rsi-0.2.1.tgz
dsh plugin --profile <name> add /path/to/open-dream-rsi/plugins/deepseek_harness
dsh plugin --profile <name> add github:patrykorwat/open-dream-rsi#path:plugins/deepseek_harness

dsh --profile <name> --dump-config    # shows the "# == dsh-open-dream-rsi" layer

Git installs fetch sources; this bundle needs no build step and no build allowance. Pin a commit so a later push cannot silently change what runs:

dsh plugin --profile <name> add "github:patrykorwat/open-dream-rsi#<sha>&path:plugins/deepseek_harness"

(The pin must point at a commit that already contains this directory — pnpm fetches sources, not releases.)

Install (stdio, --patch overlay)

1. Make the server importable (not on PyPI — install from the repo): python3 -m pip install git+https://github.com/patrykorwat/open-dream-rsi, or export PYTHONPATH=<ODR checkout> in the overlay's env: block.

2. Edit both /ABSOLUTE/PATH/... placeholders in odr.cordis.yml to your project's tasks.json and memory dir (DSH does not expand ~; use absolute paths).

3. Apply it once:

   dsh --patch /ABS/PATH/TO/odr.cordis.yml web
   

   To persist across runs, merge the overlay's - insert: entry into $DSH_HOME/profiles/web/cordis.patch.yml (do not overwrite that file — it may already hold unrelated patches). Verify the layer mounted:

   dsh --patch /ABS/PATH/TO/odr.cordis.yml --dump-config | grep -A2 open_dream_rsi
   

Install (remote)

Serve the endpoint first, then apply odr-http.cordis.yml the same way. The URL is a credential — see the note in the overlay.

Where the dreamer's model comes from

The bundle needs no LLM configuration at all. The bridge runs an OpenAI-compatible proxy inside the harness process; the Python child is pointed at it via OPENAI_BASE_URL=http://127.0.0.1:<port>/v1 and every /v1/chat/completions call is served by the harness's own configured model through the dsh-llm service (ctx.llm.stream). The route is resolved once, in order of intent: ODR_LLM_MODEL pins the model; otherwise the harness's own agent default route (ctx.agentDefaultModel); otherwise the first registered provider plus its first catalog model (ctx.llm.listModels). GET /v1/models reports that model, so ODR's auto-detection picks it up.

Escape hatch: if the harness process already has a real OPENAI_BASE_URL set, the child is pointed there directly and the proxy stays idle (direct mode). Set ODR_LLM_MODEL to pin a specific model in either mode.

Environment scrubbing still applies: DSH drops child-env names matching KEY|PASSWORD|SECRET|TOKEN and everything DSH_*, and the bridge (childEnv()) re-passes only LLM vars that are actually set — an empty ODR_LLM_PRESET="" never reaches the child (older ODR releases fed it into preset selection and died with Unknown preset '').

The hand-rolled --patch overlay (odr.cordis.yml) has no bridge: it re-passes the vars it needs (process.env.VAR || undefined) and ODR then resolves an endpoint itself — OPENAI_* env, a preset (ODR_LLM_PRESET=local|openai|cursor|goose), or its local default (http://127.0.0.1:8000/v1 with model auto-detection).

Timeouts

toolCallTimeoutMs: 1800000 (30 min) replaces the 60 s default because odr_run_once / odr_dream run bounded improvement cycles that can take tens of minutes. odr_status, odr_recipes, odr_lessons and odr_add_task return in milliseconds.

Verify

In a DSH session:

1. mcp__open_dream_rsi__odr_status — returns the loop's learned-state summary (policies, recipes, events). Expected on a fresh memory dir: zeros plus a hint, not an error.
2. mcp__open_dream_rsi__odr_add_task with a small task (prompt + tests), then mcp__open_dream_rsi__odr_run_once — with the bundle, the cycle calls the model your harness session already uses; with the overlay, it needs a resolvable LLM endpoint (env, preset, or localhost vLLM) and reports the resolution failure instead of hanging.

Model-facing behavior notes (recipes as warm start, add-task-then-dream workflow) live in the main README's "Plug in your favourite agent" section.