The runner cuts every engine tool result to 240 characters, so no instruction can return file contents to the Pilot — and the prompt tells it to keep trying #700

The runner cuts every engine tool result to 240 characters, so no instruction can return file contents to the Pilot — and the prompt tells it to keep trying

What the owner saw

Live run on bd43f4de-ef35-4051-bdec-43f8571414a1, session
csess_6ce3627a-3c3f-439a-90f3-ff4a6de3167a, 2026-08-17. Twelve of the run's sixteen
instructions (seq 9286–9297) were the Pilot trying to get the raw text of one file,
web/e2e/helpers.ts, out of the engine. Each is a full BYOK Claude decision round. Verbatim,
from coding_timeline:

The owner's reading of step 9292 — "the CLI is summarizing" — is what the evidence in front of
the Pilot supports. It is not what happened.

The mechanism: the runner truncates, not the CLI

Claude Code returns the whole file over stream-json. packages/browser-runner/src/coding/headless.ts:680
renders each tool_result into the transcript through toolResult(), and :910-919 is that
function:

function toolResult(content: unknown): string {
	let text = "";
	…
	text = text.replace(/\s+/g, " ").trim();
	return text.length > 240 ? `${text.slice(0, 240)}…` : text;
}

Two losses, both before the pane exists:

1. 240 characters. ~3 lines of code, whatever the command asked for.
2. \s+ → " ". Every newline and indent is collapsed, so even those 3 lines arrive as one
   unbroken line. sed -n '1,50p' and cat -n | head -60 produce byte-identical shapes at that
   resolution.

The sibling shortInput() at :899-903 does the same to the argument at 160 chars.

So no phrasing can work. Every one of those twelve instructions routes the file through a
Bash or Read tool_result, and the cap fires on all of them identically. The Pilot was not
being obtuse; it was running a search whose space is empty.

Nothing in the loop prompt asks the engine to summarise —
grep -n "summar" workers/api/src/lib/coding-loop.ts returns nothing. The engine summarises
because a model asked "show me this file" answers conversationally; its text block is what
carries the answer, and that block is pushed untruncated (headless.ts:671).

How often it fires — population, not one run

Swept every stored terminal snapshot on this instance (20 sessions, 43 snapshots, 251 tool-result
lines), counting lines ending in the truncation ellipsis:

Max observed result-line length 246 = " ↳✓ " (6) + 240. The cap is not a corner case; it is
the common case, and it fires on Read — the tool whose entire job is returning file contents.

The second half: the prompt names the wrong constraint

workers/api/src/lib/coding-loop.ts:542:

- You see only the LAST ~${PILOT_PANE_CHARS} characters of the terminal, never all of it. An instruction whose output is longer than that can never be verified by you: **ask for a bounded slice (a line range, a grep, head/tail)** rather than a full dump…

PILOT_PANE_CHARS = 6000 (lib/coding-repetition.ts:37). That line was added for #522 cause B,
whose recorded diagnosis is at coding-repetition.ts:17-21:

"The Pilot reads {@link PILOT_PANE_CHARS} characters of terminal while instructing a dump of
roughly twice that, so its own instruction is unverifiable by construction"

That attribution is wrong, and this run is the disproof. The dump is not in the pane in
truncated form — it was never in the pane at all. The binding limit is 240, not 6,000, and it does
not depend on how much was asked for. The prompt therefore hands the Pilot a remedy that cannot
work and a reason that is not the reason: sed -n '1,100p' → sed -n '1,50p' → head -60 →
sed -n '1,80p' is a model correctly following instructions that are false. #522's renderPaneForPilot
fix stands (stating a measurement beats leaving it implicit); the number it states is the wrong one
for this failure.

This is not #534. That is repo_read_file's 8 KB cloud-side cap on the repo connector path,
where an offset argument is the fix. This is the engine-drive path, where the Pilot has no
tool at all — it types a shell command and reads a pane. Different file, different remedy. #534
correctly predicted the Pilot would "page through a file by asking the engine to print it"; it
attributed the failure of that fallback to the 6,000-char pane, same as #522, and this is the
measurement that says otherwise.

What to do — cheapest first, and they are separable

1. Fix the prompt (one string, ships today). Replace the "ask for a bounded slice" advice at
coding-loop.ts:542. It must state the real bound and the one channel that has full fidelity:

A tool's OUTPUT reaches you truncated to ~240 characters on a single line, whatever command you
ran — cat, sed, head and grep all arrive the same size, so re-asking with a smaller range
will not help and a shell command can never show you a file. The engine's own REPLY text is not
truncated: to learn a file's contents, ask the engine to answer you with them ("quote lines
1-40 of X verbatim in your reply"), or ask it a question about the file and take its answer.

