[BUG] IME input causes performance issues and duplicate conversion candidates

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.

!Image

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.

!Image

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:
!Image

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

<img width="1367" height="243" alt="Image" src="https://github.com/user-attachments/assets/260d72da-2eed-4afd-9035-20438a6552dc" />

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! 😅

no one fix this?

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

Nobody helps... It's 2025 December now...

This is a bug in the ink library.
The same issue has been reported in other CLI tools that reference the ink library (gemini-cli, copilot-cli, etc.).
(ex: gemini-cli issue link: <https://github.com/google-gemini/gemini-cli/issues/1796>)

Currently, gemini-cli is working to resolve this issue.
I have submitted a pull request to the ink library that moves the terminal cursor focus to properly display the IME candidate windows.

• <https://github.com/vadimdemedes/ink/pull/833>
• <https://github.com/jacob314/ink/pull/38>

If this pull request is reviewed and merged, there is a high likelihood that the issue will be resolved soon.
If you have time, I would appreciate your testing and review of this logic.
Thank you.

I confirmed in the 2.0.68 changelog.md at <https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md>.
"Fixed IME (Input Method Editor) support for languages like Chinese, Japanese, and Korean by correctly positioning the composition window at the cursor."

However, I am still experiencing this issue. (MacOS 15.6.1 + all terminals & emulators (iTerm, VSCode, Tmux... etc).

I confirmed in the 2.0.68 changelog.md at https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md. "Fixed IME (Input Method Editor) support for languages like Chinese, Japanese, and Korean by correctly positioning the composition window at the cursor." However, I am still experiencing this issue. (MacOS 15.6.1 + all terminals & emulators (iTerm, VSCode, Tmux... etc).

This is sample. macOS 26.1(M4)+Wezterm+zellij.

https://github.com/user-attachments/assets/41fa69be-9be5-49e8-9e7d-d4cb6d8408aa

Same here, nothing appears to have changed. I confirmed that the issue has not been resolved in the following environment:

• Windows 11 25H2: Google Japanese Input (PowerShell and WSL2, terminal and VS Code)
• Ubuntu Linux 24.04.3: Mozc (Ghostty)
• macOS 26.1 Google Japanese Input (iTerm and VS Code)

At https://luma.com/ioed4ksj?tk=fHofVJ, I got positive reaction from Claude Code team 🤟

Thai Script Also Affected

Adding Thai as another language experiencing the same IME issues.

Environment

• Claude Code: 2.1.12
• - OS: macOS 26.2 (arm64)
• - - Terminal: Terminal.app (xterm-256color)
• - - - Input Method: macOS built-in Thai IME

Symptoms

1. White/yellow boxes appear around Thai characters during composition
2. 2. Extra spacing between characters
3. 3. Issue persists after every Thai input - requires terminal resize (SIGWINCH) to temporarily fix
4. 4. Problem returns immediately on next Thai input

What I've Tried

• Updated Claude Code 2.1.8 → 2.1.12 (no improvement)
• - Tried iTerm2 instead of Terminal.app (same issue)
• - - Resize terminal window (temporary fix only)

Notes

Thai script, like CJK languages, relies on IME composition. The React Ink TextInput component assumptions don't account for this, similar to the Japanese/Korean issues described above.

Looking forward to the fix!

Gemini CLI Fixed this issue.

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?

@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)

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.

@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.

@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.

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 (?)

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.

Please help Asian users.

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.

Nvim in 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

@JiehoonKwak

• MacOS + ghostty / wezterm / iterm + claude code
• MacOS + ghostty / wezterm / iterm + tmux + claude code

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.

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:
| Terminal | IME Support | Notes |
|----------|-------------|-------|
| iTerm2 | Good | Set Preferences → Profiles → Terminal → "Report terminal type" to xterm-256color |
| Kitty | Fair | May need allow_remote_control yes for proper IME positioning |
| Ghostty | Good | Generally handles IME well out of the box |
| Terminal.app | Poor | Known to have issues with many Ink-based TUIs |
| VS Code terminal | Fair | Native UI mode avoids IME issues entirely |
If you're on Terminal.app, switching to iTerm2 or Ghostty often resolves the duplicate candidates issue.
Workaround 2 — Type in English, then paste Japanese:
Compose your Japanese text in a separate editor (Notes, TextEdit, etc.) and paste it into Claude Code with Cmd+V. This bypasses the IME composition entirely.
Workaround 3 — Use pipe mode for Japanese prompts:

echo "日本語のプロンプトをここに書く" | claude -p

Pipe mode doesn't use the TUI input, so IME issues don't apply.
Workaround 4 — Reduce input lag:
Adding to your terminal profile:

export LANG=ja_JP.UTF-8
export LC_ALL=ja_JP.UTF-8

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.