anthropics / anthropics/claude-code
[FEATURE] Let $.prompt.submit request "next" priority so a plugin can reach a running turn
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 147k
- Forks
- 24k
- PR merge metrics
- PR metrics pending
Description
Preflight Checklist
- I have searched existing requests and this feature hasn't been requested yet
- This is a single feature request (not multiple features)
- 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
contextfrom atool.callhook. 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.
- The person asks for a refactor. The agent starts a long turn: reads files, edits several, runs commands.
- 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.
- 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.
- 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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the plugin-facing $.prompt.submit entry point and trace how plugin prompts are queued, comparing it with the existing person-input path that uses next priority. Done means plugins can request priority: 'next' while the default remains 'later', with the prompt reaching the next tool boundary during a running turn; consider the stated allowlist, capability, or tier gating options.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli, developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100