[BUG] IME-committed character inserted mid-line duplicates the CJK prefix and suffix (display-width miscalculation in the IME commit path only)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

What's Wrong?

Inserting a character via an IME into the middle of a prompt duplicates part of
the line. It only happens when the surrounding CJK text was typed through the
IME. Identical text that was pasted is completely immune.

Steps to Reproduce

1. With a Chinese IME, type 你好世界abcdef into the prompt (CJK entered

character by character through the IME)

1. Move the cursor between 界 and a
2. With the IME still active, type ，

Expected: 你好世界，abcdef
Actual: 你好世界你好世界，abcdefabcdef

Isolation matrix

| Surrounding CJK | Inserted character | Result |
| :------------------- | :----------------- | :------------- |
| pasted | IME (，) | correct |
| typed via IME | IME (，) | duplicated |
| typed via IME | ASCII, IME off | correct |

Both conditions are required. Pasting the exact same string and editing it
freely never reproduces the bug.

Observations

Prefix before the cursor is 你好世界: 4 code points, 8 display columns.
The duplicated span is 4 — the difference between the two.

Second, unrelated string: prefix claude为什么会有 (11 code points, 16 display
columns) produced
claude为什么会有claude为什么会有，这种bug？这种bug？ — duplicated span 5.

In both cases the duplicated span equals the number of CJK characters before
the cursor, i.e. code-point count minus display width for that prefix. Note
that in the second case there are 2 further CJK characters after the cursor
(这种) which do not contribute to the offset.

Ctrl+L restores the correct display, so the input buffer is intact — this is a
cursor-positioning/redraw bug, not data corruption.

Hypothesis (not verified)

Since pasted CJK is immune, the fault does not appear to be in measuring the
buffer at render time — that would break for pasted text too. It looks more like
a cached cursor column that is advanced by character count instead of display
width as each IME character is committed, with the error then surfacing on the
next IME commit. Ordinary keypresses appear to take a path that recomputes the
column correctly, which is why inserting ASCII into the same drifted line renders
fine.

The fact that the offset tracks the pre-cursor prefix rather than the whole line
suggests cursor movement partially recomputes this state; I could not determine
the exact bookkeeping from the outside.

Scope

Reproduces with both renderers: default, and fullscreen /
CLAUDE_CODE_NO_FLICKER=1. This is not the renderer-specific no-flicker CJK
cluster (#65806, #65394).

Likely affects Japanese and Korean IMEs too, since the root cause is display
width rather than anything Chinese-specific.

Environment

• Claude Code version: <claude --version>
• OS: <e.g. Windows 11 + WSL2 Ubuntu 24.04>
• Terminal: <e.g. Windows Terminal>
• IME: <e.g. Microsoft Pinyin>
• Renderers tested: default and no-flicker, both reproduce

What Should Happen?

Steps to Reproduce

1. With a Chinese IME, type 你好世界abcdef into the prompt (CJK entered

character by character through the IME)

1. Move the cursor between 界 and a
2. With the IME still active, type ，

Expected: 你好世界，abcdef
Actual: 你好世界你好世界，abcdefabcdef

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. With a Chinese IME, type 你好世界abcdef into the prompt (CJK entered

character by character through the IME)

1. Move the cursor between 界 and a
2. With the IME still active, type ，

Expected: 你好世界，abcdef
Actual: 你好世界你好世界，abcdefabcdef

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_