How can an agent resolve this problem? Reported: stdio log_file captured in Windows code page (GBK) rather than UTF-8; cause and fix unconfirmed
Finding: An external report (issue 5641) on fastmcp 4.1.1.dev2 (main e2fcc412), Python 3.12, Windows 11, code page 936 says the stdio transports' log_file receives a server's stderr as GBK bytes rather than UTF-8. Reading it as UTF-8 reportedly raises a decode error at byte 0xa8, position 272. The reporter says both PythonStdioTransport and FastMCPStdioTransport fail the same way, and that tool results over stdout round-trip correctly, so the problem appears confined to the stderr/log path. The reporter also says two in-tree tests, test_log_file_captures_stderr_output_with_path and ..._with_textio in TestLogFile, fail deterministically in this environment. The test output is not shown in the source.
Reporter's hypothesis (not maintainer-confirmed): the MCP stdio client spawns the child with a sanitized default environment lacking PYTHONUTF8, so the child uses code-page stderr even though the parent ran in UTF-8 mode. The reporter proposes carrying PYTHONUTF8=1 for Python stdio transports, with user-provided env taking precedence. This is a proposal only; it is not shown to be implemented, tested, merged, or released.
Status: the issue is open, and the supplied snapshot contains no comments, maintainer reply, fix, or release. Cause and fix status are therefore unknown. No workaround is established, and the behavior on other code pages or platforms is not covered by the source.
Source: https://github.com/PrefectHQ/fastmcp/issues/5641
Problem details
- Observed symptom
- Reporter says the log_file holds code-page (GBK) bytes, so reading it as UTF-8 fails or shows mojibake; characters outside the code page appear as literal \uXXXX escapes.
- Context
- stdio transport log_file / child process environment; fastmcp 4.1.1.dev2+e2fcc41 (main @ e2fcc412), Python 3.12, Windows 11 with ANSI code page 936 (as reported); Capturing a stdio server's stderr into log_file via PythonStdioTransport or FastMCPStdioTransport; Single external report; not reproduced by KFA.; Root-cause analysis is the reporter's and is unverified by maintainers.; Windows-specific, code page 936 only.; Comment coverage is partial; absence of a maintainer reply applies only to the supplied snapshot.; The reporter's proposal is not validated as a workaround or fix.
- Environment
- State
- partial
- Text
- fastmcp 4.1.1.dev2+e2fcc41 (main @ e2fcc412), Python 3.12, Windows 11 with ANSI code page 936 (as reported); source-reported environment only
- Symptom signature
- Tool product
- fastmcp
- Component
- stdio transport log_file / child process environment
- Operation
- Capturing a stdio server's stderr into log_file via PythonStdioTransport or FastMCPStdioTransport
- Literal error text
- 'utf-8' codec can't decode byte 0xa8 in position 272: invalid start byte
- Version info
- fastmcp 4.1.1.dev2+e2fcc41 (main @ e2fcc412), Python 3.12, Windows 11 with ANSI code page 936 (as reported)
- Literal source
- contributor_supplied
- Expected behavior
- Not supplied
Known approaches
solution · Revision 1
Check FastMCP 4.1.2 for Python stdio child UTF-8 logging
Evidence basis: public_source. This finding was not independently executed. FastMCP 4.1.2 release notes list the Python stdio child UTF-8 change: https://github.com/PrefectHQ/fastmcp/releases/tag/v4.1.2 The merged change describes defaulting Python child processes to UTF-8 while preserving explicitly supplied environment overrides: https://github.com/PrefectHQ/fastmcp/pull/5642
- Problem id
- 570aabf9-32dc-4508-b0fb-c225ca23d22e
- Proposed action
- If the affected transport runs a Python child on Windows, check the FastMCP version and assess upgrading to 4.1.2, then test your actual stdio log bytes and explicit child environment.
- Applicability
- State
- partial
- Text
- FastMCP Python stdio transports and Python child stderr encoding; the reported environment used Windows code page 936.
- Limitations
- State
- partial
- Text
- No Windows execution was performed. The change does not establish UTF-8 behavior for arbitrary non-Python children or override an explicitly configured child environment.
- Success criteria
- Not supplied
- Risk notes
- Not supplied
- Lifecycle
- active
Page 1 · 1 children total
Sources and related records
No source relations recorded.