Content pollution between concurrent chats

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I have a user who was working in two chats at the same time. In agent mode, version 3.1.15.

  1. In chat 1 they were working on work item 112967 and PR 122386
  2. They opened a new chat 2 and typed in /load-task-memory we have a failed build in PR 122386 (for context, /load-task-memory is a skill we have for loading previously recorded memory files)
  3. Before doing anything else in chat 2 (including activating the load-task-memory or doing any searching or lookups) the thinking mode thoughts revealed:

The user wants to:

  1. Load task memory for work item 112967
  2. Address a comment on PR 122380
  3. Investigate a failed build in PR 122386
    [more stuff]

So the user asked about PR 122386 in a chat, and the first thought of Cursor (opus-4.6-thinking) was to look up things for a work item and PR that was discussed a few minutes before IN A COMPLETELY DIFFERENT CHAT.

Steps to Reproduce

I cannot reproduce it at will, but it has happened to a bunch of users in my company in the last week. The description above is representative.

Expected Behavior

Chats are completely independent and Cursor will not pull in context from one chat to the other without permission, or if it does, needs to make it clear

Screenshots / Screen Recordings

SCR-20260430-jppg.png
SCR-20260430-jppg.png727×309 33 KB

Operating System

MacOS

Version Information

It happened on 3.3.15 for sure, not sure about every version for every user where it happened

For AI issues: which model did you use?

Opus 4.6 thinking

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hi @yaakov_fg,

I’ve explained why this may be happening here: Context is leaking between chats.

Our team is actively investigating and working on improving chat isolation. The most reliable workaround right now is to use separate Cursor windows for work streams you want to keep fully independent.

9

@mohitjain thanks for the reply. But as far as I can tell, Cursor doesn’t let you open up the same project root in multiple windows. And then there is a much bigger memory penalty for this - after all, we want all work streams to be fully independent - leakage at any point is unacceptable. But I cant tell my users to open up new windows for every single chat. Just not realistic.

10

Yaakov, that’s fair. I hear you on all three points.

To be direct: proper per-chat isolation within a single window is what needs to happen here, and our team is actively working on it. Right now, some workspace-level state (like recently viewed files, open tabs, and git status) is shared across all chat sessions in the same window by design. That shared state is likely what’s causing the model to reference context from other work streams.

To help us narrow down exactly which mechanism is causing the pollution your team is seeing, could you grab a Request ID from the next time it happens? In the chat pane, click the three dots at the top right and select Copy Request ID, then share it here. That would let us trace exactly what context was injected into that specific request.

We’ll follow up as improvements to chat isolation ship.

11

@mohitjain here is one: 709e27dd-3588-457a-867a-a5e16342f7ea

12

Thanks for sharing the Request ID. Unfortunately, your team has Privacy Mode enabled.

To help us investigate the x-chat-context injection you’re seeing, could you try the following?

  1. Temporarily switch to “Share Data” in Cursor Settings > Privacy (just for one test session)

  2. Reproduce the issue — start a new chat and note if unrelated context from another chat appears

  3. Copy the new Request ID from that session (three dots menu > Copy Request ID) and share it here

  4. You can switch back to Privacy Mode immediately after

This will let us see exactly what context was passed to the model, so we can confirm whether x-chat-context is behaving as expected or if something unexpected is happening.