macOS: bundled LibreOfficeDev.app registers with Launch Services, claiming Owner rank on ODF types and appearing in Open With

What version of the Codex App are you using?

26.810.52044 (build 6662)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS 26.6.2, build 25G83)

What issue are you seeing?

The Codex runtime installs a full LibreOffice application bundle into the user cache:

~/.cache/codex-runtimes/codex-primary-runtime/dependencies/native/libreoffice-headless/libreoffice/LibreOfficeDev.app

macOS Launch Services indexes any .app under the user's home, so this bundle registers as a normal installed application. Its Info.plist declares 27 CFBundleDocumentTypes entries, all with CFBundleTypeRole: Editor, covering 71 UTIs in total.

Two consequences follow.

Open With clutter. The 3rd party formats entry claims 43 UTIs at LSHandlerRank: Alternate, including CSV, plain text, PNG, JPEG, TIFF, RTF, HTML, and the full Word, Excel, and PowerPoint sets. "LibreOfficeDev.app" now appears in Finder's Open With menu for a large fraction of everyday files. I never installed LibreOffice and could not tell where the entry came from until I dumped the Launch Services database.

Owner rank on ODF. The other 25 entries claim LSHandlerRank: Owner, covering every OpenDocument and OpenOffice.org type (.odt, .ods, .odp, .odg, .odb, templates, Flat ODF, and the LibreOfficeDev extension type). A cached alpha build can therefore become the system default handler for those formats, which is more than a cosmetic menu entry.

Confirmation from lsregister -dump:

/Users/<user>/.cache/codex-runtimes/codex-primary-runtime/dependencies/native/libreoffice-headless/libreoffice/LibreOfficeDev.app
/Users/<user>/.cache/.../LibreOfficeDev.app/Contents/PlugIns/QuickLookPreview.appex
/Users/<user>/.cache/.../LibreOfficeDev.app/Contents/PlugIns/QuickLookThumbnail.appex

The bundle also carries two QuickLook app extensions, so it registers Finder preview and thumbnail providers as well.

For CSV, the bundle imports the UTI and binds the extension:

{
 "UTTypeIdentifier": "org.libreoffice.csv-document",
 "UTTypeDescription": "Comma-Separated Value Document",
 "UTTypeTagSpecification": {
  "public.mime-type": ["text/csv"],
  "public.filename-extension": ["csv"]
 }
}

Runtime metadata, for reference:

{ "bundleFormatVersion": 2, "bundleVersion": "26.601.10930",
  "nativeDependencies": ["libreoffice-headless", "poppler"],
  "targetArch": "arm64", "targetPlatform": "darwin" }

{ "name": "libreoffice-headless", "version": "25.2-headless-codex.1",
  "targetPlatform": "darwin", "targetArch": "arm64" }

The bundle reports itself as LibreOfficeDev 26.8.0.0 and occupies 408 MB.

What steps can reproduce the bug?

1. Install the Codex App on macOS and let it provision codex-primary-runtime (the Documents plugin pulls libreoffice-headless).
2. Right-click any .csv, .docx, .png, or .txt file in Finder and open the Open With submenu.
3. "LibreOfficeDev.app" is listed, despite LibreOffice never having been installed by the user.

To see the registration directly:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump \
  | grep -o "[^ \"]*LibreOffice[^ \"]*" | sort -u

To see the rank distribution:

A=~/.cache/codex-runtimes/codex-primary-runtime/dependencies/native/libreoffice-headless/libreoffice/LibreOfficeDev.app
plutil -extract CFBundleDocumentTypes json -o - "$A/Contents/Info.plist" | python3 -c "
import json,sys
from collections import Counter
d=json.load(sys.stdin)
print(Counter(t.get('LSHandlerRank') for t in d))"

Output here: Counter({'Owner': 25, 'Alternate': 2}).

What is the expected behavior?

A headless conversion backend should not register as a document handler.

The dependency is named libreoffice-headless and is used only for background conversion, so the document type claims and the QuickLook extensions serve no purpose in this code path. Some options, roughly in order of how well they contain the problem:

• Ship the conversion backend as a plain directory tree rather than an .app bundle, invoking soffice by absolute path. This is the only fix that also stops the QuickLook extensions from registering.
• Strip CFBundleDocumentTypes, UTImportedTypeDeclarations, UTExportedTypeDeclarations, and Contents/PlugIns at packaging time.
• Set LSBackgroundOnly and drop the document type claims, so the bundle stays launchable but stops advertising itself.

The Owner-rank claims on ODF types are the part I would prioritize, since those can change a user's defaults rather than just lengthen a menu.

Additional information

Both the Codex App and the Codex CLI (codex-cli 0.152.0) are installed on this machine, and the runtime lives at the shared ~/.cache/codex-runtimes path, so I cannot say from the outside which surface provisioned it.

lsregister -u <path> clears the entry, but the bundle stays on disk and the user cannot delete it without breaking the Documents plugin.

The same bundle path appears in #27797 and #32968, which cover choosing a system LibreOffice and configuring host fonts. This report is about the packaging of the bundled copy itself, which affects every user regardless of whether they have their own LibreOffice.

Start by tracing provisioning of ~/.cache/codex-runtimes/codex-primary-runtime/dependencies/native/libreoffice-headless and inspect the bundled LibreOfficeDev.app packaging, especially Contents/Info.plist and Contents/PlugIns. Use lsregister -dump to confirm the document and QuickLook registrations, then verify that headless conversion still works while the bundle no longer registers as a document handler.