Read tool returns false-success tool_result for truncated PDFs (no is_error: true on structurally-invalid input)
Summary
The Read tool, when invoked on a PDF file that is structurally invalid (missing %%EOF, missing startxref, fails mutool info), returns a success-shaped tool_result of the form "PDF file read: <path> (XX.X KB)" with no is_error: true flag. The tool validates file size (the path resolves and the file is non-empty) but does not validate PDF structure.
Reproduction
- Truncate a PDF file at a byte offset before its
%%EOFmarker (e.g.,head -c 134958 valid.pdf > truncated.pdfwhere the original was 328338 bytes). - Invoke the Read tool on the truncated file.
- Observe: tool_result returns
"PDF file read: <path> (131.8KB)"with no error indication.
Expected
tool_result should return is_error: true with an error message indicating the PDF could not be parsed.
Why it matters
This false-success contributed to a downstream stuck-loop in claude-cli (see companion issue on the synthetic short-circuit). The model never saw a tool error and the cli's PDF-to-document handler choked on the invalid file silently. Full incident: 11-turn stuck-loop, 12 minutes of unusable session, required full session reset.
Suggested fix
After file-size validation, attempt minimal PDF structure validation: %%EOF marker presence, startxref presence. On failure, return tool_result with is_error: true and a message like "PDF file is structurally invalid (no %%EOF / startxref). Cannot be parsed."
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