[BUG] Cowork on Windows corrupts non-ASCII characters when syncing files from sandbox to host filesystem

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?

Description

When Cowork writes files containing non-ASCII characters (en dashes, em dashes, curly quotes, bullets, euro signs, etc.), the files appear correct inside the Cowork sandbox but are corrupted when synced to the Windows host filesystem. Multi-byte UTF-8 sequences are decoded as Windows-1252 single-byte characters, producing classic mojibake.

This causes silent data corruption for any workflow that reads Cowork output files from the host filesystem (e.g., sync agents, scripts, or the user opening files in external editors).

Reproduction

1. Open Cowork on Windows
2. Ask Claude to write a file with special characters:

``
Write a file called encoding-test.txt to your outputs directory with this content:
en dash: –
em dash: —
curly quotes: "hello" 'world'
euro: €
bullet: •
``

1. Claude reads the file back inside Cowork and reports all characters are correct
2. Open the file from the Windows filesystem (e.g., via PowerShell Get-Content)

Expected behavior

File on disk contains valid UTF-8:

en dash: –
em dash: —
curly quotes: "hello" 'world'
euro: €
bullet: •

Actual behavior

File on disk contains mojibake — UTF-8 bytes decoded as Windows-1252:

en dash: â€"
em dash: â€"
curly quotes: “hello†‘world’
euro: €
bullet: •

Analysis

The en dash – (U+2013) is encoded as UTF-8 bytes E2 80 93. These three bytes are being interpreted as three Windows-1252 single-byte characters:

• E2 → â
• 80 → €
• 93 → "

This produces the Unicode string â€" (U+00E2, U+20AC, U+201C), which is then written to the file. The corruption is irreversible without knowing the original encoding.

This is the same class of bug as #29699 (Edit tool mojibake on Windows) and #31295 (Bash tool UTF-8 corruption on Windows), but occurring in a different layer — the mechanism that syncs files from Cowork's sandbox to the host filesystem.

Impact

This is a data corruption bug, not just a display issue. Any external process that reads Cowork output files on Windows receives corrupted data.

Environment

• OS: Windows 10 (Version 10.0.26200.8037)
• Claude Desktop: Installed from standard installer (not Microsoft Store)
• Plan: Max
• Model: Opus 4.6

What Should Happen?

Expected behavior

File on disk contains valid UTF-8:

en dash: –
em dash: —
curly quotes: "hello" 'world'
euro: €
bullet: •

Error Messages/Logs

Steps to Reproduce

Reproduction

1. Open Cowork on Windows
2. Ask Claude to write a file with special characters:

``
Write a file called encoding-test.txt to your outputs directory with this content:
en dash: –
em dash: —
curly quotes: "hello" 'world'
euro: €
bullet: •
``

1. Claude reads the file back inside Cowork and reports all characters are correct
2. Open the file from the Windows filesystem (e.g., via PowerShell Get-Content)

Expected behavior

File on disk contains valid UTF-8:

en dash: –
em dash: —
curly quotes: "hello" 'world'
euro: €
bullet: •

Actual behavior

File on disk contains mojibake — UTF-8 bytes decoded as Windows-1252:

en dash: â€"
em dash: â€"
curly quotes: “hello†‘world’
euro: €
bullet: •

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Cowork

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_