[Feature Request] Desktop app: messages typed during active agent turn should interrupt or be configurable, not silently queue

Resolved 💬 2 comments Opened Jun 10, 2026 by jsolly Closed Jun 14, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

In the Claude Code CLI, submitting a new message while the agent is actively running interrupts the current turn (or at minimum, Escape gives a non-queuing escape hatch). The user is always in control of the turn boundary.

In the Claude desktop app (local code sessions / Epitaxy), messages typed while the agent is working are silently queued and delivered only after the current turn completes. There is no interrupt path from the input box — the user cannot redirect, correct, or stop the agent through the normal message input while it is running.

This creates a meaningful UX regression when switching between the CLI and the desktop app for Claude Code sessions.

Expected Behavior

At minimum: parity with the CLI — typing and submitting a message mid-turn should interrupt the current run (same as pressing Escape + sending a new message in the CLI).

Ideally: a user preference controlling whether mid-turn input interrupts immediately or queues.

Current Behavior

Messages submitted while the agent is running in the desktop app are buffered and delivered at the next turn boundary. The only workaround is:

  1. Press Escape to stop the current run
  2. Wait for it to stop
  3. Then send the new message

This two-step process is awkward and not discoverable, and it loses whatever work was in flight.

Steps to Reproduce

  1. Open a local code session in the Claude desktop app
  2. Give Claude a multi-step task (e.g. read and edit several files)
  3. While Claude is actively running tool calls, type a new message and press Enter
  4. Observe: the message is silently queued, not delivered until the turn ends

Expected: the running turn is interrupted and the new message is processed

Environment

  • Platform: macOS
  • App: Claude desktop (local code session)
  • Comparison: Claude Code CLI does not exhibit this queuing behavior

Additional Context

The CLI's interrupt loop reads stdin continuously as a process-level concern. The desktop app's Electron UI queues input at the UI layer with no channel back to the running agent turn. This is not configurable via claude_desktop_config.json, ~/.claude/settings.json, or any exposed preference surface.

Related (but distinct — that issue is about non-destructive steering within the CLI, not the desktop/CLI gap): #30492

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