Preflight Checklist

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

Problem Statement

When Claude Code is actively executing a multi-step task (running tools, editing files, etc.), users often type short frustrated messages like "wtf", "hurry up", or "are you even working??" — these get queued and later processed as real tasks, cluttering the conversation and breaking flow.

There is currently no way for Claude to acknowledge or respond to queued messages while actively working. When Claude finally processes them, it either treats them as real instructions (derailing the task) or provides an unnecessary status update (wasting tokens and time).

I built a plugin (claude-vent-mode) that attempts to solve this using UserPromptSubmit hooks + skills to detect frustrated messages and respond with humour. The detection works correctly, but the response can't fire during active tool execution — queued messages only get processed after the current tool chain completes, making the side-channel response impossible with the current architecture.

Proposed Solution

[FEATURE] Side-channel responses for queued messages during active task execution

Summary

When Claude Code is actively executing a multi-step task (running tools, editing files, etc.), users often type short frustrated messages like "wtf", "hurry up", or "are you even working??" — these get queued and later processed as real tasks, cluttering the conversation and breaking flow.

Proposal: Add a lightweight side-channel response mechanism that allows Claude to respond to queued messages during active task execution — without interrupting the current work.

The Problem

1. User gives Claude a complex task (e.g., "refactor this codebase to TypeScript")
2. Claude starts executing — running Bash, editing files, reading code
3. User gets impatient and types: "bruh", "wtf so slow", "are you even alive??"
4. These messages sit in the queue until the current tool chain finishes
5. When Claude finally processes them, it either:
   • Treats them as real instructions, derailing the task
   • Provides an unnecessary status update, wasting tokens and time

There is no way for Claude to acknowledge or respond to queued messages while actively working.

Proposed Solution

A new hook event or built-in mechanism that fires when a message is queued during active tool execution, allowing:

1. Classification — Is this a real instruction or just the user venting/reacting?
2. Side-channel response — A lightweight reply that appears in the UI without interrupting the active task
3. Continue working — The main task continues unaffected

Possible implementations:

Option A: New hook event QueuedMessage

{
  "QueuedMessage": [
    {
      "hooks": [
        {
          "type": "prompt",
          "prompt": "The user sent this while you're working: $ARGUMENTS. Is this a real task or frustration? If frustration, respond with a short witty quip. If real, return 'queue' to process normally."
        }
      ]
    }
  ]
}

Option B: UserPromptSubmit with an is_queued field
Add an is_queued: true flag to the UserPromptSubmit hook input when the message was submitted during active execution. This lets hooks differentiate between regular prompts and queued-while-busy messages.

Option C: Built-in side-channel UI
A separate lightweight response area in the terminal UI (or inline) where Claude can drop a short acknowledgment without it being part of the main conversation thread.

Why This Matters

• Developer experience — Waiting for AI is frustrating. A witty acknowledgment turns a negative moment into a positive one
• Conversation quality — Prevents frustrated messages from polluting the task context
• Token efficiency — A short quip costs far less than Claude derailing to address "bruh" as a real instruction
• Real demand — I built a plugin ([claude-vent-mode](https://github.com/Ramesh-Giri/claude-vent-mode)) that attempts this with UserPromptSubmit hooks + skills. The detection works, but the response can't fire during active tool execution due to the current architecture

What I've Tried

I built and published a plugin that:

• Uses a UserPromptSubmit hook with a bash classifier script to score messages on frustration indicators (keywords, length, punctuation, emojis)
• Injects additionalContext via hookSpecificOutput to instruct Claude to respond with humor
• Uses a skill with autoActivate: true that teaches Claude vent detection and witty response patterns

Result: The hook fires and tags messages correctly, but Claude doesn't process queued messages until the current tool chain completes. By then, the task context dominates and Claude either ignores the vent tag or treats the message as a real instruction.

The plugin repo with full implementation: https://github.com/Ramesh-Giri/claude-vent-mode

Impact

This would enable an entire category of plugins:

• Vent mode — Humor responses to frustrated users
• Progress acknowledgment — "Got it, I'll handle that next" for real instructions
• Smart queue management — Classify and prioritize queued messages before processing
• User presence detection — Know when the user is actively watching vs. AFK

Environment

• Claude Code version: latest
• OS: macOS
• Plugin system: hooks, skills, slash commands all working correctly
• The limitation is specifically that queued messages cannot be responded to during active tool execution

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

No response

Additional Context

No response