[BUG] Cowork: large tool results spill to a file with a preview that truncates load-bearing fields (e.g. record IDs), encouraging fabrication
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
- Call a tool returning 30+ records, each with an
idplus a large text field, exceeding the inline preview budget. - Result spills to a file; inline preview is head-truncated.
- 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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