Queued/interrupted input consumed mid-turn as a phantom instruction (v2.1.205, VSCode)

Bug report: queued input consumed mid-turn as a "ghost" instruction the user never issued

Environment

• Claude Code version: 2.1.205
• Entrypoint: VSCode extension (claude-vscode)
• Platform: macOS (Darwin 25.x)
• Mode: a long-running assistant turn (a multi-step code task) was in progress when the issue occurred.

Summary

During a single assistant turn, an instruction that I (the user) never typed —
referencing a file app.py that does not exist anywhere in my project — was acted on
by the assistant. It ran shell commands searching for app.py and answered about it,
even though no corresponding user prompt for that instruction exists in the session log.
My next actual prompt (asking "who said this? I never wrote that") only arrived
~3 minutes later. This looks like a queued/interrupted input being consumed inside the
previous turn without being recorded as its own user message, producing a phantom
instruction.

Evidence (from the local session .jsonl, timestamps UTC)

Neutral event timeline around the anomaly (content redacted; only record types/timestamps/prompt-ids shown):

idx  type              timestamp                  promptId
306  assistant         20:34:44.607Z              None      (still the previous request "R1")
307  assistant         20:34:46.332Z              None
308  user(tool_result) 20:34:50.931Z              R1
309  assistant         20:34:56.109Z              None
310  assistant         20:35:08.498Z              None
311  user(tool_result) 20:35:10.327Z              R1
312  assistant(text)   20:35:30.984Z              None      <- final answer to request R1
313  assistant(think)  20:35:31.434Z              None
314  assistant(Bash)   20:35:33.003Z              None      <- searches for "app.py" (never asked)
315  user(tool_result) 20:35:33.098Z              R1        <- tool result still attributed to R1
316  assistant(text)   20:35:39.584Z              None      <- answers about app.py
317  queue-operation   20:38:30.532Z              None
318  queue-operation   20:38:30.533Z              None
319  system            20:35:39.707Z              None
320  user(text)        20:38:30.544Z              R2 (NEW)  <- my real next prompt: "who said this?"

Key points:

• The app.py shell search (314) and answer (316) descend, in the parent chain, directly

from the assistant's final answer (312) to the previous request R1. There is no user
message introducing an app.py instruction anywhere in that chain.

• The tool-results at 308/311/315 all carry request R1's promptId — i.e. the assistant kept

acting under R1's turn.

• The first genuinely new user promptId (R2) appears only at 320, ~3 min later, and is me

asking who issued the app.py message.

• queue-operation records appear at 317/318 (20:38:30), and there was an interrupt in the

same window.

• The string app.py appears in only this one session file out of all my sessions — so

this is not a cross-session/cross-user leak; it entered through my own local VSCode input
channel.

What it looked like to me (the user)

In the transcript I saw what appeared to be separate user turns:
@app.py 문제 있어? / [Request interrupted by user] / @app.py 이거 봐줄수 있어?…
— none of which I typed. When I asked the assistant "who said this?", forensic inspection of
the session log showed these were not recorded as my prompts; they were consumed inside
the prior turn.

Impact

• The assistant executed actions (shell commands) based on an instruction the user never gave.
• User-facing confusion / trust concern: it appears as if input was injected. (In my case it

stayed within my own local session — no data crossed sessions — but the "phantom instruction
executed mid-turn" behavior is the bug.)

Suspected cause

A queued input (possibly from an @file mention autocomplete, a stray paste, or an interrupt)
was flushed into the currently running turn instead of being registered as a new user
message, so the assistant treated it as an instruction to act on while attributing everything
to the previous request's promptId.

Repro (best-effort)

1. In the VSCode extension (v2.1.205), start a long multi-step assistant turn.
2. While it is running, queue an input (and/or use @file mention) and/or interrupt.
3. Observe whether the queued text gets consumed inside the running turn (no distinct user

promptId) rather than starting a new turn.

Ask

Please confirm whether queued/interrupted inputs can be consumed within an in-flight turn
without being registered as their own user message, and fix so queued inputs always start a
new, attributable user turn.