You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Character encoding of stdin/stdout on Windows is not UTF-8. (It will depend on the Windows locale, but usually CP437 or CP1252.) This breaks JSON, which requires proper Unicode. The Windows Claude Desktop application at least sense UTF-8 encoded data.
To Reproduce
Steps to reproduce the behavior:
Run Claude Desktop on Windows with an MCP server
Send something with an emoji
Observe corruption
Expected behavior
Unicode characters are not corrupted. (MCP clients/servers should be using UTF-8; see additional context below.)
Screenshots
N/A
Desktop (please complete the following information):
OS: Windows 11
Browser: None (Claude Desktop)
Version: ???
Smartphone (please complete the following information):
N/A
Additional context
The JSON spec requires UTF-8, UTF-16, or UTF-32 encoding, so the default behavior on Windows is out of spec. The MCP protocol spec does not specify encoding and has no handshake to establish it, so this leaves some ambiguity, but I think UTF-8 is by far the most reasonable default in the modern era.
Describe the bug
Character encoding of stdin/stdout on Windows is not UTF-8. (It will depend on the Windows locale, but usually CP437 or CP1252.) This breaks JSON, which requires proper Unicode. The Windows Claude Desktop application at least sense UTF-8 encoded data.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Unicode characters are not corrupted. (MCP clients/servers should be using UTF-8; see additional context below.)
Screenshots
N/A
Desktop (please complete the following information):
Smartphone (please complete the following information):
N/A
Additional context
The JSON spec requires UTF-8, UTF-16, or UTF-32 encoding, so the default behavior on Windows is out of spec. The MCP protocol spec does not specify encoding and has no handshake to establish it, so this leaves some ambiguity, but I think UTF-8 is by far the most reasonable default in the modern era.
I have put up a PR with a fix: #198
The text was updated successfully, but these errors were encountered: