anthropics
[BUG] IME input causes performance issues and duplicate conversion candidates
Environment
Platform (select one):
- [x] 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.
Other terminal based applications (emacs,vim etc) can handle Japanese input correctly as expected.
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.)
A separate conversion candidate window appears outside of Claude Code's interface
I can confirm that this same behavior occurs with ATOK as well.
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.
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.
Hi all, I've begun investigating this. The ink library 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!
Additional Environment Information
I'm experiencing the same issue on Windows 11 Pro (Version 24H2) with Microsoft IME.
Environment:
- OS: Windows 11 Pro (24H2)
- Editor: VS Code 1.101.1
- IME: Microsoft IME (default Windows IME)
- Claude Code Version: 1.0.30
Observed Behavior:
- Japanese input characters and conversion candidates appear in the bottom right corner of the Claude Code interface
- This creates a confusing user experience as the IME overlay interferes with the normal UI
Screenshot:
This confirms that the IME display issue affects not only macOS users but also Windows users with the default Microsoft IME, suggesting it's a broader cross-platform issue with the IME integration.
When using Linux/Anthy, in the regular terminal, typing Japanese text before engaging the picker with the spacebar shows the text in the window. However, when typing in the Claude Code terminal, no text is displayed at all until the picker is engaged.
Although, interestingly, when claude code is run in a terminal inside VSCode, the text is displayed as it is being typed before engaging the picker...
I think the Chinese input method not following the cursor is the same issue?
#6342 #2237 #3343
Confirming same issue on Linux/Wayland
I'm experiencing identical symptoms on Ubuntu 24.04 LTS with GNOME 46 (Wayland):
Environment:
- Ubuntu 24.04.2 LTS
- GNOME Shell 46.0 (Wayland)
- ibus-mozc (also tested Fcitx5-mozc)
Symptoms match exactly:
- IME candidate popups appear in unstable/random positions
- Performance degradation during Japanese input
- Duplicate/misaligned conversion candidates
- Issue isolated to Claude Code CLI
Cross-platform confirmation: This confirms the React Ink TextInput IME handling issue affects both macOS and Linux Wayland environments, suggesting it's a fundamental terminal IME integration problem.
Current workaround: External editor + paste for longer Japanese text.
Posted via Claude Code CLI while experiencing this very issue! 😅
The majority of CLI AGENT have now fixed this issue, including codex, ampcode, etc. This issue in Claude Code is quite annoying and is hurting UX.
Same trouble happen using zellij. It is very painful. It was recorded on video.
- macOS Tahoe
- iTerm2/WezTerm/Ghostty
- with zellij 0.43.1
- (with tmux; Japanese Input displays under the input area
https://github.com/user-attachments/assets/68df9664-e45f-43fc-9727-dfeae9a1a8d1
