[BUG] bug in Claude Code's PDF parser

The "workarounds" don't work either -- the file has a lot of equations, figures and tables so converting to text doesn't help.

Bro, have you deal with it?
I also meet this problem

I don't have a solution yet. It might be a problem with Visual Studio or perhaps the interface between Visual Studio and Claude?

Thanks, I used claude code in cmd rather than Visual Studio, maybe its the problem of Claude.....
I tried to use python to make my pdf to png which is feasible.

Reproduction file:

acme-manual.pdf

Reproduction prompt:

can you read and summarize acme-manual.pdf

PDF metadata (from pdfinfo):

Title: ACME User Manual
Author: ACME, Inc.
Creator: LaTeX with hyperref
Producer: LuaTeX-1.17.0
Pages: 14
Encrypted: no
File size: 72738 bytes
PDF version: 1.5

Claude Version:

VSCode extension anthropic.claude-code-2.1.71-win32-x64

Observed behavior:

Claude Code's Read tool returns the following error when attempting to read this PDF:

PDF is password-protected. Please provide an unprotected version.

More details:
Call Read with pages: "1-5" → error: "PDF is password-protected"
Call Read without pages parameter → correctly returns metadata including page count
Key observations:

Omitting pages works (partially — returns metadata, reports correct page count of 14)
Adding any pages range triggers the false encryption error
PDF was also tested as: qpdf --decrypt rewrite, linearized, and downgraded to PDF 1.4 — all fail identically
pdfinfo confirms: Encrypted: no, Producer: LuaTeX-1.17.0, PDF version 1.5
The error message is misleading — the actual issue appears to be in the page range extraction/splitting code path, not encryption detection

Expected behavior:

The PDF should be read normally — pdfinfo confirms Encrypted: no. The file is not password-protected.

The bug is simpler and worse than the GitHub issues describe. The issue reports blame PDF permission flags (/Encrypt
dictionary, "do not print" restrictions). Our testing proved that's wrong — the pages parameter fails on every PDF on
Windows, including clean arXiv papers with zero encryption. The error message "password-protected" is a red herring
from a completely broken page-splitting code path.

The fix is a page extractor, not a permission stripper. pdf-extract-pages.py creates a new small PDF with just the
pages you need. The Read tool happily reads small PDFs without the pages parameter. The workflow becomes:

1. python pdf-extract-pages.py paper.pdf "1-5" → produces paper_p1-5.pdf
2. Read(file_path="paper_p1-5.pdf") → works perfectly

Why the GitHub reporters got confused: Some PDFs with permission flags fail even without pages (the Read tool checks
encryption before page splitting). But the pages code path has its own independent bug that kills ALL PDFs. Two
separate bugs, same misleading error message.

Workaround: PreToolUse hook + page extraction script (Windows)

We built a three-piece workaround for this bug on Windows 11:

1. Python page extractor (pdf-extract-pages.py) — Uses PyMuPDF to create a fresh PDF with only the requested pages via

insert_pdf() into a new empty document. Supports single ranges ("15-25") and batch mode (--batch) which splits the
entire PDF into 10-page chunks. The new PDFs have no /Encrypt dictionary and read fine without the pages parameter.

1. PreToolUse hook on the Read tool — A bash script that intercepts every Read call targeting a .pdf file. If the

pages parameter is present, it blocks with exit code 2 (the code path is broken regardless of file). If pages is
absent but the PDF has >10 pages, it also blocks (Read silently rejects PDFs with 11+ pages even without pages). Small
PDFs pass through.

1. /pdf skill — A slash command that automates the split-read-synthesize workflow: runs the extractor in batch mode,

reads each chunk sequentially without pages, synthesizes against the user's prompt, then cleans up.

Key finding from testing: The bug is NOT about PDF permissions or /Encrypt dictionaries. We created a completely clean
PDF (no encryption, permissions=-4, verified via PyMuPDF) and it still fails when pages is specified. We also
confirmed that the same arXiv PDF that fails with pages="1-5" reads perfectly without the pages parameter. The pages
code path is independently broken on Windows — the "password-protected" error message is misleading.

Additional finding: The Read tool's actual page limit without pages is 10, not 20 as stated in the error message. PDFs
with 11+ pages are rejected as "too many to read at once."

this is not stale, my simple reproduction case still gives the same "password-protected" error on version anthropic.claude-code-2.1.111-win32-x64

i have exactly the same error on w11 2.1.109 (supposedly "stable"). i have to use codex for reading now since there isnt a fast viable workaround :/

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Downloading the latest release of poppler-windows and adding the Library\bin folder to PATH should solve the issue. See: https://github.com/anthropics/claude-code/issues/66563#issuecomment-4699807250