Read tool PDF support broken on Windows — sandbox rejects pdftoppm from all locations
Description
The Read tool's built-in PDF support does not work on Windows. The tool requires pdftoppm (from Poppler) to render PDF pages as images, but the sandbox rejects the binary regardless of installation location.
Environment
- OS: Windows 11 Pro 10.0.26200
- Claude Code version: Latest (as of 2026-06-03)
- Poppler version: 24.08.0
- Shell: PowerShell 7+
Steps to Reproduce
- Install Poppler for Windows (e.g., via
poppler-24.08.0) - Place
pdftoppm.exeinC:\Program Files\poppler\(standard Program Files location) - Add to system PATH and confirm
pdftoppm -vworks from both PowerShell and Bash - Attempt to read a PDF with the Read tool:
````
Read({ file_path: "C:\path\to\file.pdf", pages: "1" })
Expected Behavior
The Read tool renders the PDF page(s) as images and returns them, as documented: "This tool can read PDF files (.pdf)."
Actual Behavior
pdftoppm failed: Command 'pdftoppm' not found or is in an unsafe location (current directory)
This error persists regardless of where pdftoppm.exe is installed:
C:\Program Files\poppler\— rejectedC:\tools\poppler\poppler-24.08.0\Library\bin\— rejected- On system PATH, user PATH, or both — rejected
Proof the Binary Works
Running pdftoppm directly from Bash or PowerShell within the same Claude Code session works perfectly:
pdftoppm -png -r 200 -f 1 -l 2 "input.pdf" "output-prefix"
# Produces PNG files successfully
# Read tool can then read the resulting PNG images without issue
Workaround
Two-step process via Bash:
- Convert PDF to PNG:
pdftoppm -png -r 200 "file.pdf" "output" - Read the PNG with the Read tool
This works reliably but requires extra Bash permission prompts and is not discoverable.
Root Cause (Suspected)
The Read tool's sandbox appears to have a hardcoded allowlist of trusted directories for external executables. On Linux/macOS, pdftoppm is typically at /usr/bin/pdftoppm which is likely on the allowlist. On Windows, there is no standard location that the sandbox recognizes, so it always rejects the binary — even from C:\Program Files\.
Suggestion
Either:
- Add
C:\Program Files\to the sandbox's trusted directory list for Windows - Allow a configuration option for trusted binary paths
- Use a built-in PDF rendering approach that doesn't depend on an external binary
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