[Bug] pdf-viewer plugin: local PDFs always rejected — MCP roots never populated + Windows file:// path mangling (C:\C:\...)

[Bug] pdf-viewer plugin: local PDFs always rejected — MCP roots never populated + Windows file:// path mangling (C:\C:\...)

Preflight

• Reproduces in both Claude Code (desktop app, Code mode) and Claude Desktop chat (Cowork mode) on Windows.
• Related to (closed, unresolved) #66250 — this report adds new evidence: a second, independent server-side bug (Windows path mangling) and confirmation that Cowork folder grants do not propagate.

Environment

• OS: Windows 11 Pro 10.0.26200
• Claude Desktop (unified app with Chat / Cowork / Code modes), plugin PDF Viewer 0.2.0 from Marketplace (Anthropic), shown enabled in Settings → Plugins
• Plugin is the bundled pdf-viewer-inline variant (~/.claude/plugins/data/pdf-viewer-inline exists but is empty — no user-editable manifest)
• Underlying server: @modelcontextprotocol/server-pdf (latest on npm: 1.7.4; runs fine standalone via npx)
• Node.js v24.16.0, npx 11.11.0

Summary

The pdf-viewer plugin's MCP tools connect and work for HTTPS URLs, but every local file is rejected with:

Local file not in allowed list: C:\C:\Users\jalgaba\repos\pdf-test\investigacion_1186.pdf
Allowed directories:

Two distinct defects are visible in that single error line:

Bug 1 — allowedDirectories is always empty (client side)

list_pdfs returns {"localFiles":[],"allowedDirectories":[],"truncated":false} in every surface tested. Per #66250, the server populates allowedLocalDirs only from CLI path args or MCP client roots (gated on clientCapabilities.roots), and the client initializes with capabilities: {} — so the list stays empty forever.

New evidence: granting folder access through Cowork does not fix it. In Cowork mode, Claude prompted "Claude desea hacer Cowork en: C:/Users/jalgaba/repos/pdf-test", the user accepted, the folder appears as the working folder, and the user also added C:\Users\jalgaba\repos to Cowork's trusted folders — yet the immediately following display_pdf call still failed with an empty allowed list. Cowork's folder-permission system and the pdf-server's roots are not wired together.

Bug 2 — Windows drive letter duplicated: C:\C:\... (server side)

The rejected path in the error is mangled: input C:\Users\jalgaba\repos\pdf-test\investigacion_1186.pdf (or file:///C:/Users/...) becomes C:\C:\Users\.... Reproduced from two independent clients:

• Claude Code session, calling display_pdf with file:///C:/Users/jalgaba/repos/pdf-test/comprar_antigravity.pdf → error shows C:\C:\Users\...
• Claude Desktop (Cowork mode), plain Windows path → error shows C:\C:\Users\...

This looks like file:// → native-path conversion prepending the drive again (classic url.pathname = /C:/... joined onto C:\). Even if Bug 1 is fixed, local files on Windows may still fail to match any allowed root because the compared path is malformed. This likely belongs to @modelcontextprotocol/server-pdf (modelcontextprotocol/ext-apps) — happy to cross-file there if preferred.

What works vs. what doesn't (tested matrix)

| Surface | MCP tools available | display_pdf HTTPS URL | display_pdf local file | Interactive viewer UI renders |
|---|---|---|---|---|
| Claude Code (desktop, Code mode) | ✅ (after slow initial connect) | ✅ returns viewUUID | ❌ empty allowed list + C:\C:\ | — |
| Claude Desktop, Chat mode | ❌ tool search doesn't surface display_pdf ("search only surfaces Gmail and Chrome tools") | — | — | — |
| Claude Desktop, Cowork mode | ✅ | ✅ returns viewUUID | ❌ empty allowed list + C:\C:\, even after granting the folder | ❌ only the JSON tool-result card is shown; no inline viewer iframe appears |
| claude.ai web / mobile | N/A (local MCP unsupported by design) | | | |

Steps to reproduce

1. Windows, Claude Desktop with PDF Viewer plugin 0.2.0 enabled.
2. In Cowork mode: /view-pdf C:\Users\<user>\...\some.pdf
3. Accept the Cowork folder-access prompt when offered.
4. display_pdf fails: Local file not in allowed list: C:\C:\Users\... / Allowed directories: (empty).
5. list_pdfs at any point → {"localFiles":[],"allowedDirectories":[],"truncated":false}.

Expected

• The workspace/Cowork-granted folder is exposed to the pdf-server (as MCP roots or a launch arg), so local PDFs open.
• Windows paths/file:// URLs are normalized correctly (no drive-letter duplication).

Additional observations

• No [pdf-viewer] or UtilityProcess spawn timeout entries in any %APPDATA%\Claude\logs\main*.log — this is not #62617; the server connects and answers.
• With an HTTPS URL in Cowork mode, display_pdf succeeds (valid viewUUID) but no interactive viewer (MCP Apps iframe) renders inline — only the collapsed tool-call card with raw JSON. Unclear whether Cowork mode supports MCP Apps rendering; if it doesn't, a graceful message would help. ("Artefactos impulsados por IA" toggle made no difference.)
• Screenshots attached: Cowork permission prompt + subsequent failure; Allowed directories: empty; C:\C:\ mangled path; Settings → Plugins showing the plugin enabled.