[FEATURE] Let $.prompt.submit request "next" priority so a plugin can reach a running turn

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)
• [x] I am on the latest version of Claude Code (2.1.278)

Problem Statement

A plugin cannot say anything to its session while a turn is running.

Verified on 2.1.278: every $.prompt.submit is queued at priority later, so it enters only once the current turn ends. A prompt the person types mid-turn is queued next and joins the running turn at the next tool result. (Probe: 60 submits issued during a 45 s tool call — none entered until the turn finished.)

This matters for any plugin that watches something outside the conversation and needs to tell the agent before it goes further: a test or typecheck watcher, a build or deploy that just failed, a monitoring alert, a bridge relaying the person's own message from a phone or a chat app, or another session in a multi-agent setup. All of these are useful in the first seconds of a long turn and close to worthless after it, once the agent has finished the work the message would have redirected.

Turns are exactly when this is needed. A turn can run for many minutes and dozens of tool calls, and that is precisely the window in which new information arrives and is worth acting on.

Proposed Solution

Let a plugin ask for the priority it needs:

$.prompt.submit({ text, priority: 'next' })   // joins the running turn
$.prompt.submit({ text })                     // unchanged default: 'later'

The delivery path already exists. The engine queues the person's own mid-turn input at next, and it already has mid-turn wording for plugin prompts: "The \<name\> plugin sent a message while you were working: … Address the message above as you continue this turn." What is missing is the plugin-facing option to request it.

Gating it would be entirely reasonable — a managed-settings allowlist, a plugin.json capability, or restricting it to a tier. The ask is a supported route, not unrestricted access. Keeping the existing framing on such prompts is right: it is what tells the model the prompt did not come from the person, and that matters more mid-turn, not less.

Alternative Solutions

• Wait for the turn to end (today's behaviour). Right for "FYI" messages, useless for anything meant to change what the agent is doing.
• Attach context from a tool.call hook. The one way in today, and the wrong shape for it: it only lands if a tool happens to run, it arrives as an invisible addendum to an unrelated tool's result rather than as a message, it means hooking every tool call to carry something unrelated to any of them, and the person sees nothing in the transcript explaining the change of course.
• Have the agent poll. It costs tool calls, the agent has to choose to do it, and it cannot help during work already under way.

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

A plugin watches the project's typecheck and tests in the background.

1. The person asks for a refactor. The agent starts a long turn: reads files, edits several, runs commands.
2. Two minutes in, the watcher sees that an edit the agent just made broke the build in a file the agent has not looked at.
3. Today the plugin can only queue that for after the turn. The agent keeps editing on a wrong assumption, and reads about it once the work is done.
4. With priority: 'next', the warning arrives at the agent's next tool boundary — the same place the person's own mid-turn message would — and the agent corrects course inside the turn.

The same shape covers a deploy that failed, an alert that fired, and a message the person sends from their phone through a bridge plugin: something outside the conversation changed, and the agent should hear about it before it continues.