dsh-loop-continue
Continue a DeepSeek Harness agent turn when the model only narrated its next
action and forgot the tool call.
The agent loop closes a turn as completed the moment a step emits text and no
tool call. A model that writes "now I will re-apply the change" and stops looks
finished to the loop, even though the work is half done.
This plugin listens on agent/turn-stopping, replays the current turn's own
session log, and only asks a judge model one strict true/false question
when the shape matches that failure mode. true steers the same turn to run one
more step; false (or an unparseable answer) lets the turn close.
Install
Install into a profile with the dsh CLI. Its plugin subcommand forwards to
pnpm inside the profile directory, so add/remove behave as usual:
dsh plugin --profile <profile> add dsh-loop-continue
Then restart the profile. The profile's package.json gains the dependency and
dsh.profile.bundles entry, and the bundled cordis.patch.yml inserts the
guard into the layer stack — no manual patch editing is required.
To remove it:
dsh plugin --profile <profile> remove dsh-loop-continue
Working from a local checkout instead? Point the profile at the directory:
dsh plugin --profile <profile> add link:/path/to/dsh-loop-continue
Source edits under lib/ are picked up only on restart.
Config
| field | default | in card | meaning |
|---|
maxContinuations | 10 | yes | hard cap on steering per turn (no infinite loop) |
maxSteps | 10 | yes | newest steps shown to the judge |
maxTailChars | 2000 | yes | trailing-text budget split across the first and last halves |
judgePrompt | built-in | yes | instruction telling the judge what counts as unfinished |
steerText | built-in | yes | message injected when the guard steers |
debug | false | yes | log every evaluation (needs a restart) |
judgeProvider | null | no | override provider; null/unset = derive from the session route |
judgeModel | null | no | override model; null/unset = derive from the session route |
judgeMaxTokens | 64 | no | judge output cap |
judgeTemperature | 0 | no | judge sampling temperature |
Deterministic gates
No model call runs unless the turn both:
- ended on a text-only step (no tool call), and
- called at least one tool earlier (so a plain one-shot answer is untouched).
This keeps the extra judge call off ordinary finished turns and only spends it
where the model plausibly dropped a pending action.
Stopping early
Steering is not free: each continuation costs a judge round-trip plus one more
agent step. So the guard also watches whether a steer worked.
When it steers, it records how far the session log had grown. The next time the
same turn stops, it checks whether any assistant step in between actually called
a tool. If the model only narrated again, the steer was ignored and the turn is
closed instead of spending the remaining budget on the same refusal. A model
that answers the steer with a real tool call keeps its normal budget.
Configuring the guard
The guard resolves its config on every evaluation rather than freezing it at
mount, so a change reaches the very next turn-stopping check. Two ways to set
values:
- the user settings file,
~/.dsh/settings.yaml, under a loop-continue: key, or
- the profile's own
cordis.patch.yml.
Prefer leaving judgeProvider/judgeModel unset. The guard then judges with
the model the current conversation is already running, which is by definition a
working route; set them only to judge with a different model on purpose.
Editing the prompts
Both prompt texts ship as defaults and are plain config fields, so you can
retune the guard without touching code. The package ships a browser half, so
the editor is a card under Settings > Plugins > plugin config. It starts
collapsed like every other plugin card; click the header to open it:
Loop Continue - resume an unfinished turn
judgePrompt - decision policy [textarea]
steerText - resume message [textarea]
max steering per turn [3] 0..100
steps in the summary [10] 1..100
trailing-text budget (chars) [2000] 100..20000
debug - log every verdict [ ]
The prompts save on blur, not per keystroke: the Host validates and
persists the whole document on every write, and one write per keystroke of a
740-character policy paragraph is wasteful. The numeric fields and the toggle
save immediately. Every change except debug applies to the next
turn-stopping check with no restart; debug is read when the plugin is
loaded, so it needs one.
The same fields are editable in ~/.dsh/settings.yaml, which is also the
surface to use when the plugin runs headless with no browser half loaded:
loop-continue:
judgePrompt: >-
You inspect one coding-agent turn that just ended. Reply with exactly one
word: true if the trailing text promises work that no tool call performed,
false otherwise.
steerText: >-
You described an action but did not call any tool. Emit the tool call now.
Both surfaces write the same namespace, so a value set in the card shows up in
the file and vice versa.
What each field controls:
judgePrompt — the judge's whole decision policy. The judge sees a
deterministic summary (tool calls per step, trailing text, the human request)
and must answer one word. Tighten it if the guard steers turns that were
actually finished; loosen it if it misses dropped actions.steerText — what the model is told when a turn is steered. This is the
message the model acts on, so phrase it as an instruction to emit the call.
To revert, delete the fields; the built-ins come back.
Hot mount
cordis.patch.yml ships a plain insert — only id + name, no config
and no !!js expressions — so a market hot-mount can add or remove this plugin
as a minimal row. No user-specific endpoint, provider, or key is baked into the
patch: policy is resolved at runtime as described above.
A patch-layer change is replayed in full on every reload
(applyEntryPatches clones the entry list before applying), so a row adds and
removes cleanly and never accumulates.
Whether a patch edit takes effect without a restart depends on the host:
- Under the CLI (
dsh profile), runProfile installs an HMR service and
registers the profile and user patch files with it, so patch edits are applied
live.
- Under DSH Desktop 2.0.3 that path is not taken — the desktop shell
composes the profile itself (
dsh-app-boot helpers) and never loads
cordis-plugin-hmr, so a cordis.patch.yml edit needs a profile restart.
Edits to lib/*.js always need a restart: the dsh HMR service is created with
root: [], so no source directory is watched for module replacement.
