Skip to content

Desktop app (macOS) ignores PATH from all sources — Read tool cannot find poppler/pdftoppm #42248

@thatChadM

Description

@thatChadM

Environment

  • Claude Desktop app version: 1.2.234
  • OS: macOS 15.7.2 (Sequoia), Apple Silicon (arm64)
  • Shell: bash
  • Homebrew prefix: /opt/homebrew
  • poppler version: 26.03.0 (installed via brew install poppler)

Description

The Claude Code Desktop app's Read tool cannot find pdftoppm (poppler) for PDF rendering. The Bash tool also operates with a minimal 4-entry PATH (/usr/bin:/bin:/usr/sbin:/sbin) that excludes Homebrew, MacPorts, and /usr/local/bin paths.

The VS Code Claude Code extension does pick up the correct PATH from settings.json env. This is a Desktop-app-specific issue.

Steps to Reproduce

  1. Install poppler: brew install poppler
  2. Verify it works: /opt/homebrew/bin/pdftoppm -v returns pdftoppm version 26.03.0
  3. Open Claude Desktop app
  4. Ask Claude to read any PDF file using the Read tool
  5. Result: pdftoppm is not installed. Install poppler-utils...
  6. Ask Claude to run echo "$PATH" | tr ':' '\n' via Bash tool
  7. Result: Only /usr/bin, /bin, /usr/sbin, /sbin — no Homebrew, no MacPorts, no /usr/local/bin

Expected Behavior

The Read tool should find pdftoppm when it is installed and available via standard PATH locations (/opt/homebrew/bin, /usr/local/bin), or when PATH is configured via settings.json env, or when PATH is set via launchctl setenv.

Workarounds Attempted — ALL FAILED for Desktop App

1. Homebrew install (default location)

  • brew install poppler installs to /opt/homebrew/bin/pdftoppm
  • Desktop app PATH does not include /opt/homebrew/bin
  • Result: Not found

2. Symlink to /usr/local/bin

sudo ln -s /opt/homebrew/bin/pdftoppm /usr/local/bin/pdftoppm
sudo ln -s /opt/homebrew/bin/pdftotext /usr/local/bin/pdftotext
sudo ln -s /opt/homebrew/bin/pdfinfo /usr/local/bin/pdfinfo
  • Symlinks confirmed working via full path
  • Desktop app PATH does not include /usr/local/bin
  • Result: Not found

3. settings.json env PATH

{
  "env": {
    "PATH": "/opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
  }
}
  • Full quit and restart of Desktop app after edit
  • Bash tool still shows minimal 4-entry PATH
  • Note: This same setting DOES work for the VS Code extension — VS Code Claude Code sees the full configured PATH
  • Result: Not found (Desktop), Works (VS Code)

4. launchctl setenv PATH

launchctl setenv PATH /usr/local/bin:/usr/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/homebrew/bin:/opt/homebrew/sbin:/bin:/usr/bin:/usr/sbin
  • Confirmed via launchctl getenv PATH — value is set correctly
  • Full quit and restart of Desktop app after setting
  • Interesting: OTHER environment variables set via launchctl setenv ARE visible to the Desktop app (confirmed by checking custom env vars via Bash set command). Only PATH appears to be overridden.
  • Result: Not found — PATH specifically is being overridden by the Desktop app

5. Shell snapshots

  • ~/.claude/shell-snapshots/*.sh contains the full PATH with /opt/homebrew/bin and /usr/local/bin
  • Desktop app does not apply this PATH to the tool environment
  • Result: Not found

6. Session restarts

  • Multiple full quit-and-restart cycles after each workaround
  • Ensured no lingering Claude or Chrome hook processes
  • Result: Not found after any restart

Key Finding

The Desktop app picks up other environment variables from launchctl setenv (confirmed by checking non-PATH env vars), but PATH specifically is being overridden with a hardcoded minimal value. This suggests the Electron app or its utility process is explicitly constructing/replacing PATH rather than inheriting it from the session environment.

Per issue #22559, the Desktop app extracts PATH via a "utility process" — this process appears to be producing a minimal system PATH and discarding any user-configured PATH values from all sources (launchctl, settings.json, shell profiles, shell snapshots).

Workaround That Does Work

Calling pdftoppm via the Bash tool using the full absolute path (/opt/homebrew/bin/pdftoppm) works. The binary exists and functions correctly — it is only the PATH-based discovery that fails.

Related Issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:desktopbugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions