Reporting a cross-tenant / cross-user session bleed from:
$ cursor-agent --version
2026.07.01-777f564
I am working on a Linux system, on a Rust project working in US English. Agent received continuation context from another users macOS Development Session (/Users/pcy), in Chinese, for a PHP SEO Project.
I do not have data sharing enabled, but I have a conversation ID available if needed, but I would prefer to reply privately via email.
Good to confirm: this was your own private session, not anyone else’s. There was no cross-user or data leak, and your context stayed isolated to your account. What you saw was the model generating unrelated content (a hallucination), not real data from another user. It’s a known generation-quality behavior and we’re actively working to reduce it.
Please try a different model and let us know if you still get the same results.
If it happens again, feel free to send over the conversation ID and I’ll take a closer look. It helps to disable privacy mode if possible before re-creating the scenario. Here’s how you can do that:
To disable Privacy Mode:
Open Cursor Settings with Cmd+Shift+J on macOS or Ctrl+Shift+J on Windows/Linux.
Go to General.
Turn Privacy Mode off / switch to Share Data.
To get the Request ID:
Open the relevant conversation in the Chat sidebar.
I have the same issue. I see the prompts of other people. When the task is finished, I see a summary of other people’s projects. When I give a prompt. It starts working on other projects. It even modified my remote repo without asking
How do you really know? I mean, you didn’t see what I saw, I just briefly summarized the behavior. I know that’s kind of the stock reply you give to people who make these reports, but this was extremely specific about someone else’s system and code base. Could it have been some model training data, sure, but it was quite detailed and long.
Reporting the issue here, after analysis, is what the same model told me to do. I did interrogate the model within the session about this:
What makes “only hallucination” less convincing
Some details are oddly specific for pure invention:
• A concrete Mac username: /Users/pcy/… (not /Users/REDACTED/ or a generic placeholder).
• A coherent alternate product story (chaowu-uniapp, chouchoule, box-stage.vue, Ichiban.php, grid row/col mapping from two figures).
• Several unrelated roots in one burst (/Users/pcy/…, iCloud 归档 path, d:\mchat-admin…).
Random drift usually produces vaguer junk; this read more like pasted-in context from somewhere else or a bad merge in a summary/handoff. I still can’t prove
which from here.
I understand why the level of detail made this feel like another person’s real project. We do stand by our earlier assessment: this was unrelated content generated by the model, not another user’s session or a cross-user data leak.
Models can sometimes generate highly specific names, paths, files, and coherent project narratives. That specificity can be unsettling, but it does not mean the content came from live customer data.
We still take the behavior seriously as a generation-quality issue. If you share the conversation ID privately, we can investigate the specific output further.
It seems like an illusion, we still need to check the entire tool_use entry. If this occurs after web_search, it’s possible that the code has confused the context; if this information was retrieved using the grep tool, that’s a major problem.
@Alphayellowcat thanks for looking at this more concretely. Here are some more details, to follow up with my emailed in transcript. I also disassembled store.db to capture historic Request ID’s from cursor-agent.
User prompt: “Get started on the next wave” (RFC 9112 HTTP conformance work on Linux - not PHP/UniApp)
Workspace: my local Rust repo on this machine
cursor-agent2026.07.01-777f564, Auto
No web_search in this incident
There is no web_search tool call in the exported transcript for lines 592–601 (or anywhere in the export I have). So this doesn’t look like search results getting merged into context.
Full tool_use chain (lines 592–601):
Legitimate work first:
Line
Tools
Target
592
Grep, Shell
my Rust conformance crate, cargo test
593
StrReplace
RFC 9112 validator / checklist files in my repo
594
Read
normalize.rs in my repo
Then an immediate pivot — no user message in between:
Chinese PHP/UniApp design doc (Ichiban.php, BoxLocationQuery, etc.)
On grep
The only Grep in the incident window that touches foreign material is line 599 — and it searches a path the model had already introduced. It is not how /Users/pcy or chaowu-uniapp first appeared.
The earlier Grep (line 592) was scoped to my repo only.
None of the /Users/pcy/… or d:\\… paths exist on my Linux host; those tool calls failed locally. So this wasn’t “grep returned another user’s file contents” — but the model did emit those paths as tool inputs under a parent request I didn’t use to ask for foreign work.
Haven’t gotten a ticket reference for the forum side of this from you.
I have gotten one from [email protected] that precedes your new ticket creation, but no activity or information.
I also was directed to [email protected], forwarded them the information, no additional details were requested, and I was told I would get an acknowledgement from them within the 5 business day commitment, but did not.