here's what i found: every AI coding environment i tested has the same structural bug when you type in Japanese.
not "some of them." all of them, across different codebases and different teams.
the bug isn't flashy. it doesn't crash anything. but if you type Japanese in an AI coding tool and wonder why it feels off, this is probably why.
what IME composition actually is
Japanese input works differently from English. you type roman characters to form a Japanese word, and the OS enters a "composition state" -- the text is provisional, unconfirmed. you press Enter (or a function key) to confirm the word and commit it to the field. the browser fires compositionstart, then compositionupdate as you type, then compositionend when you confirm.
the problem: confirming an IME word uses the same physical key (Enter) that most apps use to "submit" or "execute."
properly handling this requires checking event.isComposing before acting on Enter, or waiting for compositionend to fire first. it's one of those things that only surfaces when someone actually tests CJK input on a real Japanese keyboard session.
pattern 1: Enter during composition triggers the wrong action
in any input wired to "send on Enter," pressing Enter to confirm a Japanese word also fires the send. you wanted to commit 確認 to the text field. instead you submitted an incomplete message, or ran an empty command.
this is the most common form. i've run into it in chat UIs, terminal prompts, AI command bars, inline editors. the fix is always the same -- check event.isComposing before acting -- but it requires knowing the bug exists. if your QA happens in English, it's invisible.
pattern 2: the IME candidate window collides with AI overlays
AI coding tools add their own overlays: autocomplete popups, inline suggestions, slash command menus. these need to be positioned relative to cursor. on Windows or macOS with Japanese input active, the OS's own IME candidate window appears near the cursor too.
when both exist, they stack. the AI suggestion panel and the kanji candidate list fight for the same screen real estate. which one wins depends on z-index and platform behavior. neither the tool nor the OS wins cleanly.
this is harder to fix than the Enter problem, because there's no standard API to ask the OS where the IME window is sitting. it requires the tool to actively coordinate around it.
why this keeps appearing in well-funded products
i've submitted about two dozen i18n and CJK-related patches across open source projects. what i notice is consistent: it's not that these teams are careless. it's that CJK input almost never makes it into the release test matrix.
compositionstart doesn't fire during English typing. the Enter-to-submit shortcut works fine on Latin keyboards. the test suite passes. the product ships. the bug is invisible until someone outside the core team uses the product in its actual CJK context.
AI coding agents add another dimension here. they layer additional keyboard-listening logic on top of existing editors -- each layer is another place composition state can be dropped or misread. the more agentic the tool (intercepting keystrokes, watching for trigger phrases, managing context windows), the more surfaces there are for the bug to live.
the structural gap
this isn't about one product being sloppy. it's a category pattern: tools built and tested primarily in English environments ship with CJK edge cases that only get caught when users in Japan, China, Korea, or Taiwan try to use them seriously in production.
the fix for pattern 1 is genuinely simple:
input.addEventListener('keydown', (e) => {
if (e.key === 'Enter' && !e.isComposing) {
handleSubmit();
}
});
compositionstart and compositionend have been in the browser spec for years. this isn't obscure. it's just not tested.
i don't expect this to change until CJK test coverage becomes a gate rather than an afterthought -- or until more people from these communities speak up about it inside the repos where it matters.
field notes on the Japan-shaped holes in global software · github.com/greymoth-jp
Top comments (0)