[CRITICAL] Korean IME: Composing characters display at wrong position (unusable for Korean users)

Status Closed — duplicate
Maintainer reply None cached
Activity 11 comments · opened Jan 5, 2026 · closed Feb 10, 2026

CRITICAL for Korean Users

This issue makes Claude Code practically Annoying for Korean users.
Every single character typed requires looking away from the cursor position to see what's being typed.

--> What's ridiculous is that they already released 2.0.68, saying they fixed this issue.
It's still not fixed in v2.1.6

Description

When typing Korean using IME, composing characters (incomplete/in-progress characters) display at the wrong position - they appear on the next line at the beginning, instead of at the current cursor position.

Once the character is finalized, it jumps to the correct cursor position.
But during composition, it's misplaced, making typing extremely annoying.

Expected Behavior

Composing characters should display at the cursor position (simple)

Actual Behavior

Composing characters appear far away from the cursor (next line, beginning of line).

Environment

  • OS: Windows 11

--> Local ; VS Code, Antigravity integrated-terminal, Windows terminal, pwsh, etc.
--> WSL2 ; VS Code, Antigravity integrated-terminal, zsh, warp, bash, etc.

  • Claude Code Cli : Local installation
  • IME: Windows Korean IME

Reproduction

  1. Launch Claude Code
  2. Type Korean characters
  3. Observe composing characters appear at wrong position

Reproduction rate: Always 100% (every single Korean character)

Impact

  • Usability: CRITICAL
  • Affected users: All Korean language users
  • Workaround: just ignore the screen and type, remembering it in my head.
  • Makes the product essentially very very annoying for Korean input

Additional Info

  • VS Code's Terminal handles Korean IME correctly (shows composing chars at cursor)
  • Windows Terminal handles Korean IME correctly (shows composing chars at cursor)
  • WSL: ZSH terminal handles Korean IME correctly (shows composing chars at cursor)
  • Issue only occurs in Claude Code
  • English input works normally

** Should be a simple fix: display composing characters at cursor position.

View original on GitHub ↗

11 Comments

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/14814
  2. https://github.com/anthropics/claude-code/issues/6342
  3. https://github.com/anthropics/claude-code/issues/13660

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

btxe · 7 months ago

There are three issues related to the Japanese and Chinese IMEs, but this one concerns the Korean IME. While related to the three existing issues, this issue should exist independently (case by case, the practical workarounds).

btxe · 7 months ago

Why? Are you releasing an unresolved issue as resolved? I reported an unresolved issue, but they are trying to close it as a duplicate (the issue is not identical in detail). Please set up claude-bot to properly handle the issue, because it is not working properly.

This issue is common when using 'Korean, Japanese, Chinese' which use special IME to create character combinations, and is common to all types, regardless of whether it is a standalone terminal or an IDE integrated-terminal.

The funny thing is, this issue is common in the latest version of gemini cli. So, it seems like they're using the same library functions. (While combining characters by typing) Even the incorrect locations where characters appear are the same. Haha.

Jan 22, 2026 -->The Gemini CLI team fixed the issue of "wrong positioning error when combining characters using special IMEs." --> So, Team CC Cli ? .......... -_-;

The v2.1.6 update came out a few hours ago, but Still the issue hasn't been fixed at all.
The absurd thing is... They already announced it was fixed (see below).

What exactly did they say was fixed in v2.0.68?
I doubt these people actually test whether the fixes are properly applied and document them in the release notes. I wonder if they just order Claude to run a test drive.
----------------------------------------------------------------------------------------------------------------------------
In the release log, Claude Code Cli v2.0.68
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#2068

  • Fixed IME (Input Method Editor) support for languages like Chinese, Japanese, and Korean by correctly positioning the composition window at the cursor
btxe · 7 months ago
  1. An error occurred in Claude Code Cli (using a special IME) where the display of the language combination did not match the actual cursor position.
  1. Google Gemini Cli also had an almost identical error, including the cursor position. 3 hours ago, I tested Gemini Cli, which had fixed the issue, and it was completely resolved.

I hope the Claude Code Cli team takes note. how and where to fixed it.

Here's the test url link.

https://github.com/google-gemini/gemini-cli/issues/1796#issuecomment-3782005514

sangrokjung · 6 months ago

+1 Same issue on macOS.

Environment:

  • macOS (darwin 24.4.0)
  • Terminal: iTerm2
  • Claude Code: latest

While this issue is reported for Windows, I experience similar problems on macOS. Korean composing characters don't display at all during composition - they only appear after the syllable is finalized.

This significantly impacts usability for Korean users. Would appreciate a fix that works across all platforms.

Related: #18291 (macOS specific report)

cirospaciari · 6 months ago

This has been fixed. The terminal's real cursor is now positioned at the input caret, so composing characters display at the correct position.

btxe · 6 months ago
This has been fixed. The terminal's real cursor is now positioned at the input caret, so composing characters display at the correct position.

@cirospaciari ???? The Korean characters still appear in the wrong positions during composition. Why did you mark it as complete without actually testing it? I just tested it and the bug still occurs without any changes.

This issue was once mentioned in the release log as being resolved in Claude Code Cli v2.0.68, but even then, it wasn't resolved at all.

I would appreciate it if, if an issue was raised, they would have confirmed through testing that it was actually resolved before declaring it complete. This is a very important issue, so please take care of it carefully.

FYI, the same issue existed in gemini cli, but team gemini had fixed it on Jan 22, 2026 (issue contributors were given a chance to test it before the final release).

Test Environments

OS ; macOS
Term ; Ghostty, Antigravity Integrated Terminal, macOS default Terminal
Claude Code Cli v2.1.34 Latest version as of today - Feb 6th, 2026.

<img width="388" height="270" alt="Image" src="https://github.com/user-attachments/assets/a1477fa4-5c5d-47ed-b4e6-881d9582b151" />

gunny-nbase · 6 months ago

@cirospaciari I'm experiencing the same issue.

Environment:

macOS (Darwin 25.2.0)
Tested on both iTerm2 and VS Code integrated terminal
Reproduction:
While typing Korean characters (e.g., "안녕"), the character currently being composed appears outside the input border/line. Once the composition is complete (by pressing the next key), the composed character jumps back inside the input area.

This issue is 100% reproducible regardless of the terminal application used. It was previously reported as fixed, but the problem persists.

cirospaciari · 6 months ago
@cirospaciari I'm experiencing the same issue. Environment: macOS (Darwin 25.2.0) Tested on both iTerm2 and VS Code integrated terminal Reproduction: While typing Korean characters (e.g., "안녕"), the character currently being composed appears outside the input border/line. Once the composition is complete (by pressing the next key), the composed character jumps back inside the input area. This issue is 100% reproducible regardless of the terminal application used. It was previously reported as fixed, but the problem persists.

We need to revert the IME support yesterday but will fix it and ship again I promise, sorry for the trouble

cirospaciari · 6 months ago
github-actions[bot] · 6 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.