Skip to content

IME candidate window is misplaced, invisible, or detaches in CJK (Japanese) input #1698

Closed
Bug
Closed
IME candidate window is misplaced, invisible, or detaches in CJK (Japanese) input#1698
Bug

Description

@MtkN1
MtkN1
opened on Feb 26, 2026

Describe the bug

When using Japanese IME input in Copilot CLI, the candidate suggestion popup does not appear immediately below the input box as expected.
Instead, the IME preedit/candidate window appears detached from the main interface (or otherwise fails to track the input line), making Japanese/CJK input difficult to use in Copilot CLI.

This is the same phenomenon as reported in other ink-based CLIs, such as Gemini CLI and Claude Code:

Screenshots:

  • Copilot CLI (problem): Image

    • While composing Japanese text (e.g., typing “こんにちは”), the IME candidate / conversion UI appears as a detached floating popup near the bottom-left of the terminal window rather than being positioned directly under the Copilot CLI input line.
    • This makes the IME experience confusing and makes it harder to input Japanese/CJK text in the Copilot CLI prompt.

  • Gemini CLI (fixed / expected): Image

    • Under the same environment and IME usage, the IME candidate / conversion UI behaves as expected (i.e., it appears in the correct place relative to the input line and is usable).

Affected version

GitHub Copilot CLI 0.0.418.

Steps to reproduce the behavior

  1. Start Copilot CLI in interactive mode
  2. Use Japanese (or any CJK) IME in your OS
  3. Try to input Japanese text. Observe that the IME candidate popup does not appear below the input box.
  4. Input suggestions may instead appear detached (floating or elsewhere), or not at all. Composition buffer/preedit is not displayed in line.

Expected behavior

When inputting CJK text using an IME, the candidate window and composition buffer (preedit) should appear directly under the CLI input field, and input should be usable and perform as expected (same as native terminal apps like bash/zsh/vim).

Additional context

  • OS: WSL Ubuntu 24.04.1 LTS
  • Copilot CLI: 0.0.418
  • Language input: Japanese IME (CJK)
  • Terminal: Windows Terminal
  • IM framework: Microsoft IME

