CRITICAL: truncated tool call permanently breaks the session — cleanup path unreachable, generated content destroyed

[ScrewTSW]

Note: this issue was filed under a wrong theory and revised several times as evidence came
in. The body below is the corrected account. Earlier comments contain retracted claims — in
particular that a corrupt file was written to disk (it was not; the file in question was
created manually by the user). See the retraction comment for what was withdrawn.

Summary

When a tool call's arguments are truncated mid-stream, Continue offers the incomplete call to
the user for acceptance. Accepting it fails with a JSON parse error, nothing is applied, and
the generated content is recoverable only by copy-pasting from the chat transcript.

Observed 3× while generating a single large Python file.

Sequence

tool-call arguments truncated mid-stream
  → call promoted to `generated` WITHOUT validating arguments
  → surfaced in the UI as a normal, acceptable pending write
  → user clicks Accept
  → JSON.parse fails: "invalid string: missing closing quote"
  → nothing applied; no file created
  → content lost from the actionable path (still visible in transcript)

The user ultimately created the file by hand from the response block.

Two triggers, one defect

Truncation arises two ways, and they are currently indistinguishable:

Trigger	signal.aborted	Notes
Output window exhausted	false	Reasoning + prose + tool argument share one budget
User cancels generation	true	Reproduced at 879 bytes — nothing near any limit

The cancellation case is what proves this is not a context-window bug. Same error, same
mid-string cut, at a fraction of the size.

The exhaustion boundary also moves, because the argument gets whatever the reasoning and
prose leave behind:

effective_limit = window − (reasoning + prose)

Observed truncation columns: 31,447 → 31,395 → 879. Any test asserting a fixed byte
threshold will be flaky.

Root causes (verified in code)

1. core/tools/parseArgs.ts:17-24 — parse failure swallowed

try {
  return JSON.parse(toolCall.function?.arguments?.trim() || "{}");
} catch (e) {
  //console.error(...)   // diagnostic commented out
  return {};
}

{} conflates "no arguments" with "arguments were corrupt". Shared by Anthropic, Gemini,
Bedrock and callTool.ts.

2. gui/src/redux/slices/sessionSlice.ts:951-973 — setToolGenerated validates nothing

