[BUG] Remote-execution sandbox: LibreOffice cannot load any document — type detection fails for all formats, --convert-to exits 0 with no output

What's Wrong?

In the Claude Code remote-execution ("on the web") worker sandbox, LibreOffice is installed and soffice starts, but its document-load path is completely non-functional: it fails to load any document, of any format, headless. The failure is at LibreOffice's document type-detection stage — both --convert-to and UNO loadComponentFromURL fail there.

This breaks every workflow that shells out to LibreOffice in the sandbox: format conversion, spreadsheet recalculation via a UNO bridge, and the document skills' soffice-backed paths.

Two aggravating factors:

• --convert-to produces no output file yet exits rc=0, so callers that check the exit code see success and fail later, far from the cause.
• The javaldx binary is missing entirely from the image (every run warns failed to launch javaldx), which suggests the LibreOffice install in the sandbox image is incomplete — likely the same packaging problem that broke type detection.

Ruled out during diagnosis:

• Memory / OOM: a single load peaks at ~211 MB RSS against ~15 GB free; no cgroup memory cap (memory.max is the unlimited sentinel); zero kernel OOM-killer events in dmesg.
• Missing shared library: ldd soffice.bin is clean (no "not found"); libmergedlo.so is present (individual libs are merged in — expected for a mergelibs build).
• The JVM: the CSV conversion needs no Java and still fails; capping the heap / clearing JAVA_TOOL_OPTIONS changes nothing.
• Stale profile or lingering process: reproduced with a fresh -env:UserInstallation and no lingering soffice processes.

What Should Happen?

soffice --headless --convert-to pdf on a trivial CSV should produce the PDF. UNO loadComponentFromURL should load the document. If a load fails, soffice should exit non-zero so callers can detect the failure.

Error Messages/Logs

$ printf 'a,b,c\n1,2,3\n' > /tmp/in.csv
$ soffice --headless --nologo --norestore \
    -env:UserInstallation=file:///tmp/lo_profile \
    --convert-to pdf --outdir /tmp/out /tmp/in.csv; echo "rc=$?"
Warning: failed to launch javaldx - java may not function correctly
Error: source file could not be loaded
rc=0

No output file is produced despite the clean exit. The user profile bootstraps fully (registrymodifications.xcu etc. written).

Loading via UNO (python-UNO socket bridge) fast-fails with the same root cause:

com.sun.star.lang.IllegalArgumentException: Unsupported URL <file:///tmp/in.csv>:
"type detection failed" at ./framework/source/loadenv/loadenv.cxx:189

Steps to Reproduce

1. Start a Claude Code remote-execution ("on the web") session.
2. In the sandbox, run:

``bash
printf 'a,b,c\n1,2,3\n' > /tmp/in.csv
soffice --headless --nologo --norestore \
-env:UserInstallation=file:///tmp/lo_profile \
--convert-to pdf --outdir /tmp/out /tmp/in.csv; echo "rc=$?"
ls /tmp/out
``

1. Observe Error: source file could not be loaded, rc=0, and an empty /tmp/out.

The same failure occurs for xlsx→csv, csv→xlsx, and xlsx→pdf, and for every input tested — a plain CSV, a 3-cell openpyxl-generated .xlsx, and a real .xlsx workbook.

Environment

• Claude Code remote-execution worker sandbox (Firecracker microVM), observed 2026-07-20
• LibreOffice 24.2.7.2 420(Build:2); /usr/bin/soffice → /usr/lib/libreoffice/program/soffice (POSIX shell wrapper) → soffice.bin (mergelibs build)
• OpenJDK 21.0.10 present, but javaldx is missing from the image
• ~15 GB RAM free, no cgroup memory cap, ~30 GB disk free

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

N/A — remote-execution worker sandbox image ("Claude Code on the web"); no CLI version visible from inside the sandbox

Platform

Anthropic API

Operating System

Other Linux (sandbox image)

Terminal/Shell

Non-interactive/CI environment

Additional Information

Diagnosis was performed by a Claude managed agent running inside the sandbox, which produced the minimal repro and the ruled-out list above. Because the failure is at the type-detection stage rather than content parsing, it is format-independent, and the clean rc=0 exit masks the breakage from any caller that only checks exit codes — worth keeping in mind for the bundled document skills, whose soffice-backed paths will silently produce nothing in this environment.