[bug] Four smaller ones: an uncancellable compaction, a borrowed timestamp in the crash-repair closer, an over-window first prompt, and an unbounded child turn

[mattafaak]

Four small ones from the same deployment (0.1.2-alpha.5, local model via
llama.cpp). Happy to split any of them out.

1. An in-flight compaction cannot be stopped, and leaves no signal that it is running

Automatic compaction runs inside the turn and takes minutes on a local model
(measured here: 131 s to generate a 2,876-token summary, then 77 s to
re-prefill). During that window the UI's stop does not cancel it, and the
process exiting does not either — the work is simply lost.

Worse for anything supervising the process: there is no signal that a
compaction is in flight. The session log is silent for its whole duration (no
tool/call, no step/*), the projection cache does not move, and there is no
child process. A restart in that window is indistinguishable from a restart
while idle — until you notice the turn is gone.

Suggestion: let the turn's cancel signal reach it, and emit something
observable while it runs (a compaction/progress, or simply keep
compaction/start visible in the projection cache).

2. The crash-repair closer borrows the previous event's timestamp

interruptedTurnClosers() synthesises the closing events for a turn that was
open when the log was reopened and — per its own comment — reuses the timestamp
of the last real event:

{"type":"turn/end","data":{"turn":1,"reason":{"kind":"interrupted"}}}   ts = <last real event>

That is indistinguishable from a user stop at that moment. It cost me a wrong
conclusion twice: a turn killed at 19:57 appeared to have ended at 19:54:56,
which was simply the last thing it had done.

Suggestion: stamp the repair time and mark it synthetic ("synthesized": true).

3. A first prompt over the context window is sent anyway, with max_tokens clamped

A first user message larger than the model's context window is sent with
max_tokens clamped to the remainder and dies with a provider 400. Compaction
cannot help — there is nothing yet to compact — so the useful behaviours are to
refuse with a clear message, or to split.

Measured: a 126.5k-token prompt against a 131,072 window returned
400 status code (no body). Five sessions died this way before I set a margin in
the route's declared contextWindow (126,976 under a 131,072 lane), which turns
it into dsh's own limit and produces a comprehensible error.

4. Nothing bounds a child turn

tool-subagent has maxDepth (which caps tree depth) but nothing caps a
child's own turn: no step limit, no wall clock. A child that loops does so until
it exhausts the context.

I added a PreToolUse guard that denies repeated identical calls, which makes a
loop cheap but not finite — a deny reaches the model as an error and the turn
continues. In one recorded case a child emitted 1,255 calls after its guard
started denying them.

Suggestion: a maxSteps or a deadline on agentOptions.

[mattafaak]

The report said a subagent tool call has no step or time bound. Here is a
concrete instance from 2026-09-03 on 0.1.2-alpha.5, with the session log kept.

What happened

A benchmark drove a parent agent under a web-like composition. One task never
finished. At the 600 s external timeout the parent had produced nothing; the
child was still generating.

The child's session log:

subagent/descriptor  {version: 3, mode: 'one-shot', provider: 'spawn',
                      label: 'Read reports.py 6800-end'}
text-chunks          196 events, 3,511 characters
distinct strings emitted: 8
  '\n'  x701      "'"  x700      "'\\"  x699      'n'  x699   ...

Eight tokens, cycling ~700 times each. The child was emitting the literal
characters '\n' over and over and would have continued until something
outside it intervened. Nothing inside dsh did.

Why the existing guard does not catch it

We run a PreToolUse repeat guard that denies the 4th identical tool call and
the 8th in 30. It cannot see this, because the child never made a tool call
— it degenerated inside a single assistant message. A tool-call guard is the
wrong layer for a decode loop.

Why this is worse in a child than in a parent

• A parent's loop is visible: a human is watching the stream.
• A child's is not. The parent shows one pending subagent call, which is
  indistinguishable from a child doing slow, useful work.
• The parent cannot cancel it. Stopping the parent from the web UI does not
  kill a running tool subprocess (same class as [bug] Four smaller ones: an uncancellable compaction, a borrowed timestamp in the crash-repair closer, an over-window first prompt, and an unbounded child turn #5524's item 1).
• Cost is unbounded in wall clock, tokens, and — where the tier pins the child
  to another model — in lane residency: ours swap the GPU lane and re-prefill
  the parent afterwards, 1.5–2 min each way.

What would have been enough

Any one of these turns an outage into a logged failure:

1. maxTokens on the child turn, defaulting to the parent's.
2. A wall-clock deadline per tool-subagent call.
3. A repetition stop inside the child's stream — n identical chunks in a row is
   cheap to detect and unambiguous at 700 repeats.

(1) looks smallest: tool-subagent already accepts agentOptions, so a
maxTokens there would need no new surface.

Our mitigation, and why it is not a fix

We now strip delegation tiers from that benchmark's composition, and bound each
task externally. That stops the benchmark lying; it does nothing for a real
session, where a child can still run until a human notices.

[mattafaak]

The report said a subagent tool call has no step or time bound. Here is a
concrete instance from 2026-09-03 on 0.1.2-alpha.5, with the session log kept —
and a correction to our own proposed fix, since maxTokens turns out to exist
already and not to help.

What happened

A benchmark drove a parent agent under a web-like composition. One task never
finished. At the 600 s external timeout the parent had produced nothing; the
child was still generating.

The child's session log:

subagent/descriptor  {version: 3, mode: 'one-shot', provider: 'spawn',
                      label: 'Read reports.py 6800-end'}
text-chunks          196 events, 3,511 characters
distinct strings emitted: 8
  '\n'  x701      "'"  x700      "'\\"  x699      'n'  x699   ...

Eight tokens, cycling ~700 times each. The child was emitting the literal
characters '\n' over and over and would have continued until something
outside it intervened. Nothing inside dsh did.

Why the existing guard does not catch it

We run a PreToolUse repeat guard that denies the 4th identical tool call and
the 8th in 30. It cannot see this, because the child never made a tool call
— it degenerated inside a single assistant message. A tool-call guard is the
wrong layer for a decode loop.

Why this is worse in a child than in a parent

• A parent's loop is visible: a human is watching the stream.
• A child's is not. The parent shows one pending subagent call, which is
  indistinguishable from a child doing slow, useful work.
• The parent cannot cancel it. Stopping the parent from the web UI does not
  kill a running tool subprocess (same class as [bug] Four smaller ones: an uncancellable compaction, a borrowed timestamp in the crash-repair closer, an over-window first prompt, and an unbounded child turn #5524's item 1).
• Cost is unbounded in wall clock, tokens, and — where the tier pins the child
  to another model — in lane residency: ours swap the GPU lane and re-prefill
  the parent afterwards, 1.5–2 min each way.

maxTokens is NOT the missing bound — it was already set

Correcting our own first reading of this, because it changes the ask.
AgentOptions already carries maxTokens?: number ("Maximum output tokens for
each conversation-model request"), and every one of our seven tiers sets it
— the runaway child had maxTokens: 8192 in force the whole time.

It did not help, and the type comment says why: the cap is per
conversation-model request, and a turn is many requests. A child that
degenerates can keep starting fresh requests, each one comfortably under the
cap, for as long as anything lets it. Verified in 0.1.2-rc.1's shipped
packages — occurrences across dsh-subagent* and dsh-tool-subagent*:

bound	occurrences
maxTokens (per request)	present, and set by us
maxSteps	0
maxTurns	0
maxIterations	0
timeoutMs	0
deadline	0

So the gap is not a missing token cap. It is that nothing bounds the TURN.

What would have been enough

Any one of these turns an outage into a logged failure:

1. A step or turn bound on the child — the layer maxTokens does not reach.
   maxDepth already exists on tool-subagent and caps the delegation tree;
   a maxSteps beside it would need no new surface and would read naturally.
2. A wall-clock deadline per tool-subagent call.
3. A repetition stop inside the child's stream — n identical chunks in a row is
   cheap to detect and unambiguous at 700 repeats.

(1) looks smallest, and (3) is the only one that would also catch a child
looping slowly enough to stay under a deadline.

Our mitigation, and why it is not a fix

We now strip delegation tiers from that benchmark's composition, and bound each
task externally. That stops the benchmark lying; it does nothing for a real
session, where a child can still run until a human notices.

[argszero]

Mattafaak, the point-4 decode-loop is a genuinely distinct failure mode, and I think (3) is the highest-value bound for exactly the reason you state — a tool-call repeat guard is the wrong layer because a degenerate child never makes a tool call. It degenerates inside a single assistant message, and a per-request maxTokens: 8192 cannot stop it because a turn is many requests.

Since I had the session log format already open, I put (3) into practice as a diagnostic rather than a fix: a degenerate-stream detector that scans the assistant/chunk record for a run of many identical consecutive deltas. It is cheap (one pass, compare adjacent chunk texts), unambiguous at high repeat counts, and — unlike a wall-clock deadline — also catches a child looping slowly enough to stay under a deadline.

At 70x identical chunks it is clearly the loop; the same code runs as a REPETITIVE_STREAM finding in
@argszero/cordis-plugin-session-audit (v0.1.1), a session-log completeness audit:

[REPETITIVE_STREAM] 40 consecutive identical chunk(s) near seq 42 —
  a degenerate decode loop (repeated "\n"); a tool-call repeat guard cannot
  see this because no tool call is made between chunks.  Nothing bounds
  the turn length in the harness itself.

The one thing that stands out from your fix list: a diagnostic is not a stop. The audit flags the loop after the fact; it cannot bound the turn. That is the actual gap, and it lives in the harness, not in a plugin — tool-subagent has maxDepth (tree depth) but explicitly no step/turn bound, and your table shows maxSteps/maxTurns/maxIterations/timeoutMs/deadline are all 0 in every tier. A maxSteps beside maxDepth (your option 1) would need no new surface and would read naturally; (3) as an in-loop stop would be the only one that also catches a slow loop. I'd push for (1) as the primary bound and (3) as the safety net — but both are harness changes, not plugin territory.

For anyone hitting this today, the audit at least turns an opaque "child never finished" into a named reason ("decode loop, N identical chunks"), which is the first step to catching it.

[mattafaak]

@argszero — the REPETITIVE_STREAM detector is a good call and the framing
"a diagnostic is not a stop" is exactly right. One thing to add before (1) and
(3) get treated as primary-and-safety-net: they catch different failure
modes, and neither catches both.

The instance I filed degenerated inside a single assistant message — no tool
calls, which is why a PreToolUse guard is blind to it and why your chunk
detector sees it. There is a second flavour where the opposite is true.

Five child turns from one run, looping on tool calls

From a single shakedown on 0.1.2-rc.1, every one a depth-1 one-shot child:

child	tool calls	denied	most-called
bea6946b	335	300	skill ×334
535cb524	413	369	skill ×411
a95e02ed	911	900	web_fetch ×887
90e36c37	1,285	0	skill ×1,284
25e4ec49	1,313	1,080	read ×656, skill ×649

None of these would trip a consecutive-identical-chunk detector: the child is
making varied calls and streaming different text between them. Every one of
them would trip a maxSteps.

Honest caveat, because it changes how much to read into it: this is a
provoked loop. The test deliberately hands a read-only child a task it has no
tool for ("create a file … if you have no tool that can write, reply CANNOT
WRITE and stop"), to prove the toolFilter holds. The provocation is
artificial. The shape is not — a child asked for something outside its tool set
is ordinary — and the unboundedness is not artificial at all.

A deny is not a stop

This is the part worth having measured. Those denials are our own PreToolUse
hook, not dsh. In 25e4ec49 it refused 1,080 of 1,313 calls and emitted its
hardest escalation —

STOP: N consecutive tool calls were denied and the agent keeps calling. BLOCKED

— 202 times in one child turn. The turn continued anyway, and ended only
when an external timeout killed the process; no terminal kind is recorded
in any of the five transcripts.

A hook can refuse an action. It has no way to end a turn. So the guard many
of us are running is not a partial mitigation for this — it is zero mitigation,
just a louder log. That is the same gap you identified for the audit plugin,
one layer further in: not only can a diagnostic not stop it, a deny cannot
stop it either. Both live outside the loop that would have to break.

And 90e36c37 is the case that should settle it: 1,285 calls, zero denials.
The guard matches repeated calls, and there the arguments varied, so it never
fired once. A repeat guard is not even reliably a louder log.

So

• (1) maxSteps beside maxDepth catches all five above; it cannot catch the
  one I filed, which makes ~no steps.
• (3) an in-loop repetition stop catches the filed one and, as you say, a slow
  loop; it does not catch these five.

Two bounds, two failure modes. If only one lands, (1) is the cheaper surface
and covers the shape that is trivial to hit by accident — but it would be worth
saying in the docs that it does not cover a decode loop, so nobody reads
maxSteps: 200 as "a child cannot run away".