IME regression on macOS: duplicate characters, double-press Backspace, and Tab inserts literal \t with Boshiamy IME (broken between Stable 0.2026.04.29 and 0.2026.05.13)

[ethan-tsai-tsai]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there

Describe the bug

Between Warp Stable 0.2026.04.29.08.57.01 and 0.2026.05.13.09.15.03, IME handling on macOS regressed. With the Boshiamy (無蝦米) input method active, three distinct symptoms appear that did not exist in the prior Stable build:

1. Duplicate characters — committed characters appear twice (committed char + the raw latin keystrokes used during composition leak into the terminal).
2. Backspace requires two presses to delete a single character (first press is consumed by the IME composition buffer, second press reaches the shell).
3. Tab inserts a literal \t instead of triggering shell completion (Tab is sent as a raw character before the IME finishes committing).

All three symptoms are facets of the same underlying issue: IME composition keystrokes are leaking into the terminal instead of being fully consumed via NSTextInputClient, contrary to standard macOS NSResponder behavior.

To reproduce

1. macOS with the Boshiamy (無蝦米) input method selected as the active input source.
2. Open Warp Stable 0.2026.05.13.09.15.03.
3. Type any Chinese character via Boshiamy. Example: keys v o r → expected 項.
4. Observed: 項項 or 項vor appears in the prompt instead of just 項.
5. Press Backspace once → nothing visibly deleted. Press a second time → one character is deleted.
6. Press Tab during or immediately after composition → a literal \t is inserted; shell completion is not triggered.

Reproduces 100% of the time on the affected build. Does not reproduce at all on Warp Stable 0.2026.04.29.08.57.01 on a second Mac with the same OS family and the same Boshiamy install.

Expected behavior

• IME composition keystrokes should be fully consumed by the input method during composition. Only the committed text should reach the terminal.
• Backspace during/after composition should behave atomically — one press deletes one character.
• Tab should trigger shell completion, not insert a literal tab character, regardless of whether an IME is active.
• Behavior should match 0.2026.04.29.08.57.01, Terminal.app, and iTerm2.

Screenshots, videos, and logs

Screenshot of the duplicate-character symptom available on request (will attach via web UI in a follow-up comment). Happy to also capture a screen recording and attach Warp logs if it would help narrow down the offending build.

Operating system (OS)

macOS

Operating system and version

macOS 26.5 (build 25F71), Apple Silicon (arm64)

Shell Version

zsh 5.9

Current Warp version

v0.2026.05.13.09.15.03 (Stable channel, bundle ID dev.warp.Warp-Stable)

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

2026-04-29 — confirmed working on Warp Stable v0.2026.04.29.08.57.01 on a second Mac (same macOS family, same Boshiamy install, same shell, same locale). Regression window: 2026-04-29 → 2026-05-13 on the Stable channel.

Additional context

Bisect evidence

Machine	Warp version	Bundle ID	Channel	Symptoms
Broken (this report)	0.2026.05.13.09.15.03	dev.warp.Warp-Stable	Stable	All 3 symptoms
Working (second Mac)	0.2026.04.29.08.57.01	dev.warp.Warp-Stable	Stable	None

Only the Warp version differs between the two machines.

Cross-terminal verification (same machine as the broken Warp)

A/B tested Boshiamy on this same Mac in:

• Terminal.app — all 3 symptoms absent, Boshiamy works correctly.
• iTerm2 — all 3 symptoms absent, Boshiamy works correctly.

So the issue is specific to Warp 0.2026.05.13.09.15.03 on this machine; it is not a system-level IME or Boshiamy install issue.

Workarounds attempted (none resolved the issue)

• Switched Settings → Appearance → Input to Shell (PS1) (Classic Input). Symptoms unchanged — Classic Input only changes prompt rendering, not the IME handling layer.
• Verified LC_ALL / LANG are zh_TW.UTF-8.

Suspected cause

The NSTextInputClient implementation in the input layer appears to have changed between 0.2026.04.29 and 0.2026.05.13. Composition keystrokes are no longer being fully consumed by the IME, so they leak through as raw key events to the terminal. Boshiamy is particularly affected because its radical alphabet is a-z, which 100% overlaps with valid shell input — every leak is visible. IMEs whose composition uses non-ASCII radicals (e.g., Zhuyin's ㄅㄆㄇ) may hide the same leak.

Related issues

• Keybindings don't trigger on non-US input sources - international i18n ime international keyboards #341 (IME-related keybinding issues — still open)
• IME (Input Method Editor) Support Issues for Non-Latin Languages #6891 (general IME support — closed as duplicate of Keybindings don't trigger on non-US input sources - international i18n ime international keyboards #341)
• The problem of not being able to follow when inputting Chinese #2335 (Chinese input following issue)

This appears to be a fresh regression on top of the longer-standing IME limitations, not a pre-existing issue, so a revert of the input-layer change between 04-29 and 05-13 may be a quick fix candidate.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

[oz-for-oss]

@ethan-tsai-tsai

Here's what I found while triaging this issue:

This looks like a distinct macOS IME regression in terminal input handling, not something the Classic Input/Shell (PS1) setting would be expected to fix. I found related IME reports, but not a clear duplicate for this Boshiamy-specific Stable regression window.

I have a few follow-up questions before I can narrow this down:

1. Could you attach a short screen recording showing vor committing to 項, then one Backspace press, then Tab in the affected Stable build?
2. What exact macOS version and CPU architecture are on the broken and working machines?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that macOS Stable IME regression where Boshiamy composition keystrokes appear to leak into terminal input after commit..

Triage

This appears to be a macOS terminal input regression affecting IME composition and commit handling. The report includes exact working and broken Stable builds (0.2026.04.29.08.57.01 -> 0.2026.05.13.09.15.03), a concrete Boshiamy repro (vor -> 項), and three symptoms that are all consistent with composition key events leaking into terminal input.

Reproducibility

High. The issue is environment-specific because it requires macOS plus the Boshiamy IME, but the reporter supplied a narrow version regression window, concrete repro steps, locale details, and a negative test for Classic Input/Shell (PS1).

Likely root cause

The most relevant code is the macOS text input bridge and terminal key suppression path. WarpHostView calls interpretKeyEvents: in keyDownImpl, batches committed text from insertText:, tracks marked text through setMarkedText: / unmarkText, and then dispatches the original KeyDown into Rust with an is_composing flag. Terminal elements suppress ordinary key handling while is_composing is true, but if a Boshiamy commit leaves the event classified as non-composing, both the committed IME text and the raw radical/control key event can reach the terminal.

The reported Stable window contains recent macOS IME changes touching this path: fc1157e066 (performKeyEquivalent: skip while IME is composing) and 3ff78d29b5 (marked-text/insertText handling for Japanese IME split commits). Those commits are not confirmed as the cause, but they are the highest-signal starting points for investigation.

Duplicate check

I found related IME issues (#341, #2335, #8566, #8919, #9906), but not two open issues matching this exact macOS Boshiamy regression with duplicate committed/raw text plus Backspace and Tab leakage, so I am not marking this as a duplicate.

Question reasoning

1. Could you attach a short screen recording showing vor committing to 項, then one Backspace press, then Tab in the affected Stable build? — The exact timing of commit versus raw key leakage will help confirm whether the raw Boshiamy radicals/control keys are emitted before, during, or after marked text is cleared.
2. What exact macOS version and CPU architecture are on the broken and working machines? — The report says the machines are in the same macOS family, but exact AppKit/architecture differences can affect IME behavior and will help maintainers reproduce the regression locally.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz