fix(runner): a file reaches the Pilot — a tool result keeps its lines and is capped per tool, not collapsed to 240 chars (#700)

`toolResult()` in `headless.ts` did two things to every engine `tool_result` before the
pane existed: collapsed `\s+` to a single space, and cut it to 240 characters. The
consequence is not that results were short — it is that the SHAPE of a result no longer
depended on the command that produced it. `cat`, `sed -n '1,50p'`, `cat -n | head -60` and
"print every character" all arrived identically sized, on one line, indentation gone.

So a Pilot that could not see a file had no move left. Live run `csess_6ce3627a`: twelve of
sixteen instructions were one file being asked for twelve ways, each a full BYOK Claude
decision round, and step 9292 concluded "the CLI is summarizing file contents rather than
showing raw output" — the correct reading of the evidence in front of it, and the wrong
diagnosis, because the evidence had been destroyed upstream. Measured across 20 sessions:
150 of 251 tool-result lines (59.8%) hit the cap, 43 of them `Read`.

WHAT CHANGED, and what each costs

- **Line structure survives.** `transcript-lines.ts` keeps newlines; every line after the
  first carries `  │ `. This is the half that matters most and costs 4 characters a line:
  `cat -n` output is unreadable space-joined at ANY length, so the collapse made the cap
  worse than its size alone implies. The prefix also means a result can no longer FORGE the
  framing — a file containing a line starting `⚙ ` would otherwise parse as a call the
  engine never made.
- **The cap is per tool, deliberately not one raised number.** 1,500 characters over 60
  lines for `Read`/`Bash`/`Grep`/`Glob`/`BashOutput`/`NotebookRead`; the historical 240 for
  everything else, because an `Edit`'s "has been updated successfully" was never near the
  cap and widening it would spend pane and buy nothing. An unknown tool takes the
  conservative budget.
- **A cut states its own size** — `…[cut: 1,500 of 18,432 chars]` — so "ask for a slice
  that fits" is a strategy rather than a guess.

WHAT IT COSTS THE PANE, stated rather than implied

A `terminal` row stores 8,000 characters and one Pilot decision reads 6,000, so every
character bought here is bought by evicting history. 1,500 is derived from that, not
picked: a quarter of the Pilot's window in content, and `RESULT_RENDERED_MAX` (~1,840) once
per-line framing and the disclosure are paid for — under a third of the window, so three
consecutive content results coexist with the `⚙`/`↳` framing and the narrative instead of
replacing them. Both figures are pinned as arithmetic in `transcript-lines.test.ts`; anyone
raising the cap has to argue with them.

TWO CONSEQUENCES ELSEWHERE, both fixed here because leaving either would make this a net loss

- `parseEngineToolCalls` read the arrow line only, so a 34-line result would have been
  reported as its first line, and `outputCut` (which keyed on a trailing `…`) would have
  read a cut result as a complete one — the #503 shape. It now reads `  │ ` continuations,
  bounded by an `inResult` flag so a stranded tail whose arrow line fell outside the
  8,000-char window is dropped rather than attributed to the wrong call.
- `FEED_TOOLCALL_BYTES` 12,000 → 24,000. That knee was measured against 240-char results;
  at the new cap the same mean production row (12.05 calls) serialises to ~25,000 B, and a
  call dropped by that cap is gone for good — no cursor reaches it. 24,000 is one of the two
  numbers the original measurement showed behaviour-identical on that corpus.

THE PROMPT NOW STATES A MECHANISM, NOT A NUMBER

`coding-loop.ts` said "cut to ~240 characters on a single line" and "NO shell command can
show you the contents of a file". True of every runner then published, false of an upgraded
one — the same defect pointing the other way, and the cloud cannot tell which machine it is
talking to. It now names the SIGNAL a Pilot can read on either: a cut result says it was
cut and by how much; ask for a slice that fits ONCE; if the next result is cut at the same
size and shape, the cap is on the result and re-asking is the same request. The untruncated
reply channel is still named, because it works on every runner ever published.

VERIFIED END TO END, not at the unit boundary

`headless.test.ts` drives a REAL spawned stream-json engine returning the same
~4,000-character file two ways. The `Read` route now delivers 34 numbered lines as lines
(`marker001`…`marker030` present, `marker092` absent, the cut figures stated) against ~5
lines space-joined before, with the `⚙ Read` and `  ↳✓` framing intact. That harness is the
one this issue's earlier round used to disprove the pane-window attribution, and it is the
level the claim has to hold at.

SHIPPING: `packages/cli` 0.4.54 → 0.4.55. The runner half reaches a machine only through a
published CLI, and 0.4.54 is already on npm so CI's publish step has been skipping. This one
bump also carries #636 (a stopped application lands under Cancelled) and #641 (a handoff
whose page was closed is lost, not solved), both of which have been sitting on `main`
finished and unshipped for exactly that reason.

