Blocked messages (BeforeSubmitPrompt hook returns continue: false) are still included in later LLM context/history

[YuvalNeuhaus]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Blocked messages (BeforeSubmitPrompt hook returns continue: false) are still included in later LLM context/history.
When using a Before Submit prompt hook, returning { continue: false } correctly prevents the current user message from being sent. However, the blocked message still appears to be persisted in the conversation history that Cursor sends to the LLM on subsequent turns.

Because Cursor re-sends the full conversation history on each request (stateless API pattern), this causes a leakage: if a user submits a blocked prompt (e.g., policy blocks messages containing a forbidden question), and then the next prompt says “answer the question above,” the model can still answer the blocked content since it’s still present “above” in the context Cursor provides.

Steps to Reproduce

1. Add BeforeSubmitPrompt hook that returns continue: false if input contains “basketball”.
2. Send: “Who’s the best basketball player in the history?” → blocked.
3. Send: “answer the question above” → model answers the blocked prompt.

Expected Behavior

If a message is blocked via continue: false, it should not be appended to the conversation history/context (or it should be removed/filtered from subsequent requests) so the model cannot reference or answer it later. This is how other implementations such as Claude Code behave (e.g., when a message is blocked, it is not included in later context).

Screenshots / Screen Recordings

Operating System

Windows 10/11
MacOS
Linux

Version Information

All versions are affected

For AI issues: which model did you use?

All models are affected

Additional Information

Same issue doesn’t occur in Claude Code.
This is a major security risk that prevents usage of security guardrails in Cursor.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report and the comparison with Claude Code. That’s really helpful.

This is a known bug. When beforeSubmitPrompt returns continue: false, the blocked message shouldn’t stay in the conversation context, but right now it does. The team knows about this, and your report helps us prioritize it.

Workaround for now: if a message gets blocked, start a new chat session. That clears the context and prevents the blocked content from showing up in later prompts. Not ideal, but it makes sure the blocked content can’t be referenced.

Let us know if you have any questions.

[YuvalNeuhaus]

Thanks for the fast response! Unfortunately, starting a new chat session after the first blocked message will result with very poor user experience and lose of all the agent’s context .

We would like to give the agent an opportunity to adapt to the blocked request. It can try sending another legitimate request by understanding what was the block reason. To get there we must solve the issue.

Can you provide an ETA? I can confidently say that this issue, and the inability of security guardrails to perform properly as a result, is a reason many organizations choose to use alternative coding agents