Bug: render_docx.py builds invalid Windows file:// URI for LibreOffice UserInstallation

Component

Codex App / documents skill / render_docx.py

Environment

• OS: Microsoft Windows 10.0.26200, x64
• Codex CLI: codex-cli 0.142.2
• LibreOffice: LibreOffice 26.2.2.2 1f77d10d6938fd34972958f64b2bcfa54f8b1ba5
• Shell: PowerShell

Summary

On Windows, render_docx.py passes a Windows path to LibreOffice as:

-env:UserInstallation=file://C:\Users\...\AppData\Local\Temp\soffice_profile_xxx

LibreOffice fails before producing the PDF and prints:

libpng error: Write Error

The same conversion succeeds when UserInstallation is expressed as a valid Windows file URI:

-env:UserInstallation=file:///C:/Users/.../AppData/Local/Temp/soffice_profile_xxx

Reproduction

1. On Windows, run the bundled documents renderer against any valid .docx:

& "<codex-runtime-python>\python.exe" `
  "<codex-documents-skill>\render_docx.py" `
  "D:\path\sample.docx" `
  --output_dir "D:\path\rendered" `
  --verbose `
  --emit_pdf

2. The script constructs a LibreOffice command like:

soffice -env:UserInstallation=file://C:\Users\...\AppData\Local\Temp\soffice_profile_xxx --invisible --headless --norestore --convert-to pdf --outdir C:\Users\...\AppData\Local\Temp\soffice_convert_xxx D:\path\sample.docx

3. LibreOffice exits with code 1 and stderr:

libpng error: Write Error

4. No PDF is produced, and render_docx.py raises:

RuntimeError: Failed to produce PDF for rasterization (direct and ODT fallback).

Expected behavior

render_docx.py should produce a PDF and PNG pages on Windows when LibreOffice is installed and the input DOCX is valid.

Actual behavior

PDF generation fails because LibreOffice receives an invalid UserInstallation file URI.

Evidence

The same input document and LibreOffice installation were tested with two UserInstallation forms:

file://D:\...\lo_profile       -> fails with "libpng error: Write Error"
file:///D:/.../lo_profile      -> succeeds and generates the PDF

Running LibreOffice without the isolated profile can also generate the PDF, but that is not a good long-term workaround because it uses the default user profile and can be affected by profile locks or user configuration.

Likely cause

render_docx.py currently constructs the argument by string concatenation:

"-env:UserInstallation=file://" + user_profile

On Windows this produces a non-standard file URI with backslashes and no third slash after file:.

Suggested fix

Use platform-aware URI construction, for example:

from pathlib import Path

"-env:UserInstallation=" + Path(user_profile).resolve().as_uri()

This produces file:///C:/... on Windows and valid file URIs on other platforms.