[BUG] Platform File Ingestion Lossy Conversion

Resolved 💬 2 comments Opened Mar 18, 2026 by rulesr-alt Closed Mar 21, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Opus 4.6, running in the claude.ai Project interface with computer use (file creation) enabled. The bug is in the Project Files upload pipeline specifically, not the CLI, so the relevant product surface is claude.ai Projects (the knowledge base file ingestion layer). The behavior is that .docx files uploaded to Project Files are silently converted from Office Open XML (ZIP archive) to plain-text markdown, discarding comments.xml, tracked changes, styles, images, and all other non-body-text XML content, while retaining the original .docx filename extension.

.docx files uploaded to Project Files are silently converted to plain-text markdown. The original .docx filename and extension are preserved, but the file content is UTF-8 text, not a ZIP archive. The file command reports "Unicode text, UTF-8 text" instead of "Microsoft Word 2007+". All content stored outside word/document.xml body text is permanently lost, including word/comments.xml (reviewer comments), tracked changes, embedded images, styles, headers/footers, and document metadata. Neither the user nor the agent receives any indication that conversion occurred.

Symptom:
Agent reads a .docx file from /mnt/project/ and finds plain-text markdown content despite the .docx extension. The file command reports "Unicode text, UTF-8 text" instead of "Microsoft Word 2007+". Reviewer comments, tracked changes, embedded images, styles, headers/footers, and all other Office XML content are absent. Agent may not detect the loss and proceed as though the file is complete.
Root Cause:
The Claude Project Files ingestion pipeline extracts body text from uploaded .docx files and stores the result as plain-text markdown, discarding the ZIP/XML structure. The original filename and extension are preserved, creating a false signal that the binary is intact.
Affected File Types (confirmed): .docx. Likely also .xlsx, .pptx, and other Office Open XML formats (unconfirmed as of March 2026).Impact: Loss of reviewer comments (Pink Team, Red Team, color team feedback), tracked changes, document metadata, embedded graphics, and any content stored outside word/document.xml body text. Agent builds on incomplete source material without awareness of the gap. Particularly severe for proposal review cycles where comments are the primary deliverable.

What Should Happen?

Project Files should either (a) preserve uploaded .docx files as intact binary ZIP archives so agents can access the full Office Open XML structure (comments, tracked changes, styles, images, metadata) using standard tools like unzip or the docx skill's unpack.py, or (b) if lossy conversion is intentional, clearly indicate to the user at upload time that XML packaging will be stripped, and rename/re-extension the file (e.g., .md or .txt) so the agent can distinguish converted files from intact binaries.

Error Messages/Logs

The Claude agent claims that the source docx file is a UTF-8 text file with no XML.

Steps to Reproduce

  1. Create or open a .docx file in Microsoft Word containing at least one reviewer comment (Insert > New Comment) and some body text
  2. Save the file
  3. Open a Claude Project in claude.ai
  4. Upload the .docx file to Project Files (the project knowledge base, not as a chat attachment)
  5. Start a new conversation in the project
  6. Ask the agent to run: file /mnt/project/[filename].docx
  7. Observe the output reports "Unicode text, UTF-8 text" instead of "Microsoft Word 2007+"
  8. Ask the agent to run: head -c 50 /mnt/project/[filename].docx
  9. Observe plain-text markdown content instead of a PK ZIP signature
  10. Ask the agent to extract comments using the docx skill's unpack.py - it fails with "not a valid Office file"

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Opus 4.6, running in the claude.ai Project interface with computer use (file creation) enabled

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