@documents silently substitutes Liberation Serif for explicitly requested Times New Roman in generated legal documents

What version of the Codex App are you using?

Codex Desktop 26.730.61639

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS, Apple Silicon (arm64)

What issue are you seeing?

The OpenAI primary-runtime Documents plugin silently substitutes Liberation Serif for an explicitly requested Times New Roman font when generating or rendering legal documents.

This did not occur during an arbitrary user-created LibreOffice workflow. I repeatedly instructed the ChatGPT Project to use the OpenAI Documents plugin explicitly:

[@documents](plugin://documents@openai-primary-runtime)

I also explicitly required Times New Roman, including Times New Roman 12-point formatting for legal documents. Nevertheless, the Documents workflow reported or revealed that LibreOffice had substituted Liberation Serif for Times New Roman.

The problem is not merely that a fallback font exists. The problem is that the Documents plugin:

1. accepted an explicit Times New Roman requirement;
2. generated the document through its supported document workflow;
3. silently substituted Liberation Serif;
4. did not warn before producing the final document that the requested font was unavailable; and
5. could present the result as satisfying the requested formatting even though the rendered or exported result did not use Times New Roman.

This has happened repeatedly. It is significant for legal-document workflows where the requested typeface may be part of a court, filing, or professional formatting requirement.

What steps can reproduce the bug?

1. In Codex Desktop on macOS, start a Project or task that creates a legal .docx document.
2. Explicitly invoke or request the OpenAI Documents plugin:

``text
[@documents](plugin://documents@openai-primary-runtime)
``

1. Require the document to use Times New Roman, for example:

``text
Use Times New Roman, 12 pt, throughout the document.
``

1. Have the Documents workflow create and render or export the DOCX using its bundled LibreOffice path.
2. Inspect the render/conversion output or font diagnostics.
3. Observe a message or result equivalent to:

``text
LibreOffice substituted Liberation Serif for Times New Roman
``

1. Observe that the workflow did not stop or clearly warn before finalizing the document.

What is the expected behavior?

When @documents is explicitly asked to use Times New Roman, it should do one of the following:

• use and embed the actual Times New Roman font in the rendered output;
• expose a host-installed Times New Roman font to the bundled LibreOffice runtime; or
• stop and clearly disclose that Times New Roman is unavailable before producing or approving the final document.

The plugin should not silently substitute Liberation Serif while representing the document as compliant with the requested font.

The Documents workflow should also include a font-fidelity validation step for requested fonts and report the actual resolved/rendered font before declaring the artifact complete.

Additional information

Feedback was uploaded from the affected Codex session.

Feedback ID:

019fd34f-510d-76a0-b9e9-e5b3fe949783

Potentially related issue:

• #32968 — Add a supported host-font configuration for bundled LibreOffice and Poppler runtimes

That issue concerns the broader inability of bundled Fontconfig-based tools to access host fonts. This report is narrower: the supported @documents workflow accepts an explicit font requirement, silently substitutes a different font, and does not disclose the resulting noncompliance before finalizing a legal document.