if (toolCallState) {
  toolCallState.status = "generated";   // unconditional

This is what makes a truncated call eligible for the approval UI. callToolById.ts:33-34
correctly refuses anything not generated — but the status claims generated, so it is admitted
and fails downstream, after the user has committed.

3. finish_reason never reaches the tool layer

Absent from core/index.d.ts; read once in openaiTypeConverters.ts:410 and dropped. So
exhaustion, cancellation, and a genuinely malformed model response are indistinguishable at the
point of decision — though only the first is resumable.

4. gui/src/redux/slices/sessionSlice.ts:581-584 — abortStream leaves calls in-flight

Aborts the controller and replaces it without marking in-flight tool calls. A cancelled call
keeps status: "generating" indefinitely. (Same shape as the reasoning-span bug fixed in #16 —
an in-flight state no path closes on cancellation.)

Not a security issue

Verified: a cancelled tool call cannot execute. callToolById.ts:33-34 hard-returns unless
status === "generated", and streamNormalInput.ts:300 returns early on abort. An interrupted
python3 << 'EOF' … payload could not have run.

Desired behaviour

Handle the two triggers differently, because the user's intent differs:

Cancellation — deliberate. Mark generating → canceled. Never parse, never execute, never
offer for acceptance. Render as interrupted, not failed.

Exhaustion — accidental. The work exists and is visibly correct. Salvage it:

• recover completed keys plus the partial trailing string value
• require a fully-parsed destination path (never guess)
• present as incomplete, with Continue / Discard / Keep — never a plain Accept that must fail
• on Continue, re-prompt with the tail of the recovered content so the model appends at the right
  boundary rather than regenerating
• cap resume attempts so an unattended agent cannot loop

Fix order

1. setToolGenerated must refuse to promote unparseable arguments — stops the bad acceptance
   offer at its source
2. parseArgs must surface a typed failure instead of {}
3. Plumb finish_reason to the tool layer
4. Salvage + user-gated resume (highest user-facing value)
5. abortStream marks generating → canceled

Tests

• Truncated args → call is never offered as acceptable
• Cancel mid-argument → status canceled, no execution, no side effects
• Exhaustion + valid path → salvage offered with the recovered tail
• Malformed JSON with finish_reason: stop → clear error, not resumable
• Resume appends without duplicating the boundary region
• No fixed byte threshold — the boundary moves with reasoning length

Environment

Fork main @ 63bc4ef9d; observed on a local model via the orchestrator.

[ScrewTSW]

Recurrence — same payload, same byte offset

The failure repeated later in the same session, and the details narrow the cause considerably.

Identical truncation point. Both failures report parse error at line 1, column 31447, and
both cut at the same place in the payload — mid-epilog inside parse_arguments(), at
%(prog)s --velocity. Byte-for-byte the same prefix.

This rules out random corruption. A transmission glitch would not truncate twice at an
identical offset. A deterministic boundary at ~31.4 KB points at either a fixed buffer/size
limit in the tool-call path, or the same queued call being retried rather than a new one being
composed.

The assistant made no such call on either occasion. In the second instance the preceding
actions were gh issue create (filing this issue) and an Edit repairing
CONTINUE_ASSESSMENT.md. Neither carried Python content. The payload is arriving from outside
the assistant's turn.

This shifts weight toward hypothesis 2 in the original report (content leaking into the
tool-call path) and away from hypothesis 1 (benign truncation of an intended write), since
there is no intended write to truncate.

Still nothing written. No file created or overwritten in either instance.

Additional investigation notes

• Identify what sits at the ~31,447-byte boundary — buffer size, transport frame, or
  serialisation limit
• Determine whether the retry is harness-level (re-submitting a queued call) or upstream
• Priority: confirm no code path can write a payload the assistant did not author. The
  loud failure is what surfaced this; a silent success would not have been noticed.

[ScrewTSW]

Correction — origin identified, this is a Continue bug

The earlier framing in this issue was wrong and should not be followed.

The payload did not "leak" from anywhere. The user prompted the Continue extension to write a
Python ballistic calculator; the payload is the model's legitimate response to that prompt. The
reason it appeared unattributed is simply that it originated in a different session (a Continue
chat) than the one that observed the failure (a Claude Code session). There is no cross-context
contamination, and the speculation about content entering the tool-call path unauthored is
withdrawn.

What this actually is

Continue fails to write a file when the model's tool-call argument exceeds ~31 KB.

• Reproduced twice, both failing at column 31447, cut at the identical character
  (mid-epilog in parse_arguments(), at %(prog)s --velocity)
• The argument string is truncated before its closing quote, so the JSON never parses and the
  write is abandoned
• No file is written and no partial file is left behind — the failure is loud, which is the
  one good thing here

Why the offset matters

31,447 is not a round number — not 32768, not 32000, not any power of two. A fixed buffer
limit would land on a round boundary. This looks more like the argument being terminated
mid-construction, i.e. a streamed tool-call argument cut off before completion, rather than a
hard cap being enforced.

That places it in the same family as #1 (stream chunks carrying usage swallowed) and #2 (batched
messages dropped after a <think> block) — mid-stream content loss on a local-inference path.
Worth checking whether the tool-call argument accumulator has the same class of defect.

Impact

Any prompt asking for a large single file — a long script, a full module, a big config — will
fail to write. This is a plausible everyday failure for local-model users generating substantial
files, and the ~31 KB threshold is low enough to hit routinely.

Revised investigation

• Locate where streamed tool-call arguments are accumulated and find what terminates at ~31 KB
• Determine whether the cap is in the extension, the adapter layer, or the model server
• Check whether the same truncation affects other large tool arguments (Edit, MultiEdit)
• Add a regression test with a >31 KB write payload
• Reproduce with a known-good local model to rule out the model server

Not the token cache

Ruled out: core/llm/tokenCountCache.ts is Map<string, number> — it stores counts, not text,
and is not in the tool-call serialisation path. #19 remains confirmed-working; it is unrelated.

[ScrewTSW]

Correction 2 — a file IS written, and it is corrupt. Severity raised.

Earlier claims in this issue that "no file was written and nothing was lost" are WRONG.
That was inferred from the JSON parse error rather than verified against the filesystem. It has
now been checked and the opposite is true.

Verified on disk

$ wc -lc /home/tdancs/ballistic_calculator.py
818 30311 /home/tdancs/ballistic_calculator.py

