[BUG] present_files tool intermittently serves incomplete DOCX artifact on first call for small files (~13KB)

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?

DOCX files (~13 KB) generated via Claude computer-use tools and served via present_files intermittently fail to open in Word and Pages on the client side. The failure mode has two variants:

1. Initial-load failure: "Failed to load document" on the first download attempt. The file on disk is structurally valid throughout — ZIP integrity passes, LibreOffice converts it cleanly to PDF, XML parses without error. A second call to present_files with the same unchanged file path sometimes succeeds.

1. Flash-then-fail: The document preview briefly renders (visible for ~1 second), then the viewer switches to "Failed to load document." This suggests the file is successfully fetched and partially rendered before the stream is interrupted or an error state is set.

What Should Happen?

DOCX files presented via present_files should open reliably on every call when the file on disk is structurally valid. The expected behavior is consistent with PDF artifacts, which never fail in the same session under identical conditions.

Error Messages/Logs

Client-side: "Failed to load document"

No error output from the file generation side. LibreOffice conversion succeeds:
  convert output.docx as a Writer document → output.pdf using filter: writer_pdf_Export
  Exit: 0

Python zipfile.testzip(): None (all entries clean)
xml.etree.ElementTree.fromstring(document.xml): no ParseError
All ZIP entries: compress_type=8 (deflate), all entries readable

File characteristics at time of failure:
  Size:             12,989 bytes
  ZIP entries:      18
  document.xml:     31,813 bytes uncompressed, 5,574 bytes compressed
  Permissions:      0o100644
  MD5 (unchanged):  c04ded3d9506e2a471aba72bdf740b8d across multiple present_files calls

Steps to Reproduce

1. In a Claude computer-use session, generate a DOCX file via docx-js (Node):

const buf = await Packer.toBuffer(doc);
fs.writeFileSync('/mnt/user-data/outputs/output.docx', buf);

1. Verify the file is structurally valid:

python -c "import zipfile; z=zipfile.ZipFile('output.docx'); print(z.testzip())"
→ None

1. Call present_files with the output path:

present_files(["/mnt/user-data/outputs/output.docx"])

1. Download the DOCX artifact from the claude.ai interface.

1. Attempt to open in Microsoft Word or Apple Pages.

Observed: "Failed to load document" on approximately 30–40% of first-call downloads.
Workaround attempted: re-writing the file to itself (shutil.copy2 to force mtime update) then re-calling present_files — inconsistent results.

Consistent observation across this session: PDF artifacts generated from the same DOCX source via LibreOffice headless (present_files with a .pdf path) open successfully on every call. The failure is specific to the DOCX MIME type (application/vnd.openxmlformats-officedocument.wordprocessingml.document).

Additional pattern: the "flash-then-fail" variant (preview renders ~1s then fails) suggests the file content is successfully transferred but the serving layer raises an error mid-stream or post-render.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — this is the first session where we systematically observed and root-caused it. The pattern may be pre-existing but previously attributed to "corrupted files" on the generation side. After ruling out all file-side causes, the failure is confirmed to be in the present_files serving layer.

Claude Code Version

v2.1.173

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Session context: observed across 5+ DOCX artifacts in a single session. Each file passed all structural validation. PDF versions of each file never failed. DOCX files that initially failed sometimes opened on retry without any change to the file.

Hypothesis: present_files is initiating the download stream before the output filesystem write is fully flushed/synced on first call — the file is valid on disk but the download is served from a partially-written page cache. Re-presenting after a delay resolves it because the flush has completed.

Alternative hypothesis for the flash-then-fail variant: the artifact viewer successfully fetches the DOCX, begins rendering, but the serving layer times out or closes the connection mid-stream, causing the viewer to fall back to an error state.

A same-session comparison:

• 5 DOCX files presented → 3–4 initial failures
• 5 PDF files presented → 0 failures
• File content identical (PDF generated from DOCX via LibreOffice)