[BUG]Korean characters broken (encoding issue) in Composer/Agent

joshwang · April 10, 2026, 6:20pm

Feature request for product/service

AI Models

Describe the request

Issue: Korean text renders as garbled characters (diamond question marks) only when using Composer 1.5 and 2. GPT-5.4 works fine.

Request ID: 8090d3c5-5e52-478e-be2b-1ed0bbbc03e6

Details: This seems to be a streaming encoding issue specific to the Composer/Agentic models. Please fix the character encoding for Korean users.

Where does the bug appear (feature/product)?

Cursor IDE
Cursor CLI
Background Agent (GitHub, Slack, Web, Linear)
BugBot
Somewhere else…

Describe the Bug
Critical encoding issue where Korean characters are rendered as replacement symbols () or broken text. This issue occurs specifically and consistently in Composer 1.5 AND Composer 2 during streaming responses. Other models like GPT-5.4 or Gemini 3.1 Pro do not have this issue.

Steps to Reproduce
Set the model to Composer 1.5 AND Composer 2.

Input a prompt in Korean or request an explanation for code containing Korean comments.
The AI response starts streaming with broken Korean characters (as seen in the attached screenshot)
Changed files.encoding to utf8 in settings.json.
Set locale to ko in argv.json.
Reinstalled Cursor and cleared the cache.
Tested in different modes (Side panel vs. Ctrl+I window).
Result: None of the above fixed the issue for Composer 1.5/2.

Expected Behavior
Full support for UTF-8 encoding in Korean, providing readable text without any garbled characters.

Screenshots / Screen Recordings

Operating System

Windows 10/11
MacOS
Linux

Version Information