$ tail -3 /home/tdancs/ballistic_calculator.py
Examples:
  %(prog)s --velocity

$ python3 -m py_compile /home/tdancs/ballistic_calculator.py
  File "/home/tdancs/ballistic_calculator.py", line 816
    epilog='''
           ^
SyntaxError: unterminated triple-quoted string literal (detected at line 818)

The file exists, is 818 lines / 30,311 bytes, ends mid-statement at exactly the truncation
point seen in the error (%(prog)s --velocity), and does not compile.

Corrected failure description

1. A large tool-call argument is truncated mid-string (~31 KB)
2. The partial content is written to disk anyway — a real file is created
3. The tool call then reports a JSON parse failure
4. The artifact left behind is not merely incomplete but syntactically invalid

The 30,311 bytes on disk vs. the parse error at column 31,447 differ by ~1.1 KB, which is
consistent with JSON escaping overhead (\n, \") in the argument string — i.e. the file on
disk and the failed argument are the same truncated payload.

Why this is worse than originally filed

The original report praised the failure for being "loud". It is not. The user sees an error and
would reasonably conclude nothing happened, while a broken file sits on disk. Discovered only
because the user re-opened the session and asked the model to read the file back.

Concrete risks:

• Silent corruption of an existing file. If the target already existed, this overwrites it
  with truncated content. Original contents are unrecoverable outside version control.
• Invalid artifacts that fail later, far from the cause
• The error message points at JSON parsing, giving no hint that the filesystem was touched

Revised priorities

• Make the write atomic. Nothing should reach disk unless the full argument parsed.
  Write to a temp file and rename, or validate before opening the target. This is the fix
  that matters regardless of what causes the truncation.
• Find what truncates the argument at ~31 KB (still open; 31,447 is not a round number, so
  likely mid-construction termination rather than a fixed cap)
• Check whether Edit/MultiEdit share the partial-write behaviour — potentially destructive
  on existing files
• Surface a real error naming the file that was touched
• Regression test: >31 KB write must either fully succeed or leave the target untouched

Reproduction

Prompt the extension to generate a single file larger than ~31 KB (e.g. "write a ballistic
calculator with SI/Imperial units, wind, altitude, and Coriolis placeholders"). Observed twice,
truncating at the identical character both times.

[ScrewTSW]

Lead: 32,768 — likely the same wrong-window bug as #18, not a max-response cap

Considered and largely ruled out: max response length.

core/llm/constants.ts:1 → DEFAULT_MAX_TOKENS = 4096. The truncated file is 818 lines /
30,311 bytes (~8–9k tokens for Python), so generation overran 4096 rather than stopping at it.
A maxTokens stop also yields a clean finish_reason: "length" — the model stops emitting and
the tool call is absent or well-formed-but-short. It does not produce a JSON prefix cut
mid-string-literal, which is what was observed.

It also would not be byte-deterministic. The same prompt truncated at the identical character
twice; token sampling would shift where the text lands.

Better candidate — line 2 of the same file

core/llm/constants.ts:1: const DEFAULT_MAX_TOKENS = 4096;
core/llm/constants.ts:2: const DEFAULT_CONTEXT_LENGTH = 32_768;

DEFAULT_CONTEXT_LENGTH = 32_768, and the truncation is at 31,447 — roughly 1.3 KB
short of it.

This is the same 32,768 that #18 exposed: the context meter reported 786% because Continue
assumed a 32,768 window against a real 262,144+. That was diagnosed at the time as a config bug
the clamp was masking (see #18 and CONTINUE_RESUME).

Why it fits better than a response cap:

• A window ceiling is something generation runs into, not something the sampler respects —
  which explains a cut mid-string-literal rather than a graceful stop
• Byte-deterministic: same prompt, same boundary, same character
• 31,447 < 32,768 with ~1.3k headroom, consistent with prompt/system overhead taking the rest
• Explains why this surfaces on large single-file generation specifically

Not yet confirmed

This is a strong correlation, not a traced cause. Still to verify:

• Which contextLength the user's model config actually supplies — if it sets a real value,
  DEFAULT_CONTEXT_LENGTH never applies and this lead is wrong
• Whether the truncation happens at generation time (window exhausted) or at
  argument-assembly time (accumulator capped)
• Whether finish_reason on the failing request is length or stop — this alone
  distinguishes the two
• Reproduce with an explicitly-set large contextLength to see if the boundary moves

If the boundary moves when contextLength changes, this is confirmed and the fix is shared with
the #18 config problem. If it stays at ~31.4 KB regardless, it is an accumulator cap and
unrelated.

The atomic-write fix remains correct and independent of this outcome — a truncated argument
must never reach disk, whatever truncates it.

[ScrewTSW]

Lead refined — the ~1.3 KB headroom was reasoning + prose, not prompt overhead

Correcting the previous comment: the gap between the 31,447 truncation point and
DEFAULT_CONTEXT_LENGTH = 32_768 was not prompt/system overhead. It was the agent's own
reasoning block and its response sentence, emitted in the same completion before the tool
call.

Why this matters

All three draw from one output budget:

[ reasoning ] + [ response prose ] + [ tool-call argument ]  ≤  window

The file received whatever was left after the first two. That explains:

• Why it stops mid-string-literal. The budget ran out mid-emission; there is no structural
  boundary at that byte.
• Byte-level determinism across runs. Same prompt → same reasoning → same prose → the
  remainder ends at the same character. A sampling-level cap would not reproduce this exactly.
• Why large single-file generation is the trigger. It is the only workload where the tool
  argument is the dominant consumer.

The limit is not a fixed ~31 KB

Earlier framing (including this issue's title) implies a constant threshold. It is not:

effective_write_limit  =  window − (reasoning + prose)

A more talkative turn writes a shorter file. A model with longer reasoning truncates earlier.
Any test asserting a fixed ~31 KB boundary will be flaky for this reason.

Relationship to #18

#18 found Continue assuming a 32,768 window against a real 262,144+, reported as a display bug
(the 786% meter) with the clamp as the fix. This suggests the same wrong window has a second,
silent consequence: it truncates generated output, not just the percentage shown.

The clamp fixed the symptom that was visible. This is the symptom that was not.

Sharpened verification

• Confirm the model config's contextLength — if unset, DEFAULT_CONTEXT_LENGTH (32,768)
  applies and this is confirmed
• Re-run the same prompt with reasoning disabled — the file should get longer if this
  model is right
• Re-run with an explicitly large contextLength — boundary should move outward
• Check finish_reason on the failing request

Prediction that would falsify this: if the boundary stays at ~31.4 KB when contextLength is
raised and when reasoning is disabled, it is an argument-accumulator cap and this lead is
wrong.

The atomic-write fix is still independent and still correct — whatever truncates the
argument, partial content must never reach disk.

[ScrewTSW]

Design: graceful stop + resume on truncated tool calls

Root cause found

core/tools/parseArgs.ts:17-24 — the parse failure is swallowed:

try {
  return JSON.parse(toolCall.function?.arguments?.trim() || "{}");
} catch (e) {
  //console.error(...)   // <-- diagnostic commented out
  return {};
}

A truncated argument becomes an empty-args tool call that proceeds silently. The corrupt file is
not written despite an error — it is written because the error was discarded.

Compounding this: finish_reason never reaches the tool layer. It does not appear in
core/index.d.ts at all, and is read only once (openaiTypeConverters.ts:410) before being
dropped. By the time callTool.ts:246 executes, the fact that the response was cut off is
already unrecoverable.

safeParseToolCallArgs is shared by Anthropic, Gemini, Bedrock and callTool.ts — changes here
affect all four.

---

Layer 1 — Detect (stop discarding the signal)

Returning {} conflates "no arguments" with "arguments were corrupt". These need different
handling:

export type ParsedToolCallArgs =
  | { ok: true; args: Record<string, any> }
  | { ok: false; raw: string; error: Error };

Keep a thin safeParseToolCallArgs wrapper returning {} so existing call sites are unaffected,
and migrate them deliberately.

Also plumb finish_reason through to the tool layer. length is authoritative: it distinguishes
"model was cut off" (resumable) from "model emitted malformed JSON" (a model bug, not
resumable). Currently indistinguishable — and only the first should ever be resumed.

Layer 2 — Salvage (recover the partial value)

A truncated argument still holds usable data:

{"filepath": "ballistic_calculator.py", "content": "#!/usr/bin/env python3\n\"\"\"\nBasic Ball…
     ^ complete                                          ^ valid prefix

A tolerant scan recovers completed keys and the partial value of the final in-flight string.
This is what makes resume possible rather than merely safe.

Guardrails:

• Only attempt when finish_reason === "length"
• Require the destination path to have parsed completely — never guess a path
• Cap salvage attempts per turn to prevent loops

Layer 3 — Resume (write deliberately, then continue)

Write the partial content, but mark it incomplete and give the agent what it needs to
continue:

1. Write to the real path — the user did ask for the file
2. Return a tool result stating explicitly:
   • the write was partial, with byte count
   • the tail of what was written (last ~200 chars)
   • instruction to continue by appending, not regenerating
3. Next turn appends from that boundary

The tail is the critical detail: without it the model resumes at a guessed boundary and either
duplicates or drops content.

PARTIAL WRITE — output window exhausted mid-argument.
Wrote 30,311 bytes to ballistic_calculator.py (incomplete).
Content ends with:
    epilog='''
    Examples:
      %(prog)s --velocity
