[BUG] Desktop app (macOS): Cmd+V starts a new session instead of pasting with German Neo 2 keyboard layout

Environment

• macOS (Darwin 25.5.0), Apple Silicon
• Claude desktop app 1.11847.5, bundled Claude Code CLI 2.1.131
• Keyboard layout: "Deutsch (Neo 2)" via the official neo-layouts.bundle from https://neo-layout.org (the layout relocates most letter keys; the character "v" sits on the physical W key)
• No custom ~/.claude/keybindings.json

Steps to reproduce

1. Select the German Neo 2 keyboard layout in macOS input sources.
2. Copy any text or a screenshot to the clipboard.
3. Focus the composer in the Claude Code desktop app and press Cmd+V (i.e. Cmd + the key that types "v", which is the physical W key under Neo 2).

Expected: clipboard content is pasted into the composer.

Actual: a new session is started; nothing is pasted. Happens for both text and image clipboard content. This is a recent regression — it started a short while ago, the same setup worked fine before.

Additional observations

• Cmd+W typed as a character (physical T key under Neo 2) correctly closes the window — that shortcut is matched by the produced character and works fine with the layout.
• Cmd + physical V key (which types "p" under Neo 2) does nothing — expected, since the native paste menu accelerator is character-based.
• Cmd+V pastes normally in other macOS apps with the same layout, so the layout's Cmd plane reports the correct characters to the OS.
• The configurable TUI keybinding system (~/.claude/keybindings.json) has no "new session" action, and the keybindings docs list cmd+v as macOS-reserved (not bound by the app) — so the trigger appears to live in the desktop shell layer, and there is no user-side rebinding workaround.

Interpretation

Some shell-level handler intercepts Cmd+V as typed on Neo 2 (character "v", physical KeyW) and starts a new session, swallowing the event before the native Edit-menu paste accelerator can fire. Since Cmd+W is matched correctly by character, shortcut matching appears inconsistent across handlers — possibly one code path matches the physical key position (event.code) while others match the produced character (event.key). Layouts that relocate letter keys (Neo, Dvorak, Colemak) would all be affected.

Not yet verified whether the issue also reproduces with QWERTZ/US layouts (i.e. whether it is strictly layout-dependent).