[MODEL]

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude modified files I didn't ask it to modify

What You Asked Claude to Do

I uploaded a Microsoft Word document (.docx) containing reviewer comments (Word comments stored in word/comments.xml within the Office Open XML ZIP structure) to a Claude Project's Project Files (knowledge base). In a subsequent conversation within that Project, I asked Claude to extract and analyze the reviewer comments from the document.

What Claude Actually Did

I uploaded a Microsoft Word document (.docx) containing reviewer comments (Word comments stored in word/comments.xml within the Office Open XML ZIP structure) to a Claude Project's Project Files (knowledge base). In a subsequent conversation within that Project, I asked Claude to extract and analyze the reviewer comments from the document.What Claude Actually DidClaude read the file from /mnt/project/ and processed it as though it contained the full document content. However, the file had been silently converted during the Project Files upload pipeline from a valid Office Open XML ZIP archive to plain-text UTF-8 markdown. The file command on the uploaded document returned Unicode text, UTF-8 text, with very long lines instead of Microsoft Word 2007+. The first bytes of the file were | Proposal to Provide: (markdown text) instead of the expected PK ZIP signature. Claude's docx skill unpack.py tool failed with "not a valid Office file" because the ZIP structure no longer existed.All content stored in the Office XML package outside of word/document.xml body text was permanently lost during ingestion, including:

word/comments.xml (83 reviewer comments from 5 authors)
Tracked changes
Document styles (word/styles.xml)
Headers and footers
Embedded images (word/media/)
Document metadata
The original .docx filename and extension were preserved on the converted file, providing no indication to either the user or the agent that conversion had occurred.

Expected Behavior

Project Files should either:

Preserve the uploaded file as an intact binary so agents can access the full Office Open XML structure using standard tools (unzip, the docx skill's unpack.py, etc.), OR
If lossy text extraction is intentional, clearly indicate to the user at upload time that XML packaging will be stripped, and change the file extension (e.g., to .md or .txt) so agents can programmatically distinguish converted files from intact binaries.

The current behavior — silently performing lossy conversion while preserving the original extension — is the worst outcome because neither the user nor the agent has any signal that data was lost.

Files Affected

Uploaded file: (can't share this docx because of sensitivity)
Project Files location (lossy): (can't share this docx because of sensitivity)
Chat attachment location (intact): (still can't share this docx because of sensitivity)

The same source file uploaded via two different paths produced two different results: Project Files stripped the binary, chat attachment preserved it.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. Create a .docx file in Microsoft Word containing at least one reviewer comment (Insert > New Comment) and some body text. Save the file.
2. Open a Claude Project in claude.ai.
3. Upload the .docx file to Project Files (the project knowledge base).
4. Start a new conversation in the Project.
5. Ask Claude to run: file /mnt/project/[filename].docx
6. Observe: Output reports Unicode text, UTF-8 text instead of Microsoft Word 2007+.
7. Ask Claude to run: head -c 4 /mnt/project/[filename].docx | od -A x -t x1z
8. Observe: First bytes are plain text (e.g., 7c 20 2a 2a), not the ZIP signature (50 4b 03 04).
9. Ask Claude to extract comments using the docx skill: python scripts/office/unpack.py /mnt/project/[filename].docx unpacked/
10. Observe: Fails with "not a valid Office file."
11. Now upload the same file as a chat attachment (drag into message field).
12. Ask Claude to run: file /mnt/user-data/uploads/[filename].docx
13. Observe: Output reports Microsoft Word 2007+ — binary preserved.
14. Ask Claude to unpack the chat attachment version — succeeds, comments extracted.

Claude Model

Opus

Relevant Conversation

Agent's diagnostic output during the session:
$ file /mnt/project/...Pink_Team_Feedback_v2.docx
Unicode text, UTF-8 text, with very long lines (1541)

$ file /mnt/user-data/uploads/...Pink_Team_Feedback_v2.docx
Microsoft Word 2007+

$ python scripts/office/unpack.py /mnt/user-data/uploads/...Pink_Team_Feedback_v2.docx unpacked/
Unpacked (40 XML files), simplified 6 tracked changes, merged 538 runs
The Project Files version was confirmed to start with markdown text (| **Proposal to Provide:**), while the chat attachment version started with a valid ZIP header and unpacked successfully into 40 XML files including word/comments.xml containing all 83 reviewer comments.

Impact

High - Significant unwanted changes

Claude Code Version

claude.ai (web interface), Claude Projects with computer use (file creation) enabled. Model: Claude Opus 4.6.

Platform

Other

Additional Context

Pattern: This appears to affect all .docx files uploaded to Project Files, not just files with comments. Multiple .docx files in the same project (proposal drafts, past performance documents, planning documents) all showed the same Unicode text, UTF-8 text signature when checked with the file command.
Likely scope: The conversion is probably not limited to .docx. Other Office Open XML formats (.xlsx, .pptx) are also ZIP archives and may be subject to the same text extraction pipeline. In this project, .xlsx files in Project Files also appeared to be converted (unconfirmed whether formula/sheet structure was lost, but the pipeline behavior would be consistent). I have not tested .pptx.
Workaround: Upload files requiring binary preservation as chat attachments (which land in /mnt/user-data/uploads/ as intact binaries) rather than adding them to Project Files. This is a viable per-session workaround but defeats the purpose of Project Files as a persistent knowledge base, since chat attachments are session-scoped.
Session continuity impact: Because the workaround requires chat attachment upload, the intact binary is only available in the session where it was attached. Subsequent sessions in the same Project only have access to the lossy Project Files version, meaning the data loss recurs across sessions unless the user re-uploads the attachment every time.