macOS: Chinese IME keystrokes leak into terminal during composition

[ChrisOr-Dev]

Issue Description

When using a Chinese input method (Cangjie, Zhuyin, or Pinyin) on macOS, the Roman letter keystrokes used to compose Chinese characters leak into the terminal input, causing unintended characters to appear.

For example, typing a Chinese character that requires pressing c twice in Cangjie input results in cc appearing in the terminal prompt in addition to (or instead of) the intended Chinese character.

This is a regression/continuation of the same root cause reported in:

• Discussion macOS: Some input method keybinds penetrates #2628 — macOS: Some input method keybinds penetrates (Japanese AquaSKK, unfixed)
• Issue Ctrl+key keybinds broken during Chinese IME composition (macOS) #11550 — Ctrl+key keybinds broken during Chinese IME composition (closed by bot, unfixed)

The issue has persisted unfixed through at least v1.3.1.

Expected Behavior

IME keystrokes should be consumed entirely by the input method and not forwarded to the terminal. This is the standard macOS NSResponder behavior. Both iTerm2 and Terminal.app handle this correctly — only the composed Chinese character is sent to the terminal.

Actual Behavior

The Roman letter keystrokes used during Chinese IME composition (e.g. c, c for a Cangjie character) are leaked into the terminal, producing unintended literal characters in the shell prompt alongside or instead of the composed Chinese character.

Reproduction Steps

1. Open Ghostty on macOS.
2. Switch to a Chinese input method (Cangjie, Zhuyin, or Pinyin).
3. Type any Chinese character that requires multiple Roman keystrokes (e.g. press c twice in Cangjie).
4. Observe that the Roman keystrokes (e.g. cc) appear literally in the terminal prompt.
5. Open Terminal.app or iTerm2 and repeat — the leak does not occur.

Ghostty Logs

No relevant logs captured; the issue is reproducible consistently.

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.4.1 (Build 25E253)

Minimal Ghostty Configuration

# Default configuration — reproducible with no custom config

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the Preview tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks.

[Nagato-Yuzuru]

I have same issue. Other terminals don't penetrates.

In Vim, this issue causes unexpected characters to be inserted.

[Nagato-Yuzuru]

I might be wrong, this isn't necessarily a same problem.

[bo2themax]

I'm not sure what "leak" means in your description, but I think it's also probably fixed by #12547.

[mickeyhuang-sketch]

Still broken on 1.3.1, and it's worse than "letters leak during composition" — it breaks copy/paste entirely for CJK users.

Setup: Ghostty 1.3.1 (stable), macOS 26.6.2, Apple built-in Traditional Chinese Zhuyin input source (com.apple.inputmethod.TCIM.Zhuyin).

Repro:

1. Switch to Zhuyin. Don't type anything.
2. Press Cmd+C.
3. The terminal receives "c", which the IME turns into the Bopomofo symbol ㄏ and opens a composition.
4. Press Cmd+V. Nothing is pasted — the paste is swallowed by the open composition.

So every copy/paste cycle requires switching to an English input source first. Terminal.app and iTerm2 handle the exact same steps correctly. Chinese, Japanese and Korean users all live with an input method toggled on, so this isn't an edge case; it is the default state for a large part of your user base.

I see #12547 ("avoid replaying keys that commit preedit") was merged on May 2 and may address this, but 1.3.1 shipped in March and there has been no stable release since. Could we get a 1.3.2 point release with that fix, or at least confirmation that it covers this case? Asking CJK users to run tip builds for a working Cmd+C is not reasonable.

While I'm here: #12842 (mixed text/HTML clipboard format since 1.3.0) also breaks pasting into Electron apps unless you rebind Cmd+C to copy_to_clipboard:plain. Two separate clipboard regressions in one stable release, both still open — the clipboard path could use a CJK and Electron test pass before the next release.

[jcollie]

There will not be a 1.3.2 point release. 1.4 will be released soon™ if you do not want to run a development build.