Hey, awesome report. The hex proof and the minimal repro help a lot.
This is a known bug. On Windows with a non-UTF-8 system code page, in your case Korean CP949, the payload read on the Cursor side via PowerShell gets interpreted as ANSI instead of UTF-8. That’s why you see mojibake in stdin. The temp file itself is written as valid UTF-8, it breaks specifically at read time. This is the same class of issue already reported for Chinese and Cyrillic:
- Hook stdin pipe double-encodes non-ASCII on non-UTF-8 Windows
- Windows: Cursor Hooks corrupt Chinese (UTF-8) characters in stdin - replaced with question marks
We’re tracking it, but I can’t share an exact fix timeline yet. I’ll add your case to the existing report. It confirms the issue is still present in 3.6.31.
As a workaround, you can try enabling system-wide UTF-8 in Windows: Region settings → Administrative language settings → Beta: Use Unicode UTF-8 for worldwide language support → reboot. That switches the system code page to UTF-8 65001, and reading should work correctly. This is a system setting, so keep in mind it affects your whole environment, not just Cursor. Let me know if it helps.
I’ll mark this thread as a duplicate of Hook stdin pipe double-encodes non-ASCII on non-UTF-8 Windows so we keep everything in one place.