Test ChatGPT's bundled LibreOffice like a document pipeline, not a bloat rumor

Why the bundled document engine is worth a look

If your work lives in office files, the most interesting part of the desktop app may not be the chat. It may be the quiet machinery that lets an agent open, convert, and edit documents on the machine in front of you. That is a useful capability, but it is also a permission surface. Treat it like a document pipeline, not like a rumor about bloat, and you can get the value without handing over your whole file system.

The Codex desktop app, now rebranded as ChatGPT, contains a 1.7GB local runtime folder that includes LibreOffice binaries. That folder is not just dead weight. The bundled runtime includes a documents folder with skills that tell Codex how to find and use the bundled binaries. In plain terms, the app is carrying a local document engine and a set of instructions for using it. That is the part worth auditing.

The context matters. OpenAI merged Codex into the ChatGPT desktop app and launched ChatGPT Work, which returns finished documents, spreadsheets, and web apps. The merged ChatGPT desktop app's Chat, Work, and Codex modes share projects, files, browser access, a unified plugin directory, and a single governance layer. That is a more integrated product. It is also a more integrated local footprint.

The old boundary was cleaner. Codex's original cloud execution was sandboxed, offline by default during the agent phase, and did not touch host files outside the designated workspace. The merged desktop app adds a built-in browser and Computer Use capabilities that can move files across the local environment. Once an agent can reach more of the machine, the question is no longer whether it can produce a file. The question is whether it should be allowed to roam while doing it.

What this means for document-heavy operators

For a practical user, the bundled document engine is most useful when the task is narrow: turn a draft into a clean file, convert a spreadsheet, update a slide deck, extract tables, or produce a versioned export. The value comes from local processing and fewer round trips. The risk comes from treating the agent as a general file manager. A document pipeline should have an input folder, an output folder, a limited set of tools, and a clear stop condition. If the workflow cannot be described in those terms, it is probably too broad.

For IT admins, the desktop app is a different class of software. The right response is not to ban it reflexively. The right response is to define the smallest workspace, the narrowest file access, and the clearest audit trail that still lets the work happen.

The most common mistake is to point the agent at a whole user profile and hope for the best. That is how a task meant to clean one report ends up touching a folder of contracts, a spreadsheet of payroll data, or a folder of client materials. The fix is boring: separate the work, limit the paths, and verify the result. The agent can be useful without being omnipresent.

A five-point audit for local document work

1. Isolate the workspace. Create a dedicated folder for the task. Put only the source files inside it. Create a separate output folder for results. Do not point the agent at your home directory, desktop, downloads folder, or a shared network drive unless the task explicitly requires it. If a file is not in the workspace, the agent should not need it.
2. Verify the bundled binaries. Before relying on the local document engine, inspect the runtime folder and confirm that the expected bundled binaries are present. Check that the bundled instructions point to the bundled tools rather than to some unexpected external path. If the binaries are missing, broken, or replaced by a wrapper, stop and treat the setup as untrusted.
3. Run conversion and editing tasks. Start with low-stakes files. Ask the agent to convert a sample document, update a spreadsheet, or modify a slide deck. Compare the output against the source. Look for broken formatting, missing tables, lost formulas, renamed files, and unexpected extra files. A document pipeline is only as good as its diff.
4. Check network and file paths. Watch what the process reads and writes. If the task only needs one folder, any access outside that folder is a red flag. If the agent needs the network for a simple local conversion, ask why. If it needs to move files across unrelated folders, stop and narrow the task. File paths are the best evidence of what the agent is actually doing.
5. Set least-privilege access rules. Run the app under a normal user account, not an administrator account. Use operating-system permissions to limit the folders it can reach. Keep broader desktop capabilities off unless a specific task requires them. If your organization uses endpoint controls, define rules for the runtime folder, the output folder, and any network access the document workflow needs.

The practical bottom line

The bundled document engine is not a reason to panic, and it is not a reason to assume the app is a safe, self-contained converter. It is a scoped tool that becomes useful when you scope it. Give it a narrow workspace, verify the binaries, test the outputs, watch the paths, and lock down the permissions. Do that, and the local document pipeline can be a genuinely useful part of agent workflows. Do not, and you have built a convenient way for a file-handling agent to wander through your local files.