[BUG] IME (ATOK) candidate window overlaps input area on Windows Terminal
Status Open
Reported on v2.1.191
Maintainer reply None cached
Activity 4 comments · opened Jun 25, 2026
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?
When typing Japanese text using ATOK IME in Claude Code's input prompt,
the IME candidate/conversion window overlaps with the input area,
making it difficult to see what is being typed.
What Should Happen?
The IME candidate window should appear directly above or below the
input cursor without overlapping the input text, as it does in
normal terminal input (outside of Claude Code's TUI).
Error Messages/Logs
Steps to Reproduce
- Launch Claude Code in Windows Terminal on Windows 11
- Switch to ATOK (Japanese IME)
- Type Japanese text requiring conversion (e.g. "かんきょう" → "環境")
- Observe the position of the IME candidate window
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.191 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
- Windows 11 26H2 (Build 26300)
- Windows Terminal 1.24.11321.0
- IME: ATOK (JustSystems)
- The same issue likely occurs with MS-IME and Google Japanese Input,
as the root cause appears to be Claude Code's TUI (React Ink) hiding
the real terminal cursor position from the OS IME subsystem.
- Related issues: #1547, #25186, #19207, #35307
<img width="1423" height="354" alt="Image" src="https://github.com/user-attachments/assets/cba0f327-a656-4b2e-a032-eb6ba9e60732" />
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate. All three referenced issues are closed:
If the fix merged for #61385 fully resolved this class of bug, I should not be seeing it on v2.1.191. This is either a regression or an
incomplete fix.
Additionally, #61385 was specifically about the Agent View → session transition path. My report is about normal interactive input — no
Agent View involved.
Since all three issues are closed (and #35307 is locked), there is no existing open issue to upvote. This issue serves as a fresh repro on
the latest version.
Still reproducing on Claude Code 2.1.220 (Windows Terminal, ATOK) -- same overlap between the IME candidate window and the input area as originally described. Flagging this to prevent stale auto-close; the fix in #61385 was specific to the Agent View to session transition path and doesn't cover this normal interactive-input case.
Additional data point on the root cause: on Windows Terminal (Claude Code 2.1.238, ATOK), the candidate window's vertical position tracks the caret correctly (confirmed across different rows). However, the horizontal position is stuck at the terminal's left edge (column 0) regardless of caret column — reproduced by typing a long line of digits and triggering the emoji/candidate palette mid-line; the popup rendered flush-left while vertically aligned with the input row.
This is narrower than the "real cursor fully hidden, falls back to (0,0)" explanation in the issue body — Y is not falling back, only X is. Might point at a column-calculation bug specific to Windows/ConPTY (e.g. wide-character width miscount in the column offset, or the column component of the cursor-position escape sequence not being emitted/interpreted correctly) rather than the cursor being hidden entirely.