This is a known issue with how Cursor’s Agent file write path handles encoding on Windows. Several fixes shipped in recent versions (most recently in March), but based on your report, the GBK-specific variant appears to persist in 3.0.13.
Other users have reported the same class of bug:
Your observation about ACP changes having no effect is consistent with how the encoding path works.
Your detailed reproduction case and workaround script are very helpful. I’ve shared this with our engineering team as an additional data point, specifically highlighting the GBK/zh-CN behavior that persists after the March encoding fixes.
For now, your Python fix script is the best workaround. You might also try creating a fresh workspace with no pre-existing GBK-encoded files to avoid the majority-detection feedback loop.