Repository navigation
[BUG] IME input causes performance issues and duplicate conversion candidates #1547
Description
Environment
Platform (select one):
- Anthropic API
- AWS Bedrock
- Google Vertex AI
- Other:
Claude CLI version: 1.0.10 (Claude Code)
- Latest changes: Added markdown table support, improved streaming performance
Operating System: macOS 15.5 (Build 24F74)
Terminal: Terminal.app
IME: macOS default Japanese IME
Account: Claude Max Account
Model: Default Opus 4 for up to 20% of usage limits, then Sonnet 4 (currently using Opus)
Bug Description
When typing Japanese text using macOS default IME in Claude Code, the application becomes significantly slower and displays duplicate conversion candidates. The IME conversion candidates appear in a separate system popup window instead of being properly integrated with Claude Code's input field, causing performance degradation and a poor user experience.
Steps to Reproduce
- Launch Claude Code in Terminal.app on macOS
- Start typing Japanese text using the default macOS Japanese IME
- Observe the conversion candidate behavior during typing
Expected Behavior
- Japanese IME input should work smoothly without performance issues
- Conversion candidates should be handled properly within Claude Code's interface
- No duplicate or separate conversion candidate windows should appear
- Typing experience should be as responsive as typing English text
Actual Behavior
- Claude Code becomes noticeably slower during Japanese IME input
- A separate conversion candidate window appears outside of Claude Code's interface
- The typing experience is laggy and unresponsive
- Performance degradation affects the overall usability when working with Japanese text
Additional Context
This issue appears to be related to how Claude Code handles IME input events and rendering. The problem is reproducible consistently when using Japanese input and significantly impacts productivity for Japanese-speaking developers.
Screenshots attached showing the duplicate conversion candidates appearing in a separate system window while typing Japanese text.
Workaround
Currently, switching to English input temporarily resolves the performance issue, but this is not a viable long-term solution for Japanese developers.
Note: This issue specifically affects Japanese IME input and has not been reported in existing issues. It differs from issue #678 which deals with pasting Japanese text, as this problem occurs during real-time IME typing.
Activity
kengonakajima commentedon Jun 4, 2025
Other terminal based applications (emacs,vim etc) can handle Japanese input correctly as expected.
chatii commentedon Jun 4, 2025
I use "ATOK," a third-party Japanese IME, instead of macOS's default IME.
I don't notice significant issues with terminal responsiveness or slowness.
(Though it's definitely slower compared to English-only input.)
I can confirm that this same behavior occurs with ATOK as well.
llongmane584 commentedon Jun 4, 2025
My environment is Windows 11, and I'm using Claude Code with WSL. When using ATOK, similar to what @chatii -san described, I don't experience a performance drop, but the conversion candidate window appears outside of Claude Code's interface.
go-numb commentedon Jun 4, 2025
I am running this in a Windows 11 WSL environment（IME: Google日本語入力）.
I am experiencing the same issue as others, and in addition, I am unable to select text in the input section, which makes operation difficult.
[-][BUG] Japanese IME input causes performance issues and duplicate conversion candidates[/-][+][BUG] IME input causes performance issues and duplicate conversion candidates[/+]rboyce-ant commentedon Jun 4, 2025
Hi all, I've begun investigating this. The
inklibrary that we use makes some assumptions in its TextInput component that don't hold true for IMEs used in terminal. It may take a little while to get these fixes in, but we're looking into fixing this!Fix IME input handling issues (anthropics#1547)
22 remaining items
iblea commentedon Feb 5, 2026
Gemini CLI Fixed this issue.
MtkN1 commentedon Feb 7, 2026
This issue was closed as "completed," but the IME problem still persists as of v2.1.34. Could you clarify why this was closed? Does this mean the fix from the forked Ink (e.g., jacob314/ink#38) is planned to be incorporated in an upcoming release?
cirospaciari commentedon Feb 10, 2026
@MtkN1 sorry the issue was closed but my fix was reverted, will ship it again (we did not use the fix from the forked Ink mentioned we used our own fix that fits better our internals)
juniqlim commentedon Feb 10, 2026
FYI — Ink 6.7.0 (released in vadimdemedes/ink#866) now includes framework-level support for IME cursor positioning via a new
useCursor()hook. It allows apps to position the terminal cursor after each render, so IME composition characters appear at the correct location. It also wraps output with Synchronized Update Mode to prevent intermediate cursor positions from leaking.jedipunkz commentedon Feb 11, 2026
@juniqlim Thank you. ❤
I've confirmed that the Japanese input issue has been fixed in examples/cursor-ime/cursor-ime.tsx in the master branch of ink. It's also improved when using zellij and tmux.
I'd be happy if you could incorporate the latest version of ink.
iblea commentedon Feb 23, 2026
@cirospaciari
Is there a justification for delaying this fix by 2–3 weeks?
This is a critical bug that seriously degrades the UX for CJK users.
As far as I know, users from Asian regions such as Japan and Korea make up a significant portion of Claude's user base.
I'd strongly urge you to prioritize multilingual user support.
b100to commentedon Mar 10, 2026
I've been waiting since last year, but has it still not been changed? That's why I'm working with the VS Code Extension.
What's inconvenient is that I want to open multiple terminal windows and run multiple agents, but it's quite frustrating... I'm curious about how far along the work is, or if it hasn't started yet, when it might begin. There's no way for an individual to solve this problem — it seems like waiting is the only option, or maybe learning English fast enough to work abroad might actually be quicker (?)
juniqlim commentedon Mar 11, 2026
For anyone who can't wait for an official fix, another workaround is to use or fork an open-source terminal emulator and handle IME composition at the terminal layer.
I took this approach in https://github.com/juniqlim/growterm on macOS. By intercepting IME composition before input reaches the PTY/TUI layer, I was able to make Korean composition behave correctly even with apps like Claude Code.
This is not a substitute for a proper upstream fix, but it may be a practical workaround for people who need multiple terminal windows or multiple agents today.
JayAhn2 commentedon Mar 18, 2026
Please help Asian users.
JiehoonKwak commentedon Mar 26, 2026
The 2.1.84 fix for cursor tracking works great in Ghostty and IME renders inline as expected.
But inside
Zellij, IME composition still doesn't render at the correct position.Nvimin the same Zellij session handles IME fine. So Zellij isn't fundamentally breaking IME and something about how Claude Code's cursor sync interacts with Zellij specifically is off. Possibly querying cursor position and getting pane-relative coordinates back instead of screen-absolute ones?I didn't test in tmux though
iblea commentedon Mar 26, 2026
@JiehoonKwak
I've confirmed that the program runs fine in the environment mentioned above.
Zellij still has the same IME issue. tmux is working fine though.
yurukusa commentedon Mar 31, 2026
This affects CJK (Chinese, Japanese, Korean) input across many TUI applications, not just Claude Code. The root cause is that Claude Code's input handling conflicts with the terminal's IME composition mode.
Workaround 1 — Use a terminal that handles IME better:
Different terminals have varying levels of IME support with Ink-based TUIs:
xterm-256colorallow_remote_control yesfor proper IME positioningPipe mode doesn't use the TUI input, so IME issues don't apply.
Workaround 4 — Reduce input lag:
Adding to your terminal profile:
This ensures proper locale settings, which some terminals need for correct IME behavior.
For Anthropic's team: The Ink framework (which Claude Code's TUI is built on) doesn't have native IME composition support. The duplicate candidates appear because keystrokes during IME composition are being processed as both raw input and composition events. A fix would likely need to be at the Ink level or by intercepting composition events before they reach the input handler.