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 executing a complex, multi-step workflow (pipelines, multi-file refactors, coordinated subagent work), the user has no way to steer the work mid-execution. Messages typed during processing are queued and delivered at the next turn boundary — by which point Claude may have completed significant work in the wrong direction.

The existing interrupt mechanism (Escape) is destructive: it discards in-progress work and forces a restart. What's missing is a non-destructive steering channel — a way to say "pivot to file X instead" or "skip the tests, focus on the implementation" without losing what's already been done.

Related issues address adjacent problems:

• [FEATURE] Side-channel responses for queued messages during active task execution #29224 addresses acknowledging queued messages (side-channel responses)
• [Feature Request] Add interrupt handling for stop words during agent processing #29490 addresses detecting stop-words to pause execution
• Queued messages get misinterpreted when user types during AI response #26388 addresses temporal misinterpretation of queued messages

This request addresses a different need: intentional mid-execution redirection — giving the user the ability to change the agent's course while it's working, without interrupting or restarting.

Why This Matters

As Claude Code is used for increasingly autonomous, longer-running workflows — agent teams, multi-step pipelines, large refactors — the gap between "fully autonomous" and "user-steerable" becomes a real problem. Users who delegate complex work need to be able to course-correct when they see the agent heading in a suboptimal direction. The current options are:

1. Wait until the turn completes (potentially minutes of wasted work)
2. Escape to interrupt (destructive — loses in-progress work)
3. Hope the queued message is interpreted correctly at the next boundary (unreliable per Queued messages get misinterpreted when user types during AI response #26388)

None of these support the natural collaboration pattern: "hey, I see what you're doing — shift your focus to this instead."

Proposed Solution

A priority message channel that delivers user messages to Claude between tool calls during active execution, rather than queuing them for the next turn boundary.

Core mechanism: Between tool calls (Read, Edit, Bash, etc.), Claude Code already runs PreToolUse hooks. A native priority message system could use this same interstitial window to deliver queued user messages as high-priority context, tagged so Claude recognizes them as steering input rather than conversational replies.

Possible implementation approaches:

1. Native priority injection: Messages typed during execution are tagged as [steering] and injected into Claude's context at the next tool call boundary (before the next PreToolUse hook fires), rather than waiting for the full turn to complete. Claude sees: [User steering message — typed during active execution]: "skip the tests, focus on implementation"

2. Explicit steering mode: A user-activated mode (e.g., /steer or a keybinding) that changes message delivery from queued to priority. When active, typed messages are delivered between tool calls. When inactive, normal queuing behavior applies.

3. Priority classification: Claude Code automatically classifies queued messages as "steering" (directional — "focus on X", "skip Y", "pivot to Z") vs. "conversational" (reactions, questions) and delivers steering messages with priority.

What this would look like for the user:

# Claude is actively running a multi-step refactor...

# User types (while Claude is working):
> Actually, start with the API layer, not the UI

# Instead of being queued until Claude's turn ends,
# the message is delivered at the next tool-call boundary.
# Claude sees it before its next Read/Edit/Bash call
# and adjusts course without losing completed work.

Workaround (Current)

It's possible to approximate this today using a PreToolUse wildcard hook that:

1. Checks a file for user messages on every tool call
2. Injects any contents as additionalContext
3. Clears the file after reading

Combined with a shell alias (steer "pivot to X"), this gives near-real-time steering during tool-heavy work. But it requires the user to write to a file from another terminal rather than typing naturally into Claude Code, and the hook overhead (however small) applies to every tool call in every session.

A native solution would be simpler, more natural (type into the same interface), and could handle edge cases the workaround can't (like delivering messages during the gap between a tool completing and the next generation starting).

Additional Context

This becomes increasingly important as agent teams and long-running autonomous workflows mature. The team lead pattern (where Claude coordinates multiple sub-agents) already provides partial steerability — the user can message the lead while teammates work. But the lead itself is unsteerable during its own processing turns. A priority message channel would close this gap entirely.

The fundamental insight: Claude Code already has interstitial windows between tool calls where context can be injected (PreToolUse hooks prove this). The feature request is to make those windows available for user messages natively.