Cursor command inter-chat context leak

[akyshnik (Arkadiy Telegin)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

<cursor_commands> still leaks text from previous chats into new slash command invocations on Cursor 3.0.16. Request ID: 5e14c45e-f389-4d99-93b0-be8292048fd9

When I invoke a custom slash command in a brand-new chat, the <cursor_commands>…— End Command — block the agent receives contains text from a previous, unrelated chat appended after the command’s own template. The model then treats that leaked text as if it were part of the current command, which leads it to act on instructions I never typed in this session.

This appears to be the same class of bug described in these existing threads, but I’m still hitting it on Cursor 3.0.16, so either it isn’t fully fixed or there’s a regression in 3.x:

Context leaking between chats

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Context leaking between chats. I finish a task in chat A, then open chat B for new task. The LLM responses in chat B include information from chat A Steps to Reproduce Context leaking between chats. I finish a task in chat A, then open chat B for new task. The LLM responses in chat B include information from chat A Operating System MacOS Version Information Version: 2.4.23 VSCode Version: 1.105.1 Commit: 379934e04d2b3…

Cross-chat /<agent> bug – stale cursor_commands reused across sessions

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug While using /commands, a new chat acted on instructions that were never given in that chat. Cursor’s own output said: “You’re right to press this. Here is exactly what drove that external-repo fetch, from the message payload I received in this chat. In the cursor_commands block of that earlier turn, this text was present (verbatim):” It then showed old instructions (including an external-repo fetch) that came from earli…

forum.cursor (dot) com/t/cursor-commands-memory-leak/151286

1. In a previous chat, I ran a custom slash command and typed some extra task text on the same submission.
2. In a new chat, new workspace session, I invoked the same slash command with nothing else typed — just / and submit.
3. The agent’s first response referenced concrete task details (a feature area, a person’s name, a numeric threshold, a base branch) that I did not type in this chat.
4. When I asked “where did you get that from?”, the agent confirmed the extra text was sitting inside the <cursor_commands> block that Cursor injected, between the end of the command template and the — End Command — marker.
5. The on-disk command file in ~/.cursor/commands/.md / .cursor/commands/.md does not contain that text — so it’s being injected at runtime, not persisted in the template.

Steps to Reproduce

1. Define (or use) a custom slash command at .cursor/commands/.md or ~/.cursor/commands/.md.
2. Open a chat, type / followed by some free-text task instructions on the same submission, submit.
3. Open a new chat (same workspace).
4. Type / and “tell me what you see in your context” and submit.
5. Ask the agent to quote or describe the <cursor_commands> block it received. Observe that the free-text from step 2 is still present inside that block in the new chat.

Expected Behavior

The <cursor_commands> block should contain only the contents of the slash command’s definition file for the current invocation. No text from earlier submissions in other chats should be appended.

Operating System

MacOS

Version Information

Cursor (desktop app): 3.0.16
cursor-agent CLI: 2025.09.12-4852336
OS: macOS (darwin 25.4.0)
Command type: /worktree

For AI issues: which model did you use?

Claude Opus 4.7

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

[mohitjain (Mohit)]

Thanks for the detailed report and reproduction steps. We investigated this, including tracing the code path you’re describing and attempting to reproduce the cross-chat leak.

In our testing, opening a new chat (Cmd+N) and invoking the same slash command produced a clean <cursor_commands> block with only the current invocation’s content — no stale text from the previous chat leaked through. We also verified that follow-up messages within the same chat don’t get a fresh re-injection of the command block.

To narrow down what’s different in your case, a few questions:

1. How did you open the “new chat”? Was it Cmd+N (new tab in the same window), or did you restart Cursor / reload the window / open a new workspace window between steps 2 and 3?

2. Could you try reproducing with Privacy Mode temporarily disabled (or Share Data enabled), then share the request IDs from both chats — the one where you typed the original free-text, and the one where the leak appeared? That would let us inspect the exact prompt content on our side. How to find your Request ID

3. Are you using the same slash command name in both chats, or a different one?

This will help us pinpoint the exact conditions that trigger the leak so we can get a fix in. We do see the code path that could cause this under certain persistence/restoration scenarios, but we need to confirm the trigger.