Version: 3.0.16 (system setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Composer 1.5 AND Composer 2

For AI issues: add Request ID with privacy disabled
Request ID:

f9a7046a-279b-47e5-ab48-6e8dc12daba1
090d3c5-5e52-478e-be2b-1ed0bbbc03e6

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue

system · April 10, 2026, 6:20pm

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

Cursor IDE
Cursor CLI
Background Agent (GitHub, Slack, Web, Linear)
BugBot
Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

…
…
…

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

Windows 10/11
MacOS
Linux

Version Information

For Cursor IDE: Menu → About Cursor → Copy
For Cursor CLI: Run agent about in your terminal

IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

joshwang · April 11, 2026, 5:38am

Feature request for product/service

AI Models

Describe the request

Issue: Korean text renders as garbled characters (diamond question marks) only when using Composer 1.5 and 2. GPT-5.4 works fine.

Request ID: 8090d3c5-5e52-478e-be2b-1ed0bbbc03e6

Details: This seems to be a streaming encoding issue specific to the Composer/Agentic models. Please fix the character encoding for Korean users.

Where does the bug appear (feature/product)?

Cursor IDE
Cursor CLI
Background Agent (GitHub, Slack, Web, Linear)
BugBot
Somewhere else…

Describe the Bug
Critical encoding issue where Korean characters are rendered as replacement symbols () or broken text. This issue occurs specifically and consistently in Composer 1.5 AND Composer 2 during streaming responses. Other models like GPT-5.4 or Gemini 3.1 Pro do not have this issue.

Steps to Reproduce
Set the model to Composer 1.5 AND Composer 2.

Input a prompt in Korean or request an explanation for code containing Korean comments.
The AI response starts streaming with broken Korean characters (as seen in the attached screenshot)
Changed files.encoding to utf8 in settings.json.
Set locale to ko in argv.json.
Reinstalled Cursor and cleared the cache.
Tested in different modes (Side panel vs. Ctrl+I window).
Result: None of the above fixed the issue for Composer 1.5/2.

Expected Behavior
Full support for UTF-8 encoding in Korean, providing readable text without any garbled characters.

Screenshots / Screen Recordings

Operating System

Windows 10/11
MacOS
Linux

Version Information

Version: 3.0.16 (system setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Composer 1.5 AND Composer 2

For AI issues: add Request ID with privacy disabled
Request ID:

f9a7046a-279b-47e5-ab48-6e8dc12daba1
090d3c5-5e52-478e-be2b-1ed0bbbc03e6

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue

deanrie · April 11, 2026, 6:12am

Hey, thanks for the detailed bug report. I can see the screenshot with garbled Korean characters, so the issue is clear.

This is a known bug that affects CJK languages like Korean, Japanese, and Thai when using Composer models. We’ve gotten a few similar reports over the last few days:

Composer 2 Fast: Korean UTF-8 broken in chat and agent edits (Composer 2 OK)
Thank you for Cursor - Japanese text gets garbled in Composer 2 Fast, but renders correctly in regular Composer and GPT
Unicode (Thai) garbled in Composer 1.5/2 and sometimes on Auto

I’ve passed this to the team along with your Request IDs. There’s no ETA for a fix yet, but more reports help us prioritize it.

As a workaround, you already noticed GPT-5.4 and Gemini 3.1 Pro work correctly. Until there’s a fix, I’d recommend using those models for tasks with Korean text.

I’ll update the thread when I have more info.

joshwang · April 11, 2026, 7:00am

2026년 4월 11일 (토) 오후 3:22, Dean Rie <[email protected]>님이 작성:

tobe500 · April 13, 2026, 1:02am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using Composer 2 in Fast mode, the generated text sometimes becomes corrupted.
Parts of the output contain garbled characters (e.g., �), making the content hard to read.

Steps to Reproduce

Enable Composer 2 Fast mode
Ask a normal question
Check the output

Expected Behavior

Text should be generated in clean, readable UTF-8 without any corruption.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.0.13
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

Composer 2 Fast

For AI issues: add Request ID with privacy disabled

e14e01c1-54a7-40c4-9066-805173bd3270

Does this stop you from using Cursor

No - Cursor works, but with this issue

Nick_Kim · April 13, 2026, 7:21am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

[Bug] Korean text renders as ◆ symbols in Chat panel when using Auto model mode

Bug Description

When Agent model is set to Auto, all Korean characters in AI responses
appear as ◆ (broken glyphs) in the chat panel.

Setting the model explicitly to Claude Sonnet 4.6 resolves the issue completely.

Steps to Reproduce

Set Agent model to Auto
Ask any question in Korean
Korean characters in response display as ◆ symbols

Workaround

Manually fix the model to Claude Sonnet 4.6 → Korean renders correctly.

Suspected Cause

Auto mode may route to a model that outputs Korean in NFD (decomposed Unicode).
Cursor’s chat renderer does not handle NFD Korean correctly.

Environment

OS: Windows 10
This likely affects ALL Korean users in Auto mode.

Steps to Reproduce

Bug Description

When Agent model is set to Auto, all Korean characters in AI responses
appear as ◆ (broken glyphs) in the chat panel.

Setting the model explicitly to Claude Sonnet 4.6 resolves the issue completely.

Steps to Reproduce

Set Agent model to Auto
Ask any question in Korean
Korean characters in response display as ◆ symbols

Workaround

Manually fix the model to Claude Sonnet 4.6 → Korean renders correctly.

Suspected Cause

Auto mode may route to a model that outputs Korean in NFD (decomposed Unicode).
Cursor’s chat renderer does not handle NFD Korean correctly.

Environment

OS: Windows 10
This likely affects ALL Korean users in Auto mode.

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
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

devmyung · April 13, 2026, 7:36am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi, I found a reproducible issue where Korean output is garbled only when using Composer 2.

Issue

When I ask a question in Korean using Composer 2, the response text is corrupted and shows many broken replacement characters.
My Korean input displays correctly, but the Composer 2 output does not.

Reproduction Steps

Open Cursor
Select Composer 2
Ask a short question in Korean
The response appears garbled

Expected Behavior

Korean output should render normally.

Actual Behavior

Only the Composer 2 response is broken.
If I switch to GPT in the same environment, Korean output displays normally.

Notes

This is reproducible even with very short Korean prompts
User input is displayed correctly
I attached a screenshot: composer2-korean-text-broken.png
I can provide a Request ID if needed.

Steps to Reproduce

Open Cursor
Select Composer 2
Ask a short question in Korean
The response appears garbled

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Environment

Cursor Version: 3.0.16
VSCode Version: 1.105.1
macOS: 26.4 (25E246)

Does this stop you from using Cursor

No - Cursor works, but with this issue

Sangsu_Lee1 · April 11, 2026, 2:21am

Describe the Bug

Summary:
With the “Composer 2 Fast” model selected, Korean text is corrupted in the AI chat and in code/files modified by the Agent. With “Composer 2” (non-Fast) on the same machine, Korean displays correctly. Other editors and tools also show Korean correctly.

Environment:

OS: macOS (fill in version, e.g. 15.x)
Cursor: (fill in exact version from Cursor → About)
Problem model: Composer 2 Fast
Control: Composer 2 — Korean OK

Steps to reproduce:

Set the chat/agent model to Composer 2 Fast.
Ask for a reply in Korean, or use the Agent to edit a UTF-8 file that contains Korean.
Observe mojibake / replacement characters in the chat and/or in saved file content.

Expected:
Korean should render and be written correctly as UTF-8, same as with Composer 2.

Actual:
Korean is corrupted only when Composer 2 Fast is selected.

Notes:
System locale and UTF-8 are not suspected; the issue is isolated to Composer 2 Fast in Cursor.

Steps to Reproduce

Steps to reproduce:

Set the chat/agent model to Composer 2 Fast.
Ask for a reply in Korean, or use the Agent to edit a UTF-8 file that contains Korean.
Observe mojibake / replacement characters in the chat and/or in saved file content.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.0.16 (Universal)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: glass
Build Type: Stable
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

imshysim · April 11, 2026, 12:42pm

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

dai_u · April 11, 2026, 1:53am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Thank you for Cursor. Japanese text gets garbled in Composer 2 Fast, but renders correctly in regular Composer and GPT on the same machine.

Steps to Reproduce

Open Cursor on Windows 10.
Use Composer 2 Fast.
Ask for a somewhat long Japanese response.
Some parts of the Japanese text become garbled.
Switch to regular Composer (non-Fast).
Ask for the same or similar Japanese response.
Japanese renders correctly.
GPT / normal chat also renders Japanese correctly.

Expected Behavior

Japanese text should render correctly in Composer 2 Fast, just like it does in regular Composer and GPT.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.0.16 (system setup)
VSCode Version: 1.105.1
Commit: 475871d112608994deb2e3065dfb7c6b0baa0c50
Date: 2026-04-09T05:33:51.767Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

No - Cursor works, but with this issue

Shimakenize · April 11, 2026, 2:42am

Title suggestion:
[Additional data] Japanese garbling reproduces only on Composer 2 Fast (Codex 5.3 is clean)

Body:
I ran additional checks and the repro condition is now clearer.

OS: Windows 10/11
Same machine / same network
Tested with medium-to-long Japanese responses
Garbling (missing chars / � replacement) reproduces on Composer 2 Fast
Under the same conditions, Codex 5.3 renders Japanese correctly
Regular Composer / GPT paths are mostly fine

Additional notes:

Rebooting the PC did not fix the issue on Composer 2 Fast
Corrupted text remains corrupted after copy-paste into a file, so this does not look like a display-only issue

Simple repro:

Select Composer 2 Fast
Ask for a somewhat long Japanese response
Observe missing characters or � replacements
Run the same prompt on Codex 5.3 and compare (renders correctly)

Please investigate this path-specific encoding/render pipeline.

sungasot · April 13, 2026, 11:41am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary
Assistant replies that contain Traditional Chinese characters display corrupted text: many CJK glyphs are replaced with the Unicode replacement character (black diamond with question mark, ``) or similar. The same conversation shows English text correctly. User-typed Chinese in the chat input often appears fine; the corruption is primarily on model output in the Composer/Chat panel.

Steps to Reproduce

Open Cursor on Windows.
Open Composer or Chat.
Ask the assistant to reply with several sentences in Traditional Chinese (e.g. “請用繁��中文回覆三句話”).
Observe the assistant message body.

Expected Behavior

All Chinese characters should render correctly (UTF-8), consistent with the editor and with English text in the same message.

Actual behavior

Many Chinese characters are missing or shown as (or), making the reply unreadable. Copy-pasting the message into Notepad or another UTF-8 editor still shows corruption, suggesting the issue is not only font rendering but possibly incorrect encoding or lossy conversion in the chat output path.

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
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Composer 2

For AI issues: add Request ID with privacy disabled

eb47c1c5-54ea-40e5-be8b-9d14b8233f8d
e75dc768-ccbb-47d6-9386-e2b31b9921b7

Additional Information

What we tried (no lasting fix)

Set Files: Encoding to UTF-8.
Set Editor: Font Family to include 'Microsoft JhengHei UI', 'Microsoft YaHei UI', ... (was previously empty).
Restart Cursor.

Impact

Blocks use of the product in Traditional Chinese for technical/business documentation; workaround is to ask the model for English-only replies and translate locally.
Thank you.

Does this stop you from using Cursor

Yes - Cursor is unusable

imshysim · April 14, 2026, 5:16am

verson 3.1.10 “While Korean corruption in the chat window has improved, the issue persists when Composer writes or edits files (.md, .py). As seen in the screenshots, Korean literals are still replaced with ``, making the generated documents unusable and significantly slowing down my workflow. This needs urgent fixing for file-writing mode.”

imshysim · April 15, 2026, 3:06am

Even after updating to the newly patched version (v3.1.14), the encoding issue is still not fixed when Composer/Agent writes files.

The situation is actually getting worse: as you can see in my screenshot, the AI itself recognizes that Cursor’s native “Write” tool breaks Korean characters. To bypass this broken tool, the AI is now forcibly writing and executing a separate Python script (_emit_... .py) just to create a simple Markdown document in UTF-8.

Having the AI resort to writing Python scripts just to save a text file without corruption is an extreme workaround. Please urgently fix the UTF-8 encoding loss in the file-writing module itself.

park2053 · April 15, 2026, 2:23am

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

In Agent mode, Korean text in the assistant’s chat replies started showing corruption (replacement characters U+FFFD, missing syllables, or broken words mid-sentence). This did not happen before a recent Agent-mode-related update; normal Editor typing and non-Agent flows seem fine. The issue looks like UTF-8 multibyte sequences being split or mishandled during streaming/rendering.

Environment

Cursor version: [fill: Cursor → About Cursor]
OS: [fill: e.g. macOS …]
Mode: Agent mode (Chat)
Privacy: [Privacy Mode / Share Data when reproducing]

Steps to reproduce

Open Agent mode chat.
Ask the agent to perform a typical task (e.g. start dev server, run commands) that yields a Korean-language summary in the reply.
Observe the assistant message body.

Expected

Korean sentences display correctly, same as when typing in the editor.

Actual

Korean breaks mid-word or mid-sentence. Examples from UI:

Intended: “개발 서버를 띄워 두었습니다” → broken with missing syllables / replacement glyphs.
Intended: “동작 확인 … 307 … 리다이렉트” → similar breakage.
Pattern: corruption clusters around multibyte UTF-8 boundaries; English and URLs often remain intact.

Screenshots

[Attach the screenshot(s) you already captured showing the broken Korean in Agent chat.]

Request ID

[Paste from ⋯ → Copy Request ID for the affected conversation]

Notes

Suggests regression in Agent response streaming, buffering, or markdown/UI layer after an update.
Not observed (or much less) in non-Agent editor workflows.

Thank you.

Steps to Reproduce

Open Cursor with a workspace loaded.
Open Chat in Agent mode (not plain editor-only flow).
Ask the agent to do something that produces a Korean-language reply in the chat (e.g. start the dev server on port 3000 and confirm when it’s running).
Read the assistant’s message in the chat panel. Observe whether Korean text is corrupted mid-word or mid-sentence (missing syllables, mojibake, or U+FFFD replacement characters). URLs and English often stay intact.
For comparison: type the same Korean text directly in the editor — it should display correctly.

If it doesn’t happen every time: repeat with a longer Korean reply or watch the message while it streams in.

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.1.14 (Universal)
VSCode Version: 1.105.1
Commit: d8673fb56ba50fda33ad78382000b519bb8acb70
Date: 2026-04-14T01:39:23.679Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

For AI issues: add Request ID with privacy disabled

3a17c98e-877a-4622-af6e-26867e91e3b8

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

mohitjain · April 17, 2026, 9:34am

Hey everyone — quick update. We know this is still happening, especially when Composer writes or edits files. The team is actively working on the underlying fix. In the meantime, switching to a non-Composer model (like Claude Sonnet 4.6 or GPT) for tasks involving CJK text is the most reliable workaround. I’ll follow up here when there’s progress.

Topic		Replies	Views
Bug Report: Korean Character Corruption (U+FFFD) in Composer After Recent Update Bug Reports chat , composer	2	44	May 5, 2026
Composer 2 Fast: Korean UTF-8 broken in chat and agent edits (Composer 2 OK) Bug Reports chat , composer	3	109	April 13, 2026
Korean output is garbled only in Composer 2 Bug Reports chat , composer	2	20	April 13, 2026
Composer 2 (Fast mode) produces garbled text / encoding issues Bug Reports composer	4	80	April 13, 2026
Cursor AI Korean Encoding Bug Bug Reports	9	1411	December 17, 2025