[BUG] Cmd+Enter no longer queues a message, it interrupts the running turn

Status Open
Maintainer reply None cached
Activity 3 comments · opened Sep 10, 2026

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?

Cmd+Enter no longer queues a message, it interrupts the running turn
Environment
Claude desktop app (Code tab), version 1.49585.0
macOS 26.5 (25F71), Apple Silicon
Bundle written 2026-09-08 06:07, executable stamped 06:08, so the update applied on the next relaunch after that
Previous working version unknown: the updater kept no cached bundle, so there is no local rollback and no version number to point at
Summary
Cmd+Enter used to add a message to a visible queue, held until the current turn finished, with the option to cancel or edit it while it sat there. After updating, the same keystroke sends immediately and cancels whatever is in flight. The queued item and its cancel and edit controls no longer appear at all.

Expected
Cmd+Enter during a running turn adds the message to the queue. The turn continues. The queued message shows in the UI and can be cancelled or edited before it is sent.

Actual
The message is delivered straight away, the in-flight turn is cancelled, and the transcript records "[Request interrupted by user]". No queue chip appears at any point.

Steps to reproduce
Open the Code tab and give Claude something that runs a tool for several seconds, for example a shell command that sleeps.
While that tool call is executing, type a message and press Cmd+Enter.
Observe the tool call is cancelled and the message is processed immediately, rather than being queued until the turn ends.
Reproduced repeatedly in one session, including against an in-flight Bash tool call, which is the clearest case: the tool was cancelled mid-execution.

Impact
The queue was the way to stack up follow-ups without breaking a long-running turn. Losing it means any mid-turn message destroys the work in progress, and there is no longer a confirmation step to cancel or edit a message sent by accident. Partial tool work is lost rather than completed.

Notes
The CLI interactive-mode docs describe Enter to queue and Esc to interrupt, which is the terminal surface. This report is about the desktop app's Cmd+Enter queue UI, which those docs do not cover. Recent CLI release notes mention input responsiveness and input character handling fixes but say nothing about queuing or mid-turn steering.

What Should Happen?

Expected
Cmd+Enter during a running turn adds the message to the queue. The turn continues. The queued message shows in the UI and can be cancelled or edited before it is sent.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce
Open the Code tab and give Claude something that runs a tool for several seconds, for example a shell command that sleeps.
While that tool call is executing, type a message and press Cmd+Enter.
Observe the tool call is cancelled and the message is processed immediately, rather than being queued until the turn ends.
Reproduced repeatedly in one session, including against an in-flight Bash tool call, which is the clearest case: the tool was cancelled mid-execution.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.49585.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

3 Comments

vincent-caetano · 1 month ago

Same for me

Geek2017 · 1 month ago

any upodate on this same on w10

loganngarcia · 15 days ago

fixed?