Skip to content

macOS: IME commit with 2+ characters triggers unexpected clipboard paste when clipboard contains image #8764

New issue
New issue
Closed
Closed
macOS: IME commit with 2+ characters triggers unexpected clipboard paste when clipboard contains image#8764

Description

@bulice
bulice
opened on Nov 25, 2025

Description

When the macOS clipboard contains an image, using Chinese IME (Input Method Editor) to input 2 or more characters triggers an unexpected
paste operation in TUI applications like Claude Code (ink-based terminal UI).

Single character input works fine. The issue only occurs when committing 2+ characters from the IME candidate selection.

Steps to reproduce

  1. Copy an image to the macOS clipboard (e.g., screenshot with Cmd+Shift+4)
  2. Open Alacritty and launch a TUI application (tested with Claude Code, which uses ink for terminal UI)
  3. Switch to Chinese IME (tested with WeChat Input Method, macOS native Pinyin, and Sogou - all reproduce the issue)
  4. Type pinyin and select a word with 2+ characters from candidates
  5. Result: The selected Chinese text appears briefly, then gets replaced by the clipboard image being pasted

Expected behavior

Chinese text should be committed normally without triggering any clipboard/paste operation.

Observations

  • Single character input: works fine
  • 2+ character input: triggers unexpected paste
  • Same steps in vim/nano inside Alacritty: works fine
  • Same steps in other terminals (iTerm2, Terminal.app) with Claude Code: works fine
  • Minimal Alacritty config (only shell specified): still reproduces

This suggests the issue is specific to how Alacritty handles IME commit events in combination with certain TUI frameworks.

System

  • OS: macOS 15.1 (Darwin 25.1.0)
  • Alacritty version: 0.16.1 (42f49ee)
  • Shell: fish
  • Affected IMEs: WeChat Input Method, macOS Pinyin, Sogou Pinyin (all tested)
  • TUI application: Claude Code (ink-based React terminal UI)

Logs

[Launch alacritty with alacritty -v if debug logs are needed]

Additional context

The issue appears to be related to how Alacritty processes multi-character IME commit events on macOS. When the clipboard contains an image
(not just text), something in the commit handling path seems to trigger a paste operation.

Activity

  1. chrisduerr commented on Nov 25, 2025

    @chrisduerr
    chrisduerr
    on Nov 25, 2025
    Member

    Are you suggesting the path to the image gets pasted? Alacritty is incapable of pasting images.

  2. askfiy commented on Nov 25, 2025

    @askfiy
    askfiy
    on Nov 25, 2025

    same! i use claude on alacritty! input many cjk char, auto replace [image #.]. i use macos.

  3. chrisduerr commented on Nov 25, 2025

    @chrisduerr
    chrisduerr
    on Nov 25, 2025
    Member

    Getting the alacritty --print-events log while this is happening would likely provide some insights.

  4. shenyfg commented on Dec 25, 2025

    @shenyfg
    shenyfg
    on Dec 25, 2025

    Getting the alacritty --print-events log while this is happening would likely provide some insights.

    Hi, I reproduced this issue and attatched the log file—hope this helps.

    Image

    1.txt

  5. chrisduerr commented on Jan 2, 2026

    @chrisduerr
    chrisduerr
    on Jan 2, 2026
    Member

    @shenyfg Your log contains the following IME events:

    Ime(Commit("hello"))
Ime(Enabled)
Ime(Preedit("hello", Some((5, 5))))
Ime(Preedit("he l l", Some((6, 6))))
Ime(Preedit("he l", Some((4, 4))))
Ime(Preedit("he", Some((2, 2))))
Ime(Preedit("h", Some((1, 1))))
Ime(Preedit("", None))

    So it seems pretty clear that what happens here should be "hello" getting submitted to the terminal through IME.
    There's nothing in the logs suggesting that indicates Alacritty is trying to paste anything.

    I'd be curious to know what happens when the clipboard doesn't contain an image, since nobody mentioned that but if Alacritty was pasting things, then that should also happen when text is in the clipboard.

    So far since all of you are talking about some random AI app, I'm going to go with blaming the app itself on this one. If you can reproduce this in a real application or on a plane bash prompt, please let me know.

  6. chrisduerr
    closed this as completedon Jan 2, 2026

  7. chrisduerr commented on Jan 2, 2026

    @chrisduerr
    chrisduerr
    on Jan 2, 2026
    Member

    Just as a follow-up I want to point out that Alacritty does submit IME text through bracketed paste mode (iirc), so my guess would be that the application is trying to be smart by detecting that and fails horribly to function properly in the process.

  8. chrisduerr commented on Jan 2, 2026

    @chrisduerr
    chrisduerr
    on Jan 2, 2026
    Member

    Just out of curiosity I decided to take a look at the claude-code bugtracker and with the million open issues regarding bracketed paste mode I can only recommend people to stay far away from that mess.

  9. bulice commented on Apr 8, 2026

    @bulice
    bulice
    on Apr 8, 2026
    Author

    Follow-up: confirmed this is a Claude Code (ink TUI) issue, not Alacritty.

    Ran alacritty --print-events and captured the IME commit for "你好":

    [107.063s] Ime(Commit("你好"))    ← single atomic commit, correct
[107.113s] Terminal(Wakeup) × 5   ← Claude Code triggers 5 wakeups + 4 redraws for 2 chars

    Alacritty commits the full string atomically. The flickering is caused by Claude Code's ink-based TUI processing bracketed paste content character-by-character instead of batching into a single render.

    Filed upstream: anthropics/claude-code#44939

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

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions