OpenAI's ChatGPT Desktop App Quietly Bundles LibreOffice, Poppler, Git

Simon Willison was browsing his ~/.cache/ folder with OmniDiskSweeper — the kind of routine disk-cleanup task most of us do without thinking — when he found something that belongs in a security review, not a Finder window.

What Willison found

Inside ~/.cache/codex-runtimes/codex-primary-runtime/ sits 1.7GB of vendored software quietly installed by the OpenAI Codex desktop app, since consolidated into the ChatGPT desktop app. Per Willison's breakdown, it includes:

• A complete Node.js installation (446.4 MB)
• A complete Python installation (440.6 MB)
• LibreOffice, headless (429.7 MB) — the office suite that forked from OpenOffice.org in 2010
• Poppler, a PDF rendering library (187.9 MB)
• git (148.1 MB)
• Smaller image libraries including libheif and jxrlib

A plugins/openai-primary-runtime/plugins/documents folder underneath it contains skills — instructions that tell the agent when and how to reach for each binary, presumably so it can open, convert, or extract text from real-world document formats a user hands it.

Why this matters beyond disk space

None of this is exotic. Agent tools that read spreadsheets, PDFs and Office files need something capable of parsing those formats, and shelling out to mature, battle-tested open-source tools is a reasonable engineering choice. The part worth a second look is what it does to the app's attack surface. Document parsers — Poppler and LibreOffice among them — have a long, well-documented history of memory-safety bugs triggered by malformed input files, which is exactly why enterprises track their versions and patch them on a schedule. Vendoring a private copy inside an AI app's cache directory takes that copy out of the normal OS/package-manager update path. It gets patched when the vendor rebuilds its runtime bundle, not when your endpoint management pushes updates.

Layer the agent on top and the risk model changes again. A skills file that lets the agent decide, autonomously, to hand an incoming file to LibreOffice or Poppler means untrusted input — an email attachment, a downloaded file, content pulled from the web during an agentic task — can reach native code paths without a human choosing to open that file in that specific application.

The broader supply-chain angle for agentic tools

This is a pattern security teams evaluating agentic AI products should expect to see more of. Coding and research agents increasingly ship their own private stack of interpreters, package managers and native binaries so they can act on files and code without depending on what happens to be installed on the host. That's convenient for the vendor and the user, but it also means a growing chunk of software running on an employee's laptop never shows up in a normal asset inventory, SBOM, or EDR-visible install list — it's just a folder in ~/.cache.

What to check before rolling out agentic tools like this

• Ask vendors what's vendored inside their desktop/CLI agent runtime, and what the patch cadence is for each bundled component.
• Add AI-agent runtime caches (~/.cache, %LOCALAPPDATA%, etc.) to your software inventory or SBOM process rather than treating them as opaque app data.
• If you red-team or pen-test environments where staff use agentic coding tools, include malformed-document handling against the agent's document pipeline in scope.
• Restrict what file types and sources an agent's document-handling skills can act on in sensitive environments, the same way you'd sandbox any auto-invoked parser.

There's no disclosed vulnerability here — Willison's post is an observation about what's on disk, not a proof-of-concept exploit. But for anyone assessing agentic AI tools for enterprise use, it's a concrete illustration of why "what does this agent actually install and run locally" belongs in the questionnaire, next to prompt-injection and data-handling questions.