Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
I am writing to report a critical encoding issue regarding Korean character corruption in the Cursor Chat and Composer interfaces following the most recent update.
Currently, Korean text is frequently breaking and displaying as replacement characters (, U+FFFD) within the Composer window. I have already attempted the standard troubleshooting steps, including modifying my settings.json to enforce UTF-8 and adding Korean encoding fallbacks:
JSON
“files.autoGuessEncoding”: true,
“files.candidateGuessEncodings”: [“utf8”, “korean”, “cp949”],
“files.encoding”: “utf8”
Despite these configurations, the issue persists. Through further testing, I have identified a few key behaviors that point to a bug in the recent patch rather than a local environment issue:
Agent-Specific Issue: The character corruption seems to be specifically tied to certain agents (e.g., Composer 2). When I switch to a different AI agent within Cursor, the Korean text renders perfectly fine.
Cross-Device Persistence: I am experiencing the exact same text corruption issue across multiple different PCs.
Recent Update Trigger: This issue only began occurring immediately after applying the latest Cursor version upgrade.
Given that the text renders correctly when switching agents and occurs across multiple machines, it is highly likely that the recent patch introduced a regression in how the Composer agent internally handles or streams UTF-8 encoding for non-Latin characters.
This significantly impacts the workflow for Korean users. I strongly request that your team investigate the text decoding/encoding pipeline for the Composer agent and deploy a hotfix patch to resolve this as soon as possible.
Steps to Reproduce
Open Cursor IDE on a Windows environment.
Use the “Composer” or “Chat” feature with an agent (specifically Composer 2).
Open or reference a file containing Korean characters (UTF-8 or CP949 encoded).
Ask the agent to analyze or edit the code involving Korean comments or strings.
Observe that Korean characters in the chat response or the diff view are replaced with replacement characters (, U+FFFD).
Note: This occurs even when “Files: Auto Guess Encoding” is enabled and the default encoding is set to UTF-8 in settings.json.
Expected Behavior
Regardless of the selected AI agent (e.g., Composer 2), all Korean characters in the Chat, Composer, and Diff view should be rendered correctly in UTF-8 without any corruption or replacement characters ().
The IDE should consistently respect the encoding settings and properly decode the stream of text from the AI, ensuring that multi-byte characters like Korean Hangeul are displayed as intended, just as they do when switching to other stable agents.
Screenshots / Screen Recordings
Operating System
Windows 10/11
Version Information
Version: 3.0.16 (user setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
OS: Windows_NT x64 10.0.26200
For AI issues: which model did you use?
Comporser 2.0, 1.5
For AI issues: add Request ID with privacy disabled
f3074280-ce8e-4dea-8512-fc12fd4913b6
Additional Information
“Other users have reported that this issue only occurs with ‘Composer 2 Fast’ and switching to other models resolves it. However, in my current environment, I don’t have any other options available except for the ‘Fast’ model. This means I am completely stuck with this encoding bug and cannot use the workaround.” Critical Issue: The documents and code explanations generated by Cursor are completely unreadable because all Korean characters are corrupted into replacement characters (). This makes it impossible to understand the logic or instructions provided by the AI, rendering the documentation features effectively useless for Korean-speaking users.This issue seems to be model-specific. While it occurs frequently with Composer 2, switching to other models sometimes resolves the character corruption, suggesting a regression in how specific agents handle stream encoding.
I have confirmed this behavior across multiple workstations with different hardware configurations, but all running Windows with the latest Cursor update.
Standard encoding fixes (Auto Guess Encoding, manual UTF-8 settings) do not resolve the corruption in the chat/composer UI, even when the underlying source files are correctly encoded.
This started happening immediately after the most recent update (Version 3.0.16).
Does this stop you from using Cursor
Yes - Cursor is unusable