Simon Willison went looking through his disk cache on 1 September 2026 and found 1.7GB of software he had not installed. It sat in a folder called codex-primary-runtime, put there by the Codex coding app from OpenAI, the lab that makes ChatGPT. Willison notes the app has since been rebranded to ChatGPT as well. Willison lists what is in it: a full Python installation, a full Node.js installation, and native binaries for git, for Poppler and for LibreOffice. LibreOffice is the free office suite that he notes was forked in 2010 from OpenOffice.org. Alongside the binaries sit instruction files telling the agent how to find them and what to do with them.

The disk space is the least interesting thing in that folder. Those instruction files are the part worth stopping on. They put the document-handling path of a flagship AI product through a PDF library derived from the xpdf code base and a fork of OpenOffice.org, invoked as subprocesses by the runtime that sits around the model. Both are outside projects with their own homes: Poppler's site directs patches and bug reports to its own repository at gitlab.freedesktop.org, and LibreOffice's licence page tells contributors how to license code to the project.

The same tools, in public

The relationship is not identical at the two labs. OpenAI ships the binaries; Anthropic's public repository assumes they are already in the environment. What is the same is which tools the work runs through, and you do not have to go through a cache folder to see the second one. Anthropic publishes its Agent Skills, the instruction files that tell Claude how to handle particular file types, in a public repository at github.com/anthropics/skills. The docx skill tells the model that after writing a Word file it should render it and look at it, using two commands: a LibreOffice call to convert the document to PDF, and pdftoppm, one of Poppler's command-line tools, to turn that PDF into images. The pptx skill describes the same helper as a "LibreOffice wrapper" and adds, in the same table cell, that "bare soffice hangs in this sandbox".

That helper is the part I keep coming back to. In Anthropic's repository soffice.py runs to 192 lines of Python, and most of it deals with the gap between what LibreOffice assumes about its environment and what an agent sandbox actually provides. It forces the headless graphics backend. It creates a throwaway user profile directory for every single invocation, because a non-root sandbox cannot bootstrap the default one, and without it, as the file's own docstring says, LibreOffice "aborts with 'User installation could not be completed' and converts nothing".

Then it gets more involved. The script tests whether the sandbox permits Unix domain sockets, a local inter-process channel that LibreOffice uses among its own processes. If they are blocked, it writes out a C source file at runtime, compiles it with gcc, and loads the result through LD_PRELOAD so that LibreOffice's socket calls are intercepted and answered by a fake implementation the sandbox will tolerate. Anthropic publishes a hand-written C shim so that a word processor will convert a file inside an agent sandbox.

I have written that kind of shim once, for a build system that would not run in a container, and it was the worst week of that project. You do not write one because a dependency is convenient. In my experience you write one when the dependency is not optional and the easy fixes are gone. I cannot see inside Anthropic's decision, and I am inferring from the artefact rather than reading anyone's mind.

The pitch, which is largely right

The engineering case here is strong and deserves stating properly rather than as a setup for knocking down.

A .docx file is a ZIP archive of XML, as Anthropic's own skill file says in its opening line. A .xlsx is the same kind of package with spreadsheet parts inside it. Anthropic's skill files take a clear position on how to produce one: write a script that drives a real library, convert the result with a real converter, then render the output and look at it. That is a description of not trusting the model to emit a binary format directly. It matches my own experience of trying, which produced files that opened with an error dialog rather than files that were merely wrong. Bundling the binaries rather than trusting whatever the user happens to have installed is also correct, because it removes a whole class of works-on-my-machine failures from a path the user never sees.

Willison himself presents the find as a curiosity rather than a scandal, and he is not wrong to. Next to model weights, 1.7GB does not warrant a paragraph. LibreOffice is available under the Mozilla Public License v2.0, as its licence page states, and the same page notes that contributions are licensed jointly under that and the LGPL v3+. Those terms contemplate redistribution of exactly this kind. Whether every obligation that comes with redistribution has been met is a separate question, and I come back to it below.

All of that holds. My disagreement is not with the engineering decision but with what the two companies have taken on, and with what I cannot see either of them accounting for from outside.

What I counted

Poppler's site describes it as "a PDF rendering library based on the xpdf-3.0 code base", ships frontends for C++, GLib, Qt5 and Qt6, and points at a GitHub mirror of its repository. On 4 September 2026 I pulled the commit history from that mirror, github.com/tsdgeos/poppler_mirror, asking the GitHub API for everything since 1 September 2025. It returned 785 commits carrying 38 distinct author names. The author string "Albert Astals Cid" appears on 567 of them, which is 72 per cent. His is also the name on poppler.freedesktop.org as the signer of the current release tarball, poppler-26.09.0, dated 3 September 2026.

