Would be nice if they donate to LibreOffice then, to improve the support of various MS Office features in files, as well as comparison/diffing features. Win-win to everyone.

I actually bundle LibreOffice with my app too and the reason is reading files, especially old xls files. Since I'm bundling it I'm now using it for everything docs related but the specific reason is those old files. I couldn't find anything else that I could just drop it and feel confident it'll just read anything I give it.

Does that really mean that it's bundling those apps from the start or did it just download and install them at some point to do some local work on some prompt or job you ask it to?

I don't see it making much sense to bundle it. I'm sure a LOT of LLM prompts are related with docs, excels, powerpoints etc, etc but don't really see it worth it for it to be bundled on the codex app from the get go, because otherwise, why not also install dozens of other apps?

The new app is an unbelievable mess. Settings are senselessly organized, too. The whole thing has this aesthetic slickness and then underneath it's like the people who make it have never even used it.

It's not surprising that it's pulled in absolutely massive dependencies, although I'm not sure it's the wrong call on some operating systems. LibreOffice is pretty tried and true.

Is that what it is using to render and manipulate MS Office documents? That'd explain the poor rendering of some of my files. Bundling all of LibreOffice seems like a pretty huge dependency.

There is a serious threat to Microsoft here, if everyone starts using AI for generating and updating Office docs. At some point Office will become just a viewer.

Now someone please use ChatGPT/Codex or Claude Code to rewrite the entire LibreOffice source into a single Rust binary already! Just like Jarred Sumner did for Bun [1] or Carmine Paolino did for Fastpotify [2] - granted there are some rough edges for sure, but the slim diet trimmed down and performance gains were wrothy.

[1] https://bun.com/blog/bun-in-rust [2] https://fastpotify.rocks/

Curiously, I didn't find any reference in the Open source licences section of the codex app.

Is this a MPL 2.0 violation?

Imagine the enormous complexity of office file formats if your business is literally building coding models/agents and still you choose to bundle LibreOffice.

First Claude installed 10GB VM [0] without asking, but OpenAI ships LibreOffice. What's next? Somebody ship their monorepo verbatim?

Honestly, not sure it's worth having those app on your localhost at all. I ended up uninstalling all frontier labs bloated apps and start using Google AI Mode + Antigravity CLI / Claude Code sometimes.

[0] https://github.com/anthropics/claude-code/issues/22543

I suspect that it’s used in headless clip mode to reliably convert file formats back and forth.

Someone may need to explain to me what is wrong with this sorry. Is it because it bloats the app with functionality that some users will never use? I feel like that is fairly usual for productivity/business apps generally.

I wonder why they didn't try to discover if the user already has those binaries and use them before downloading.

Also in the newest app I think the transcription feature is unusable. Ok, I can have a shortcut to start and stop recording. Wow, cool! Ok, but where did the transcription go? In my clipboard? To my cursor? Hey? :(

I've noticed that when I have codex read/modify word files the live reasoning snippets often allude to LibreOffice, so that makes sense. I think it was a quick and dirty way for them to interface with docx and xlsx files?

Are they at least respecting the licenses (.i.e.: providing a verbatim copy of each license?)

It might be for their new Work product which can produce docx, pdf and pox files.

spinning up an entire copy of libreoffice sounds super heavy?, if someone here is actually using chatgpt to edit docx documents then they can feel free to use us. vespper.com

My agent did it? I didn’t do it.

I don't see the problem?

Last time I used the Windows version it pegged all my cores at 100% usage for some reason. The machine became unusable. Instead I used Codex with JetBrains Rider (doing a C# project) and it worked flawlessly.

(I made a similar comment in a different post by Simon Willison yesterday about GPT Work)

I am unsure the direction that AI assisted document creation work will go in. I am opinionated and building something in the space. In this reply I discuss my view + what I have been building.

My opinion is: We now have AI, this new amazing flexible tool. We can throw it at any problem. But in terms of document creation we have a choice between old fashioned siloed document formats (.pptx, .pdf, .xlsx, .docx, etc.) and a freshly rendered - slightly randomly styled - html site with some basic javascript within it. I think these combinations are odd and do not maximise the powers of AI.

I've been building something called SmallDocs [0][1] which is a new take on work documents. It's all Markdown, but it always renders (100% privately) on the SmallDocs site. This means the SmallDocs renderer can convert recognised Markdown combinations into powerful traditional document formats [2]. For example, we convert a ```cells block into an in-line spreadsheet you can export to Excel.

This gives an agent the ability to express itself with a great deal of depth and flexibility. For example, your agent can produce a single data analysis "SmallDoc" with text, charts, spreadsheets, etc. [3] I find that combining formats quickens the speed I can understand a topic.

SmallDocs also have standardised and pretty boring styling. This means you spend less time understanding the layout of a flashy HTML page and more time on the content.

I also believe a pre-determined rendering engine has a lot of advantages over a freslhy built HTML artifact. It allows you to build in lot's of useful defaults that the agent doesn't have to code from scratch. These can be small things, for example, every time your agent renders a Markdown table in SmallDocs you can instantly copy it as a CSV or a PNG. And these can be bigger things, such as a rich slides DSL with solid styling defaults, which saves your agents a lot of tokens and results in consistently attractive HTML slides [4]. (Slides can also be automatically exported to .pdf and .pptx.)

I've been at it for a few months, and am still working on the project. I am looking for feedback and open source collaborators. Thanks for reading!

[0] https://smalldocs.org

[1] https://github.com/espressoplease/smalldocs

[2] https://smalldocs.org/blogs/what-is-a-smalldoc

[3] https://smalldocs.org/s/46fWiAyF77T9c7tqYwAQqp#k=j78ZEOOrgo8...

[4] https://smalldocs.org/s/QrmeWMsULGS871nXQYOacB#k=ubOHH9QtTWp...

(And something totally different, your agent can also use SmallDocs to walk you through code files: https://smalldocs.org/s/JsI_-tWSH0UpSd_YXxVLPm#k=G5jLCYA4JUX...)

Presumably this is for ChatGPT Work? https://simonwillison.net/2026/Aug/30/understanding-chatgpt-...

There's no security benefit to doing this versus demand-downloading hashed-locked components on need.

And wait till you find out about @oai/walnut

probably uses it extensively to convert between LLM working on a doc and exporting it out to excel, word etc

[flagged]

[dead]

[dead]

[dead]

[dead]

I still don’t understand why with all their cash these companies dont redo their apps in Rust or native. They are all so heavy and dog slow. There are already some very fast cross platform (wasm too!) libraries that can do what poppler does as well as parse and produce various office file formats. Because 2gb is crazy town, these things could be around 100mb, just throw some tokens at the problem.