[Bug] Files with .odt extension are silently corrupted on download — binary file transcoded as UTF-8 text #1256

Summary

Any .odt file (OpenDocument Text) that an agent creates in Z.ai web chat arrives corrupted when the user downloads it: the file grows in size and is no longer a valid ZIP/ODF container. Byte-level forensics prove the download pipeline treated this binary file as UTF-8 text and replaced every invalid byte with U+FFFD (REPLACEMENT CHARACTER).

Other binary formats — .docx, .pdf, .zip — download byte-identical and are not affected.

Environment

• Client: Z.ai web chat (browser), Windows 10
• Date observed: 2026-10-27
• Affected file type: .odt (MIME application/vnd.oasis.opendocument.text)

Steps to reproduce

1. Ask the agent to create any .odt file (e.g. "generate a report as .odt") and download it from the chat.
2. Compare the downloaded file with the original produced by the agent (size / md5).
3. Try to open it in LibreOffice / OpenOffice — it fails; unzip -t reports a broken archive ("Bad offset for central directory").

Expected result

The downloaded file is byte-identical to the original. ODT is a ZIP container and must be transferred as binary.

Actual result

The file is silently corrupted in transit:

Forensic evidence

Byte-level comparison of the downloaded copy identifies the exact transformation:

downloaded == original_bytes.decode('utf-8', errors='replace').encode('utf-8')

• The equality is exact (same md5), so the transport ran the binary through a UTF-8 text transcoding path.
• 77,573 bytes were invalid UTF-8 and were each replaced with U+FFFD (EF BF BD), inflating the file by ~82% and destroying the ZIP structure.
• The same .odt packed inside a .zip attachment arrives byte-identical — the file itself is valid; only the loose-.odt download path is broken.

Probable root cause

The MIME type application/vnd.oasis.opendocument.text contains the substring text, so the transport likely classifies .odt as a text file and applies text processing. Consistent with this: .docx (application/vnd.openxmlformats-officedocument.wordprocessingml.document) and .pdf (application/pdf) do not contain text in their MIME type and pass through unchanged.

Suggested fix

Treat attachments as opaque binary by default. If a text-detection heuristic is needed, restrict it to text/* plus a whitelist of known text formats (.txt, .md, .csv, .json, …) — and explicitly exclude binary container types such as application/vnd.oasis.opendocument.*. Never apply errors='replace' transcoding to file downloads.

Workaround for users

Pack .odt (and any binary file) into a .zip wrapper — zip attachments survive the transfer untouched.

Impact

Silent data corruption: the file looks normal in the chat UI, but the downloaded copy is unusable. Users who don't verify checksums lose their documents without noticing.

Suggested labels: type: Bug · category: file operations · severity: affects experience