Commit counts measure one thing, badly. A git author field is a string, not an identity, and it says nothing about code review, triage, packaging, release engineering, or the hours that never reach git at all. Take the number as a shape rather than a headcount.

I ran the same query against github.com/LibreOffice/core the same day, over the same window, and got a different picture. I stopped after 1,500 commits, which already carried 86 distinct author names, and the history had not run out. That is a lot of distinct author strings, however hard you discount them. The distinction matters, and folding the two dependencies into one story about neglected open source would be wrong.

So the accurate version is narrower than the dramatic one. One of the two bundled dependencies shows 86 different author strings in a partial sample of a single year. The other has a commit history concentrated, over the past year, in a single author name, and, in the workflow Anthropic publishes, it is the one that turns the converted file into the images the agent inspects. That is not proof of a bus factor of one, and I am not claiming it is. Issue triage, review, packaging and release work do not show up in a commit count at all. It is one public signal, from outside, and it points one way.

The strongest case against me

The best counter-argument is that nothing has changed. Poppler's own site says its continuous integration runs against Debian Unstable, Ubuntu 24.04 and Fedora 44, which is a project testing itself against the environments the distributions ship. Its release page shows a new version most months, 26.08.0 dated 2 August 2026 and 26.09.0 dated 3 September, with an archive of earlier releases behind it. That is not the release pattern of a project in trouble. On that reading, adding these two to a user list that already includes the major distributions is a rounding error, and my commit count describes a project that works rather than one at risk. Concentration is not the same as fragility. Plenty of important libraries have one excellent maintainer and are better for it.

That case is good, and on the funding question I think it mostly holds. Where I think it breaks is on the kind of load rather than the amount.

An interactive viewer and an agent pipeline consume Poppler differently, and I have no usage data telling me which is now the larger share. A good deal of Poppler's existing load is already non-interactive: search indexers, thumbnail generators, print paths. The two ends still differ in one respect that matters here. When a person is looking at a page that rendered badly, they see it, and the report that eventually reaches the maintainer comes from someone who can describe what they were looking at. When an agent converts a generated slide deck to images so it can check its own work, and the conversion drops a font or collapses a table, the failure is consumed by a model first. The user sees a slightly wrong deck and blames the AI brand. That is a failure mode I expect rather than one I have measured. I would expect the signal that used to reach the maintainer to be absorbed one layer up, inside a company that does not govern the project it depends on.

The licence dimension has the same shape. Poppler's README is unusually direct: "Poppler is licensed under the GPL, not the LGPL, so programs which call Poppler must be licensed under the GPL as well." Invoking the command-line tools as separate executables is a different question from the linking case that sentence describes, and where exactly the process boundary sits under the GPL is an argument older than either company, which I am not going to settle here. What is not in dispute is simpler: a consumer AI app is now distributing GPL-licensed programs, and that carries the ordinary obligations. Anthropic takes this seriously in the skills repository: its third-party notices file reproduces GPLv3 in full for FFmpeg 7.0.2 and links the exact source tarball. It carries no entry for LibreOffice or Poppler, which is consistent, since that repository assumes those tools are present rather than shipping them. OpenAI's app does ship them. What attribution and source offer travels with those binaries, I could not verify from outside the app.

The bet

One more thing belongs on the record. The Document Foundation's published values commit it to letting users of office software "retain the intellectual property in the documents they create", and reject "the ownership of office productivity tools by monopoly suppliers". Their code is bundled inside one proprietary AI product and named in another's published instructions, in both cases so a user can ask for a document rather than make one. The licence permits it, and becoming the default document engine of the agent era is a kind of win. It is not a breach of anything, and I am not suggesting otherwise. It is just a different outcome from the one that manifesto imagines.

So, a falsifiable version of my read. If this dependency is as structural as the bundle and that shim together suggest, then within twelve months, by September 2027, I expect at least one of OpenAI or Anthropic to be either paying directly for work on Poppler or LibreOffice, or shipping a conversion path of its own that it can debug itself. Those are not the only two things that could happen. They are the two I would bet on. If September 2027 arrives with the bundle unchanged, no funding, no in-house renderer, and the commit history still concentrated the same way, then the pressure I think I can see is not there, and I have overread a cache folder.