This alone converts twelve wasted rounds into one, and it is the fix that reaches every run
immediately — a runner change needs a CLI publish plus each machine upgrading.

2. Raise the result cap, deliberately — and this is a design decision, not a constant bump.
The pane is a fixed window: the API stores TERMINAL_SNAPSHOT_CHARS = 8000
(lib/terminal-snapshot.ts:57) and the Pilot reads 6,000 of it. At 240 chars a result, ~59% of
251 results still fit alongside the narrative. At 2,000, three large results fill the entire
stored snapshot and evict everything else — including the ⚙/↳ framing that
engine-tool-calls.ts parses into toolCalls, and the engine-error lines #580's
acceptance criterion exists to keep visible. So a flat raise buys file text by spending history.

The shape that does not: cap by tool. Read/Bash are the ones the Pilot needs verbatim;
Edit/Write/TodoWrite results are status strings that were never over 240 anyway (see the
sample above — "has been updated successfully", 176-214 chars). A per-tool cap raises exactly the
results that carry content. Owner's call whether that is worth the runner change at all once (1)
lands — my recommendation is to ship (1), measure whether runs still stall, and only then decide.

3. Stop collapsing whitespace regardless of the cap. \s+ → " " destroys line structure for
no size benefit worth naming, and it is the reason cat -n and sed are indistinguishable to the
Pilot. Cheap, independent of (2).

4. Correct the recorded cause. coding-repetition.ts:17-27 is the place a future reader learns
why this happens. Its "CAUSE B" paragraph should name the 240-char result cap as the binding limit
and keep PILOT_PANE_CHARS as the secondary one, or the next person re-derives the wrong fix.

Alternatives considered and rejected

• Give the Pilot a read_file tool of its own. Rejected here as out of scope and as a
  collision: repo_read_file already exists on the connector path and is [bug] repo_read_file caps at 8KB of the 64KB the runner already read, with no offset to fetch the rest — the root cause under #522's repeated "read the full file" #534's subject. Two file
  readers with different caps is worse than one working prompt. Revisit only if (1) is measured
  insufficient.
• Detect the pattern and stop the run. repetitionVerdict (coding-repetition.ts:116)
  deliberately does not catch this — the twelve instructions are paraphrases, not repeats, and its
  own docblock says no honest normalisation unifies them. Correct; a stall detector is not a
  substitute for removing the impossibility.
• Raise PILOT_PANE_CHARS. Rejected: it is not the binding limit. It would raise cost per
  decision and change nothing about this failure.

Acceptance criteria

1. A test replays the twelve instructions' shape — a Bash/Read result of 4,000 characters — and
   asserts what the Pilot's snapshot actually contains, so the 240-char loss is pinned rather than
   described.
2. The prompt no longer advises a bounded slice as the remedy for unverifiable output, and states
   the ~240-character tool-result bound and the untruncated reply-text channel.
3. coding-repetition.ts's CAUSE B names the binding limit correctly.
4. If (2) is taken: Read/Bash results survive to a stated length; the guard states the length
   and shows the stored snapshot still carries its ⚙/↳ framing afterwards.
5. Whitespace is no longer collapsed within a result.

Regression risk

(1) and (4) touch a prompt string — the risk is that a Pilot now asks the engine to quote long
files into its reply, which lands in the pane untruncated and can push the 8,000-char stored
snapshot's older content out. The #432/#466 snapshot-dedup and prune behaviour is where that
would show; lib/terminal-snapshot.ts's tests are the place to assert it.

(2) is a runner change: it ships only via a CLI version bump and per-machine upgrade
(platform/CLAUDE.md § Distribution), and old runners keep the 240 cap — so any cloud-side reader
must keep tolerating short results. engine-tool-calls.ts already models this (resultTruncated,
:116) and must keep doing so.

Verified vs inferred

• Verified: all twelve instructions, read verbatim from GET …/timeline?full=1 on the named
  session; the 150/251 truncation sweep across 20 sessions; the 246-character maximum; the four
  cited headless.ts lines; that block.text is pushed untruncated at :671; that
  grep -n "summar" workers/api/src/lib/coding-loop.ts returns nothing; PILOT_PANE_CHARS = 6000;
  TERMINAL_SNAPSHOT_CHARS = 8000.
• Inferred, and NOT reproduced end-to-end: that the corrected prompt would have got the file in
  one round. I did not drive a live run — the session belongs to the owner and was still live. The
  claim rests on block.text being untruncated, which is verified in code but not observed
  carrying a deliberately-quoted file.
• Not measured: whether the twelve rounds' BYOK cost is recoverable from ai_usage. The run
  was cancelled (outcome seq 9303: "cancelled — Stopped by you."), so a cost figure would need
  the ledger, not the timeline.