Windows: render_docx.py passes invalid file:// URI to LibreOffice UserInstallation

I can reproduce a closely related Windows failure on another Codex Desktop install, with one additional symptom that may help debugging.

Environment:

• OS: Windows 11 Pro 10.0.22631, x64
• Documents runtime bundle: openai-primary-runtime/documents/26.630.11634
• LibreOffice: LibreOffice 26.2.4.2 0229ac93fcf0d7cbc6376066c6f35021cef002dc
• Shell: PowerShell

Observed behavior:

• When Codex renders a DOCX page preview through the bundled render_docx.py, LibreOffice can show a GUI error dialog in Chinese:

The application cannot be started. The configuration file "C:\Program Files\LibreOffice\program\bootstrap.ini" is corrupt.

• The file is not actually corrupt. On this machine, C:\Program Files\LibreOffice\program\bootstrap.ini is readable and normal, and direct LibreOffice conversion works.
• Running the unpatched renderer showed the same bad argument shape described in this issue:

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

• The renderer process then hung during DOCX conversion until killed by the caller.

Local fix that worked:

1. Build the LibreOffice profile argument with Path(user_profile).resolve().as_uri():

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

1. On Windows, resolve LibreOffice to soffice.exe explicitly. Using plain soffice may resolve through Windows command lookup in a way that is harder to diagnose.

1. The same renderer then reached the PNG stage, where this Windows bundle also needed the real Poppler directory passed explicitly to pdf2image:

.../dependencies/native/poppler/Library/bin

After applying those local changes, the same test DOCX rendered successfully to page-1.png, with no leftover LibreOffice processes.

So the misleading bootstrap.ini is corrupt dialog appears to be another manifestation of the malformed Windows file:// UserInstallation argument rather than an actual LibreOffice installation corruption.

I hit this on Windows with the bundled documents runtime openai-primary-runtime/documents/26.630.12135 and confirmed the root cause/fix locally.

The cached renderer contains three instances of:

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

On Windows this builds an invalid URI, for example:

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

LibreOffice then fails conversion with:

libpng error: Write Error

and may show the misleading dialog that C:\Program Files\LibreOffice\program\bootstrap.ini is corrupt.

I verified the same LibreOffice install succeeds when the URI is built with Path.as_uri():

from pathlib import Path

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

That produces the valid Windows form:

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

Local validation after patching render_docx.py:

[render_docx] $ soffice -env:UserInstallation=file:///C:/Users/jmorr/AppData/Local/Temp/soffice_profile_wpb2y36u --invisible --headless --norestore --convert-to pdf --outdir ... test.docx
convert ... test.docx as a Writer document -> ... test.pdf using filter : writer_pdf_Export
Pages rendered to ...\rendered

Output files were produced successfully:

page-1.png
test.pdf

The public openai/codex repo appears to reference openai-primary-runtime as a plugin/runtime, but I could not find the actual documents/render_docx.py source in the public tree, so I cannot submit a direct source PR for this file. The minimal runtime patch is to construct UserInstallation with Path(user_profile).resolve().as_uri() anywhere this command argument is assembled.

I can reproduce this on a newer Codex Desktop documents bundle.

Environment:

• Windows 11 Pro for Workstations 10.0.26200, x64
• Documents runtime bundle: openai-primary-runtime/documents/26.709.11516
• LibreOffice: 26.2.4.2
• Shell: PowerShell

Observed behavior:

1. The bundled render_docx.py still constructs the profile argument as:

``text
-env:UserInstallation=file://C:\Users\<USER>\AppData\Local\Temp\soffice_profile_xxx
``

1. In this Codex process, LibreOffice's program directory is not in PATH, so the unmodified renderer can first fail with FileNotFoundError: [WinError 2] when it invokes bare soffice.

1. After temporarily making LibreOffice discoverable, both direct DOCX -> PDF and the ODT fallback exit with code 1 and:

``text
libpng error: Write Error
``

LibreOffice also displayed the misleading Chinese GUI dialog saying that C:\Program Files\LibreOffice\program\bootstrap.ini was corrupt. The file is readable and appears normal.

Controlled comparison with the same trivial DOCX:

