About two weeks into using Antigravity daily, I hit something I don't usually see in plain VS Code: I typed a Japanese comment, hit Enter to confirm the IME candidate, and the editor swallowed the whole composition and pasted an English suggestion in its place. If you write in Japanese, Chinese, or Korean, odds are you've hit a variant of this.
IME trouble in Antigravity rarely has a single root cause. The AI inline completion runs constantly, keybinding extensions hook the same keys your IME needs, and the WebView-based panels (chat, Manager Surface) occasionally intercept composition events before the editor receives them. The good news: once you know which of the four common patterns you're hitting, each one is a ten-minute fix.
Identify your symptom first
These four patterns look similar but have different fixes. Check yours before applying changes.
- Pattern A: The composition underline disappears mid-typing, or characters are replaced with something unexpected.
- Pattern B: While cycling candidates with Space, the AI inline completion commits itself and overwrites your composition.
- Pattern C: Re-conversion keys (Control+Shift+R on macOS Kotoeri, for example) stop responding.
- Pattern D: Typing full-width punctuation (
、,。,,) triggers an unintended command.
A and B point to AI completion or extension conflicts. C suggests the OS input method and the editor are disagreeing about focus. D is almost always a keybindings.json clash.
Patterns A & B — stop AI completion from hijacking the IME
Antigravity's inline completion sometimes treats your pre-commit IME buffer as a candidate worth replacing. The moment you press Tab or Enter to confirm the Japanese candidate, the AI interprets the same keystroke as an accept and pastes an English completion over the top.
Open your user settings.json from the Command Palette (Preferences: Open User Settings (JSON)) and add:
{
// Suppress inline suggestions while the IME buffer is active
"editor.inlineSuggest.suppressSuggestions": true,
"editor.suggest.preview": false,
"editor.quickSuggestions": {
"comments": "off",
"strings": "off",
"other": "on"
},
// Change Antigravity's inline completion trigger to manual (Cmd+\)
"antigravity.inlineCompletion.trigger": "manual"
}Setting the inline completion trigger to "manual" is the change that made the biggest difference for me. Completions still appear, but only when I press Cmd+\ (or Ctrl+\ on Windows/Linux). Anyone who writes long CJK comments inside code will probably prefer this mode permanently.
If you'd rather keep automatic completion but disable it only inside comments and strings, the editor.quickSuggestions settings above are enough on their own — you don't need the manual-trigger change.
Pattern C — restore re-conversion on macOS
When "select confirmed Japanese text and press Control+Shift+R to re-convert" stops working, it usually means Antigravity's WebView panels (chat, Manager Surface) are capturing the input event before the OS sees it.
Isolate the cause before changing anything:
# 1. Open a profile with all extensions disabled:
# Command Palette → "Developer: New Empty Window with Extensions Disabled"
# 2. Try re-conversion in that window.
# 3. If it works there, re-enable extensions one at a time to find the culprit.If extensions aren't the problem, check for a keybinding clash at the OS level. On macOS, open System Settings → Keyboard → Input Sources → Edit, and look at the shortcuts for your IME (Kotoeri, Google Japanese Input, Kawasemi). In my setup, Ctrl+Shift+R was bound to Antigravity's "Restart Window" command, which silently ate the re-conversion trigger. Remapping the IME side to Ctrl+Shift+J fixed it.
The Antigravity Editor advanced customization guide covers how keybinding precedence works between the OS, Antigravity, and extensions — worth skimming if you hit clashes often.
Pattern D — block full-width punctuation from firing commands
Every few months someone reports that typing 、 or 。 in Japanese opens the Command Palette. This happens because a keybindings.json entry responds to the character, and the IME-composed output reaches the keybinding layer.
Fix it by adding an IME-aware when clause. Open Preferences: Open Keyboard Shortcuts (JSON) and add:
[
{
// Disable Command Palette shortcut while IME composition is active
"key": "ctrl+,",
"command": "-workbench.action.showCommands",
"when": "editorTextFocus && !inComposition"
},
{
// Disable Save while IME composition is active (so the commit happens first)
"key": "cmd+s",
"command": "-workbench.action.files.save",
"when": "!inComposition"
}
]!inComposition is a built-in context key meaning "IME has no pending composition". Adding it to any keybinding that competes with CJK input prevents almost all accidental firings mid-conversion.
Still broken? A checklist
If none of the patterns match or the fix didn't stick, walk through this before filing a bug:
- Antigravity version: Check
Help → Aboutand scan the changelog for any recent IME-related fixes. - Extension conflicts: Temporarily disable Vim, IdeaVim, Emacs Keymap, or any keybinding-override extension and retry.
- OS input method: On macOS, try toggling Live Conversion off. On Windows, switch MS-IME to "Previous version (compatibility mode)". On Linux, inspect
fcitx/ibusconfiguration and make sure the editor is registered as an IME-aware client. - Profile switch: Use
Preferences: Switch Profileto create an empty profile and reproduce there. Profile-level keybinding inheritance sometimes reveals the real cause.
If AI completion is misbehaving in other ways alongside the IME issue, the troubleshooting guide for tab completion has a structured diagnostic flow. Silently-crashed language servers can also masquerade as completion problems — see diagnosing unresponsive language servers for that case.
What to do next
IME problems are the kind of thing people "fix with a restart and forget", until it hits again at 2 a.m. the day before a deadline. Even if you only take one thing from this article, add this single line to your settings.json today:
"editor.quickSuggestions": { "comments": "off", "strings": "off" }It removes the most common source of CJK composition accidents and costs you nothing in code completion. You'll notice the difference on the first comment block you write tomorrow morning.