Not run: `pnpm test:e2e`. This change touches no `store/`, console or `agents/coder/web`
code, so nothing Playwright exercises is in the diff.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: serge-the-dev

packages/browser-runner/src/coding/headless.test.ts

@@ -3,6 +3,7 @@ import { tmpdir } from "node:os";
 import { join } from "node:path";
 import { afterAll, beforeAll, describe, expect, it } from "vitest";
 import { buildClaudeArgs, defaultStatePath, HeadlessSession, parseCommand, mergeEnv } from "./headless.js";
+import { RESULT_RENDERED_MAX, toolResultBudget } from "./transcript-lines.js";
 
 /**
  * A stand-in for `claude -p --input-format stream-json --output-format stream-json`:
@@ -594,13 +595,14 @@ describe("HeadlessSession — a stream-json turn reports its own error (#545)",
  *
  * The run this pins spent twelve of sixteen Pilot decisions rephrasing one request — `cat`, then
  * `sed -n '1,100p'`, then `cat -n | head -60`, then "print every character" — because the file
- * never arrived and nothing told it why. Every one of those routes through a tool_result, and
- * {@link toolResult} caps it at 240 characters and collapses `\s+` to a single space BEFORE the
- * pane exists, so all four produce the same size and the same shape. The search space was empty.
+ * never arrived and nothing told it why. Every one of those routes through a tool_result, which the
+ * runner cut to 240 characters with `\s+` collapsed to a single space BEFORE the pane existed, so
+ * all four produced the same size and the same shape. The search space was empty.
  *
- * These two tests measure both routes against the SAME ~4,000-character file, because the prompt
- * fix is only honest if the channel it points at is actually wider. The reply-text route is the
- * one the prompt now names; if this pair ever stops holding, that advice is a placebo.
+ * These tests measure both routes against the SAME ~4,000-character file, through a REAL spawned
+ * engine rather than by calling the renderer directly — the claim being pinned is end-to-end
+ * ("a file reaches the Pilot"), and the earlier attribution of this failure to the pane window
+ * rather than the runner is what a unit-level check would have missed again.
  */
 describe("HeadlessSession — how much of a file reaches the pane (#700)", () => {
 	let dir: string;
@@ -615,7 +617,7 @@ describe("HeadlessSession — how much of a file reaches the pane (#700)", () =>
 	});
 	afterAll(() => rmSync(dir, { recursive: true, force: true }));
 
-	it("a tool_result loses ~94% of it — 240 chars, on one line, whatever command produced it", async () => {
+	it("a Read result arrives as LINES, ~1,500 characters of them, and says how much it lost", async () => {
 		expect(file.length).toBeGreaterThan(4000);
 		const s = new HeadlessSession({ id: "file-tool", workDir: dir, clientType: "claude", bin, statePath: defaultStatePath(dir) });
 		s.start();
@@ -624,25 +626,46 @@ describe("HeadlessSession — how much of a file reaches the pane (#700)", () =>
 		s.input("read web/e2e/helpers.ts"); // no "quote" — the engine uses its Read tool
 		await until(() => s.snapshot().includes("↳"), 8000, "the tool result line");
 		const pane = s.snapshot();
-
-		const resultLine = pane.split("\n").find((l) => l.startsWith("  ↳"));
-		expect(resultLine).toBeDefined();
-		// `"  ↳✓ "` (6) + the 240-char cap + the ellipsis. 246 is the maximum observed in production
-		// across 251 sampled result lines, and this is where that number comes from.
-		expect((resultLine as string).length).toBeLessThanOrEqual(246);
-		expect(resultLine as string).toMatch(/…$/);
-
-		// The head survives; everything past ~6 lines of a 92-line file does not.
-		expect(resultLine as string).toContain("marker001");
-		expect(resultLine as string).not.toContain("marker010");
+		const lines = pane.split("\n");
+
+		// The framing `engine-tool-calls.ts` parses is intact: the call line, then the arrow line.
+		expect(lines.some((l) => l.startsWith("⚙ Read "))).toBe(true);
+		const arrow = lines.findIndex((l) => l.startsWith("  ↳"));
+		expect(arrow).toBeGreaterThanOrEqual(0);
+		expect(lines[arrow].startsWith("  ↳✓ ")).toBe(true);
+
+		// THE fix: the file's own lines are lines again. Before this, not one of them survived as
+		// its own line at any length, which is why `cat -n` and `sed -n '1,50p'` were the same
+		// request to the Pilot.
+		const body = lines.slice(arrow + 1).filter((l) => l.startsWith("  │ "));
+		expect(body.length).toBeGreaterThan(30);
+		expect(body[0]).toContain("marker002");
+
+		// ~34 of 92 lines rather than ~5, and the cut is disclosed WITH its size — the number that
+		// tells the Pilot how narrow a slice would arrive whole.
+		expect(pane).toContain("marker010"); // the old 240-char cap stopped short of this
+		expect(pane).toContain("marker030");
 		expect(pane).not.toContain("marker092");
-
-		// And line structure is gone: not one line of the file survives as its own line, so
-		// `cat -n`, `sed -n '1,50p'` and `head -60` are indistinguishable at this resolution.
-		expect(pane.split("\n").some((l) => l.startsWith("  const marker"))).toBe(false);
+		expect(pane).toMatch(/…\[cut: 1,500 of 4,0\d\d chars\]/);
+
+		// And it is still bounded: the whole block — content, per-line framing and the disclosure —
+		// honours RESULT_RENDERED_MAX, which is under a third of the Pilot's 6,000-character window,
+		// so two more results can follow it before anything is evicted.
+		const block = [lines[arrow], ...body].join("\n");
+		expect(block.length).toBeLessThanOrEqual(RESULT_RENDERED_MAX);
+		expect(RESULT_RENDERED_MAX * 3).toBeLessThanOrEqual(6000);
 		s.stop();
 	}, 15_000);
 
+	it("a status-string tool keeps the old 240, so the widening is paid for only where it buys something", async () => {
+		// Same pane, different tool: `FAKE_CLAUDE_TOOLS` answers a `Bash` and a `Read`. The point is
+		// the negative one — a per-tool cap means an `Edit`/`TodoWrite` receipt cannot spend the
+		// window. Measured here on the budget function's own boundary rather than by spawning a
+		// fourth fake engine.
+		expect(toolResultBudget("Edit")).toEqual({ chars: 240, lines: 6 });
+		expect(toolResultBudget("Read").chars).toBeGreaterThan(240);
+	});
+
 	it("the engine's own REPLY text arrives whole — the one channel a file can travel", async () => {
 		const s = new HeadlessSession({ id: "file-reply", workDir: dir, clientType: "claude", bin, statePath: defaultStatePath(dir) });
 		s.start();

packages/browser-runner/src/coding/headless.ts

@@ -2,6 +2,7 @@ import { type ChildProcess, spawn } from "node:child_process";
 import { classifyCommand, commandFromToolInput, type EngineActRecord, fillTargetFromResult, toolCallOk, toolResultMark } from "./engine-acts.js";
 import { type EngineUsageRecord, parseEngineUsage } from "./engine-usage.js";
 import { type EngineTurnReport, turnReportFromExit, turnReportFromResult } from "./engine-turn.js";
+import { renderToolResult, shortInput, stripAnsi } from "./transcript-lines.js";
 
 /**
  * Merge the platform's resolved engine env over the machine's, where an EMPTY value means
@@ -191,6 +192,15 @@ export class HeadlessSession {
 	 * damages the record exactly as much as missing a real one.
 	 */
 	private awaitingResult = new Map<string, EngineActRecord[]>();
+	/**
+	 * `tool_use_id` → tool name, for the ONE decision the result event cannot make on its own: how
+	 * much of it reaches the pane (#700, `toolResultBudget` in `transcript-lines.ts`).
+	 *
+	 * Separate from {@link awaitingResult}, which holds only the small minority of calls that
+	 * classify as consequential acts. Entries are deleted when their result arrives and the whole
+	 * map is cleared at the turn boundary, where a call that never got one is known never to.
+	 */
+	private toolNames = new Map<string, string>();
 	/** Turn counter — only used to build a fallback id when the CLI's event has no `uuid`. */
 	private usageSeq = 0;
 	/**
@@ -669,15 +679,25 @@ export class HeadlessSession {
 					if (block.type === "text" && typeof block.text === "string" && block.text.trim()) {
 						this.push(`[${stamp()}] ${block.text.trim()}`); // timestamped agent reply
 					} else if (block.type === "tool_use") {
-						this.push(`⚙ ${String(block.name ?? "tool")} ${shortInput(block.input)}`); // ⚙
+						const name = String(block.name ?? "tool");
+						this.push(`⚙ ${name} ${shortInput(block.input)}`); // ⚙
+						// The result arrives in a LATER event carrying only `tool_use_id`, and how much
+						// of it reaches the pane depends on which tool it was (#700) — so the name is
+						// remembered here and read back in `settleAct`'s sibling branch below.
+						if (typeof block.id === "string" && block.id) this.toolNames.set(block.id, name);
 						this.noteAct(block);
 					}
 				}
 				break;
 			case "user": // tool results come back as a synthetic user message
 				for (const block of ev.message?.content ?? []) {
 					if (block.type === "tool_result") {
-						this.push(`  ↳${toolResultMark(block)} ${toolResult(block.content)}`); // ↳✓ / ↳✗ (#597)
+						const id = typeof block.tool_use_id === "string" ? block.tool_use_id : "";
+						// `""` when the call was not seen (a pane that began mid-turn, a runner restart):
+						// an unknown tool takes the conservative budget rather than the generous one.
+						const tool = this.toolNames.get(id) ?? "";
+						this.toolNames.delete(id);
+						this.push(renderToolResult(toolResultMark(block), block.content, tool)); // ↳✓ / ↳✗ (#597)
 						this.settleAct(block);
 					}
 				}
@@ -703,13 +723,16 @@ export class HeadlessSession {
 				// never saw whether it worked" is a materially different claim from silence, and
 				// silence is what a supervisor would read as "it did nothing".
 				this.flushAwaitingActs();
+				this.toolNames.clear(); // no further result is coming for anything still named here
 				this.run = "idle"; // the turn is OVER — a fact, not a guess
 				break;
 			}
 			default:
 				break;
 		}
-		// Keep the in-memory transcript bounded.
+		// Keep the in-memory transcript bounded. Counts ENTRIES, and an entry may now be a
+		// multi-line block (a result, or a long assistant reply) rather than one line — the
+		// character bound that matters is `MAX_PANE` in runtime.ts, applied on the way out.
 		if (this.transcript.length > 4000) this.transcript = this.transcript.slice(-3000);
 	}
 
@@ -735,8 +758,8 @@ export class HeadlessSession {
 	 *
 	 * The result carries more than the outcome: `gh pr create --fill` states its PR number nowhere
 	 * but its own stdout, so an unnumbered `pr.open`/`pr.merge` takes it from here (#417). It is read
-	 * from the RAW `block.content`, never from `toolResult()`'s display line — that truncates to 240
-	 * characters for the transcript and would cut the URL off a verbose result.
+	 * from the RAW `block.content`, never from `renderToolResult()`'s display lines — those are cut to
+	 * the pane's budget (`transcript-lines.ts`) and would drop the URL off a verbose result.
 	 *
 	 * This path (and `noteAct`) is reachable ONLY from the structured stream-json handling above
 	 * (`assistant` → `tool_use`, `user` → `tool_result`). A Codex/Grok session is a raw spawn with no
@@ -889,36 +912,6 @@ export function buildClaudeArgs(userArgs: string[], resumeId: string | null): st
 	return args;
 }
 
-/** Strip ANSI/VT escape sequences so a raw CLI's coloured output reads as plain text. */
-function stripAnsi(s: string): string {
-	// biome-ignore lint/suspicious/noControlCharactersInRegex: stripping terminal escape/control codes from terminal output.
-	return s.replace(/\x1b\[[0-9;?]*[ -/]*[@-~]/g, "").replace(/\x1b[()][AB0-2]/g, "").replace(/[\x00-\x08\x0b\x0c\x0e-\x1f]/g, "");
-}
-
-/** Compact a tool_use input object to a single readable line. */
-function shortInput(input: unknown): string {
-	if (input == null) return "";
-	try {
-		const s = typeof input === "string" ? input : JSON.stringify(input);
-		return s.length > 160 ? `${s.slice(0, 160)}…` : s;
-	} catch {
-		return "";
-	}
-}
-
-/** Render a tool_result's content (string, or array of {type:text,text}) to text. */
-function toolResult(content: unknown): string {
-	let text = "";
-	if (typeof content === "string") text = content;
-	else if (Array.isArray(content)) {
-		text = content
-			.map((b) => (b && typeof b === "object" && "text" in b ? String((b as { text: unknown }).text) : ""))
-			.join(" ");
-	}
-	text = text.replace(/\s+/g, " ").trim();
-	return text.length > 240 ? `${text.slice(0, 240)}…` : text;
-}
-
 // ── tiny on-disk store: our session id → Claude's session id (resume key) ──────
 // So a runner restart can `--resume` the conversation. One JSON file, best-effort.