The ChatGPT App Is 154MB Until It Decides to Download LibreOffice
Simon Willison found 1.7GB of Python, Node.js and headless LibreOffice in his cache folder, downloaded by OpenAI's desktop app. We measured our own copy: 154MB of application, 428 launches, and none of it.
The WJS Desk
Sep 3, 2026 · 6 min read
Simon Willison went poking around his cache folder with OmniDiskSweeper on 1 September, the way you do when a laptop starts complaining about space, and found 1.7GB sitting in a directory called codex-primary-runtime. Inside it: a full Python installation, a full Node.js installation, and native binaries for git, Poppler and the LibreOffice office suite. The OpenAI Codex desktop app, since folded into the ChatGPT app, had assembled most of a Linux userland on his Mac without mentioning it.
His post is four sentences long. It hit 446 points and 208 comments on Hacker News inside a day, which tells you the finding landed on a nerve. We already had the ChatGPT app installed, so before writing anything we measured our own copy: a 154MB application, launched 428 times, with not one byte of LibreOffice anywhere on the disk.
What is actually in the 1.7GB
The breakdown below is read off the screenshot in Willison's post. We are reporting his numbers, not ours, because the folder does not exist on our machine and we could not weigh it ourselves.
| Component | Size |
|---|---|
| Native binaries (total) | 771.0 MB |
| LibreOffice, headless | 429.7 MB |
| Poppler | 187.9 MB |
| git | 148.1 MB |
| Node.js | 446.4 MB |
| Python | 440.6 MB |
The three native entries add up to 765.7MB against a stated 771.0MB, so the nesting is what it looks like: LibreOffice, Poppler and git are the native tier, and Node plus Python sit alongside it. Add the lot and you get about 1.66GB, which is the 1.7GB figure. In the thread, the commenter zamadatix independently confirmed the largest line, reporting that libreoffice-headless still showed 429.7MB on their own install.
Willison notes that the plugins/openai-primary-runtime/plugins/documents folder contains skills telling Codex how to find and use those binaries. That is the tell. This is not accidental bloat. It is a document toolchain, deliberately shipped, so that a model asked to fix a spreadsheet has something real to run.
What we found on our own Mac
Our install is ChatGPT 1.2026.119, build 1780053722, on an M4 Pro running macOS 26. We measured the app rather than trusting the thread.
| What we measured | Result |
|---|---|
| ChatGPT.app bundle on disk | 154 MB |
| Largest component (ChatGPT.framework) | 113 MB |
| Recursive grep for codex-runtimes, soffice, libreoffice | 0 matches |
| ~/.cache/codex-runtimes | does not exist |
| Times the app has been launched (Spotlight use count) | 428 |
| Application Support plus Caches | 204 MB |
| LibreOffice, Poppler, Python or Node in acknowledgements.html | 0 mentions in 231,630 characters |
So the shipped artifact is clean. Four hundred and twenty eight launches of the chat app did not pull a single office binary, which narrows the trigger considerably: it is the Codex and agent side of the product that provisions the runtime, not the chat window. That matches what zamadatix described in the thread, that the folder appeared not after installing but after the first run with its long startup screen, and that they saw it on macOS but not on Windows.
Worth knowing: we could not reproduce the download, so we cannot tell you exactly which action triggers it or whether the current build still fetches the same set. Everything about the 1.7GB is Willison's measurement plus corroboration in the thread. Everything about the 154MB is ours.
The word bundles is doing a lot of work
The Hacker News title said the app bundles a full copy of LibreOffice. Two of those words are wrong, and the person who found it said so first. Willison pointed out that the post "is more of a tweet than a blog post, it really wasn't written with Hacker News in mind". zamadatix went further: "Despite the title, I'm not sure it's actually bundled. Some of the skills plugins will download it on the first run." Another reader suggested the accurate headline would have been "Codex Bundles Headless LibreOffice", since the screenshot plainly says headless.
That distinction is not pedantry, and our own null result is why. An installer that ships an office suite is a download size problem. An app that fetches one on demand is a supply chain and disclosure problem, because the bytes arrive after every review, notarisation and app store check has already been passed.
The licence question nobody in the thread settled
The commenter vb-8448 asked the question the thread then spent two hundred comments circling: "Curiously, I didn't find any reference in the Open source licences section of the codex app. Is this a MPL 2.0 violation?"
Here is what we can establish. LibreOffice is distributed under the Mozilla Public License v2.0, with Apache 2.0 covering code inherited from OpenOffice.org and contributors asked to license jointly under LGPLv3 or later. MPL 2.0 requires that recipients be told the source form is governed by the licence and how to get a copy, and that licence notices are not removed. Several people in the thread reached for the GPL instead, and prmoustache corrected them: "it can't be a GPL violation since Libreoffice is distributed under the MPL v2.0 license."
Then zamadatix went and looked, and found the licence file exactly where it should be, at codex-primary-runtime/dependencies/native/libreoffice-headless/libreoffice/LibreOfficeDev.app/Contents/Resources/LICENSE. So the notice travels with the binary. What is missing is any mention in the place a user would actually look. We read all 231,630 characters of the acknowledgements file that ships inside ChatGPT.app and it lists Segment, Auth0 and a long tail of MIT-licensed Swift packages. LibreOffice, Poppler, Python and Node.js appear zero times.
The licence is in the payload. The credit is nowhere in the product.
We are not lawyers and we are not calling this a violation. We are saying that a build-time acknowledgements file cannot describe a runtime that gets fetched afterwards, and that every agent vendor now has this problem.
Why an office suite is the reasonable choice
The most useful part of the thread was the people who had tried the alternatives. pseudosavant opened by wondering whether LibreOffice explains the poor rendering of some of their files. nomel asked the obvious follow up, what else would you use, and the answers came in: Apache POI, pandoc, computer use, the Microsoft 365 and Google Workspace CLIs.
The reply that ended the argument came from johnsmith1840, who had built the same thing: "Spent an ENOURMOUS amount of time trying everything I could and in the end libre was the only thing even somewhat functional. Easily 2 months of my life lost to these god forsaken systems. APIs and CLIs sound reasonable until you actually attempt anything in this space."
nomel made the structural point about POI: it reads and writes Office documents but it is not an office suite, and LibreOffice exposes a full API including spreadsheet recalculation. If your agent has to answer what this workbook evaluates to, you need something that can evaluate it. Nobody has spent thirty years building a second one.
What this means for anyone shipping an agent
This is not an OpenAI story so much as an agent story. paaloeye pointed at Anthropic in the same thread, and we verified the issue they linked: claude-code issue 22543, opened on 2 February 2026 and still open, reports that the cowork feature creates a 10GB VM bundle at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img that is never cleaned up and regrows within a day of being deleted. Different vendor, same shape. Give a model a real computer and something has to install one.
Our position is that the disk usage is the least interesting part. Nobody is going to abandon a coding agent over 1.7GB when the model weights people run locally are sixty times that. The interesting part is that the software inventory of your machine is now decided at runtime by a plugin manifest you have never read, and the only person who noticed was someone auditing their own cache folder with a disk visualiser.
If you ship an agent, the fix is dull and obvious: put the runtime manifest somewhere a user can read it before it downloads, and make the acknowledgements file describe what actually lands on disk rather than what your Xcode project links against. If you use one, run a disk visualiser over your home folder this week. You will find something.