Continue by APPENDING from exactly this point. Do not rewrite the file.

Why not plain rollback

Discarding 818 correct lines because the final 3 are incomplete wastes real work and, on a local
model, real minutes. Recoverable beats atomic here — provided the partial state is explicit,
which today it is not.

Rollback remains correct when the path did not parse, or when finish_reason !== "length".

Open questions

• Does a partial file break anything downstream that assumes valid syntax (indexing, LSP)?
• Should the partial file get a marker (.partial sidecar) rather than a bare truncated file?
• Existing-file overwrite: partial write destroys the original. Needs backup-then-write,
  or refuse-and-report when the target exists and is non-empty.
• Interaction with Edit/MultiEdit, which are destructive by nature

Test plan

• Truncated JSON at several boundaries (mid-key, mid-value, mid-escape) → no silent {}
• finish_reason: length + valid path → partial write + resume instruction containing the tail
• finish_reason: stop + malformed JSON → no write, clear error
• Resume appends without duplicating the boundary region
• Overwrite of an existing file never destroys it
• Do not assert a fixed byte threshold — the limit is window − (reasoning + prose) and
  varies per turn

[ScrewTSW]

Revised: user-gated resume, not auto-append

Supersedes the auto-append design in the previous comment.

Why the change. Auto-appending assumes we know the stop was a truncation. We often cannot:
finish_reason is the only authoritative signal and it currently never reaches the tool layer.
Resuming a malformed-JSON call (a model bug, not a cut-off) would append garbage on top of
garbage. Putting the user at the boundary makes the ambiguous case safe — they can see the
partial result and decide.

