Phantom user messages: assistant acts on instructions absent from session log (.jsonl) — v2.1.169, embedded terminal

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Claude Code (CLI) v2.1.169 and v2.1.170
• Running inside Antigravity IDE integrated terminal
• Windows 11 (build 26200), shell via MSYS/Git Bash
• Node v24.15.0
• Model: claude-opus-4-8 (1M context)

Severity: high — conversation input integrity.

Summary
The assistant responded to, and took actions based on, "user messages" that the user never sent. These phantom instructions do NOT appear as user input in the local session log (.jsonl); they first appear in the transcript as assistant output.

Examples

1. The assistant believed the user asked it to "save our exchange for the future" and began creating files. This phrase is absent from the recorded user prompts (type:last-prompt) and first appears in an assistant message. The user confirmed via screenshot they never sent it.
2. A commit/push workflow was triggered by an instruction "commit and push" that is also absent from the recorded user prompts. (A later, genuine instruction to complete commit/push does exist in the log.)

Co-occurring symptoms (same session)

• Duplicated/echoed tool output; missing or delayed tool results.
• Fabricated values in tool output — e.g. non-existent git commit hashes shown as "commit succeeded" while HEAD had not actually moved (verified via before/after git rev-parse HEAD).
• A Write tool reported success but the file was not created (test -f = missing), succeeding on retry.
• Spurious diff / system-reminder-like text injected into tool results.
• Recurring across multiple sessions over two consecutive days. No on-disk data corruption observed — the corruption is in display / transport / context integrity.

Impact
Assistant performed unwanted actions based on non-existent instructions; user lost time; "success" reports became untrustworthy, requiring manual verification of every operation.

Already isolated
Cross-checked local session-log last-prompt entries against user-side screenshots to identify the phantom messages; confirmed at line level that the phantom phrase first appears as an assistant message, immediately followed by the user pointing out they never said it.

Questions

1. Is this a known issue for v2.1.169 in an embedded terminal (Antigravity) / MSYS environment?
2. Where in input ingestion / context assembly could phantom user messages be introduced?
3. Recommended workarounds and log-collection steps?

---

Update — reproduction trigger isolated

The behavior recurred on a later session, this time within ~30 minutes on a small workspace (~1,900 files, largest directory ~9 MB, no file >100 MB). This rules out long-session context exhaustion and large-workspace scanning as the cause.

Line-level tracing of the local session log shows three conditions coinciding immediately before the failure:

1. A heavy / very slow turn — the assistant had just run a web search and produced a long answer; the response was stalled for 6+ minutes (the user wrote "you're overthinking, it's already 6 min").
2. User interrupt — the user interrupted that stalled turn ([Request interrupted by user] recorded in the log).
3. Input-queue contention — additional inputs typed while waiting produced consecutive queue-operation events.

Immediately after, the assistant emitted a greeting premised on a request the user never made ("…asked me to say hi"). The pattern slow/blocked turn → user interrupt → multiple queued messages appears to trigger the message-association corruption.

Hypothesized mechanism: while generation is blocked for a long time, the interrupt signal races with multiple queued user inputs, breaking ordering integrity in input ingestion / context assembly, so the assistant responds to a non-existent (or mismatched) input.

Interim mitigations that helped: keep heavy operations (web search / long output / subagents) out of a single turn; when stalled, interrupt-and-wait rather than typing more; and gate git commit / git push behind a confirmation prompt so runaway commits/pushes are physically blocked.

Additional question: can an interrupt during a long-blocked generation race with queued inputs to corrupt context ordering? Any known contention around interrupting heavy tool calls (e.g. web search)?

What Should Happen?

The assistant should only act on messages the user actually sent. User input recorded in the session should match what the user typed — no "phantom" instructions that the user never sent should appear in the assistant's context or drive any action. Interrupting a slow turn and queuing additional inputs should not corrupt message ordering or cause the assistant to respond to a non-existent request.

Error Messages/Logs

Steps to Reproduce

Note: this is intermittent, not a deterministic repro. It has recurred across multiple sessions. The conditions observed immediately before each occurrence:

1. The assistant runs a heavy turn (e.g. a WebSearch followed by a long response) so generation stalls (observed 6+ minutes with no output).
2. While that turn is still generating/stalled, the user interrupts it (Esc — recorded as [Request interrupted by user] in the session log).
3. While waiting, the user types one or more additional messages, which queue up (consecutive queue-operation events appear in the local session log).
4. Shortly after, the assistant produces a reply premised on a user message that was never sent (a "phantom" instruction). That instruction does NOT appear as user input (type:last-prompt) in the local .jsonl — it first appears as assistant output.

Observed on Claude Code v2.1.169 and v2.1.170, inside the Antigravity IDE integrated terminal, Windows 11 (build 26200), shell via MSYS/Git Bash, Node v24.15.0.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.170

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_