dsh-goal-auto
Per-session auto-resume toggle for long-running goal sessions in DeepSeek Harness (DSH).
What it does
- Adds a 🔁 toggle to the session header action bar.
- Marked sessions are resumed automatically after the harness restarts:
the agent is reloaded, its agent preset is mounted, the goal is re-armed,
and the goal-round-driver keeps driving rounds without any manual click.
Why resume is not enough (the three layers)
A plain agents.resume() after a restart leaves the session dead. Three things
must happen before a goal session runs again:
| Layer | Problem | Fix |
|---|
| Model variables | empty options -> {{model}}/{{provider}} unset, prompt assembly crashes | pass explicit agentOptions.provider/model/maxTokens |
| Tool set | resumed agent has no tools (preset not applied) | mount the agent preset in the resume setup |
| Goal driver | after restart goal.activation resets to disarmed | call goals.resume() to re-arm; driver auto-injects next round |
Adaptive preset
The preset is read from the session header (header.agentPreset) and mounted
per session, falling back to the configured default when the header has none.
Install
dsh plugin --profile web add file://<this repo path>
Or, as used here: keep the plugin in <DSH_HOME>/plugins/dsh-goal-auto and add
a file:/link: dependency in the profile's package.json + a junction under
profiles/<name>/node_modules/@huanlin/dsh-goal-auto.
HTTP surface
GET /__goal-auto/state -> enabled mapPOST /__goal-auto/toggle -> flip a session flag (+ start now if enabled)POST /__goal-auto/resume-now -> force resume of one session (diagnostics)
State lives in <DSH_HOME>/goal-auto-state.json (per-instance; safe to edit by
hand while the harness is stopped). Logs go to <DSH_HOME>/goal-auto.log.
Layout
src/index.js — cordis bundle (host): state, HTTP, boot auto-resumesrc/client.js — client bundle: header 🔁 togglecordis.patch.yml — loader insert for the profile
Watchdog requirement (IMPORTANT)
The plugin resumes sessions when the harness starts. It does not keep the
harness process alive. If dsh web crashes, hangs (TCP alive but HTTP dead), or
is killed, nothing inside the process can restart it — you must run a process
watchdog outside the harness.
Without a watchdog:
- the service dies and nobody brings it back;
- after a machine reboot nothing auto-starts;
- goal sessions only resume on the next manual start.
A reference watchdog system is included in this repository under
watchdog/. It is the same system used by the author:
watchdog/
watchdog-instance.ps1 per-instance resident watchdog
health = TCP listening AND HTTP 200
sliding window catches hard hangs AND intermittent
"slow death" (5+ HTTP failures in last 10 probes)
boot grace 120s so fresh starts are never killed
start-instance.ps1 auto-init + start one instance (seeds settings,
credentials, agent presets, plugin environment)
control.ps1 unified control: start|stop|restart|status [instance]
instances.txt instance registry: name|home_dir|port
Design notes (all learned the hard way):
- Watchdogs are per instance (one process per
instances.txt row), all
sharing one script. A single mutex per instance prevents duplicates.
- Auto-start at logon via the Windows Startup folder (a small
.vbs per
instance calling watchdog-instance.ps1 -Name <instance>).
instances.txt and every .ps1 must stay pure ASCII — Windows
PowerShell 5.1 mis-parses UTF-8 without BOM, and the harness rejects JSON
files that carry a BOM.- Health probes use .NET
HttpWebRequest, not curl.exe (curl in 5.1
intermittently returns 000 against a healthy instance).
- Add a crash circuit breaker: if an instance dies N times within a short
window, stop relaunching and alert — otherwise a plugin bug turns the
watchdog into an infinite restart loop.
Configure instances.txt for your own homes/ports before use. The watchdog is
generic; the paths under watchdog/ reference the author's layout only as an
example.
