[BUG] Claude for PowerPoint/Excel/Word add-ins: Japanese kana direct input (仮名入力) outputs raw keystrokes instead of kana characters

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

What's Wrong?

When using Japanese kana direct input mode (仮名入力) in the Claude plugin for PowerPoint
(and likely Excel/Word) add-in chat input field, raw keystrokes are displayed instead
of the expected kana/kanji output.

Concrete example — typing「で」:

In JIS kana layout, 「で」requires two physical keystrokes:

1. W key → 「て」
2. @ key → dakuten 「゛」(voiced mark, located at @ in JIS kana layout)

Expected input field output: で
Actual input field output: w@

The add-in receives and displays the raw physical keystrokes, bypassing IME composition
entirely.

---

Root Cause Hypothesis

All Office add-in task panes (Word, Excel, PowerPoint, Outlook) run inside a WebView2
control hosted by the Office process using Visual hosting mode.

In Visual hosting mode, the host application (Office) is responsible for forwarding
input events — including IME composition messages — to the WebView2 control.
(Reference: https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/windowed-vs-visual-hosting)

For romaji input, the IME produces composed characters that flow through normal keyboard
events, so they reach the WebView2 input field correctly.

For kana direct input, the IME relies on WM_IME_COMPOSITION message routing. This
message is delivered to the Office HWND but is not correctly forwarded into the WebView2
task pane, causing raw keystrokes to appear instead of composed kana.

Microsoft Edge (the browser) does not exhibit this issue because the browser window
itself is the HWND and receives WM_IME_COMPOSITION directly — there is no forwarding
layer.

This is consistent with known WebView2 IME issues in Visual hosting mode:

• https://github.com/MicrosoftEdge/WebView2Feedback/issues/2758
• https://github.com/MicrosoftEdge/WebView2Feedback/issues/869 (labeled priority-low)

---

Steps to Reproduce

1. Open Microsoft PowerPoint (Microsoft 365, Windows 11)
2. Open the Claude by Anthropic add-in from the Home ribbon
3. Switch Windows IME to Japanese kana direct input mode (仮名入力)

• Right-click the IME icon in the taskbar → 「かな入力 (オン)」

1. Click the chat input field in the add-in task pane
2. Type any voiced kana requiring a dakuten key:

• 「で」= W key + @ key
• 「ば」= F key + @ key
• 「ぞ」= & key + @ key

Expected: Kana characters appear in the input field
Actual: Raw Latin keystrokes appear (w@, f@, &@)

---

Environment

• OS: Windows 11
• Microsoft 365: PowerPoint MSO version 2604 (Build 16.0.19929.20136) 64-bit
• WebView2 Runtime: Evergreen (bundled with Microsoft 365)
• IME: Microsoft IME, kana direct input mode (仮名入力モード)
• Keyboard: Japanese 109-key (JIS layout)
• Affected add-ins: Claude for PowerPoint (confirmed), likely Claude for Excel and

Claude for Word as well (same task pane / WebView2 architecture)

---

Impact

This issue affects all Office add-ins with text input, not just Claude for PowerPoint.

All Office add-in task panes (Word, Excel, PowerPoint, Outlook) share the same
WebView2-based hosting architecture. Therefore, kana direct input is broken across
the entire Office add-in ecosystem for any add-in that contains a text input field.

Kana direct input (仮名入力) is the preferred input method for a significant portion
of Japanese business users, particularly experienced typists and older professionals.
This makes the Claude add-in family effectively unusable for these users without a
workaround.

Workaround (current): Type Japanese text in a separate application (Notepad, etc.)
and paste into the add-in chat field. Romaji input (ローマ字入力) is not affected.

---

Key Evidence: Microsoft's own Copilot pane is NOT affected

The built-in Microsoft 365 Copilot pane (in PowerPoint, Word, and Excel) handles kana
direct input correctly in the same Office / WebView2 environment.

This confirms two things:

1. A fix is feasible at the application layer — no WebView2 runtime update is required.
2. Microsoft has already solved this problem for their own product, whether via

JavaScript-level IME composition event handling (compositionstart /
compositionupdate / compositionend) or through a first-party hosting privilege.

The existence of a working solution in the same environment makes "WebView2 limitation"
an insufficient explanation for leaving this unresolved in the Claude add-ins.

---

Suggested Fix

Since Microsoft's Copilot pane works correctly in the same environment, a JavaScript-
level fix is confirmed feasible.

Option A (recommended): Implement IME composition event handling in the add-in's
JavaScript using compositionstart / compositionupdate / compositionend events to
correctly reconstruct kana input from the raw keystroke stream. This is the approach
Microsoft appears to use in their own Copilot pane.

Option B (short-term): Detect kana input mode via the compositionstart event and
display a UI hint guiding the user to switch to romaji input, reducing confusion while
Option A is implemented.

---

Note

This is not a Claude Code CLI issue. Filed here because there is no dedicated repository
for Claude for PowerPoint/Excel/Word. Similar pattern to #25747 and #27193 (Office
add-in issues filed in this repo).

Related upstream: https://github.com/MicrosoftEdge/WebView2Feedback/issues/869

What Should Happen?

What's Wrong?

When using Japanese kana direct input mode (仮名入力) in the Claude for PowerPoint
(and likely Excel/Word) add-in chat input field, raw keystrokes are displayed instead
of the expected kana/kanji output.

Concrete example — typing「で」:

In JIS kana layout, 「で」requires two physical keystrokes:

1. W key → 「て」
2. @ key → dakuten 「゛」(voiced mark, located at @ in JIS kana layout)

Expected input field output: で
Actual input field output: w@

Error Messages/Logs

Steps to Reproduce

What's Wrong?

When using Japanese kana direct input mode (仮名入力) in the Claude for PowerPoint
(and likely Excel/Word) add-in chat input field, raw keystrokes are displayed instead
of the expected kana/kanji output.

Concrete example — typing「で」:

In JIS kana layout, 「で」requires two physical keystrokes:

1. W key → 「て」
2. @ key → dakuten 「゛」(voiced mark, located at @ in JIS kana layout)

Expected input field output: で
Actual input field output: w@

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — This issue is in the Claude for PowerPoint Office add-in, not the Claude Code CLI.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

<img width="3686" height="2385" alt="Image" src="https://github.com/user-attachments/assets/dacd8dbb-f495-481f-9258-3931824b60bb" />