Pressing Enter cancels the running turn, because focus moves to the Stop button on submit

What happens

In the Claude Code desktop app, submitting a prompt moves keyboard focus off the text input and onto the
Stop button. Enter then activates whatever is focused, so the next Enter cancels the run.

Two Enters in a row is enough, and it is a natural thing to type: the first one submits the prompt, the
second one cancels everything it just started.

Steps to reproduce

1. Type a prompt into the input.
2. Press Enter. The turn starts.
3. Press Enter again, without clicking anything.

Expected: the second Enter does nothing, or types a newline, or queues an empty message. It does not
stop the run.

Actual: the run is cancelled, as if the Stop button had been clicked.

Why it reads as a focus bug rather than a keybinding

Clicking back into the text input first restores the normal behaviour: with focus in the input, Enter
queues a follow-up message and the running turn continues uninterrupted. The destructive behaviour only
appears while focus sits on the Stop button, which is where submitting the prompt leaves it.

Impact

• The cancellation is silent and immediate: nothing asks for confirmation, and a long turn that has

already run for minutes is lost mid-work.

• It costs real work. A turn can be running tool calls that edit files and run commands, so cancelling

halfway leaves that work half-done.

• The keystroke that causes it is the same one that submits, so the failure is reached by typing slightly

too fast, not by aiming at anything.

Suggested fix

Keep keyboard focus in the text input after submitting. If focus must leave it, the Stop button should not
be the default focus target, or it should not respond to Enter.

Environment

• Claude Code desktop app, macOS 26.5.2 (Darwin arm64).
• Reproduced repeatedly during normal use, not tied to any one project or session.

Also submitted through the app's own feedback form, reference ID d09b8df7-3d59-4918-9b60-5b09ee8ec4d4.