Libre Office Skill in Codex, I use cli, but it was also in the ChatGPT. When it calls LibreOffice, there’s a popup saying bootstrap.ini is corrupt, this is coming from Codex and not LibreOffice:
Codex fixing itself:
The problem was not a corrupted LibreOffice installation. Codex’s document renderer generated an invalid Windows profile URI:
file://C:\Users…
I patched C:/Users/foo/.codex/plugins/cache/openai-primary-runtime/documents/26.727.11326/skills/documents/render_docx.py:21 to generate the correct form:
file:///C:/Users/…
Verification passed:
LibreOffice converted a DOCX to PDF successfully.
The PDF rendered to PNG.
Exit code was 0.
No error dialog or leftover LibreOffice process remained.
Your existing bootstrap.ini was left untouched because it is valid.
A future Documents-plugin update could replace this cached file; if the notice returns after an update, the same compatibility patch may need to be reapplied.
You are welcome to discuss Codex issues on the forum, however the official place to report and track them is the GitHub issue tracker for OpenAI Codex.
I had ChatGPT look for the closest related issue and it identified:
The issue remains active, with other users responding as recently as yesterday. They have offered several possible root causes and workarounds.
If that issue matches your problem, consider adding a reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.
If it is not the same issue, try searching the existing GitHub issues for a closer match. If you cannot find one, then open a new issue with as much detail as possible.
Thanks for documenting this so thoroughly, @milesdr and thank you also @EricGT for pointing that out. This definitely looks like a real issue rather than a corrupted LibreOffice installation.
From your testing, the popup is being triggered because the Documents renderer is generating an invalid Windows file URI (file://C:\...) instead of the expected file:///C:/.... Your verification that LibreOffice works normally after patching render_docx.py is especially helpful, since it narrows the problem down to the renderer rather than LibreOffice itself.
The workaround should help others who run into the same error, but as you noted it's only temporary because the cached plugin files can be replaced during an update.
We'll send this over to the team for logging. The request is to update the Documents renderer so it generates valid Windows file URIs for LibreOffice, eliminating the need for users to manually patch the cached plugin.
Thanks again for sharing the root cause and the validation steps. That kind of detail makes these issues much easier to track down.
reaction on the GitHub issue page itself, not just on the forum topic, as reactions on GitHub help the developers gauge impact and prioritize work.