IME Bug Report: Japanese IME candidate window position stuck at bottom-left
Environment
- OS: Windows 11 + WSL2 (Ubuntu)
- IME: Microsoft IME (標準), Google 日本語入力
- Terminals tried:
- Windows Terminal
- WezTerm
- wsltty (Mintty via WSL)
- VS Code WSL Remote integrated terminal
- SSH (sshd inside WSL → connect from Windows terminal)
- All terminals reproduce the same issue
Current Behavior
When typing Japanese in Command Code's TUI, the IME candidate/preedit window always appears at the bottom-left corner of the terminal, regardless of where the actual cursor is. This makes Japanese input extremely difficult — you have to look at the bottom-left corner to see what you're typing while the actual text appears elsewhere.
Expected Behavior
The IME candidate window should appear near the text cursor position, as it does in normal terminal input (e.g., bash, vim, etc.).
Likely Cause
Since the issue reproduces across all terminal emulators and connection methods (local ConPTY, SSH bypassing ConPTY, Mintty), it's almost certainly not a terminal emulator issue. The root cause is likely in Command Code's TUI framework — specifically, it's probably not sending proper Cursor Position Report (CPR) responses via DSR (Device Status Report, \e[6n), or not responding to it at all. The terminal/ConPTY relies on CPR to tell the IME where to render the candidate window.
Steps to Reproduce
- Open Command Code in any WSL terminal
- Switch to Japanese IME (Microsoft IME or Google Japanese Input)
- Start typing — the preedit/candidate window will appear at the bottom-left corner of the TUI
- Moving the cursor or typing in different positions does not change the candidate window location
IME Bug Report: Japanese IME candidate window position stuck at bottom-left
Environment
Current Behavior
When typing Japanese in Command Code's TUI, the IME candidate/preedit window always appears at the bottom-left corner of the terminal, regardless of where the actual cursor is. This makes Japanese input extremely difficult — you have to look at the bottom-left corner to see what you're typing while the actual text appears elsewhere.
Expected Behavior
The IME candidate window should appear near the text cursor position, as it does in normal terminal input (e.g., bash, vim, etc.).
Likely Cause
Since the issue reproduces across all terminal emulators and connection methods (local ConPTY, SSH bypassing ConPTY, Mintty), it's almost certainly not a terminal emulator issue. The root cause is likely in Command Code's TUI framework — specifically, it's probably not sending proper Cursor Position Report (CPR) responses via DSR (Device Status Report,
\e[6n), or not responding to it at all. The terminal/ConPTY relies on CPR to tell the IME where to render the candidate window.Steps to Reproduce