claude-code - 💡(How to fix) Fix [FEATURE] Deferred Messages — Queue Input for End of Turn

Problem Statement

When Claude Code is mid-turn (thinking, calling tools, writing code), the only way to send a message is as an interrupt — it gets injected at the next tool boundary and changes the trajectory of the current task.

This creates a tension: you often think of the next thing you want while watching the current task execute, but you have no way to queue it without derailing what's in progress. The options today are:

1. Interrupt now — risks confusing the current task, especially if the injected message is unrelated to what Claude is actively doing.
2. Wait and remember — sit idle until the turn ends, then type it. Easy to forget, breaks flow, and wastes the dead time where you could have been composing your next instruction.
3. Stash it externally — copy it to a notepad or scratchpad. Friction-heavy workaround for something the tool should handle natively.

There's a meaningful UX gap between "inject this immediately" and "send this when you're done." The interrupt model assumes every mid-turn message is urgent and contextual to the current step — but often it's just "here's what I want next."

Proposed Solution

Core: Deferred Messages

Introduce a deferred message — a message composed mid-turn that queues and fires only at end of turn, not at the next tool boundary.

Behavior:

• While Claude is mid-turn, the user composes a message and marks it as deferred.
• The message is held in a queue, invisible to Claude until the current turn fully resolves.
• Once the turn ends (Claude yields back to the user), the deferred message automatically fires as the next user turn — as if the user had typed it fresh at the prompt.
• If the user cancels the deferral before end of turn, the message is discarded (or returned to the input buffer for editing).

This preserves the interrupt model for urgent mid-turn corrections while adding a clean "I'll deal with this next" lane.

Input Affordance

The user needs a clear, low-friction way to mark a message as deferred vs. an interrupt. Several options (not mutually exclusive):

• /defer prefix — Type /defer <message> to queue it. Simple, discoverable, consistent with the existing slash command vocabulary.
• Keyboard shortcut — Ctrl+D (or another binding) toggles the current input between "interrupt" and "deferred" mode before sending. A visual indicator in the input area confirms which mode is active.
• Extend the existing stash system — The stash already handles "I typed something but don't want to send it right now." Deferred messages are a natural extension: instead of stash = discard, add stash-to-end-of-turn as a second destination. This could unify the interrupt/defer/stash concepts into one coherent input queue system:
  • Send (Enter) → interrupt (current behavior)
  • Defer (Ctrl+D or /defer) → queue for end of turn
  • Stash (Escape) → save for later, manual recall

Queue Visibility and Management

Once a message is deferred, it shouldn't vanish into a black box. The user needs:

• Persistent visual indicator — A badge, status bar element, or subtle banner showing that a deferred message is queued (e.g., ⏳ 1 deferred message). This prevents the "did I actually queue that?" uncertainty.
• Preview/inspect — Ability to view the queued message content without firing it.
• Edit — Modify the deferred message before it fires. The current task's output might change what you want to say.
• Cancel — Remove the deferred message from the queue entirely.
• Promote to interrupt — If you change your mind and decide the message is urgent, promote it from deferred to immediate interrupt without retyping.

Transition Pause

When the current turn ends and a deferred message is about to fire, provide a brief transition window (2-3 seconds, or until the user presses a key) with a visual indicator like:

✓ Turn complete.
⏳ Deferred message firing in 3s... [Enter] to fire now · [Esc] to cancel

This lets the user read the output of the completed turn and decide whether the deferred message still makes sense given the result. Without this pause, the deferred message fires blindly and might be stale or wrong.

Alternative Solutions

Current workarounds and why they fall short:

• Interrupting — Works for urgent corrections but is a blunt instrument. Mid-turn injections can confuse multi-step tasks, and there's no way to say "this isn't urgent, just queue it."
• Waiting — The simplest workaround, but it wastes the user's time and relies on memory. On long-running turns, you might forget what you wanted to say or lose the precise phrasing.
• External notepad — Copy-paste from a text editor works but adds friction and context switches. The tool should handle its own input queue.
• Stashing — The stash system gets halfway there (saves input for later) but requires manual recall and doesn't have a "fire at end of turn" destination.

Priority

High — Significant impact on productivity

This affects every session where Claude runs multi-step tasks. The longer the turn, the more valuable deferral becomes — and turns are getting longer as Claude handles more complex work autonomously.

Feature Category

Interactive mode (TUI)

Use Case Example

Scenario: Multi-step refactor with a follow-up task

1. You ask Claude to refactor an authentication module — a multi-step task involving reading files, planning, and editing across several files.
2. While watching Claude work through the refactor (3-4 minutes in), you realize you also want it to update the tests for the refactored module.
3. Today: You either interrupt (risking confusion mid-refactor) or try to remember "update the tests" for 5+ minutes until Claude finishes.
4. With deferred messages: You type /defer Now update the test suite to match the refactored auth module and keep watching. The message queues silently. Claude finishes the refactor cleanly, the transition pause appears, you confirm, and Claude picks up the test update with full context of what just changed.

Scenario: Course correction that isn't urgent

1. Claude is mid-turn implementing a feature. You notice it chose approach A, but you'd prefer approach B — however, approach A will still work and you don't want to interrupt the flow.
2. You defer a message: /defer For the next iteration, let's switch to approach B because [reason].
3. Claude finishes the current implementation cleanly, then picks up your preference for the next pass.

Additional Context

Compaction Resilience

Deferred messages should survive context compaction. If Claude hits context limits mid-turn and compresses the conversation, the deferred queue must be preserved independently — it's user intent that hasn't been acted on yet. Losing it silently would break trust in the feature.

Suggested Companion QoL (worth shipping together)

These small additions would round out the feature and prevent immediate follow-up requests:

• Deferred message count in the status bar — Wherever Claude Code shows session state (model, mode, token count), include the deferred queue count. Zero-cost awareness.
• Hook event: deferred-message-fire — Emit a hook event when a deferred message is about to fire. This lets users with custom hooks (sound effects, notifications, logging) react to the transition. Consistent with the existing hook model.
• /defer --list — Quick way to inspect the queue from the input line without a separate UI panel. Lightweight and consistent with CLI conventions.
• Keyboard shortcut to recall last deferred message — If you cancel a deferred message during the transition pause, a shortcut (e.g., Ctrl+Shift+D) to pull it back into the input buffer. Prevents "I canceled but actually I want it back."

Prior Art

• Terminal multiplexers (tmux, screen) have paste buffers and command queues — but no concept of "deferred to end of current process."
• IDE task runners (VS Code) let you queue tasks in sequence, but that's task-level, not conversational.
• Chat apps (Slack) have scheduled messages — similar concept (compose now, deliver later) but time-based rather than event-based.

The deferred message concept is most analogous to email scheduling (compose now, send later) applied to an interactive agent loop — except the trigger is "agent yields" rather than a clock time.