Tool-result pruner silently truncates without marker; compaction never fires at default minContextRatio; no heredoc protection in pwsh tool

[bochen2029-pixel]

Tool-result pruner silently removes output middles without any marker; compaction never fires at default minContextRatio

Environment

• DSH harness (deepseek-harness), Windows 11, PowerShell tool
• Preset: cordis-cc (standard coding agent)
• Model: GLM-5.3-Flash / DeepSeek-V4.1-Flash (both affected)
• Workload: long-running book-production session (multi-hour, 270+ tool calls, heavy Word COM + Python + file operations)

Bug 1 — Tool-result pruner silently truncates without marking the cut

Config (from the default preset's compaction-tool-result-pruner):

thresholdChars: 8192
headChars: 4096
tailChars: 1024

What happens: any tool result over 8,192 characters is silently pruned to the first 4,096 + last 1,024 characters. The middle — up to 3,000+ characters — is removed with no marker, no ellipsis, no indication that anything was cut. The result looks like a continuous (but wrong) output.

Why this is dangerous: the model reads the pruned result as if it were the complete output. It cannot know the middle is missing. In our session, this caused:

• The model to report file counts, page counts, and image counts that were actually from the tail fragment, not the full result
• The model to conclude that directory listings were "fabricated" when they were actually pruned (the model saw the first few and last few entries but not the middle)
• A cascade of misdiagnosis where the model re-ran verified work, produced contradictory claims, and eventually refused to use the shell at all

Reproduction: run any command that produces >8,192 characters of output (e.g., a recursive directory listing, a Python script with 50+ lines of output). The model sees ~5,120 chars (4,096 head + 1,024 tail) and fills in the gap from context.

Suggested fix: insert a visible marker between the head and tail, e.g.:

[... 3,072 characters omitted by tool-result-pruner ...]

This costs 1 line but tells the model the output is incomplete, preventing confabulation.

Bug 2 — compaction-basic minContextRatio 0.97 means compaction never runs

Config (code default, no preset override):

minContextRatio: 0.97

What happens: compaction only fires when the session reaches 97% of the model's context window. In practice, this means compaction never runs for most sessions — the tool-result pruner keeps individual results short enough that the context grows slowly, and the model finishes its task before reaching 97%.

Why this is dangerous: pruned tool results (from Bug 1) accumulate unboundedly in the context. Each one is a head+tail fragment that the model partially remembers and partially infers. Over hundreds of tool calls, the context becomes a collage of fragments that the model can't accurately attribute — leading to the model making claims about "what it saw" that don't match any real output.

Suggested fix: lower the default minContextRatio to something like 0.80, or document prominently that the 0.97 default means "compaction will likely never fire."

Bug 3 — PowerShell tool doesn't protect against heredocs/here-strings

What happens: the pwsh tool passes commands directly to PowerShell without checking for here-string (@'...'@) or heredoc (<<EOF) patterns. On Windows, PowerShell here-strings can contain arbitrary content including:

• Unbalanced apostrophes (which break the enclosing command)
• Backslash sequences (which get halved before the shell sees them)
• Content over ~10K chars (which gets silently truncated by the command-line length limit)

Evidence: four independent traps documented and reproduced across multiple sessions on Windows 11 (details in the session tapes and the operator's memory notes). The machine-wide rule (in AGENTS.md/CLAUDE.md) forbids heredocs for this reason.

Existing protection: the project provides no_heredoc.py (a PreToolUse blocker) and nop hook run --policy block (a heredoc detector). Both are registered in ~/.claude/settings.json and work in Claude Code sessions.

The gap: the default DSH preset does not mount the dsh-hooks-claude-code bridge, so these hooks never fire in DSH sessions. A heredoc in a DSH pwsh tool call executes without any check.

Suggested fix (any of):

1. Mount dsh-hooks-claude-code in the default preset with configPath pointing at ~/.claude/settings.json (where the hooks are already registered)
2. Or add a built-in heredoc/here-string check in the pwsh tool itself (before execution), similar to kdp_precheck for print interiors
3. Or at minimum, document in the preset template that the hooks bridge should be mounted for shell-safety

Workaround (applied)

All three were worked around in the operator's preset (agent.cordis.yml):

• thresholdChars: 65536 (up from 8,192)
• minContextRatio: 0.80 (down from 0.97)
• hooks-claude-code bridge mounted with configPath: C:/Users/user/.claude/settings.json

Impact

Without these fixes, long-running sessions on the default preset will: (1) silently lose the middle of long tool outputs, (2) accumulate pruned fragments that look like real data, and (3) execute heredocs that may corrupt file content — all three of which cause the model to produce confidently wrong results that are indistinguishable from hallucination.

[avpanasyuk]

A correction and an addition, checked against @deepseek-ai/dsh-compaction-tool-result-pruner 0.2.0-rc.2:

There is a marker in 0.2.0-rc.2. lib/index.js:8 defines PRUNE_MARKER = "\n\n[... tool result middle pruned ...]\n\n", and a pruned result is head + marker + tail (exactly 5,159 chars with the default 4096/1024). It is easy to miss, because the surviving head reads like a normal file listing.

There is no recency exemption, which causes a re-read loop. pruneSession (:138-146) collects every tool/result on the surface as a candidate, with no age, step or turn check, and rewrites each one over thresholdChars in place (surfaceOp: replace). So once a session reaches the compaction threshold, a file read a moment ago is cut like any old one. The agent then sees a truncated file, does not understand why, and reads it again, which is cut again at the next compaction. We measured eleven reads plus two greps of one ~70k-char file in seventeen minutes, and 32 prunes against 40 compactions in one session. It looks like a slow model.

Suggestion: exempt the N most recent tool results, or any result produced in the current step/turn, from pruning. That keeps the savings on old results and ends the loop.

(Workaround: keep each read under thresholdChars with offset/limit, or set readMaxBytes low enough that a read never exceeds it.)

[avpanasyuk]

A second ask on the pruner, with an implementation behind it: put an informative notice at the HEAD of a pruned result, not only a bare marker in the middle.

Why the position matters. In 0.2.0-rc.2 the only evidence of a prune is [... tool result middle pruned ...], placed after headChars (4096) of ordinary-looking output. A model that later reasons from the survivor reads a normal <path>…<content>1: … listing first. It has no size, no range and no recovery path. What we see in long sessions is the re-read loop described above, or work done from an amputated file. #2039 makes the same point about position (it proposes "a compaction-safe prefix marker at position 0").

What we run instead. A drop-in replacement for the toolResultPruner service: same service name, same three config keys, stock's config validation, and the same head/marker/tail cut and compaction/prune + replace event pair. The only change is a separate first text block like this one, from a live 0.2.0-rc.2 session:

[PRUNED tool result: this result was 55450 chars over 845 lines. Shown: chars 1-4096 and chars 54427-55450. NOT shown: chars 4097-54426.
Source: read {"file_path":"big.txt","offset":1} at 2026-10-12T03:27:41.011Z; it may have changed since.
File lines 62-825 are missing or partial. Recover: read offset=62 limit=434, repeating through line 825. At this gap's average line length a slice is about 28644 chars; a result over 32768 chars is cut again.]

The mid marker then names its own range ([... chars 4097-54426 not shown; see the notice at the top ...]). Details that turned out to matter:

• The recovery hint for read comes from the N: prefixes on either side of the cut. A tail span starts mid-line, so its first match is ignored: 23: may be the end of 1023: . The slice size is computed from the gap's own average line length and kept under the threshold. When no read slice can fit (a single line longer than the slice), it falls back to "re-run with narrower output", because read returns whole lines.
• A result that was already cut (stock marker present, or a reload at a lower threshold) is labelled as such, and gets no line hint, since its counts are of the survivor and not of the original.
• The notice must fit between head and tail. When thresholdChars − headChars − tailChars cannot hold it, that result gets the stock marker. The replacement never refuses a config that stock accepts: a load failure leaves ctx.get("toolResultPruner") undefined, and compaction-basic then skips pruning without saying so.
• One malformed event skips only that result, not the rest of the pass.

The ask: emit a head notice of this kind from the shipped pruner (provenance from the tool/call event, recovery hint for read), with the head/tail budget unchanged. It composes with #2039: a spill copy would give non-file tools the recovery source that read already has.