Why ChatGPT/Codex Bundles LibreOffice
Simon Willison’s note, The ChatGPT/Codex app bundles a full copy of LibreOffice, is a short developer observation about OpenAI Codex carrying a very large office-suite dependency. Why would an AI coding app need machinery for Word, Excel, PowerPoint, and document rendering at all? Codex CLI workflows are no longer only about source files; they increasingly touch the messy documents that describe the work. LibreOffice is an open-source office suite that can read, render, and convert many Microsoft Office formats locally.
Notice the dependency, not just the size
The easy reaction is to laugh at the weight. Bundling a full office suite inside an AI coding app feels strange if you think the app’s job is “read code, write code, run tests.”
But the dependency tells a more interesting story. A codex agent often needs the surrounding evidence: a product requirements document, a spreadsheet of pricing tiers, a PowerPoint from a customer workshop, or a legacy .docx design note that nobody has moved into the repo.
LibreOffice gives the app a local way to interpret those files without asking every user to export them first. That matters because office formats are not polite text files. They contain layout, embedded objects, track changes, formulas, tables, and formatting quirks that can change what the document means.
Don't treat this as only a “bloat” story. Size matters, especially on laptops and in managed environments, but the deeper question is what the agent is allowed to inspect and transform when the work starts outside Git.
Ask what Codex can inspect locally
As of September 2026, the public observation is about the ChatGPT/Codex app’s package contents, not a detailed OpenAI design note for why LibreOffice is there. Developers in the discussion reasonably asked whether the suite ships from the start or could have been downloaded later for a local job. That distinction matters for disk size and packaging, but it does not erase the workflow signal.
If an AI coding tool can read office files locally, those files can become part of the engineering loop. A vague ticket can point at pricing-model.xlsx. A migration task can reference legacy-admin-spec.docx. A release note can be checked against a slide deck from sales.
That is powerful, and a little dangerous. The agent may summarize a document correctly, miss a hidden worksheet, flatten a comment thread, or preserve the words while losing the layout that made the words meaningful.
For Codex users, the right mental model is simple: treat office documents as inputs with provenance, not as magical context. In Codex CLI workflows, that means making the conversion step visible enough to review.
Keep document conversion reviewable
A good repo does not let generated code appear without tests. It should not let generated document interpretation appear without a receipt either.
Here is a small pattern that works well in a real product repo. Put source documents in a clearly named folder, convert them into reviewable text or PDF artifacts, and ask Codex to cite the converted artifact when changing code.
repo/
docs-input/
enterprise-pricing.xlsx
admin-workflows.docx
docs-derived/
enterprise-pricing.csv
admin-workflows.md
AGENTS.md
Then make the rule boring and explicit:
# AGENTS.md
When a task depends on files in docs-input/:
- Do not edit the original .docx, .xlsx, or .pptx file unless explicitly asked.
- Create or update a derived artifact in docs-derived/ first.
- In the final answer, name the source document and the derived file used.
- If a spreadsheet has hidden sheets, formulas, or merged cells, stop and ask before changing code.
This is not glamorous. It is the difference between “the agent seemed to read the spreadsheet” and “the agent used docs-derived/enterprise-pricing.csv, which I can diff.”
If you expose a document store through Codex MCP, keep the same boundary. Start read-only, return filenames and timestamps with retrieved content, and avoid giving the agent write access to canonical business documents unless the review path is clear.
Try it safely with one repo
Use this small experiment before you trust document-heavy work to an agent. It is not a rollout plan. It is just a cheap way to see where the sharp edges are.
| Check | What to do | Why it matters |
|---|---|---|
| Pick one boring file | Use a real .docx spec or .xlsx model, not a toy sample |
Toy files hide the exact layout problems you need to catch |
| Convert outside the chat | If you have LibreOffice installed, convert to Markdown, CSV, or PDF before asking Codex to reason over it | The derived file becomes diffable evidence |
| Add one AGENTS.md boundary | Tell Codex not to edit originals and to cite derived files | The agent has a local rule instead of relying on memory |
| Ask for a narrow change | Example: “Update the pricing validation tests from docs-derived/enterprise-pricing.csv” |
Narrow tasks make document errors visible |
| Review the receipt | Check which file Codex says it used, then inspect the diff and run tests | The output should be reproducible without replaying the chat |
A simple command workflow might look like this:
mkdir -p docs-derived
libreoffice --headless --convert-to csv --outdir docs-derived docs-input/enterprise-pricing.xlsx
codex
Inside Codex, keep the prompt concrete:
Use docs-derived/enterprise-pricing.csv to update pricing validation tests.
Do not edit docs-input/enterprise-pricing.xlsx.
Show the test command you ran and name the rows that changed behavior.
The limitation is obvious: conversion is lossy. A CSV export may drop formulas, colors, hidden sheets, comments, or chart context. For anything regulated, contractual, or customer-facing, have a human open the original file too.
For adjacent CLI ergonomics, Codex Skin Themes the Codex CLI is a useful reminder that terminal agents live or die by small interface details. Document receipts are one of those details.
Further reading
Next move
Start from CLI workflows.