[Claude Desktop / Windows] Enter inserts newline instead of submitting in the Code tab (works in Chat tab and in the same bundled CLI standalone)

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Desktop: 1.44121.4 (Microsoft Store / WindowsApps install)
• Bundled Claude Code: 2.1.258 (%APPDATA%\Claude\claude-code\2.1.258\claude.exe)
• Also tested: Claude Code 2.1.208 (standalone global install)

Summary

In the Claude Desktop Code tab, pressing <kbd>Enter</kbd> inserts a newline instead of submitting the prompt. It never submits, at any window size, including fullscreen.

The same keypress submits correctly in the Desktop Chat tab, and in the exact same bundled claude.exe binary when launched from a normal terminal. This isolates the defect to the Code tab's terminal host, not to Claude Code and not to the user's configuration.

Evidence matrix

| Layer under test | Enter behavior |
| --- | --- |
| Windows / keyboard (raw byte capture) | emits [13] CR (0x0D) — correct |
| Claude Code 2.1.208 standalone, in PowerShell 7 | submits |
| Claude Code 2.1.258 standalone, in PowerShell 7 (the exact build the app bundles) | submits |
| Claude Desktop Chat tab | submits |
| Claude Desktop Code tab | inserts newline |

Same machine, same keyboard, same binary. Only the host differs.

Reproduction

1. Open Claude Desktop on Windows 11 and switch to the Code tab.
2. Type hi — a bare, single-word prompt with no autocomplete open, no attachment, no trailing backslash.
3. Press <kbd>Enter</kbd>.
4. Expected: the prompt submits. Actual: a newline is inserted; the prompt is never sent.
5. Launch the app's own bundled binary from a terminal:

``
& "$env:APPDATA\Claude\claude-code\2.1.258\claude.exe"
``

1. Type hi, press <kbd>Enter</kbd> → submits correctly.

Ruled out

Each of these was tested and eliminated, in this order:

• Keybinding configuration. No ~/.claude/keybindings.json existed; enter → chat:submit was already the default. Adding an explicit binding changed nothing.
• tui: fullscreen setting. Removing it changed nothing. (The behavior is also independent of window size, contrary to some community reports.)
• Trailing-backslash line continuation. Fails on a bare hi.
• Low-level keyboard hooks (WH_KEYBOARD_LL), per #34321. Logi Options+ was fully quit and then uninstalled, followed by a full app quit and a logout → login cycle. No change.
• PowerToys Keyboard Manager. Installed but not running; its remap table contains no Enter entry (only F12→F11, F1→Ctrl+Alt+Shift+F1, F2–F5→text).
• Stuck modifier keys. hi types lowercase, so Shift is not held.
• CR/LF mistranslation. A raw setRawMode byte logger confirms the Enter key produces [13] (CR), not [10] (LF). So Enter is not arriving as a Ctrl+J equivalent.
• Claude Code version regression. Both 2.1.208 and 2.1.258 submit correctly standalone.

Relationship to prior issues

This is likely the same user-visible symptom as #34321, #34091, #30929 and #31236, all of which were closed as "doesn't appear to be about Claude Code."

That dismissal appears correct but incomplete. The defect is genuinely not in Claude Code — the CLI is provably fine at the bundled version. It is in the Claude Desktop Code tab's terminal host, which is why it kept getting routed away. Those reports also attributed the trigger to keyboard hooks; that attribution does not hold here, since the symptom persists after the hook software is uninstalled and the byte-level capture is clean.

Impact

The Code tab cannot be used with the Enter key at all. Workarounds are to run claude in an external terminal, or to submit with <kbd>Ctrl</kbd>+<kbd>X</kbd> <kbd>Enter</kbd>. There is no user-facing setting for Enter behavior — the app's localization string table contains no "Enter to send" option.