Simon Willison found that the ChatGPT/Codex desktop app includes a complete copy of LibreOffice inside the bundle. He posted it on his blog and the discussion hit the Hacker News front page fast, with over 400 points and nearly 200 comments. There's no bug and no leak here: it's a packaging decision that was in plain sight for anyone who opened the package.
Why it matters
The easy take is "look how bloated Electron apps are." I think that's the wrong take. What the finding shows is that a desktop AI client stopped being a chat interface and became an execution environment. If the agent has to open a .docx, convert an .xlsx, or render a .pptx to PDF, somebody has to do that work, and that somebody is a real office suite running locally.
So the signal is architectural: agent capabilities are moving from the server to the user's machine. That's consistent with everything happening around it. The same day, Sonos announced Sonos 27, with a layer called Sonos 27mcp to connect external assistants to the speakers, and Google launched Pics, which lives inside Docs and Slides instead of standing on its own as an isolated app. Three different moves, one direction: the model alone isn't enough, what's being fought over is access to the tools you already use.
And when tool access gets solved by bundling third-party binaries, the problem stops being a product problem and becomes yours — the problem of whoever maintains the distribution.
What changes in practice
If you're building anything that executes actions on the user's machine, this finding hands you three concrete tasks.
First: audit your own bundle. Don't assume you know what's inside. It's literally one command:
du -sh /Applications/YourApp.app
du -sh /Applications/YourApp.app/Contents/Resources/* | sort -h | tail -20The second command sorts by size and shows you the twenty heavyweights. If something shows up that you didn't know was there, that's your starting point. On one project I worked on, the winner was a full Python runtime that had come in as a transitive dependency of an image conversion library.
Second: explicitly decide between bundling, depending, or delegating. Three strategies with different costs, and it's worth choosing deliberately instead of taking the bundler's default.
| Strategy | Installer size | Determinism | Surface to maintain |
|---|---|---|---|
| Bundle the binary | High | Total: same version for everyone | All of it: patches and licenses are yours |
| Use what's already installed | Low | Low: depends on the machine | Minimal, but unpredictable support |
| Delegate to the server | Minimal | High | Infrastructure and data leaving the device |
OpenAI picked the first one. That makes sense for a mass-market product where "conversion is broken for me" support tickets cost more than a few hundred megabytes of download. For an internal product with ten users, probably not.
Third: check your licenses. Redistributing third-party software drags obligations along with it. I'm not going to claim which ones apply in this specific case because the material I have doesn't spell them out, and it's not a topic to improvise on. But if your build stuffs someone else's binaries into the installer, somebody on your team needs to have read those licenses before the release, not after the lawyer's email.
When NOT to do it
Bundling a full suite to solve file conversion is a reasonable decision in a few contexts and a bad one in several others.
- When the installer is part of the experience. If you ship to users on poor connections or through corporate MDM, every extra hundred megabytes is real adoption friction. In Argentina this isn't theoretical.
- When you only need a fraction of the functionality. If your case is "convert docx to plain text," shipping an entire office suite is bringing in a factory to hammer one nail. There are specific parsers, far smaller, with less attack surface.
- When you can't sustain the patch cycle. Bundling a large binary makes you its distributor: every upstream CVE becomes a release of yours. If your team has no process for that, you're piling up security debt you won't see until it blows up.
- When the user's environment already has it. On a standardized corporate fleet, depending on what's installed is cheaper and more honest.
There's one more tradeoff, less technical. WIRED en Español covered studies that warn about AI's homogenizing effect on language and creativity. Translated to the architecture plane: if we all copy the same "bundle everything just in case" pattern because it's what the market leader does, we end up with an ecosystem of one-gigabyte apps that nobody decided on, only imitated. OpenAI's decision is justified by its scale. Yours, almost certainly, doesn't have that scale.
What I'd do today
I'd run du -sh on my own bundle before having opinions about somebody else's. Then I'd set up a CI task that fails if the installer grows past a threshold the team sets, so size is a conscious decision and not a Hacker News discovery. And if I need document conversion, I'd start with the smallest library that solves my specific case, measuring before scaling up to something bigger.
Willison's finding isn't a scandal. It's a reminder that AI clients carry more and more machinery inside them, and that somebody has to maintain that machinery.