Read tool returns false-success tool_result for truncated PDFs (no is_error: true on structurally-invalid input)

Resolved 💬 1 comment Opened May 12, 2026 by swildcat10 Closed Jun 11, 2026

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

  1. Truncate a PDF file at a byte offset before its %%EOF marker (e.g., head -c 134958 valid.pdf > truncated.pdf where the original was 328338 bytes).
  2. Invoke the Read tool on the truncated file.
  3. 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."

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