Flow

truncation detected
   → write partial content (explicitly marked)
   → inject continuation context for the next request
   → surface a dialog to the user
   → user chooses: Continue / Discard / Keep as-is
   → on Continue: re-prompt the agent to append from the boundary

Constraint found: "inject a system message" cannot mean session history

gui/src/redux/util/constructMessages.ts:198-218 assembles the system message per request
from rules (getSystemMessageWithRules). It is not stored in session history — anything
pushed there as a system item is discarded on the next turn.

(This is the same fact that made the system-item half of the #16 isLast bug latent rather
than live: nothing ever puts a system item into history.)

So the continuation context must be carried by one of:

1. The tool result itself — most natural. It already flows back to the model as a tool
   message, needs no new plumbing, and survives the turn boundary.
2. A rule contributed for the next request — fits getSystemMessageWithRules, but is
   global state for what is a one-shot condition.
3. A synthetic user message on resume — explicit and visible in history, but pollutes the
   transcript.

Recommendation: (1), with (3) as the visible trigger when the user clicks Continue. The tool
result carries the machine-readable boundary; the user's click supplies the intent.

Dialog

Infrastructure already exists — setDialogMessage / setShowDialog in
gui/src/redux/slices/uiSlice.ts:64-71, with ConfirmationDialog as precedent. No new
mechanism required.

⚠ Response cut off mid-file

The model ran out of output space while writing
ballistic_calculator.py. 30,311 bytes were written; the file is
incomplete and will not run.

