Hey, thanks for the detailed report. The byte-level breakdown really helps.
This is a known issue with hooking stdin on Windows. When Cursor uses Windows PowerShell 5.1, a BOM-less UTF-8 payload gets read using the system ANSI code page GBK on Chinese Windows. That causes mojibake, and then a UTF-8 BOM gets added on output EF BB BF. What you’re seeing is exactly that, and it’s not an issue with your hook script.
A workaround that fixes both issues is to install PowerShell 7 pwsh and make sure it’s in PATH. Cursor prefers pwsh over powershell.exe, and PowerShell 7 defaults to UTF-8 without BOM, so both the mojibake and the BOM go away.
As an alternative, you can enable the Windows system beta setting Use Unicode UTF-8 for worldwide language support in Region settings → Administrative → Change system locale. That switches the ANSI code page to UTF-8. Just note this affects all legacy apps system-wide, so using pwsh is usually safer.
We’re tracking the issue already. I can’t share an ETA yet, but I’ll reply in the thread if there’s an update. If you still see mojibake after installing pwsh, let me know and we’ll dig in further.
Related threads on the same topic if you’re interested: Hook stdin pipe double-encodes non-ASCII on non-UTF-8 Windows, On Windows, Cursor’s hook stdin JSON payload includes a UTF-8 BOM that breaks standard JSON.parse(), causing security guards to silently degrade to allowing commands across all agent channels