claude-code - 💡(How to fix) Fix Read tool returns false-success tool_result for truncated PDFs (no is_error: true on structurally-invalid input)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

  1. Observe: tool_result returns "PDF file read: <path> (131.8KB)" with no error indication. tool_result should return is_error: true with an error message indicating the PDF could not be parsed. 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.

Root Cause

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.

RAW_BUFFERClick to expand / collapse

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."

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Read tool returns false-success tool_result for truncated PDFs (no is_error: true on structurally-invalid input)