[BUG] Windows Desktop app: Read tool PDF fails with 'pdftoppm is not installed' while poppler is installed, on PATH, and resolvable by the same session's shells

Summary

On Windows, the built-in Read tool fails to render PDFs in Desktop app sessions with:

pdftoppm is not installed. Install poppler-utils (e.g. `brew install poppler` or `apt-get install poppler-utils`) to enable PDF page rendering.

Poppler is installed (11 days prior, via winget), registered on the HKCU user PATH, and the same session's own PowerShell/Bash tools resolve and run pdftoppm instantly — only the Read tool's internal resolver fails to find it. Reinstalling poppler does not change the Read tool's behavior.

This closely matches #73696 (identical error string), which is currently scoped to VS Code extension sessions only — this report shows the same failure in Desktop app sessions, so the bug does not appear to be IDE-specific. Also related: #65089 (sandbox rejects pdftoppm, different error string) and #23704 (not detected after install, Linux container).

Environment

• Windows 11 Pro 10.0.26200
• Claude Code 2.1.181 (Desktop app session)
• Poppler 25.07.0 via winget (oschwartz10612.Poppler), at %LOCALAPPDATA%\Microsoft\WinGet\Packages\oschwartz10612.Poppler_Microsoft.Winget.Source_8wekyb3d8bbwe\poppler-25.07.0\Library\bin, registered on the HKCU user PATH by winget at install time (2026-06-21, 11 days before repro)

Steps to reproduce

1. Install poppler: winget install --id oschwartz10612.Poppler -e (adds its Library\bin to the user PATH)
2. Reboot (to rule out stale process environments entirely)
3. In a Desktop app session, confirm the shell sees it: Get-Command pdftoppm → resolves to the winget path
4. In the same session: Read({ file_path: "<any>.pdf", pages: "1" })

Expected

PDF pages render, per the Read tool's documented PDF support.

Actual

pdftoppm is not installed. Install poppler-utils (e.g. `brew install poppler` or `apt-get install poppler-utils`) to enable PDF page rendering.

Evidence the binary is fine (same session, minutes apart)

• Get-Command pdftoppm in the session's PowerShell tool → resolves instantly to the winget location, no PATH refresh needed (machine had rebooted earlier the same evening, so every process env contained the poppler dir — stale-environment inheritance is ruled out)
• pdftoppm -png -r 150 <file>.pdf <prefix> via the session's shell tool → works, produces PNGs
• winget list → Poppler oschwartz10612.Poppler 25.07.0-0

Impact

Transcript history on this machine shows 28 sessions mentioning poppler. The recurring loop: a session tries to Read a PDF, gets this error, tells the user poppler "isn't installed" (it is), reinstalls it (a no-op), then works around it by shelling out to pdftoppm manually. Because the reinstall never fixes the Read tool, every future session repeats the loop — and the model confidently reports a false fact about the user's machine each time.

Can provide more Desktop-app-side diagnostics if useful.