Read tool PDF support broken on Windows — sandbox rejects pdftoppm from all locations

Open 💬 3 comments Opened Jun 3, 2026 by KevinM1968

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

  1. Install Poppler for Windows (e.g., via poppler-24.08.0)
  2. Place pdftoppm.exe in C:\Program Files\poppler\ (standard Program Files location)
  3. Add to system PATH and confirm pdftoppm -v works from both PowerShell and Bash
  4. 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\ — rejected
  • C:\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:

  1. Convert PDF to PNG: pdftoppm -png -r 200 "file.pdf" "output"
  2. 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:

  1. Add C:\Program Files\ to the sandbox's trusted directory list for Windows
  2. Allow a configuration option for trusted binary paths
  3. Use a built-in PDF rendering approach that doesn't depend on an external binary

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