• explicit C:\Program Files\LibreOffice\program\soffice.com
• UserInstallation generated as a real URI (file:///C:/...)

completed with exit code 0 and produced a non-empty PDF. The bundled Poppler/pdf2image path also reads the resulting PDF successfully.

This confirms the issue is still present in bundle 26.709.11516. For this Windows environment the local workaround needs both:

1. Path(user_profile).resolve().as_uri() for UserInstallation; and
2. explicit Windows resolution of soffice.com instead of relying on bare soffice/PATH lookup.

Confirmed on a newer Codex Desktop/Documents bundle. The issue is still present as of 2026-07-24.

Environment:

• Codex Desktop: 26.721.4979.0
• Windows 11 Pro: 10.0.26200, x64
• Documents runtime bundle: openai-primary-runtime/documents/26.723.12215
• LibreOffice: 26.2.4.2

Observed behavior:

1. A valid DOCX was generated successfully with python-docx and opened normally in Microsoft Word.
2. The bundled render_docx.py invoked LibreOffice with:

``text
-env:UserInstallation=file://C:\Users\<USER>\AppData\Local\Temp\soffice_profile_xxx
``

1. Both the direct DOCX -> PDF attempt and the ODT fallback exited with code 1:

``text
libpng error: Write Error
``

1. LibreOffice displayed the misleading GUI dialog:

``text
Cannot start application.
Configuration file "C:\Program Files\LibreOffice\program\bootstrap.ini" is corrupted.
``

Controlled comparison:

• Copying the same DOCX to an ASCII-only path did not change the failure.
• Invoking the same LibreOffice installation directly without the malformed UserInstallation argument succeeded and produced a non-empty PDF of approximately 483 KB:

``text
soffice.com --headless --convert-to pdf --outdir <output> <document.docx>
``

• PDF rasterization with the actual Poppler executable also succeeded afterward.

This adds another independent reproduction showing that the DOCX, LibreOffice installation, and document filename are not the root cause. The malformed Windows file URI remains the strongest explanation. The renderer still contains three occurrences of:

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

Using Path(user_profile).resolve().as_uri() and resolving soffice.com explicitly on Windows appears to be the appropriate fix.

Why this likely escaped detection on non-Windows (Windows-specific note):

Adding some context on why this passes elsewhere: on macOS/Linux, tempfile.TemporaryDirectory() returns a path beginning with / (e.g. /var/folders/.../soffice_profile_xxx or /tmp/soffice_profile_xxx). The renderer's "file://" + user_profile therefore yields file:///var/folders/... — a valid file URI, because the path's leading slash supplies the missing third slash after file:. On Windows the temp path is C:\..., so the same concatenation produces the malformed file://C:\... (two slashes instead of three, illegal backslashes, C: parsed as the authority/host).

This is consistent with every reproduction in this thread being Windows-only, and explains why the same code path does not fail on macOS/Linux dev or CI machines. The Path(user_profile).resolve().as_uri() fix proposed above generates correct file URIs on all platforms, so it should close the gap without regressing non-Windows.

Additional Confirmation & Production Workaround

We've encountered the exact same issue in production with real customers on Windows.

Our Environment

• Codex CLI: 0.145.0
• Plugin Version: 26.723.12215 (latest as of 2026-07-24)
• Confirmed: Bug still exists in the latest version

Production Impact

• Customer reported: LibreOffice popup "配置文件 [C:\Program Files\LibreOffice\program\bootstrap.ini] 已损坏"
• Diagnostic confirmed: render_docx.py lines 205, 233, 251 all use "file://" + user_profile
• Result: Document rendering fails, leaked temp directories, zombie processes

Detailed Diagnostic Report

We conducted a comprehensive diagnostic following the methodology in our support toolkit. Key findings:

• Residual soffice_profile_* directories: 18 leaked instances
• Stuck processes: 4 per failed rendering attempt
• Root cause confirmed: Invalid URI format on Windows

Workaround Solution

We've created an automated fix script for affected users:

• Script: Fix-Codex-Plugin-Windows.ps1
• Function: Automatically patches the three buggy lines with Path.as_uri()
• Distribution: Bundled with our Windows releases in support/codex/
• Limitation: Reset on plugin update

The fix script is now part of our release package to help users until upstream fix is available.

Reference Implementation

Our project (Bidwise) uses a similar pattern in our Base 1.0.2 soffice-headless.cjs:

const { pathToFileURL } = require('url');
const profileArgs = [`-env:UserInstallation=${pathToFileURL(profileDir).href}`];

This correctly generates file:///C:/Users/... on Windows.

Request

This bug affects all Windows Codex users. The fix is straightforward (3 lines). Could this be prioritized? We're happy to provide:

• Full diagnostic report (Chinese + English)
• Our automated fix script as reference
• Windows testing assistance

We're distributing the workaround with our releases, but an upstream fix would benefit the entire Windows Codex ecosystem.

---
Reported by: Bidwise Team (bidwise.ai)
Related: Customer diagnostic report available on request

Additional confirmation from another Windows Codex Desktop installation.

This bug has recurred after each Documents plugin/runtime update. I observed it in these bundled Documents versions:

• 26.521.10419
• 26.715.12143
• 26.723.12215

In every version, render_docx.py again contained:

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

On Windows this spawned LibreOffice with an argument such as:

-env:UserInstallation=file://C:\Users\<user>\AppData\Local\Temp\soffice_profile_xxx

LibreOffice 26.2.4.2 repeatedly displayed a misleading GUI error in Chinese saying that C:\Program Files\LibreOffice\program\bootstrap.ini was corrupted, while the Codex document-rendering process remained stuck. LibreOffice itself was healthy: direct headless DOCX-to-PDF conversion worked.

Changing the argument to:

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

produced file:///C:/Users/..., stopped the popup, and successfully rendered a 16-page DOCX to PNG pages. However, each Documents plugin update replaced the patched cached script and reintroduced the bug.

So this is both a Windows URI-construction bug and an update-persistence issue. The fix needs to be shipped in the upstream Documents plugin/runtime rather than applied to the local cache.

Additional reproduction data from another Windows Codex Desktop environment:

• Component: Codex Desktop / Documents DOCX rendering helper on native Windows/PowerShell.
• Documents runtime cache version observed: openai-primary-runtime/documents/26.727.11326.
• LibreOffice version: LibreOffice 26.2.4.2 0229ac93fcf0d7cbc6376066c6f35021cef002dc installed at the default path.
• User-visible error dialog, translated: unable to start application; configuration file C:\Program Files\LibreOffice\program\bootstrap.ini is damaged.
• The default bootstrap.ini was not actually damaged. LibreOffice launched normally with soffice.com --version.

The stuck LibreOffice process was launched with the invalid Windows file URI form:

soffice -env:UserInstallation=file://C:\Users\<USER>\AppData\Local\Temp\soffice_profile_... --invisible --headless --norestore --convert-to pdf --outdir C:\Users\<USER>\AppData\Local\Temp\soffice_convert_... <INPUT_DOCX>

The same local fix worked here:

from pathlib import Path

user_installation = Path(user_profile).resolve().as_uri()
# yields file:///C:/Users/<USER>/AppData/Local/Temp/soffice_profile_...

"-env:UserInstallation=" + user_installation

After patching the helper to use Path(...).resolve().as_uri(), a DOCX smoke test rendered successfully to both PDF and page PNG, and no file://C:\... LibreOffice process remained.

One recurrence detail: because the helper lives inside versioned Codex runtime cache folders, the local fix has to be reapplied when a new openai-primary-runtime/documents/... cache version appears. This environment had seen the same bad pattern across multiple cache versions, including 26.709.11516, 26.715.12143, 26.723.12215, and now 26.727.11326.

Additional production confirmation: this bug is still present in the newest official Documents plugin delivered to our installation as of 2026-07-28.

Environment:

• Codex CLI: 0.145.0
• Documents plugin: 26.727.11326
• Plugin author in .codex-plugin/plugin.json: OpenAI
• Windows with LibreOffice 26.2.x

The unmodified render_docx.py has SHA-256:

e7ab589242ca7beb4eb8c16448673c0cee639e2675ab0e18c5a6d2fc9dbe01c4

It still contains the malformed Windows URI construction at all three conversion call sites, currently lines 205, 233, and 251:

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

There is no Path(user_profile).as_uri() or equivalent platform-aware URI construction in this version. In a real Windows customer environment this still produces the LibreOffice bootstrap.ini damaged/corrupted dialog and prevents the expected conversion output.

We verified the same narrow patch at all three call sites:

from pathlib import Path

f"-env:UserInstallation={Path(user_profile).resolve().as_uri()}"

After applying it, headless DOCX/ODT-to-PDF conversions completed with exit code 0, including parallel conversions, without the popup or temporary-profile residue. A subsequent plugin refresh replaces the patched file, so downstream users still need to reapply the workaround.

Please include the platform-aware URI construction at all three call sites in the official Documents plugin release.

Additional confirmation on a newer Codex Desktop/Documents bundle.

Environment:

• Codex for Windows: 26.721.11231.0
• Documents runtime bundle: openai-primary-runtime/documents/26.730.11710
• Windows 11 Home China: 10.0.26200, x64
• LibreOffice: 26.2.4.2
• Internal Codex feedback/thread ID: 019fb707-e284-7ff0-97cd-44d0d44e4653

Observed behavior:

• The unmodified render_docx.py still contains three instances of "file://" + user_profile at the direct PDF, ODT fallback, and ODT-to-PDF call sites.
• This produces -env:UserInstallation=file://C:\Users\....
• Direct DOCX-to-PDF and ODT fallback both fail with libpng error: Write Error; no PDF is produced.
• Copying the same DOCX to an ASCII-only path does not change the failure.

Controlled comparison:

• Converting the same absolute profile path with [System.Uri]::new($profileDir).AbsoluteUri produces file:///C:/Users/....
• With that valid URI, the same LibreOffice installation and DOCX successfully produced a one-page Letter PDF and PNG.
• This confirms the bug is still present in Documents bundle 26.730.11710.

Suggested fix remains Path(user_profile).resolve().as_uri() at all three call sites.

Still reproducible on a newer documents runtime bundle as of 2026-08-06:

• OS: Windows 11 Pro 10.0.26200, x64
• Documents runtime bundle: openai-primary-runtime/documents/26.802.11031
• LibreOffice: 26.2.5.2 (cd7284b4cbbfeb507e630c1aac019f4157393acb)

The cached render_docx.py in this bundle still contains the three "-env:UserInstallation=file://" + user_profile instances, producing:

-env:UserInstallation=file://C:\Users\<user>\AppData\Local\Temp\soffice_profile_...

soffice.exe then shows the localized (Korean, in our case) "bootstrap.ini is corrupt" fatal dialog and hangs until the dialog is dismissed, so users see the dialog repeatedly on every render attempt.

Confirmed the Path(user_profile).as_uri() fix works on this setup (conversion succeeds, no dialog, no leftover soffice processes).

One additional data point for triage: the failure mode depends on the exact malformed value passed to -env:UserInstallation:

• file://C:\... (two slashes + backslashes, current bug) → fatal dialog "configuration file bootstrap.ini is corrupt" + hang
• plain path C:/... (no scheme) → silent failure: exit code 0, no output, no PDF produced
• unwritable-but-valid URI → different dialog: "The user installation could not be completed"

So depending on how the argument gets mangled, the script can also fail silently with exit 0, which is worth guarding against in addition to the URI fix.

Still reproducible after another Documents runtime update on 2026-08-07.

Environment:

• Codex for Windows package: 26.803.5235.0
• Codex CLI: 0.144.1
• Documents runtime bundle: openai-primary-runtime/documents/26.805.11740
• Windows: 10.0.19045.7548, x64
• LibreOffice: 26.2.3.2

The unmodified renderer backup (SHA-256 85BDD05ABB4F3F7BE5860BC000FAC34BC176C4B48148723E52BB97328D8007FB) still contains the malformed Windows URI construction at all three conversion call sites:

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

This again triggered the misleading LibreOffice dialog reporting that C:\Program Files\LibreOffice\program\bootstrap.ini was corrupt. The LibreOffice installation and bootstrap.ini were healthy.

A previous local fix had been applied to runtime 26.802.11031, but the update to 26.805.11740 replaced the versioned runtime directory and reintroduced the same bug.

I reapplied the narrow platform-aware fix:

from pathlib import Path

profile_uri = Path(user_profile).resolve().as_uri()
f"-env:UserInstallation={profile_uri}"

Validation using the updated bundle's own render_docx.py against a valid DOCX:

• renderer exit code: 0
• PDF generated: 313,067 bytes
• page PNG generated: 466,015 bytes
• rendered page visually checked successfully
• no LibreOffice corruption dialog
• no leftover validation/LibreOffice process

This confirms that the defect remains in bundle 26.805.11740 and that runtime updates continue to overwrite the working local patch. Please ship Path(...).resolve().as_uri() (or equivalent platform-aware URI construction) at all three call sites in the upstream Documents runtime.

All user names and document paths have been omitted.

Confirming this is still present in a newer Windows bundle.

Environment:

• Codex Documents plugin: 26.805.11740
• LibreOffice: 26.2.4.2
• Windows x64

The same malformed argument is generated:

-env:UserInstallation=file://C:\Users\<user>\AppData\Local\Temp\soffice_profile_*

Additional symptom: after several Codex document-rendering launches, LibreOffice can show a GUI modal saying:

The application cannot be started. The configuration file "C:\Program Files\LibreOffice\program\bootstrap.ini" is corrupt.

We verified that bootstrap.ini exists, is readable, and its hash/mtime remain unchanged; relevant LibreOffice/UNO environment overrides are unset. The message is therefore misleading in this case.

Local patch:

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

After patching all three conversion call sites, 5 consecutive end-to-end render_docx.py runs completed successfully (PDF plus PNG pages on every run), with no lingering soffice processes or error dialogs.

This confirms the issue is still reproducible in Documents 26.805.11740 and that URI normalization resolves it; reinstalling LibreOffice is not required.

Additional NTFS/VSS/MSI forensic confirmation from a current Windows installation. This adds evidence that the recurring bootstrap.ini is corrupt dialog can occur without any mutation of that file.

Environment

• Windows x64 build: 10.0.26200.8037
• Codex Desktop: 26.803.5235.0
• Codex CLI: 0.147.0
• Documents runtime: openai-primary-runtime/documents/26.805.11740
• Unmodified render_docx.py SHA-256: 85BDD05ABB4F3F7BE5860BC000FAC34BC176C4B48148723E52BB97328D8007FB
• LibreOffice: 26.2.5.2, x64

The current renderer still contains all three instances of:

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

Forensic evidence

• C:\Program Files\LibreOffice\program\bootstrap.ini is 112 bytes, valid ASCII/UTF-8 without BOM, and has SHA-256:

9BC1FFA0360ADACAD9666D1B9D5BE2B09E3F9FF1EB851A05F168393819CBABE0.

• That file is byte-for-byte identical to the file hash registered in the locally cached, Authenticode-valid The Document Foundation MSI for the exact installed version. The related program bootstrap/config files checked also match the MSI baseline.
• A VSS snapshot taken before the observed launch contains the same 112-byte file and the same SHA-256.
• The retained NTFS USN journal covers the observed episode. Searching the full retained journal by both bootstrap.ini and its file reference number returns zero records.
• At 11:52:10, the same USN journal records creation of both soffice_profile_* and soffice_convert_* temporary directories. A bounded search of the installed Codex scripts/runtime finds this render_docx.py as the only local generator of that exact prefix pair. The corresponding Prefetch sequence contains a LibreOffice launch.
• LibreOffice 26.2.5.2 source maps invalid/missing UserInstallation bootstrap data to the generic message that the existing bootstrap.ini file “is corrupt”: https://github.com/LibreOffice/core/blob/libreoffice-26.2.5.2/unotools/source/config/bootstrap.cxx#L235-L480

Therefore, in this captured episode there was no ordinary NTFS writer corrupting or restoring bootstrap.ini. The dialog was a misleading consequence of the malformed runtime override. This matters because users may repeatedly repair or reinstall a healthy LibreOffice installation.

The upstream correction remains:

profile_uri = Path(user_profile).resolve().as_uri()
f"-env:UserInstallation={profile_uri}"

Please apply it at all three call sites and add a Windows regression test asserting a file:///C:/... URI. A cache-only patch is not durable because Documents runtime updates replace the versioned directory.

No user names, document paths, document contents, screenshots, credentials, or private logs are included.

Additional independent verification on Windows using the bundled Documents package version 26.805.11740 and LibreOffice 25.8.7.3 on August 12, 2026.

I repeated the A/B comparison twice against the same test DOCX containing two embedded PNG images, changing only the UserInstallation URI form. In both repetitions:

• file://C:\... caused LibreOffice to exit with code 1 and report libpng error: Write Error; it produced no PDF and did not initialize the temporary profile.
• file:///C:/... caused LibreOffice to exit with code 0, produce a non-empty PDF, and initialize the temporary profile normally.

I then patched all three call sites to construct the profile URI as follows:

from pathlib import Path

user_profile_uri = Path(user_profile).resolve().as_uri()
f"-env:UserInstallation={user_profile_uri}"

A task-local copy of the patched renderer completed an end-to-end conversion of a separate three-page DOCX, producing one PDF and three page PNGs. After applying the same patch to the installed renderer, I repeated the end-to-end test and again obtained one PDF and three page PNGs.

These results provide another controlled A/B confirmation that the URI construction is the failure point. In my installation of bundle 26.805.11740, Path(...).resolve().as_uri() resolved this URI-related LibreOffice conversion failure. Related reports: #24210 and #27957.