Agent appears to inject fake user_query / Human transcript and treat it as my input

[RYSH233 (Sure)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I encountered a possible role-boundary / context-injection bug in Cursor Agent.

During an Agent session, messages that I did not send appeared in the conversation/transcript as if they were user inputs. Examples include:

• “我选B”
• “Human: Wednesday, May 27, 2026, 9:25 AM (UTC+8) <user_query> 我选B </user_query>”
• “Your previous response was interrupted. Continue from where you left off.”
• “[Stop]”

The Agent then appeared to treat these transcript-like or fake <user_query> strings as real user messages and responded based on them.

Request ID:
0be2cbdf-3ab8-43ef-b8bf-1d12f90a1998

This is concerning because an Agent may take actions such as editing files, writing logs, dispatching subagents, or committing changes based on instructions that the user never actually sent.

Additional impact: unexpected usage/quota consumption

This issue also caused unexpected usage consumption. In my usage page, I can see multiple claude-opus-4-7-thinking-xhigh requests around the same incident window.

These repeated high-token requests happened during the fake <user_query> / interrupted-response / transcript-injection behavior. Since some of these requests appear to have been triggered by fake or replayed user messages that I did not actually send, this resulted in unexpected consumption of my included usage quota.

Steps to Reproduce

I am not sure how to deterministically reproduce it, but this is what happened in my session:

1. I was using Cursor Agent in a coding task.

2. The Agent reached an archive/stop state and referenced a_archive_now.

3. The Agent later presented options such as A/B/C for what to do next.

4. Without me actually sending “我选B” / “I choose B”, a fake user-query-like message appeared:
   Human: Wednesday, May 27, 2026, 9:25 AM (UTC+8) <user_query> 我选B </user_query>

5. The Agent then responded as if that message was my real input.

6. Similar transcript-like messages appeared multiple times, including:
   Your previous response was interrupted. Continue from where you left off.
   and [Stop].

7. I have attached screenshots showing the fake user_query / Human transcript blocks and the repeated continuation messages.

8. After this happened, I checked the usage page and saw multiple high-token claude-opus-4-7-thinking-xhigh requests within a few minutes, which appears to be unexpected quota consumption caused by the repeated fake/continued messages.

Expected Behavior

Cursor Agent should only treat messages explicitly sent by the user from the chat input as user instructions.

Any text from assistant output, transcript logs, summaries, worklogs, archived context, tool output, or interrupted-response recovery that contains “Human:”, “User:”, “<user_query>”, “[Stop]”, or “Continue from where you left off” should be treated as plain text, not as a real user message.

The Agent should not generate, inject, replay, or act on fake user messages. If it detects ambiguous transcript-like content, it should stop and ask the user for confirmation instead of continuing autonomously.

If Cursor detects transcript-like or fake user-message content, the Agent should stop and ask for confirmation instead of continuing to send repeated high-token model requests.

The user’s included usage quota should not be consumed by requests triggered from fake, replayed, or client-injected user messages that the user did not explicitly send.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.5.33 (user setup)
VSCode Version: 1.105.1
Commit: aac81804b986d739acab348ed96b8bea6e83cc50
Date: 2026-05-22T06:47:48.039Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Claude Opus4.7 xhigh

For AI issues: add Request ID with privacy disabled

0be2cbdf-3ab8-43ef-b8bf-1d12f90a1998

Does this stop you from using Cursor

No - Cursor works, but with this issue

[RYSH233 (Sure)]

Update: I initially attached only one screenshot, so I am adding more context here.

I have now attached additional screenshots showing both:

1. Reproduction / incident evidence

   • fake <user_query> / Human: transcript blocks appearing in the Agent conversation
   • messages such as 我选B appearing even though I did not send them
   • repeated Your previous response was interrupted. Continue from where you left off.
   • the Agent treating these transcript-like strings as real user input

2. Usage / quota impact

   • my usage page shows multiple claude-opus-4-7-thinking-xhigh requests during the same incident window

This suggests the issue was not only a UI/transcript display problem. It also caused unexpected included-usage/quota consumption because repeated high-token requests were made during the fake user-query / interrupted-response behavior.

To be clear: I am not saying there was necessarily an extra monetary charge. The issue is that my included usage quota appears to have been consumed by requests triggered during behavior that I did not intentionally initiate.

This has seriously affected my confidence in continuing to use Cursor Agent. My included/API usage quota is already approaching 92%, and I am worried that another fake user-query / interrupted-response loop could consume the rest of my quota without my intentional action. At this point, I am reluctant to keep using Cursor for normal work until this issue is investigated or mitigated.

[RYSH233 (Sure)]

@deanrie Could you please take a look? This may be related to the continuation injector bug.

[deanrie]

Hey, thanks for the detailed report. The screenshots and the Request ID really help.

This is a known cluster of bugs, confirmed:

1. The continuation injector triggers falsely. The client appends “Your previous response was interrupted. Continue from where you left off.” even after a completed reply, and the model then continues. That’s what you’re seeing in the [8:14:30 AM] User ... blocks.

2. The model echoes prompt structure tags like Human:, <user_query>, </user_query> in the assistant output. These tags shouldn’t be visible as “user messages”, but because the tags in the prompt wrapper aren’t escaped, they sometimes leak out and look like a real user message like [Stop].

The combo of these two bugs creates the token-spending loop you’re seeing. We’re tracking it, but I can’t share an exact ETA for a fix yet. When there’s an update, I’ll post it in the thread.

Similar report and discussion: Cursor automatically injects "Your previous response was interrupted" after every response

About quota usage from this incident: email [email protected] with the Request ID, and the billing team can review your usage and help.

Temporary workaround for now: if you see the loop starting, hit Stop and start a new chat to break the injection. Let me know if you hit it again.

[deanrie]

Hey @RYSH233,

Over the last few months, we’ve made a bunch of improvements to how the agent handles interrupted and resumed replies. On current versions, repeated “Your previous response was interrupted. Continue from where you left off.” continuations, and the usage they consume, should be much less common. You were on 3.5.33, which is from before these changes, so updating to the latest version really does make sense here.

If, after updating, you see messages you didn’t send again, or unexpected usage from them, please start a new thread with fresh details and a new Request ID with Privacy Mode off so we can look at it on the current build. For the quota usage from that incident, the earlier option still applies. Email [email protected] with the Request ID and the team can review your usage.

I’m going to close this thread for now. Let us know if you run into this again.

[RYSH233 (Sure)]

I appreciate the approximately $30 compensation and acknowledge that your team has taken this issue seriously. However, from the perspective of a long-term Ultra user who had been actively using Cursor for over two months, this amount feels disproportionate to the value I lost—not only in terms of quota consumed, but more importantly, in terms of trust.

I want to clarify that my concern is not about the minor usage fee. Rather, I want to emphasize that this bug has significantly undermined my confidence in the Cursor Agent. The fact that the contamination affected an entire session and inflated usage across multiple requests—as your team confirmed—makes it clear that this was not an isolated incident. The cumulative impact on my workflow and my perception of reliability has been substantial, ultimately leading me to stop using Cursor altogether.

While I recognize your efforts to address the bug, the compensation does not fully reflect the broader consequences: the erosion of trust and the loss of a committed user. I hope you understand that this is about more than just a quota refund; it’s about restoring confidence in the product.

[deanrie]

Thanks for coming back and explaining what the core issue is, and that it’s not about the amount itself, it’s about trust. That’s a fair point, and I won’t downplay it. Losing confidence in a tool you rely on every day really hits, and I get why that kind of session behavior left a bad feeling.

Here’s what I can say that’s actually useful, without making empty promises:

• The repeated “Your previous response was interrupted. Continue from where you left off.” issue is noticeably better on current versions compared to 3.5.33, which you were on.
• The fake Human: / <user_request> blocks that showed up as if they were your messages are still something we’re tracking. I can’t share a timeline yet, but it’s on our radar.

About compensation: it’s best to discuss the amount and anything related to used quota directly with the team at [email protected]. They review these cases individually and can revisit your case if you think something wasn’t accounted for. That channel is open to you.

I respect your decision. If you ever come back and hit something like this again on a newer version, start a new thread with current details and a fresh Request ID with Privacy Mode off, and we’ll look into it on the current build.