[BUG] Read tool falsely reports unencrypted pandoc/LaTeX PDFs as 'password-protected'

Status Open

Maintainer reply None cached

Activity 6 comments · opened Jun 9, 2026

What happened

The built-in Read tool's PDF path returns:

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

…for PDFs that are not encrypted at all (no /Encrypt dictionary, no user/owner password). This forces the user to "provide an unprotected version" that already exists, or abandon the read — wasting tokens and time on a false premise.

Repro

Export a PDF via pandoc or pdflatex/LaTeX (these commonly produce PDFs with compressed object streams + cross-reference streams rather than a classic xref table).
Read the .pdf.
Observe the false password-protected error.

Evidence it is NOT encrypted

Raw byte scan for /Encrypt across the affected files returns nothing (no encrypt dictionary present):

data = open(p, "rb").read()
print("/Encrypt" in data.decode("latin1"))   # -> False for every file

And pdftotext -layout file.pdf out.txt (poppler) extracts the full text cleanly with no password. So the documents are plain, unencrypted PDFs.

Expected

The Read PDF parser should not report password-protected unless an /Encrypt dictionary actually requires a password.
For PDFs it cannot parse (object streams / xref streams), it should emit an accurate error (e.g. "could not parse PDF structure") and/or fall back to pdftotext/poppler — not blame encryption.

Impact

This is not a one-off. Every pandoc/LaTeX-exported PDF the user reads hits this. The misleading error sends both the user and the agent down a dead-end ("set a password? remove a password that was never set?"). Misdiagnosis = repeated wasted turns.

Workaround (works reliably)

pdftotext -layout "<input.pdf>" out.txt

then read out.txt. Poppler handles these PDFs fine, confirming the files are valid and unencrypted.

Environment

Claude Code on Windows
PDFs produced by pandoc / pdflatex (TeX Live 2024)
poppler pdftotext available and succeeds on the same files

View original on GitHub ↗

5 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

IxI-Enki · 2 months ago

looks like a feature if still not closed. Keep duplicate - force resolving.

zyanp · 2 months ago

Also reproduces with Edge/Chromium --print-to-pdf output (PDF 1.4) on Windows — not specific to pandoc/LaTeX.

Minimal repro (any Windows 11 box, no TeX needed):

& "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --headless --print-to-pdf=out.pdf some.html

Read on out.pdf -> PDF is password-protected. Please provide an unprotected version.

Verified unencrypted: a raw byte scan finds no /Encrypt dictionary. PyMuPDF opens it without any password and extracts the full text:

import fitz
doc = fitz.open("out.pdf")
print(doc.page_count, doc[0].get_text()[:100])

So in addition to poppler, PyMuPDF works as a fallback — supporting the diagnosis that the Read tool's parser is misclassifying valid unencrypted PDFs (likely the xref/object-stream variants Chromium also emits) as encrypted. I'm hitting this across multiple sessions and unrelated PDFs.

CrossStar · 2 months ago

Based on my investigation, this issue can be resolved by downloading the latest release of poppler-windows and adding the Library\bin folder to PATH.

The detailed reason is as follows:

When Claude’s Read tool reads a PDF, it calls the pdftoppm command to convert the PDF into JPEG images.
After we configure LaTeX, the downloaded TeX Live distribution already includes the pdftoppm command.
However, for some reason, the bundled command was not built with the ENABLE_LIBJPEG compile option enabled. As a result, the bundled pdftoppm command does not support the -jpeg parameter.
Therefore, when Claude Code invokes the Read tool, the error output dumps all relevant parameters and their corresponding descriptions at once. Among them, the descriptions of -opw and -upw contain the word password.
Claude Code’s error-handling logic appears to trigger the password-protected error as long as stderr contains the word password.

zyanp · 1 month ago

Thanks @CrossStar — your analysis was spot on and pointed me in the right direction.

One caveat for others trying this: installing poppler via winget (oschwartz10612.Poppler) does not work if you launch Claude Code from your home directory. Claude Code's internal command resolution rejects any executable located under the current working directory as unsafe, and when cwd is C:\Users\<you>, that includes the winget install location under AppData\Local\Microsoft\WinGet\Packages\.... The TeX Live pdftoppm then gets picked up instead (or resolution fails entirely), and the bug persists.

What worked for me: copy the poppler release to a directory outside your user profile (e.g. C:\poppler) and put C:\poppler\Library\bin on PATH ahead of the TeX Live entries. A symlink/junction into AppData does not work — the safety check resolves links — it has to be a real copy.

Showing cached comments. Read the full discussion on GitHub ↗