Ends with:   epilog='''
             Examples:
               %(prog)s --velocity

[ Continue writing ]  [ Discard partial file ]  [ Keep as-is ]

Three outcomes, all recoverable:

• Continue — re-prompt to append from the boundary
• Discard — remove the partial file, restore any backup
• Keep as-is — leave it; user will finish manually

Why a dialog rather than silent retry

Auto-continuation can loop: if each attempt exhausts the window, an unattended agent burns
tokens indefinitely on a local model. The user gate bounds this for free. It also makes the
failure visible, which is the property most conspicuously missing today.

Still required from the earlier design

• Layer 1 (Detect) is a hard prerequisite — without finish_reason reaching the tool layer
  and without the parse error surviving safeParseToolCallArgs, none of this can trigger
• Partial writes must never destroy an existing file (backup-then-write, or refuse)
• No fixed byte threshold in tests

Open questions

• Does the dialog block streaming, or appear after the turn settles?
• On Continue, re-prompt automatically or pre-fill the input for the user to send?
• Should the partial file carry a marker so a later session knows it is incomplete?
• Non-file tool calls truncating — same dialog, or a different path?

[ScrewTSW]

Third occurrence — boundary MOVED. Fixed-threshold theory falsified.

The boundary is not constant

Attempt	Parse error column	File written?
1	31,447	yes — 818 lines / 30,311 bytes
2	31,447	(not separately verified)
3	31,395	no — disk unchanged

Attempt 3 truncated 52 bytes earlier. The content also differed: the previously-undefined
g0/M/R were replaced with literal constants
(9.80665 * 0.0289644 / (287.05 * sea_level_temp)), and the epilog was longer. So the model
regenerated rather than replaying a cached response — different output, different length,
boundary shifts to match.

This confirms effective_limit = window − (reasoning + prose) and falsifies any fixed ~31 KB
cap. Any regression test asserting a constant threshold will be flaky. The earlier issue title
claiming "~31KB" was wrong and has been corrected.

Correction: the partial write is NOT consistent

Earlier comments state the write "partially succeeds". Verified across attempts, that is not
reliably true:

$ stat -c '%y %s' ballistic_calculator.py
2026-08-28 13:56:31 30311        <- mtime from attempt 1, unchanged

$ grep -c "g0 \* M / (R \*"  ballistic_calculator.py   # old broken version
2
$ grep -c "9.80665 \* 0.0289644" ballistic_calculator.py  # attempt-3 version
0

Attempt 3 produced different content but the file on disk is byte-identical to attempt 1 —
still the old version, same mtime. Attempt 3 wrote nothing.

So the failure has (at least) two distinct outcomes:

• sometimes a truncated file is written (attempt 1)
• sometimes nothing is written (attempt 3)

Not yet distinguished:

• Different code paths between create-new and overwrite-existing?
• Is something refusing to overwrite an existing file?
• Did attempt 1's file actually come from the write tool, or from a different event?

This matters for the fix. "Make the write atomic" assumed a consistent partial write. If the
overwrite case already refuses, the create case is the one leaking partial content — a narrower
and different fix.

Unchanged conclusions

• Root cause of silent failure stands: parseArgs.ts:17-24 swallows the parse error and returns
  {}, with the diagnostic commented out
• finish_reason still never reaches the tool layer, so truncation cannot be distinguished from
  a malformed-JSON model bug
• The user-gated resume design is unaffected — if anything the inconsistent write outcome makes
  showing the user the actual on-disk state more important, not less

Repro (now reliable)

Prompt for a single file large enough to exhaust the remaining window. Observed 3×. Do not
expect a fixed byte count; expect truncation mid-string at a boundary that varies with how much
the model reasoned first.

[ScrewTSW]

Major revision — this is NOT window exhaustion. Cancellation reproduces it at 879 bytes.

The falsifying observation

User stopped generation mid-command. Same error, same signature:

parse error at line 1, column 879: invalid string: missing closing quote
last read: '"python3 << 'EOF'\nwith open('ballistic_calculator.py', 'r') as f:\n …

Column 879. Not ~31,000. A few hundred bytes — nowhere near any context or output limit.
Nothing was exhausted; the user pressed stop.

What this means

The window boundary was never the cause. It was the most common trigger. The actual defect:

Any interruption of a streaming tool-call argument leaves an unparseable JSON fragment,
which parseArgs.ts silently discards.

Window exhaustion and user cancellation are two paths into the same hole. Previous comments in
this issue framing it as a ~31 KB / context-window problem are too narrow — the
DEFAULT_CONTEXT_LENGTH = 32_768 lead is not the root cause (though the earlier observation that
the boundary moves with reasoning length remains valid for the exhaustion path specifically).

Cancellation is far more frequent than window exhaustion. Stopping a long generation is
routine. This makes the bug considerably higher-impact than filed.

Mechanism

gui/src/redux/slices/sessionSlice.ts:581-584:

abortStream: (state) => {
  state.streamAborter.abort();
  state.streamAborter = new AbortController();
},

It aborts the controller and replaces it. It does not discard or finalise a tool call that
was mid-accumulation. The partial argument survives in state and flows to
parseArgs.ts:17-24, which catches the parse error and returns {} — with the diagnostic
console.error commented out.

Two independent defects compounding:

1. Cancellation does not invalidate in-flight tool calls (abortStream)
2. Invalid arguments are silently coerced to {} (safeParseToolCallArgs)

Either alone would be survivable. Together they turn "user pressed stop" into "tool executes with
empty/garbage arguments, silently".

Consequences beyond file writes

If a partially-parsed tool call can still execute, cancellation is not a safe operation for
any tool — not just write. A cancelled run_terminal_command accumulating
python3 << 'EOF' … is precisely the payload above. Worth verifying urgently whether a
cancelled command can reach execution with truncated arguments.

• Priority: can a cancelled tool call execute at all? If yes, that is the headline bug
• Does abortStream need to mark in-flight tool calls as cancelled/invalid?
• Are there other paths that abandon a stream without finalising tool calls?

Revised fix priority

1. Cancellation must invalidate in-flight tool calls — highest value, addresses the common
   path, and is where a cancelled shell command could otherwise run
2. Stop silently returning {} for unparseable arguments (parseArgs.ts)
3. Atomic/guarded writes so no partial content reaches disk
4. finish_reason plumbing — still needed to distinguish exhaustion from cancellation from a
   genuine model bug, all three of which currently look identical
5. User-gated resume dialog — now also the natural place to report "cancelled mid-write"

Note on the earlier inconsistency

This may also explain why attempt 1 wrote a file and attempt 3 did not: different interruption
paths (exhaustion vs. cancellation vs. completion) plausibly leave state in different places.
Still to be confirmed.

[ScrewTSW]

Design: separate cancellation from exhaustion

The two failures share a symptom (truncated JSON → {}) but must be handled oppositely:

	Cancellation	Context exhaustion
Intent	Deliberate — user wants it stopped	Accidental — user wanted the result
Partial args	Discard	Salvage
Side effects	None. Nothing may execute	Write partial + offer resume
User surface	Quiet — they know, they did it	Dialog with Continue / Discard / Keep
Correct outcome	Clean stop, marked cancelled	Recoverable stop, resumable

Executing anything after a cancel is a correctness bug. Discarding salvageable work after
exhaustion is a usability bug. Same symptom today, opposite fixes.

---

Good news: the vocabulary already exists

core/index.d.ts:534-540:

export type ToolStatus =
  | "generating"  // arguments still streaming
  | "generated"   // complete, ready to execute
  …
  | "canceled";   // canceled by user or system

"generating" vs "generated" is exactly the distinction needed: a tool call still in
generating when the stream ends never received complete arguments. No new state required.

The gap

"canceled" is set in only two places in sessionSlice.ts (lines 362, 1030) — and
abortStream (581-584) is not one of them:

abortStream: (state) => {
  state.streamAborter.abort();
  state.streamAborter = new AbortController();
},

It tears down the controller without touching in-flight tool calls. A call left in generating
keeps that status forever, and its truncated arguments remain live for parseArgs to coerce
into {}.

streamNormalInput.ts:300-326 already checks signal.aborted at three points, so the signal is
available where it is needed.

---

Cancellation path — format, never execute

1. abortStream marks every tool call still in generating as canceled (mirrors the existing
   closeOpenReasoning pattern added in fix(gui): render thinking blocks from structured reasoning_content #16 — same class of bug: an in-flight state never closed
   on the cancellation path)
2. canceled calls are never executed and never parsed for arguments
3. Render them as visibly interrupted, not failed — no error styling for a deliberate act
4. The conversation records a cancelled call, so the model is not misled into thinking it ran

Verify first: can a generating tool call currently reach execution after abort? If yes,
that is a correctness bug outranking everything else here — the observed cancelled payload was
python3 << 'EOF' …, i.e. a shell command.

Exhaustion path — chunked recovery

Requires finish_reason === "length", which today never reaches the tool layer (absent from
core/index.d.ts entirely). This is the blocking prerequisite — without it, exhaustion is
indistinguishable from cancellation and neither path can be chosen correctly.

Then:

1. Salvage completed keys + the partial trailing string value
2. Require a fully-parsed destination path — never guess
3. Write partial content, explicitly marked
4. Return the tail of what was written so the next turn appends at the right boundary
5. Dialog: Continue / Discard / Keep as-is
6. Cap resume attempts — if each retry re-exhausts the window, an unattended agent loops

Order of work

1. Verify cancelled calls cannot execute (safety — do this first)
2. abortStream marks generating → canceled
3. parseArgs stops returning {} for unparseable input; surface a typed failure
4. Plumb finish_reason to the tool layer
5. Salvage + partial write, guarded so an existing file is never destroyed
6. Resume dialog

Steps 1–3 are self-contained and fix the dangerous half. 4–6 build the recovery half on top.

Tests

• Cancel mid-argument → status canceled, zero side effects, nothing executes
• Cancel mid-argument on a terminal command → command must not run
• Exhaustion + valid path → partial write + resume instruction containing the tail
• Malformed JSON with finish_reason: stop → no write, clear error (a model bug, not resumable)
• Resume appends without duplicating the boundary
• Existing file is never destroyed by a partial write
• No fixed byte threshold anywhere — the boundary moves with reasoning length (observed
  31,447 → 31,395 → 879)

[ScrewTSW]

Safety check result: cancelled calls CANNOT execute — but the protection is a race, not an invariant

Verified: no arbitrary execution

Two independent barriers stop a cancelled tool call:

1. streamNormalInput.ts:300-302 — returns before setToolGenerated if signal.aborted
2. callToolById.ts:33-34 — hard return unless status === "generated"

if (toolCallState.status !== "generated") {
  return;
}

A call left in generating (what a cancelled, truncated call is) never reaches execution.
The user's interrupted python3 << 'EOF' … could not have run.

Severity accordingly downgraded: this is data-loss / silent-corruption, not arbitrary
execution.

But: setToolGenerated validates nothing

sessionSlice.ts:951-973:

if (toolCallState) {
  toolCallState.status = "generated";   // unconditional
  …
}

No parse check, no argument validation. Promotion to generated is unconditional, so the only
thing separating truncated arguments from execution is the abort check at line 300 firing first.

That is a race, not an invariant. It holds for cancellation (where signal.aborted is true)
and fails for exhaustion (where it is false):

Path	signal.aborted	Guard fires?	Outcome
User cancels	true	yes → early return	call stays generating, never executes ✅
Window exhausted	false	no	promoted to generated with truncated args → executes ⚠️

On the exhaustion path the call is promoted, callToolById admits it, parseArgs coerces the
unparseable arguments to {}, and the tool runs.

This explains the inconsistent writes

Previously unexplained: attempt 1 wrote a truncated file, attempt 3 wrote nothing.

• Attempt 1 / 2 — exhaustion. No abort, call promoted, tool executed with salvaged-or-empty
  args → file written.
• Attempt 3 — cancellation (user pressed stop). Abort check fired, call stayed generating
  → nothing written.

Same symptom, opposite mechanisms — exactly the split this issue now tracks.

Consequence for the fix

setToolGenerated is the right enforcement point. Promotion to generated should require that
the arguments parse; a tool call whose arguments never completed is by definition not
"generated".

That converts the current race into a real invariant:

A tool call may only execute if its arguments parsed completely.

Which holds regardless of why the stream ended — cancellation, exhaustion, network drop, or a
path nobody has hit yet.

Revised order

1. Verify cancelled calls cannot execute — done, they cannot
2. setToolGenerated must refuse to promote unparseable arguments ← now the top fix; closes
   the exhaustion hole and makes the guarantee path-independent
3. abortStream marks generating → canceled (correct status/UI; safety already holds)
4. parseArgs stops silently returning {}
5. Plumb finish_reason for the cancellation-vs-exhaustion distinction
6. Salvage + partial write + resume dialog

Test

• Exhaustion with truncated args → tool must not execute (currently it does — this is the bug)
• Cancellation → stays generating/canceled, no execution (currently passes — lock it in)
• Well-formed args → promotes and executes normally (no regression)