[Windows] Bundled Poppler .cmd wrappers resolve pdfinfo/pdftoppm to a nonexistent path

Summary

On Windows, the Documents plugin can still fail at the PDF-to-PNG stage even after DOCX-to-PDF conversion succeeds. The bundled Poppler command wrappers pdfinfo.cmd and pdftoppm.cmd resolve their executables through a relative path that does not exist in the current runtime layout.

This is independent of the already-reported LibreOffice UserInstallation URI problem (#30649, #27957, #24210).

Environment

• Codex desktop app on Windows
• Documents plugin: openai-primary-runtime/documents/26.715.12143
• Bundled Poppler: 26.05.0
• LibreOffice: 26.2.2.2
• Microsoft Word: 16.0 / Office 2021

All paths below are sanitized.

Reproduction

1. Produce a valid PDF from a DOCX (either with LibreOffice using a valid file:///C:/... profile URI, or with Word COM).
2. Run the bundled wrappers used by the Documents rendering path:

& "<codex-runtime>\bin\pdfinfo.cmd" "<workdir>\sample.pdf"
& "<codex-runtime>\bin\pdftoppm.cmd" -png "<workdir>\sample.pdf" "<workdir>\page"

1. Both wrappers fail with exit code 3 and:

The system cannot find the path specified.

A representative wrapper line is:

"%~dp0..\Library\bin\pdftoppm.exe" %CODEX_ARGS%

In the installed runtime layout, that relative target is not the location of the bundled executable.

Control experiment

Invoking the bundled executables directly succeeds against the same PDF:

& "<actual-poppler-bin>\pdfinfo.exe" "<workdir>\sample.pdf"
& "<actual-poppler-bin>\pdftoppm.exe" -png "<workdir>\sample.pdf" "<workdir>\page"

Observed results:

• pdfinfo.exe returns valid page metadata.
• pdftoppm.exe produces the expected PNG pages.
• A two-page DOCX with Chinese text and spaces in its path completes successfully when the direct executables are used.
• The failure is therefore in wrapper path resolution, not in the input PDF or Poppler itself.

Expected behavior

The bundled pdfinfo.cmd and pdftoppm.cmd wrappers should locate their bundled executables regardless of the Codex installation/cache root, so the Documents plugin can complete PDF rasterization on Windows.

Suggested fixes

1. Generate the wrappers from the actual runtime layout instead of assuming ..\Library\bin.
2. Quote and forward arguments using standard batch semantics (for example, %*) rather than relying on an environment-specific %CODEX_ARGS%, unless that variable is guaranteed by every caller.
3. Add a Windows smoke test that invokes both wrappers against a one-page PDF from an installation path containing spaces.
4. On failure, report the fully resolved executable path to make packaging regressions diagnosable.

Related issue and current workaround

The DOCX-to-PDF stage has a separate Windows issue caused by malformed LibreOffice profile URIs; see #30649, #27957, and #24210.

A working local recovery route is:

DOCX -> LibreOffice with Path(...).as_uri() (or Word COM fallback)
     -> direct bundled pdfinfo.exe / pdftoppm.exe
     -> PNG pages

No customer documents or user-specific paths are included in this report.