Activity

  1. MtkN1
    added the
    Bug
    issue type on Feb 26, 2026
  2. MtkN1
    added
    triage
    on Feb 26, 2026

  3. torumakabe commented on Feb 28, 2026

    @torumakabe
    torumakabe
    on Feb 28, 2026

    Additional observation: IME preedit renders at the terminal's last write position, not the input cursor

    I can confirm this issue on VS Code's integrated terminal on Windows as well. Through testing, I identified a consistent pattern in where the IME preedit/candidate window appears.

    Finding

    The IME preedit text is rendered at the terminal's internal cursor position (i.e., wherever the last terminal write operation left the cursor), rather than at the actual input line cursor position.

    I tested three scenarios, all typing the same Japanese text "こんにちは":

    Scenario Last terminal write position Where IME preedit appeared
    Default (status info visible in bottom-right) End of premium request count in bottom-right reqs.こんにちは (bottom-right — see impact note below)
    After /on-air (status info hidden) End of first output line skillsこんにちは (after "Environment loaded: 3 custom instructions, 10 agents, 3 skills")
    After focusing the input box End of footer text modeこんにちは (after "shift+tab switch mode")

    In all three cases, the IME candidate window and preedit text appeared at the position of the last rendered text on screen, never at the input prompt where the user is actually typing.

    Impact on VS Code integrated terminal

    When the IME preedit appears near the right edge of the status line (Scenario 1, the default), the preedit text extends beyond the terminal width, causing the entire display to shift right and clip the left side of the terminal content. This makes the CLI essentially unusable for CJK input in VS Code's integrated terminal, as the user loses visibility of both the input prompt and the left portion of the screen.

    Screenshots

    Screenshot 1 — Default state: preedit appears after status info (bottom-right), display area shifts right

    Image

    Screenshot 2 — After /on-air: preedit appears after the first output line ending with "skills"

    Image

    Screenshot 3 — After focusing input box: preedit appears after footer "switch mode"

    Image

    Possible root cause (speculation)

    It looks like the TUI framework may not be moving the terminal cursor back to the input line position after rendering the full screen. The IME subsystem (on both Windows and macOS) typically uses the terminal's reported cursor position to place the composition window. If the cursor is left wherever the last write ended (e.g., the status bar or footer), the IME window would appear there instead of at the input prompt.

    This might be consistent with how Gemini CLI had the same issue and fixed it — possibly by ensuring the terminal cursor is repositioned to the input line after each render cycle.

    Environment

    • OS: Windows (VS Code integrated terminal)
    • Copilot CLI: 0.0.420
    • IME: Microsoft IME (Japanese)
  4. devm33
    closed this as completedon Mar 4, 2026
  5. github-actions
    removed
    triage
    on Mar 4, 2026

  6. devm33 commented on Mar 4, 2026

    @devm33
    devm33
    on Mar 4, 2026
    Member

    Thanks for reporting! This should be fixed in the next release.

  7. torumakabe commented on Mar 6, 2026

    @torumakabe
    torumakabe
    on Mar 6, 2026

    @devm33 Thank you for the fix in v0.0.422-1! The IME candidate window positioning is now correct in most environments I tested.

    However, I found that the issue remains unresolved in one specific environment: Windows (native process) + VS Code integrated terminal.

    Test Results (v0.0.422-1)

    OS Terminal IME Result
    macOS Ghostty macOS standard IME ✅ Fixed
    macOS VS Code integrated terminal macOS standard IME ✅ Fixed
    Windows Windows Terminal Microsoft IME ✅ Fixed
    WSL Windows Terminal Microsoft IME ✅ Fixed
    WSL VS Code integrated terminal Microsoft IME ✅ Fixed
    Windows (native) VS Code integrated terminal Microsoft IME ❌ Not fixed

    For reference, all of these tests were run with --alt-screen on.

    Observations

    The key pattern is:

    • VS Code terminal itself is not the issue — it works on macOS and WSL
    • Windows itself is not the issue — it works on Windows Terminal
    • The problem is specific to running as a native Windows process inside VS Code's terminal

    WSL + VS Code terminal works because VS Code's remote server uses a Linux PTY (bypassing ConPTY), whereas native Windows uses ConPTY as the PTY backend for xterm.js.

    Possible upstream factor (speculation)

    This may be related to how ConPTY synchronizes cursor position with xterm.js. There are existing upstream issues that describe similar symptoms:

    I'm not certain whether this is something that can be addressed on the Copilot CLI side or if it requires upstream fixes. Would it be worth reopening this issue or creating a new one to track this specific environment?

    Environment

    • OS: Windows 11
    • Terminal: VS Code integrated terminal
    • Copilot CLI: v0.0.422-1
    • IME: Microsoft IME (Japanese)

  8. MtkN1 commented on Mar 6, 2026

    @MtkN1
    MtkN1
    on Mar 6, 2026
    Author

    Thank you for releasing v0.0.422! However, contrary to @torumakabe's test results, the issue has not been resolved in my Windows Terminal (WSL) environment. I believe this is reproducible as I have tried it on several Windows terminals. Are other users experiencing similar issues?

  9. itchenfei commented on Mar 6, 2026

    @itchenfei
    itchenfei
    on Mar 6, 2026

    Still have this issue. Microsoft Pinyin

    PS C:\Users\a\projects\uaf_project\uaf-st1> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
    20260306-114335.mp4

  10. devm33 commented on Mar 7, 2026

    @devm33
    devm33
    on Mar 7, 2026
    Member

    Hi @itchenfei and @MtkN1 sorry I should have specified, the fix was only able to be applied to the alt-screen experience. Please run (once) with --alt-screen to enable. We are working to make this the default rendering experience.

    @torumakabe looking through the linked issues if the problem you're seeing on Windows in VS Code's terminal is the same then likely need to wait for upstream xtermjs/xterm.js#5616 to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions