[tanishqbaweja]

Problem

windows-mcp install writes ~/.windows-mcp/start-server.cmd as UTF-8, but cmd.exe decodes a batch file with the console code page. When the Windows profile folder name has non-ASCII characters (a local account such as C:\Users\José or C:\Users\张三), the log paths in the script, and the interpreter path when it lives under the profile, come out garbled: with code page 437 José is read as José, with 936 张三 is read as 寮犱笁. cmd then fails on the log redirection with The system cannot find the path specified., the server never starts, and neither server.log nor server.error.log is created. install still prints Scheduled task installed — server is starting now. and points at server.log, and the error itself goes to the task's hidden console, so the user has nothing to go on.

Reproduced on Windows 11 with OEM code page 437, at 28dd6a7, without registering a task:

1. Ran install --transport sse --host 127.0.0.1 --port 9000 through click's CliRunner with _schtasks and _register_task_powershell stubbed, CONFIG_DIR and the script path in a folder named José (then 张三), and _resolve_program returning the interpreter plus a stand-in script that prints its arguments.
2. Ran the generated script like the task does, cmd.exe /d /c "<script>" (/d skips AutoRun), in a console of its own (CREATE_NO_WINDOW).

Before: exit code 1, The system cannot find the path specified., no log files. After: exit code 0, and server.log contains serve --transport sse --host 127.0.0.1 --port 9000.

It fails the same way when the console is switched to 850 or 936 before the script runs, and the old script works when the console is already on 65001.

Related: #502 (for #493) fixed how install decodes schtasks and PowerShell output on zh-CN systems. This is a different problem, in the script that install writes.

Fix

One line in _build_start_script(): chcp 65001 >nul right after @echo off. cmd decodes each line when it reaches it, so the lines after it are read as UTF-8, the encoding the file is written in. The activate.bat that venv and virtualenv generate does the same for the same reason.

Writing the file in the OEM code page instead is not enough: 张三 cannot be encoded in code page 437 or 850 at all.

Side effects: the code page change applies only to the console the task gives the script (conhost --headless). The server's own output goes to the log files. Inside the server, child output is only read through the PowerShell executor, which starts each child with CREATE_NO_WINDOW (so it gets its own console) and already forces UTF-8. install and uninstall are unchanged. Existing installs keep the old script until windows-mcp install --force rewrites it.

Tests

• New tests/test_install_start_script_encoding.py: runs install (schtasks and task registration stubbed) for a José and a 张三 profile folder with a stand-in for the server, then runs the generated script with cmd.exe /d /c without a window and checks the arguments in server.log. Both cases fail on main with The system cannot find the path specified. and pass with this change.
• tests/test_startup_task.py (3 passed), tests/test_install_hidden_console.py (2), tests/test_install_console_encoding.py (2), tests/test_cli_legacy_flags.py (11) and tests/test_cli_paired_flags.py (5): same results on main and on this branch.
• ruff check and ruff format --check are clean on the changed files.

Running the script through the task's own action, conhost.exe --headless cmd.exe /c "<script>", outside Task Scheduler gives the same result before and after (conhost exits with 0 even when the script fails).

Not tested: the real scheduled task at logon (I did not register one on my machine), and a real zh-CN system; code page 936 was simulated with chcp 936.