[BUG] Cowork: large tool results spill to a file with a preview that truncates load-bearing fields (e.g. record IDs), encouraging fabrication

Resolved 💬 2 comments Opened May 31, 2026 by clifguy Closed Jun 1, 2026

What's wrong

When a tool call returns a large result, Cowork persists the full result to a spill file and shows the model a small inline preview. The preview is a head-truncation of the serialized result, so it can cut off exactly the fields the next step depends on — e.g. the record IDs in a search result needed for the follow-up get/read call.

Because the truncation isn't always obvious (the preview looks like a complete-enough JSON object), the model can proceed on the visible prefix and fabricate the IDs it can't see rather than reading the spill file. That's a correctness hazard, not just friction.

What should happen

One or more of:

  • Make truncation explicit and unmissable, with a clear instruction to read the spill file.
  • Prioritize structured/load-bearing fields in the preview (surface the IDs even while truncating bulky prose fields) rather than a blind head-cut.
  • Provide an easy way to page/query the full spilled result.

Environment

  • Surface: Claude for Desktop (Cowork tab), Claude Code 2.1.156 (Agent SDK 0.3.156), model Opus 4.8, macOS (Darwin 25.5.0), Apple Silicon.

Steps to reproduce

  1. Call a tool returning 30+ records, each with an id plus a large text field, exceeding the inline preview budget.
  2. Result spills to a file; inline preview is head-truncated.
  3. The IDs needed for the next call fall past the truncation point — the preview is plausible but incomplete.

Impact

High — silent loss of the precise tokens a multi-step tool workflow depends on, structured in a way that invites fabrication over a re-read.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